A toolbox for a secure software supply chain
blog.chainguard.dev
blog.chainguard.dev
I recently saw a "supply chain attack" on a Web3 company[0] and it turned out it was a contractor pushing malicious code.
I've worked on "code provenance" professionally before[1] which is, apparently, a subset of "supply chain security". Specifically, I worked to help make sure that the code a dev committed was signed by their laptop, up through the CI, through the vuln scanners, and then the artifacts were verified before being deployed.
It was a lot of work and it is it's own entire field (which is what the OP article is talking about).
But now I'm also working on supply chain security[2] because I'm building tech to scan for vulns in dependencies (like NPM) by blocking known malicious packages or just enforcing security policies based on known vulns in them.
How they are all bucketed under the same term, I don't know, and it hurts my soul. We need some better terms for this stuff.
Anybody have any ideas?
0: https://ambcrypto.com/exec-issues-fbi-warning-as-sushiswaps-...
1: https://medium.com/uber-security-privacy/code-provenance-app...
To me it doesn't matter if code comes in through a vendor, a dependency or is written in house.
It's all well within the responsibility of the organization owning and deploying the artifacts.
While you can benefit from being a traitor then there is no way to secure any supply chain.
We need a new economics if we want to solve the tragedy of the commons (in this case w.r.t. bureaucracy).
Solution is to go the other way , you don't bloat your software with too many dependencies. That way you minimize your attack surface.
But what aspects? Is it just "I trust that and there's not much there, ok we're secure?" It's a little more complicated.
The stuff in the article is about leaving audit trails to verifiable identities taking known actions. To quote Ronald Reagan, tongue in cheek, "trust but verify."