▲ | Octoth0rpe 4 days ago | |
I agree with all of the problems that you're highlighting, but would say that all of those problems exist whether or you're doing manual dependency management or using a package manager. The solution IMO (which is non-existent afaik) would be to integrate some kind of third party auditing service into package managers. For example, for your npm project you could add something like this to your package.json: ` "requireAuditors": [ { "name": "microsoft-scanning-service", "url": "https://npmscanner.microsoft.com/scanner/", "api_key": "yourkeyhere, default to getting it from .env" } ] ` And when you npm install, the version / hash is posted to all of your required auditor's urls. npm should refuse to install any version that hasn't been audited. You can have multiple auditing services defined, maybe some of them paid/able to scan your own internal packages, etc. I've thought about building a PoC of this myself a couple of times because it's very much on my mind, but haven't spent any time on it and am not really positioned to advocate for such a service. | ||
▲ | wpollock 4 days ago | parent [-] | |
The Boost library went the audit route, but AFAIK, few other repositories (or libraries) have done that. I believe it's a cost and lack of manpower that prevents that. You may not have the time to audit dozens/hundreds of dependencies pulled into your projects, but there's still something you can do. For Rust/Cargo, you can run tools that check every dependency against a vulnerability list. As you have source of dependencies, you can also run static code analyzers/auditors to scan for code smells, lack of unit tests, etc. For Java, I use the OWASP plug-in of Maven to check dependencies for security vulnerabilities. I bet other languages' package managers/build tools have similar plug-ins. Some auditing is better than none at all. You shouldn't do no checking just because you can't full auditing! |