US Government: Secure Software Supply Chain Best Practices

In response to recent cyberattacks, such as those that compromised SolarWinds and its customers, and exploits that take advantage of vulnerabilities such as Log4j, the White House released an Executive Order on Improving the Nation’s Cybersecurity (EO 14028). One of the deliverables from the EO is a compendium of suggested practices for developers, suppliers, and customers, which will be released as three separate documents.

The initial document is focused on helping software developers understand the US government’s requirements for secure software development. The result is a set of best practices designed to help developers secure their software supply chain in a tractable manner despite the complexity of the issue. 

The problem lies in the fact that 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 more than one open source language, 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 security and integrity controls you could implement in order to analyze the open source components you import. How far you go down this rabbit hole is largely dependent on your appetite for risk, but also your time and resources, as well.
• Change – no supply chain is ever set in stone. Open source authors change, and the packages they produce are constantly updated, become vulnerable, and get patched. Languages go EOL, repositories move, trusted vendors change, etc. Keeping up with it all will, once again, demand time and resources.

In addition, complying with US government regulations also means generating software attestations and Software Bills Of Materials (SBOMs) as part of your development process, as well as speeding up vulnerability remediation. 

All of these requirements, and suggestions of how to implement them, can be found in the recently published “Securing the Software Supply Chain: Recommended Practices for Developers,” which can help you understand what you need to do in order to continue selling to US Government departments and agencies starting in 2023. Let’s dig in.

The Secure Software Development LifeCycle

The security risk posed by the software supply chain has been growing by 742% on average over the past 3 years, primarily due to bad actors creating open source software exploits. While bad actors still continue to exploit known, unpatched vulnerabilities, they are increasingly targeting the software supply chain by proactively injecting malicious code into third party components that are then legitimately distributed downstream through the software industry.

To combat this emerging threat, the US government has proposed a number of best practices for software developers to follow in order to better service their suppliers (i.e., resellers) and customers (i.e., departments and agencies) within the US government:

Secure Software Development Process

The result is a Secure Software Development LifeCycle (Secure SDLC) that addresses the following areas of concern:

• Architecture & Design Review – developers, suppliers and customers must work together to define the software requirements up front, as well as the completed artifacts output that are to be collected for verification and validation using software attestations. Attestations can be used to validate the secure principles and guidelines used to create the developer’s software.
• Software Threat Modeling – threats exist at every stage of the SDLC, including during the import of third-party code, the build systems used to create software artifacts, and the mechanisms whereby software, updates and patches are delivered. Security architects should develop threat models for all critical components and systems in the build pipeline and review them on a regular basis.
• Coding Standards – standard coding best practices apply, including allowing only code that has been peer-reviewed by at least two developers to be checked into a code repository that supports Multi-Factor Authentication (MFA). Multiple code branches should be used, such as development, test and production, with appropriate criteria enforced when moving code between each branch.
• Secure Library Checks – incorporate only third-party/open source libraries that have been vetted by your organization. Ensure the use of dedicated systems to download, scan, and perform recurring checks of third-party/open source libraries for new versions, updates, and known/newly reported vulnerabilities.
• Code & Executable Testing – QA teams should incorporate both Static and Dynamic Application Security Testing (SAST and DAST) as well as Software Composition Analysis (SCA) tools to identify issues and vulnerabilities in proprietary and third-party code. QA should also employ regular penetration testing, ensure fixing of security defects, and document the Common Vulnerability Scoring System (CVSS) score of the software analyzed.
• Secure Build & Delivery – harden the development, build and delivery environments, and ensure all software is developed following secure software development practices (such as proposed by the Supply-Chain Levels for Software Artifacts, or SLSA security framework) as attested to by a software attestation. All relevant artifacts must be identified via an SBOM, signed, and stored for future reference.

Post-release, vulnerabilities should continue to be tracked, with customers being provided timely notifications and security updates.

Creating a Secure Supply Chain for Third-party Code

Special attention is paid to how software developers can better manage and secure the third-party components that comprise >80% of the code in most modern applications, including free libraries, open source dependencies, and Commercial Off The Shelf (COTS) software. 

In most cases, third-party software comes with no guarantees as to the security and integrity of the code they offer. As a result, the onus is on the developer to ensure whatever they’re incorporating into their codebase is secure, free of vulnerabilities, properly licensed for commercial purposes, and well maintained. To that end, the best practices recommend a secure repository workflow when it comes to importing code: 

Secure Repository Process Flow

1. In most cases, third-party components will be downloaded from open source repositories, which typically lack strict guidelines for compiling and securing the software they offer. In any case:
2. All imported components must be scanned on download for malware, trojans, backdoors, and other malicious code. 
3. A “quarantine” repository is recommended where components can be further analyzed to ensure security and integrity. Some enterprises may want to perform further checks for compliance with corporate guidelines, as well, before the component is moved to:
4. An artifact repository, which is the only repository developers should be granted access to when it comes to incorporating third-party components into the codebase (5a). This repository should provide continuous vulnerability scanning, vulnerability status, and automated notifications (5b) when a vulnerability is found. Notifications should also include patch/upgrade recommendations.

In this manner, organizations can better vet third party code, and react quicker when new vulnerabilities arise. It should also help developers recognize which programs and projects have been affected.

Conclusions – Complying with Secure Supply Chain Requirements 

The best practices outlined by the US government for secure software development go into far more detail than this blog can cover, but it should be evident that securing the supply chain and complying with US government requirements can be both time consuming and costly to implement. 

As an alternative, consider adopting the ActiveState Platform, which can help you quickly close many of the key requirement gaps your organization may have. For example, similar to the Secure Repository Process Flow best practice described above, ActiveState:

1. Imports open source dependency source code from public repositories on a regular basis.
2. Scans and analyzes the imported source code on import.
3. Stages indemnified source code for further analysis with respect to security, maintainability and compliance with commercial licensing.
4. Provides a “per project” registry of approved dependencies automatically built from source code, which are continuously monitored for vulnerabilities and updates. Notifications are sent to the project owner as and when vulnerabilities are detected. 

The ActiveState Platform is an out-of-the-box solution that can be easily integrated into your existing software development processes in order to address key requirements, including SBOMs, software attestations and faster vulnerability remediation:

Read Similar Stories