This is gonna hit my organization hard I think.

I just learned from IT that the Guide dashboard reports that over the past 8 months we used roughly 10k tokens per month 🤕 No wonder we burnt through the free allotment within a day.

That's only US$200 a month, conservatively. That's trivial amount of $ compared to the effort of engineering around it.

If it's valuable to you, id be paying :)

Totally agree. The funding discussion is in full swing right now.

After day-burning down credits also I used -DossIndexAnalyzerEnabled=false. It helped, together with PAT auth. I guess this is kind of get rid of oss index with minimal code changes.

12.2.2 has the validForHours setting, now released, for what it's worth.

It's basically the only additional independent(*) vulnerability data source other than the NVD that ODC supports in a relatively ecosystem agnostic way - and with more specificity than the NVD because they track things at package level, not product.

https://github.com/dependency-check/DependencyCheck/blob/9acbb3392e13213eddb597fdfb11c76ad099160a/src/site/markdown/analyzers/index.md
https://github.com/dependency-check/DependencyCheck/blob/9acbb3392e13213eddb597fdfb11c76ad099160a/src/site/markdown/analyzers/oss-index-analyzer.md (docs recently updated a little bit, not yet published)

Only you can determine the value, as only you know which ecosystems you are using, how well ODC does at matching to packages, whether there are other analyzers you use that suffice (e.g Yarn/npm/pnpm analyzers giving you access to the npm subset of GHSA DB).

On top of that, you have to make your own judgment call as to Sonatype's "product" and the value of Sonatype security researcher assessment of CVEs. Guide may give you things other than the API access needed by ODC.

The NVD is slowly dying and will likely become increasingly risky as to ecosystem holes, unless it becomes a cleaner passthrough from GHSA. In my personal opinion its product orientation and custom CPE matching is already massively problematic and proven to be totally non scalable. Right now, ODC does not support GHSA or OSV.dev sources and thus Sonatype Guide / OSS Index is a way to get access to many of these even if NVD falls apart (as well as their own scoring).

The alternative is using different tools such as Trivy to get access to their otherwise commercial dataset (AquaSec VD), or commercial tools such as Snyk etc with their own aggregations and assessments of vuln severity, and their own approach to matching.

I don't make any personal assessment as to whether it's worth paying for, or how it compares to other commercial tools. Right now I am currently using ODC in unfunded open source project contexts to fill in many gaps from Github/dependabot - but I also use it alongside trivy which can scan container images that ODC cannot. if I had $ I'd choose a simpler setup all round with better tracking :)

(*) Not scored by the project/vendor themselves (supposedly, opinions vary on quality of Sonatype's work and matching)

Thanks for the insight, we're currently using trivy as well for scanning anything we have containerized (almost all of our portfolio at this point). To be honest, I work at a public university with a strong where we'd rather build and use open source rather than buy software whenever possible (it's both a mentality and funding thing). It just feels like I've been on my back foot this whole time trying to get our SCA and supply chain security analysis house in order ha

Yeah, public sector is a bit of a grey area. Funding can be a pain, especially when Sonatype Guide is not really a complete solution.

How many credits do you estimate you'd need per month? How quickly do you need to know about any new OSSinde x issues? How would that calculation look like if you could cache results for a week, or even longer (rather than 24 hours) as will be possible in the next version? Are there some types of scans for some teams/builds that OSS Index isn't worth spending the credits on?

Within a single scan, is there some configuration that'd be useful to say which components to check OSSindex for?

• I've been contemplating adding an ecosystem filter, but not sure if it'd be useful to many folks. (E.g only look on OSSIndex for maven but not npm, where people may find little added value above NPM audit API and would rather it does not consume credits)

Those are all good questions we are currently trying to answer. We've struggled so far getting scanning into every application/project within our portfolio because of growing pains, so it's hard to get a good idea of how many credits we'd need per month. I've finally got us into a decent place for asking/forcing all the teams to integrate our CI component into their pipelines so we can see what the real volume will look like. I think increased/customizable caching times would be beneficial.

As far as ecosystem filters, I think that is sounds like an interesting idea. I've only looked at the code surrounding the central/nexus analyzers so I'm not familiar with how the different JS package manager analyzers/audits are handled. The sheer volume of packages used in our node based projects (using a mix of npm, yarn, and pnpm for package management) is so much larger than what is seen on backend code (mostly a java house with mostly gradle builds). It's been a struggle to get teams to standardize on tooling, but as a member of our recently formed DevOps team I'm hoping to push the needle in the right direction there.

Again, I appreciate these discussions and am willing to help however I can.