Building a Sustainable Software Supply Chain

Security professionals tend to spend a lot of their time firefighting. People are pressured to bring a product to market quickly, and if an issue arises, they are under additional pressure to fix it fast. Consequently, there's little time or resources to think about the big picture of lasting approaches to software security. This is an issue seen across the entire supply chain.

However, the modern market is a space where standalone vulnerabilities are no longer the most challenging threats in the software supply chain. Hostile actors are stacking vulnerabilities to achieve their goals, and sophisticated attacks require sophisticated approaches to address them. Instead of swatting a single problem, you need to adjust for a larger threat vector in your supply chain.

Management of the current threat landscape emphasizes the need for software supply chain sustainability. Sustainability is about software lifecycle management: making security a continual series of processes to assess software provenance, quality, and risk. Ideally, this is supported by automation and tooling to allow for scale. This can begin with knowing the origin of your software, how you’re incorporating it into your products, how you will maintain and support it, and how you’ll replace it when necessary.

In this blog, I’ll discuss specific markers of sustainable software projects and products and highlight several steps organizations can take to strengthen software supply chain security. But first, let’s delve deeper into today’s evolving threat landscape and why it requires organizations to rethink legacy approaches to software security.

Note: This piece is based on a webinar I recently hosted: The Path to a Sustainable Software Supply Chain. If you’re interested, you can view the on-demand version linked below.

Evolution of Software Supply Chain Threats

Our threat vectors today are much different than in years past. If we look back 25 or so years, the threat vector was basically a virus. It could be installed through compromised software — someone gives you a cracked piece of software on a floppy disk, your computer gets a virus, and chaos ensues. Over time, these vulnerabilities moved to the internet. People opened a poisoned email attachment, causing damage, and so on. The potential reach increased, but fundamentally, the construct remained the same.

Those types of threats still exist and cannot be discounted, but new threats are far more sophisticated, reflecting the fact that software itself is more sophisticated. This is also partly due to the rise of nation-state cyber warfare teams, leading to a bleeding of technologies and skills into the private sector and the massive rise in profitability for large, well-funded private actors leveraging ransomware at scale.

Our attack surfaces have increased from a single point of failure — like the traditional standalone CVE — to situations where multiple vulnerabilities are stacked to accomplish objectives. One could enter a system, another could embed, and another could bring downloads onto the system or send information off it. Unless you catch the stack, you may only close the loop on the first issue, leaving your systems compromised.

A clear example of increased sophistication is the software supply chain attack. The SolarWinds hack was one such incident where a software service provider’s build system was compromised, circumventing many traditional security review failsafes. The company's code looked fine on completion and ingestion, but when it passed through the build system to customers, it was compromised with a malicious payload.

A similar, less sophisticated attack happened on WordPress, where a provider’s plug-ins were backdoored. The provider’s website was compromised, removing the “safe harbor” of provenance, leading to security failures for all parties relying on it as their primary gatekeeping mechanism.

Indicators of Sustainable Software

Reflecting on the evolution of security threats, it’s clear that responding to issues in an ad-hoc manner will always leave us a step behind. We need to understand the provenance of the software we rely on. We have to examine how we or other parties curate software from the initial source code to the delivery point. This subject is adjacent to, but differs from, issues related to code development.

Fortunately, much work has been done in the industry to support organizations of all sizes. Here are some actions to take in making sustainable security a reality for your use case.

1. Check for the Open Source Security Foundation (OpenSSF) Best Practices Badge: This badge covers open source projects and indicates they have taken steps to cover key sustainability topics. Project owners will know how they make and maintain their code. Projects like the Linux Kernel have this badge, serving as a starting point for identifying good governance.

2. Check for the ISO/IEC 5230: OpenChain Specification: Companies conforming to this standard demonstrate using key processes of a quality open source license compliance program. This identifies inflection points for potential failures and ensures a process to keep things on track.

3. Check for a Software Bill of Materials (SBOM): Transporting software should no longer involve variance in communicating what is being transported and its context. It's reasonable to expect suppliers to provide an SBOM, preferably in a human- and machine-readable format like SPDX ISO/IEC 5962 or CycloneDX. SBOMs enable companies to understand and evaluate a software product's composition and provenance.

