For many organizations, getting started on the road to software supply chain security is the most difficult step since it involves:

• Acknowledging that software supply chain issues have long existed, and are growing exponentially more threatening.
• Acknowledging that you may not have a culture within your organization that can even begin to tackle the problem at this point in time.

Most organizations would hesitate to characterize the way they work as “complete anarchy,” but that is typically what distinguishes the first stage (Stage 0) of the journey. Here, anarchy is really a double-edged sword, allowing organizations to exist on the basis of voluntary cooperation despite the disorder due to a lack of controlling systems.

Typical characteristics of organizations at Stage 0 include:

• Non-Standard Tooling – while there is agreement on shared tooling (such as the code repository, for example), every developer has their own set of preferred desktop tools.
• Lack of Standard Processes – code may or may not be peer reviewed; warnings are investigated (or not) irrespective of severity; libraries are updated (or not) depending on each developer’s need, and so on. 
• Lack of Governance – with no standards to apply, it’s pointless to introduce a governance layer to ensure processes are followed. 

While the above description may seem daunting, in practice, this way of working can actually be quite empowering, liberating everyone to be as creative as possible. But it also means that security is an afterthought, if it’s thought of at all. 

For example, when it comes to importing third-party, open source code:

• No scans are run against the imported code prior to use, opening wide the door to threats like known critical vulnerabilities being installed in dev, test and CI/CD environments.
• Binary packages are imported prebuilt from public repositories, rather than being built from vetted source code, potentially introducing compromised code to the codebase.
• Public repositories are implicitly trusted, despite the fact that they offer no guarantees as to the security and integrity of the packages they offer. This can be problematic because:
  • Open source repositories contain hundreds of thousands of packages created by tens of thousands of authors and maintainers, all of whom must be trusted.
  • Most public repositories have no gatekeepers, and only a limited set of safeguards (such as two-factor authentication). There’s simply nothing stopping anyone from uploading malware since their code will not be audited, independently reviewed, or even scanned in depth.

This reliance on prebuilt components typically means the only artifacts being generated by a build process are versions of the organization’s application/service. But a lack of standard processes and security safeguards can mean:

• Builds are created in a non-reproducible way, making it very difficult to verify issues from one build to the next.
• Build scripts can be modified at any point, providing a foothold for bad actors to compromise them and exploit the build system.
• Build environments for each step in the process are reused, increasing the chance they become corrupted or compromised. 
• The build system is connected to the Internet, potentially allowing dynamic packages to include remote, unexpected resources.
• Artifacts generated by the build process are unsigned, meaning there is no way to verify whether they have been compromised between the time they were built and the time they’re deployed.

Consequences of Poor Software Supply Chain Security

HIstorically, hackers have searched for needle-sized exploits in a worldwide haystack of corporations. All that changed in 2020 with the SolarWinds hack, which showed that one compromised development environment at a key software vendor can result in trojanized patches and software updates being propagated downstream to tens of thousands of customers. 

In other words, bad actors have discovered economies of scale: a single cyberattack against a popular software vendor can grant hackers access to corporations and governments around the globe in today’s internet-connected world.

Copycats soon followed, generating an average 742% increase in attacks over the past three years:

Source: ENISA Threat Landscape for Supply Chain Attacks

The problem is compounded because the breadth and depth of the software supply chain affords multiple points of entry for malicious actors who are always looking for the weakest link in the chain to exploit: 

• Breadth – most organizations work with multiple open source languages, and import their code from more than one public repository. Because there are no industry-wide standards in place today, each language and repository must be treated uniquely.
• Depth – There is a large set of best-practice application and system security & integrity controls that can help, but only the largest enterprises can hope to implement and maintain them all.
• Change – no supply chain is ever set in stone: open source authors change; packages are constantly updated, become vulnerable, and get patched. Languages go EOL, repositories move, trusted vendors change, etc, making it difficult to keep up.

In practice, security has always been seen as a blocker to getting software to market, and with the exception of security-conscious industries, is typically relegated to a back seat in the software development process. In other words, the threat to revenue is often seen as greater than any potential security threat.

Conclusions – The Key to Software Supply Chain Security

If all this sounds like your organization, you most likely work at a startup. But it can also be characteristic of open source or ad hoc projects – anywhere that developers gather to collaborate without the friction of process-heavy software development. 

Unfortunately, moving from Stage 0 to Stage 1 of the Secure Software Supply Chain Journey will likely be the greatest challenge you face on your software supply chain journey since it will require a completely different culture. After all, ignoring security is not a sign of willful ignorance, but rather an expedient designed to maximize code output. As such, it may not be possible to implement Stage 1 until you’ve released your product and established a market for it.

Read Similar Stories