WE ARE THINKING ABOUT THE SCOPE OF SUPPLY CHAIN SECURITY ALL WRONG
WE ARE THINKING ABOUT THE SCOPE OF SUPPLY CHAIN SECURITY ALL WRONG
As always please sign up for our weekly newsletter for additional commentary on articles and news of open source projects and public speaking.
There is an SBOM Frenzy. There is an investment frenzy in supply chain companies, almost all focused on SCA or Software Composition Analysis, betting on SBOMs being a catalyst for SCA adoption. I think there is a security tools crash coming, partially because the market is not big enough to support all the tools, and I bet SBOM companies will be at the sharp end.
What Steve Springette and the CycloneDX project realized a while ago, is that if you want to describe all of the things your application is dependent on, then it's far more than just the code. It's not an SBOM but a BOM, a Bill Of Materials that captures everything in the supply chain, both upstream, and downstream.
RedHat describes it quite well.
The supply chain includes networks of information about the software, like the components (e.g. infrastructure, hardware, operating systems (OS), cloud services, etc.), the people who wrote them, and the sources they come from, like registries, GitHub repositories, codebases, or other open source projects. It also includes any vulnerabilities that may negatively impact software security – and that’s where software supply chain security comes in.
Downstream from the code, we have things like operating systems, containers and hardware. Pro tip : watch the journalists that cover the hardware hacking space closely in the coming weeks and months. Upstream we have code repos, dependency registries and people. Yes, people, you know humans, often described as the weakest link. Who knows the people that created the code they are using, yet alone if they are foreign state actors or cyber criminals ? Imagine if someone tried to backdoor the Linux kernel, not once but repeatedly.
Imagine if a state controlled foreign adversary tried to backdoor a communications network used to send application traffic. We shamefully use Huawei gear today in the UK 5G network, although it will be removed by 2027. Imagine if your CI system was hacked like what happened to CircleCI. Imagine Github had an issue and someone was able to commit to the main branch (called something else back then) of a popular development framework at the time like Ruby on Rails. Imagine the source code of your identity provider was exposed. Imagine hackers deployed malicious code onto monitoring and management software used by thousands of enterprises and government agencies worldwide. I could go on for ages.
The elephant in the room for all of the current software supply chain security frenzy is that modern applications rely as much on online services as they do open source code. It is convenient to appsec tools vendors that appsec tools can parse code, build a dependency graph, build a call graph and look up vulnerabilities, but it's inconvenient for them to also discover things like the cloud resources and the third-party services being used. That requires another type of security tools, and yet another reason why I think the next generation of app sec tools will come from companies that combine cloudsec and appsec tools. They will offer their customers the ability to have their cake and eat it.
It’s also worth remembering that most breaches don’t come with a CVE and so a ‘clean’ SBOM and your application being ‘CVE free’ is really window dressing, unless you also know that the other parts of your software supply chain is ‘clean’ as well.
The modern supply chain is a game of dominoes. You can’t place a double six on the board and expect to win. Your stack will collapse.
Supply chain security is so much more than open source code and CVE’s.
This post can be found on LinkedIn for discussion and comments.
Share