One Ultimate Challenge in Software Supply Chain
⛓️

One Ultimate Challenge in Software Supply Chain

2021 - 2022 is when secure software supply chain (S3C) started trending, after events like SolarWinds exploit. Just in my life, some of my former coworkers left Google and started their own business focusing on S3C. Coincidently it’s also when I started working a lot more in the privacy and security space, from which I learned one ultimate challenge in S3C - to solve the trust issue across projects and organizations.
 
The best open reference is SLSA levels. Until level 3 the focus is on preserving highly trustful software provenance. This is also what most OSS tooling such as sigstore and S3C-focused companies strive to achieve in the last two years. When you hear buzz words like sbom, it’s all about that. But does “knowing where a software comes from and it’s not modified maliciously” equal to “the software is safe to use”? Not really!
 
What if the original code is problematic? Just look at the recent Zulily incident in which a former software engineer planted malicious code for a theft scheme. Unmodified malicious software is still malicious, no matter how high quality your sbom is. And the answer to this problem is a little cynical -trust no single person. The chance of two people committing evil is less than one person’s. Looking at the highest SLSA level - it “requires two-person review of all changes”. No unilateral changes.
 
Requiring two-person reviews in an organization is definitely doable. There could be company policies, code repo controls (e.g. GitHub branch protection) and audit logs. But in the “wild” OSS where many dependencies tend to be outside the control of your organization, is it still a solvable problem?
 
notion image
 
Remember this comic? The implication is not only about the potential stability issue of that dependency. Who do you think is doing the code reviews for that “random person in Nebraska” and make sure they have not turned evil? Probably no one. Even though you are now aware that this dependency is a potential risk, would you really start reviewing its code before every time you pull in a new version? And do the same for your dozens (if not hundreds) other dependencies? Meantime, you still have your real business to take care of… All in all, it seems to be a dilemma between either taking the risk of using a 3rd party dependency or bearing the burden of auditing it.
 
However, it’s not entirely hopeless. The basic solution, though not perfect, lays in the most common human social behaviors - follow the reputation and the crowd. It takes a lot of effort for organizations and individuals to build up a good reputation (and the profit coming along). The stake is too high and there is just too much to lose that they tend to do the due diligence to make sure things are done in the right way. Good reputation attracts crowd. The more people looking at something, the less chance that something would go wrong without being noticed.