Consider supporting generic vulnerability scanners

[nscuro]

We currently support multiple sources of vulnerability intelligence, among them the NVD, OSS Index, GHSA and VulnDB. In some cases, we perform the actual vulnerability scanning (e.g. NVD, GHSA), in others this is done by the sources themselves (e.g. OSS Index).

There are more great scanning tools out there, like Aqua's Trivy or Anchore's Grype, that we could also integrate with. Trivy will soon support scanning of CycloneDX SBOMs (aquasecurity/trivy#2203), and it already supports VEX output (aquasecurity/trivy#1832).

Given most tools are intended to be invoked via CLI, integration with DT may require a thin web API layer that exposes the functionality via REST or gRPC.

Instead of hardcoding integrations in DT, we could allow for configuration of generic scanners that accept CycloneDX SBOMs and return CycloneDX VEX documents. Users could then decide to only rely on Trivy, or any other arbitrary combination of scanners.

Supporting tools like Trivy may also be beneficial for environments that are not supposed to have direct internet access (https://aquasecurity.github.io/trivy/v0.28.1/docs/advanced/air-gap/).

[nscuro]

More generally, this can be an architectural opportunity to decouple vulnerability detection from the API server. Even existing scanners like OSS Index could be decoupled in this way.

[tokcum]

I'm planning to use Trivy to generate SBOMs. Trivy can add the results of its own security vulnerability scan to the CycloneDX formated SBOM. However, when I import this SBOM file into DT only the components are imported. Vulns detected by Trivy don't make it into DT.

That's very unfortunate, as Trivy detected more vulns than DT. It would be great to see this happen. What does it take to push this issue forward?

[stevespringett]

@nscuro We need to think of a few different scenarios:

1. Import BOMs with embedded VDR (what this ticket is describing)
2. Import VDR BOMs (without component inventory)
3. Import Bill of Vulnerabilities

IMO, I think 1 and 3 will likely be the most used.

[Stamka]

I'm planning to use Trivy to generate SBOMs. Trivy can add the results of its own security vulnerability scan to the CycloneDX formated SBOM. However, when I import this SBOM file into DT only the components are imported. Vulns detected by Trivy don't make it into DT.

That's very unfortunate, as Trivy detected more vulns than DT. It would be great to see this happen. What does it take to push this issue forward?

Do you solve this problem?

[ashutoshvimal]

any update?

[xico42]

any update on this?

It is very unfotunate that DT cannot read vulnerabilities from trivy generated SBOM :/

[iamrahul127]

Hi @stevespringett / @nscuro,
I see that this ticket is closed but I am still hopeful. Is there any possibility that DT can provide functionality to process vulnerabilities detected by trivy?
My reflection is it will be helpful as DT not able to detect same issues for some reason. When I upload a BOM generated by trivy DT could only identify 11 issues where as trivy reported 68 issues.

[nscuro]

I see that this ticket is closed but I am still hopeful.

The issue is still open and implementation is definitely planned.

When I upload a BOM generated by trivy DT could only identify 11 issues where as trivy reported 68 issues.

While this is a separate issue, are you able to share the BOM in question so we can investigate why DT doesn't find as many vulnerabilities?

[iamrahul127]

The issue is still open and implementation is definitely planned.

Do you have any tentative release date?

While this is a separate issue, are you able to share the BOM in question so we can investigate why DT doesn't find as many vulnerabilities?

I think 783 is either same or related. BOM I have used is myserver.web.txt. Vulnerabilities from 'vulnerabilities' section of BOM are not processed even though they are present in vulnerabilities DB.
BOM screenshot for quick reference.

Audit tab of DT show following.

DT Configurations:

• Installation & Version: AKS & 4.8.2
• Analysers enabled: Internal & Sonatype OSS Index
• Internal analyzer: Fuzzy CPE matching is disabled.
• Vulnerabilities sources: NVD & Github Advisories

Let me know if you need any more details.

[apsdts]

While trivy support is highly appreciated - I will try it soon - what about the initial question?

We can already generate SBOMs with grype that include the results, but unfortunately dependency track does not consider them (which would be ok, if depednecy track would find the same issues like grype, which is not the case) .

Are there plans to investigate / support this BOMs (with scan results) somewhere in the future ?

[nscuro]

@apsdts Yes, what's described in this issue is still planned and #3251 is not a replacement for that.

[fnxpt]

Cant that be achieved with vex upload?

[nscuro]

@fnxpt DT currently only imports analyses from VEX for vulnerabilities that have already been identified. Importing vulnerabilities themselves does currently not work, for neither VEX nor VDR.

Ideally, importing a BOM with embedded VEX or VDR should:

• Import the inventory as stated in the BOM (components, dependency graph, etc.)
• Import the vulnerabilities included in the BOM
• Apply any analyses ("not affected", "exploitable", etc.) included in the BOM, which may lead to immediate suppression of findings

And all of this should be atomic.

[fnxpt]

I might be able to create a PR to support vulnerability importation from VEX

[iamrahul127]

@apsdts Yes, what's described in this issue is still planned and #3251 is not a replacement for that.

Our current plan is to run trivy in pipeline independently and upload SBOM generated to DT for further analysis. Trying to understand if we shouldn't be taking this approach and wait for #3251 and use integrated analyzer instead. Please help.

[fnxpt]

@iamrahul127 my 2 cents in this...
To me it looks like a completely different issue, one is having the possibility of importing the vulnerabilities using a file like a vex, the other one is having an additional analyser.
If you run a pipeline and import a vex file you will be able to add the vulnerabilities but even if the analyser runs it wont be able to detect them.
Ideally we should have both, I was on vacation last 2 weeks I will try to find some time to see if I can add support for vex import soon