3 ms·

These days it's always hard to say how much of the hype in areas like supply chain security is driven by the problem actually becoming worse and how much is due

These days it's always hard to say how much of the hype in areas like supply chain security is driven by the problem actually becoming worse and how much is due to VC funded startups with enormous marketing budgets that try to convince everyone of the nearing apocalypse (but no worries, their tools can save us). Looking at integrated vulnerability reporting as found e.g. in npm (and soon Golang, I think) it seems that 99 % of alerts are just false positives, as they affect build dependencies (e.g. the tar library) somewhere down the chain that will never run in production or even touch anything sensitive, and that cannot be easily exploited even by sophisticated actors. In my opinion the "high severity" threat category is thrown around way too lightly by these tools, which leads to everyone panicking. If anything good could come out of this whole trend it might be the realization that open-source software needs better funding to address supply chain issue, my expectation though is that most of the money will go to tool vendors that simple tape over the underlying problems by creating an artificial "security layer" between the maintainers and users.

UncleMeat 4y ago
The CVE landscape has been broken for ages. In a past life I did a lot of work on a bug bounty program and the amount of "I ran some simple tool that says CVE-XYZ is present in your codebase" reporting we received when the relevant code was either dead, ran in a trusted environment, or ran on trusted input was outrageous. Then people would whine about not getting paid. I do think that organizations should have a process for identifying and triaging bugs in dependencies. But "there are vulns in dependencies" is not itself a compelling narrative because there are vulns in your business' code too. And people sure as hell are getting updates more frequently when using npm or whatever then in the alternative world of "link in some open source code and never update ever for all time." To me, the more interesting problem is the "malicious actor takes over an npm account and distributes malware" that is more unique to the npm ecosystem. This one is hard. On the one hand developers are expensive and a robust library ecosystem is basically a superpower. On the other hand you really need a trust relationship with your software vendors if you want to be confident you are delivering safe code.

UncleMeat 4y ago

The CVE landscape has been broken for ages. In a past life I did a lot of work on a bug bounty program and the amount of "I ran some simple tool that says CVE-XYZ is present in your codebase" reporting we received when the relevant code was either dead, ran in a trusted environment, or ran on trusted input was outrageous. Then people would whine about not getting paid. I do think that organizations should have a process for identifying and triaging bugs in dependencies. But "there are vulns in dependencies" is not itself a compelling narrative because there are vulns in your business' code too. And people sure as hell are getting updates more frequently when using npm or whatever then in the alternative world of "link in some open source code and never update ever for all time." To me, the more interesting problem is the "malicious actor takes over an npm account and distributes malware" that is more unique to the npm ecosystem. This one is hard. On the one hand developers are expensive and a robust library ecosystem is basically a superpower. On the other hand you really need a trust relationship with your software vendors if you want to be confident you are delivering safe code.