A criterion for dependencies
David A. Wheeler
Daniel Stenberg:Perhaps this suggests a new criterion... In a quick look through all
Right, because our focus is here on a per-project basis.Exactly. Automatic dependency scanning is easy in some situations, and difficult/impractical in others, so I've resisted the idea of requiring it at the lowest "passing" level.
The idea has merit. We have *long* listed dependency checking for vulnerabilities as a potential criterion for the next-highest level. See: https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/other.md
Which has the following draft:
Dependencies (including embedded dependencies) are periodically checked for known vulnerabilities (using an origin analyzer, e.g., Sonatype, Black Duck, Codenomicon AppScan, OWASP Dependency-Check), and if they have known vulnerabilities, they are updated or verified as unexploitable. It is acceptable if the components' vulnerability cannot be exploited, but this analysis is difficult and it is sometimes easier to simply update or fix the part. Developers must periodically re-scan to look for newly found publicly known vulnerabilities in the components they use, since new vulnerabilities are continuously being discovered."
That text should probably start "Required dependencies..." not "Dependencies..."; optional dependencies and alternatives can be rough to handle.
Sometimes this is easy to meet:
* In a typical Ruby application, just run "bundler-audit", which examines the list of libraries used (in Gemfile.lock) and compares them against the list of known vulnerable versions in ruby-advisory-db.
* In a typical Java application using Maven, OWASP Dependency-Check is helpful.
But in many other cases it's difficult to do that analysis. A partial solution is to make sure your program builds & runs on a system that stays patched. But again, not so easy... which is why I don't think we can require this at the "passing" level.
--- David A. Wheeler