Software supply chain security has been in the news repeatedly since the pandemic, when hackers realized they could gain economies of scale by compromising a single system or process at software providers that have thousands of customers, rather than targeting zero-day exploits at individual companies. The ROI on software vendor hacks has proven itself to be exponentially better, as exemplified by the SolarWinds attack. 

Yet despite the amount of press the SolarWinds hack has received since 2020, it seems like the software industry still hasn’t learned anything. Subsequent notable attacks like Codecov, Netbeans, NotPetya, Kaseya, as well as others typify the explosive growth in software supply chain attacks year on year:d

Source: Sonatype State of the Software Supply Chain

The latest victim to come forward is CircleCI in January 2023, but they won’t be the last. 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.

As a result, the US government has taken the unprecedented step of effectively legislating software supply chain security, which will force US government software suppliers to comply with a set of supply chain security requirements by June 11, 2023. Detailed in the government’s Executive Order Mandate 14028 (EOM) focused on “improving the nation’s cybersecurity,” these requirements will soon apply to any software vendor that wants to do business with the US.

This post is an introduction to our forthcoming eBook. It provides an outline of the five step framework that can help software vendors:

1. Understand the scope of what it takes to secure their software supply chain.
2. Evaluate their current supply chain security posture.
3. Create a roadmap to secure their software supply chain.

The full eBook, which will go into more depth at each stage will be released over the coming weeks. You can sign up to receive your copy at the end of this post.

The Five Stages to Software Supply Chain Security

Every journey begins with a single step, but for many smaller organizations the first step can represent such a significant cultural change that they never commit to it. On the other hand, established enterprises are likely to be well down the path, having had best practices and supporting tooling in place for many years. 

With that in mind, organizations that want to secure their supply chain can use the following journey to create a roadmap of tools, processes and initiatives, which will also allow them to comply with key US secure supply chain requirements:

Stage 0 – Complete Anarchy 

Most organizations would hesitate to characterize the way they work as “complete anarchy,” but there are more than a few organizations at this stage of the journey. Typical characteristics include:

• Non-standard tools
• Lack of standard processes
• Lack of governance

For example, while there has to be some agreement on shared tooling (such as the code repository, for example), everyone has their own set of preferred desktop tools and ways to work with them.

This way of working can feel empowering, liberating everyone to be as creative as possible, but the reality is that security is an afterthought. It’s most typically found at startups, but 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.

Stage 1 – Observable Chaos 

At some point, someone in the organization will inevitably want to gain visibility into the application security problem. This is most easily done by introducing a number of tools, such as:

• Software Composition Analysis (SCA) – SCA tools are typically used to provide information about the open source packages in an application. For example, they can identify outdated packages that may contain security vulnerabilities. 
• Software Bill Of Materials (SBOM) – SBOMs are literal laundry lists of all the components from which your application has been built. They can help you quickly determine whether your application contains a known vulnerable package, for example.

All of these tools promote awareness of application security issues, but organizations at this stage of the journey rarely act on them. For example:

• Vulnerabilities are acknowledged but go unremediated unless a critical vulnerability of note (such as Heartbleed, Log4j, etc) forces a revision. Unfortunately, multiple reports consistently confirm that the vast majority of codebases are never updated.
• SBOMs are generated, but then “put on a shelf” and never incorporated into the software development process where they could be used to help identify whether codebases have been compromised. 

This stage is most typical of the software development practices at small businesses. 

Stage 2 – Automated Security

This stage is typified by the automation of application security best practices, such as:

• Vetting imported code and quarantining suspect packages.
• Vendoring dependencies and transitive dependencies to ensure all packages can be built without requiring access to the internet.
• Building all open source packages from source code rather than using prebuilt binaries.

While most enterprises have already adopted many of these best practices, they tend to be ungoverned. In other words, there is no verification method in place to ensure that best practices are always followed in the correct manner. 

For example, while most security-conscious organizations build the open source packages they use from source code, only 22% of them can do so in a reproducible manner. This makes it extremely difficult to verify that the package was built securely in the first place. 

Stage 3 – Verifiable Safety

The next step is to ensure that exceptions to best practices are caught before they can do damage. This entails the use of verification tools and processes, such as:

• Policy Enforcement – by creating governance policies and enforcing them through a rules engine, organizations can ensure that security and compliance issues are caught before they make it to production. For example, enforcing a rule that states, “no components with a high or critical vulnerability are allowed in production.”
• Software Attestation – by automatically generating an attestation as part of the software development process, organizations can ensure (for example) that a package was built using approved source code imported from an approved repository. 

Few enterprises have adopted these kinds of advanced methodologies to date, leaving much work to be done. Adopting emerging security frameworks like SLSA (Supply chain Levels for Software Artifacts) can help.  

Stage 4 – Anti Entropy

Once you’ve put in place all the tools, processes and governance listed in the previous stages, you’ll need a plan to maintain and update them. After all, best practices evolve over time, as does hacker ingenuity. 

Key to fighting entropy are: 

• Cultural Buy-in – getting most developers to buy into security best practices is always easier once you can show them the systems and processes you’ve put in place won’t slow them down. But without their buy-in, best practices will soon go by the wayside.
• Proactive Security –  your software supply chain is only as strong as its weakest link. And that weakest link is constantly being redefined as vulnerabilities are discovered and bad actors change their targets and tactics. Take a lesson from Netflix’s Chaos Monkey and become proactive about finding your weakest link before hackers do. 

Conclusions

The journey to a secure software supply chain is just that: a journey, rather than a destination. After all, bad actors will always come up with novel approaches to find and exploit the weakest link in your software supply chain. It’s also important to realize that your supply chain is never set in stone: 

• Open source authors change
• Packages are constantly updated, become vulnerable, and get patched
• Languages go EOL
• Repositories move
• Trusted vendors change

For most organizations that use more than one open source language, securing all their software supply chains can seem like an impossible task. This is one of the key reasons we created the ActiveState Platform, which acts as a universal package management solution for open source languages, featuring:

• An automated import and quarantine system for open source code.
• A secure build service that automatically builds all packages from source (including linked C libs), and implements all the requirements to meet SLSA Level 4.
• Programmatic generation of an SPDX SBOM and software attestation, including (uniquely) attestations for binary packages

Read Similar Stories