DependencyTrack / dependency-track

Dependency-Track is an intelligent Component Analysis platform that allows organizations to identify and reduce risk in the software supply chain.
https://dependencytrack.org/
Apache License 2.0
2.43k stars 529 forks source link

Consider supporting generic vulnerability scanners #1677

Open nscuro opened 2 years ago

nscuro commented 2 years ago

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 (https://github.com/aquasecurity/trivy/pull/2203), and it already supports VEX output (https://github.com/aquasecurity/trivy/pull/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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

any update?

xico42 commented 8 months ago

any update on this?

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

iamrahul127 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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.

image

Audit tab of DT show following. image

DT Configurations:

Let me know if you need any more details.

apsdts commented 6 months ago

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 commented 6 months ago

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

fnxpt commented 6 months ago

Cant that be achieved with vex upload?

nscuro commented 6 months ago

@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:

And all of this should be atomic.

fnxpt commented 6 months ago

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

iamrahul127 commented 5 months ago

@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 commented 5 months ago

@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