Ignore Development Dependencies in OSV scan

[aunovis-heidrich]

Is your feature request related to a problem? Please describe. I was scanning the widely used Rust crate reqwest, and scorecard reported 74 Vulnerabilities. Checking the detailed probe output revealed that these were all vulnerabilities concerning npm packages. I tried reproducing the result using syft and grype, but they found no vulnerabilties. As I learned later, that's because they ignore dev dependencies when generating an SBOM. The vulnerabilities all originated from a 4 years old example application.

I think displaying 74 npm vulnerabilities for a Rust crate is very misleading.

Describe the solution you'd like The OSV scanner supports a configuration file. Calling

osv-scanner.exe -r --config=osv-config.toml .

with the config file

[[PackageOverrides]]
group = "dev"
ignore = true

inside the cloned reqwest repo finds no vulnerabilities. I think scorecard should use this config when calling the scanner, if that is possible.

This is certainly a choice. I think the ideal solution is to offer the option to include dev dependencies in the scan, but in my opinion this should not be the default. I am also ok with not offering this option, as I personally don't require it.

Describe alternatives you've considered The alternative I see is to at least print more information in the default output than "74 Vulnerabilities detected". This approach is not very automation-friendly, though, and it won't correct the total score.

Additional context My standard disclaimer: Willing to help with the implementation if I get some pointers to the relevant code.

[spencerschrock]

I think scorecard should use this config when calling the scanner, if that is possible.

We do. If the repository being analyzed has one or more osv-scanner.toml files checked-in.

in terms of separating dev dependencies by default, I'm in favor if the osv-scanner library makes the distinction available to us. Technically this is a duplicate of #3604, but this has way more detail so I'll keep this one open.

We'd want to split hasOSVVulnerabilities into two probes. We can migrate the check to use the new probes, but hasOSVVulnerabilities is marked stable so we need to keep it around.

The alternative I see is to at least print more information in the default output than "74 Vulnerabilities detected".

I almost always recommend using --show-details.

If OSV makes these details available to us, it would be here in the Scorecard code: https://github.com/ossf/scorecard/blob/aaa7df86e0c583f36e4918f888bf762009430a61/clients/osv.go#L74-L94

[spencerschrock]

It looks like OSV field we have is DepGroups:

diff --git a/clients/osv.go b/clients/osv.go
index 76df68a5..6bce0705 100644
--- a/clients/osv.go
+++ b/clients/osv.go
@@ -18,6 +18,7 @@ import (
        "context"
        "errors"
        "fmt"
+       "log"
        "os"
        "runtime/debug"
 
@@ -75,6 +76,7 @@ func (v osvClient) ListUnfixedVulnerabilities(
        if errors.Is(err, osvscanner.VulnerabilitiesFoundErr) {
                vulns := res.Flatten()
                for i := range vulns {
+                       log.Println(vulns[i].DepGroups)
                        // ignore Go stdlib vulns. The go directive from the go.mod isn't a perfect metric
                        // of which version of Go will be used to build a project.
                        if vulns[i].Package.Ecosystem == "Go" && vulns[i].Package.Name == "stdlib" {

2025/03/08 11:36:25 [dev]
2025/03/08 11:36:25 [dev]
2025/03/08 11:36:25 [dev]
2025/03/08 11:36:25 [dev]
2025/03/08 11:36:25 [dev]
2025/03/08 11:36:25 [dev]
2025/03/08 11:36:25 [dev]
2025/03/08 11:36:25 [dev]
2025/03/08 11:36:25 [dev]
2025/03/08 11:36:25 [dev]
2025/03/08 11:36:25 [dev]
2025/03/08 11:36:25 [dev optional]

[aunovis-heidrich]

Uh nice, I like these solutions. I'll make a request in reqwest, then.

[rkg-mm]

I would highly appreciate this here, too. Going especially through NPM dependencies is a pain as I regularly see >60 vulnerabilities, but almost all from dev dependencies. Ideally I think would be 2 separate metrics: One for vulnerabilities in the actual package, and one for vulnerabilities in its dev-dependencies. But I can live with skipping dev dependencies too if too much effort or the tooling doesn't provide it.

[gcanlin]

Hi @rkg-mm! I'm not familiar with javascript. Could you please share your thought about why we often don't care the dev vulnerabilities? In my opinion, it seems that dev dependencies can also affect the resulting artifact.

[rkg-mm]

Hi @rkg-mm! I'm not familiar with javascript. Could you please share your thought about why we often don't care the dev vulnerabilities? In my opinion, it seems that dev dependencies can also affect the resulting artifact.

The dependencies do affect resulting artifacts but normally the vulnerabilities in them don't. There may be exceptions to this, but somewhere you need to make a trade-off for efficiency, or be able to distinguish the types of vulnerabilities and their usage (dev/production).

One example: Some days ago I checked an npm package. 2 direct productive dependencies, 15 direct dev dependencies. Scorecard shows 99 vulnerabilities - uff. 85 of them were ReDos vulnerabilities, some where XSS and a few others. A ReDos in a dev dependency doesn't matter at all - but I could not know if its from the 2 production or the 15 dev dependencies without going through all of them manually. Also the Xss should usually not matter if its in dev dependency. So here displaying the difference would help a lot.

[github-actions[bot]]

This issue has been marked stale because it has been open for 60 days with no activity.