4. Ask about engagement in the open source community: Companies engaged with open source projects and communities are often better positioned to address complex problems quickly. They benefit from greater market insight and can rapidly deploy shared solutions.

Questions to Ask Software Vendors

When addressing your supply chain and communicating with vendors, several questions complement the above indicators. These questions help frame how vendors understand provenance and whether it aligns with your expectations.

1. Where do they get their code? Your supplier should coherently explain their code sources, helping you make informed decisions. If a vendor uses a modified Linux Kernel by a third party, ask for specifics on modifications and source code for review. Be wary of claims of entirely in-house software as open source is almost always present in modern codebases.

2. How are they maintaining their code? Bit rot is inevitable as technology becomes complex. Limited time and workforce make refactoring and refining code a challenge. If a project has no maintenance process or it's ad-hoc, this is a potential concern for sustainability and security.

3. How do they build their code? A specialized build system is fine if they can audit it adequately. Using a standardized build system doesn’t eliminate audit needs but reduces the audit scope, facilitating quicker security checks from a security perspective.

4. How do they review code origin, maintenance, and builds on an ongoing basis? Security is an ongoing process. Vendors should assess their software’s provenance and security continually. There are varied approaches to achieving this, but oversight remains critical for reducing security concerns.

5. Are they using automation to identify and remediate vulnerabilities in their code? Manual processes can achieve much, and many operate under them for compliance, security, and export control. Yet, companies automating with tools like software composition analysis handle larger code volumes efficiently, freeing resources for strategic application elsewhere.

Ultimately, using open source projects with OpenSSF Badges or buying from ISO/IEC 5230-conformal vendors ensures attention to governance. Automation in managing security issues and providing SBOMs in formats like SPDX or CycloneDX boosts confidence in vendors. Engaged suppliers with upstream projects and collaborators likely handle problematic components before they escalate.

The Software Supply Chain Sustainability Maturity Model

Having discussed markers of sustainable software projects, organizations can gauge their sustainable software supply chain progress using a framework of identifying, responding to, pre-empting, and helping others.

1. Identifying issues: Supply chain sustainability begins by recognizing issues impacting your software, such as CVEs in your leveraged code. Understanding these concerns helps you address security challenges in your code, products, and solutions.

2. Responding to issues: The next phase is quickly responding to issues through a repeatable process. Ad-hoc responses slow down resolution. Establishing a reliable process is challenging, but some steps are helpful.

• Establish your base process: Collaborate with your core security team to design a process for resolving security issues, thinking through the steps from identification to remediation.

• Automate the difficult lifting: Automate your core response concepts, like catching related CVEs, freeing programmers to focus on coding while monitoring occurs in the background.

• Iterate over time: Tailor your approach to align with your operations and market demand.

3. Pre-empting issues: Identifying and responding establishes a solid security foundation. Pre-empting issues might seem daunting, but gradually adding processes flags problems early, like addressing dependency on a minimal-maintainer project. This effort is community-driven, with organizations like OpenChain and OpenSSF supporting pre-emptive issue handling.

4. Helping others: The final phase involves companies supporting continuous open source ecosystem collaboration. Open source frequently sees competitors collaborating on code, increasingly solving security issues together. It’s sensible to share development on common infrastructure, lowering individual resource commitment while maximizing sustainability. This approach enhances security while freeing company resources to focus on product differentiation.

Ultimately, whether selling a device or service, customer security expectations are high. Security, like car wheels, is essential. In summary, enhancing security sustainability requires focusing on processes, evolution, automation, and engagement. Begin by identifying issues, quickly respond with repeatable processes, devise a pre-emption strategy, and collaborate with peers and competitors for efficient issue resolution. This maturity model benefits your supply chain and customers starting today.

About the Author

Shane is the general manager of OpenChain, a Linux Foundation project dedicated to building trust in the software supply chain. Shane has extensive experience in copyright, patents, and open source, and serves as an advisor to World Mobile and on the management board of OpenForum Europe.