How Software Supply Chain Security Differs from Normal Security
With normal security, the concern is primarily with malicious, external actors probing your software looking for direct exploits.
With software supply chain security, the concern is more about malicious actors exploiting backdoors in the creation of your software.
The terminology is different too. Whereas it makes sense to talk about "trust" in the context of normal security, that concept loses usefulness in the context of software supply chain security.
What to be Concerned about When it Comes to Software Supply Chain Security
There are 2 main areas to be concerned about
- Artifact Integrity
- Exfiltration
Artifact Integrity
Artifact integrity has to do with trying to make sure that the software that was delivered and/or is running in production is actually what was intended to be made.
An example of when this would fail is when a malicious actor is able to modify the source code used to build a container, including a backdoor that lets them collect sensitive user information.
Exfiltration
Exfiltration in this context is concerned with trying to make sure sensitive parts of the supply chains themselves aren't stolen (e.g. source code, build secrets).
An example of when this has happened is the CircleCI security incident from a few months ago, where all customer build secrets were compromised by a malicious actor.
How to Think About the Techniques That Address The Concerns
There are many techniques available to address these two concerns, but one helpful way to categorize them is how they impact the risks involved. The 3 most prominent categories are
- Risk Elimination
- Risk Mitigation
- Risk Awareness
Risk Elimination
These techniques eviscerate certain classes of risk altogether. For example,
- Signing all Git operations (e.g. commits, tags)
- Automating builds and running them in an isolated, ephemeral environment
The former prevents malicious actors from impersonating valid contributors.
The latter prevents any long-lived malicious software from living in the build environment.
Risk Mitigation
These techniques reduce the chances of certain classes of risk. For example,
- Peer review of code changes
- Using a dedicated build service
The former mitigates the case of 1 disgruntled employee trying to submit malicious code, but it does nothing for the case of 2 disgruntled employees colluding to submit malicious code.
The latter will generally improve the security of the secrets kept inside the build service. However, as the CircleCI incident showed, all build service platforms are still fallible when it comes to secrets exfiltration.
Risk Awareness
These techniques give you more insight into the risk profile of certain classes of risk. For example,
- Gathering all manifests (e.g. Software Bills of Material, SBOMs) of all of your dependencies
- Checking Reddit before updating a dependency in case there's a well-known compromise in flight
The former helps increase awareness of all the pieces comprising the software, as well as their individual security vulnerabilities (notice how this overlaps with normal security concerns).
The latter will help you become aware before merging a Dependabot dependency update PR that may contain malicious code.
Takeaways
Risk is the primitive to use when thinking about software supply chain security.
Thinking about the risk a technique or tool impacts can make it easier to reason about.
For more on this, including more practical examples, check out Part 2 of this series.
To take a deeper dive into the world of software supply chain security, check out https://slsa.dev/
Top comments (1)
The Crowdstrike outage made me realize there's a 3rd area of concern here, namely having your systems shut down or destroyed, temporarily or permanently. While maybe less common than the other 2, it's still something to take into consideration.