OSS Index: Allow exclusion of components to scan

[nscuro]

Issue Type:

• defect report
• enhancement request

Current Behavior:

When using the OSS Index scanner, Dependency-Track will send the packageURLs of all components to OSS Index. This of course includes those of internal components. The namespace of a packageURL may contain the company's name, making it fairly easy to find out who's making the requests and what their application landscape may look like.

Someone with access to OSS Index's request logs may be able to find out how often a given project is built, how many vulnerable components it has and how quickly vulnerable components get patched. The main issue here is that we simply cannot know what Sonatype does with the data being sent to it.

Although I'm explicitly mentioning Sonatype's OSS Index here, I'm sure this also affects other scanners that work similarly.

Expected Behavior:

It should be possible to exclude information about specific components from being sent to external services like OSS Index.

It should be considered that new projects (so potentially new namespaces) will be added dynamically (e.g. through the Jenkins plugin), which is why I'm certain that a Regex or "namespace contains" type of exclusion list would be optimal. E.g.:

Exclude namespaces:

• ^com\.acme.*
• .*mycompanyname.*

Environment:

• Dependency-Track Version: 3.4.0

[stevespringett]

The same exclusions should likely apply to outdated component analysis

[nscuro]

Good point. Yes, they should.

[msymons]

This idea of implementing the idea of "teaching" Dependency-Track about internal components is pretty much the same enhancement that I had been thinking for a while "I really need to log this", although @nscuro identified a use case (preventing exposure of internal information) that I had not considered. Nice one!

1. The enhancement should reduce load and speed up overall analysis time. I have checked a couple of my projects and see figures such as "196 total dependencies in project... 42 of which are internal".

2. This enhancement would also (hopefully) address a problem I have seen where (very occasionally) internal components are incorrectly identified as having threats. At the risk of leaking a bit of my own internal information, DT v3.4.0 using OSS Index as the only enabled analyser is telling me that....

pkg:maven/uk.co.card.post/iQSim-SmartCard-Client@1.0.16?type=jar

..is vulnerable to:

• CVE-2011-5036
• CVE-2012-6109
• CVE-2015-3225

3. The enhancement might make it easier to perform tasks such as performing auditing to make sure that intenal components include licenses... although I think that this might need UI checkboxes to toggle what is displayed. ie, be able to display only internal components/dependencies. (Even if search filtering worked on the Group Column, filtering is not so effective if one has multiple internal groupID patterns).

4. Perhaps in future, the concept of "internal components" could be used to apply different policies when it comes to (say) tracking component age.

[nscuro]

I addressed this issue in PR #512. Because internal components are then known to Dependency-Track, @msymons suggestion 3 is potentially easy to implement as well.

[msymons]

Another justification for exclusion of components from scanning that may be applicable to VulnDB... MONEY!

In #443 , Steve wrote that "....as the (VulnDN) service may be licensed on the number of requests per month."

[stevespringett]

https://docs.dependencytrack.org/datasources/internal-components/

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.