Every company building software is building a software supply chain.
They do this through assembling open source components and libraries to speed up development or access new technologies, through use of third-party APIs from partners or services to add functionality, or the use of open source tools in the software development lifecycle (SDLC). DevOps teams heavily rely on a cadre of open source tools like Jenkins and Argo. As a result, most application code is not written or directly maintained by the owner of the application. And according to the 2023 State of Open Source Report, 80% of organizations expect to use even more open source code.
For their part, attackers see open source as a fabulous target — a way to compromise a single organization and also gain trusted access to thousands or millions of organizations and propagate attacks. The vast and intricate nature of the software supply chain makes it a challenging attack surface to map and secure. Nevertheless, organizations can take five critical steps to bolster their software supply chain security.
Software Bill of Materials (SBOM)
An SBOM is a comprehensive list detailing every piece of software, library, and component used in an application. By maintaining an SBOM, organizations can gain a clear understanding of their software inventory, making it easier to identify and address potential vulnerabilities. SBOMs also create a historical record of changes made over time, enabling security teams to more easily pinpoint when and where a vulnerability or compromise was injected into the supply chain. The U.S. Federal Government is making SBOMs mandatory for all applications running on government systems. Many tools can generate SBOMs, from CI and CD systems to software composition analysis scanners to specialized SBOM generation and management tools. A growing trend among organizations, as well, is to require an SBOM from any key supplier or vendor, or from open source projects upon which they rely.
Software Lifecycle Security Assurance Processes (SLSA)
SLSA (pronounced “salsa”) is a Open Source Security Foundation (OpenSSF) project that helps organizations ensure software undergoes rigorous security checks throughout its lifecycle. In is a unified language and set of incrementally adoptable guidelines designed to address the entire software supply chain and can be applied programmatically by SLDC tooling. Particularly useful for open source code and the set of dependencies and constant updates it generates, the framework’s strength lies in its structured approach. With clear benchmarks and best practices, SLSA enables organizations and developers to assess and improve their software’s security posture, and it can help measure compliance with the Secure Software Development Framework (SSDF).
Code Signing for Attribution
Code signing is a digital security practice that attaches a one-way hash signature to software, affirming its authenticity and integrity. Similar to other forms of signatures, these digital signatures secure supply chains by assuring users that the software originates from a legitimate source and remains unaltered since its signing. Signatures can feed into SBOMs and indicate that a line-item in the SBOM is more or less trusted (depending on the code signature status). This enhances the software publisher’s reputation, prevents warning prompts in modern operating systems and browsers, and safeguards against malware infiltration. For an organization to implement code signing, it needs to obtain a code signing certificate from a trusted certificate authority (CA). Once acquired, the organization can use specialized tools or built-in platform utilities to sign their software binaries and scripts. A widely used and well supported open source code signing systems is Sigstore, another OpenSSF project. Sigtstore packages code signing, monitoring, policy management, OpenID and other elements into an integrated solution that can be added to your SDLC. Regularly updating and managing the private keys associated with the certificate, and potentially integrating the signing process into the software development lifecycle, ensures a seamless and secure software distribution process. In the future, all code will be signed, and the supply chain will have a true source of provenance and accountability that will reduce supply chain attacks.
Trusted Package and Container Policies
A favorite target for supply chain security attacks are package managers and indexes, like npm for Node.js, PyPI for Python, and Gems for Ruby. A trusted package policy is a set of rules ensuring the security, authenticity, and reliability of third-party software packages that are approved for use in an organization’s applications and infrastructure. Key components include making sure packages come from approved and verified repositories, adhering to specific version controls, requiring digital signatures for package authenticity, routinely scanning for vulnerabilities, monitoring license compliance, and establishing clear package update protocols. Often, organizations simplify this process by relying only on packages and containers from trusted registries or ones that are certified as reliable by a package manager, index, or registry. Most registries allow organizations to set up secure private registries and limit the use of packages to only those registries. By implementing a “trusted package” policy, organizations can ensure that only vetted and approved software packages are integrated into their systems. This policy reduces the risk of integrating malicious or vulnerable components that might compromise supply chain security.
Regular Software Audits and Code Scans
Regular software audits and continuous code scans play a pivotal role in an organization’s software development and maintenance strategy and, by extension, in software security. With the increase in AI code completion, these proactive practices are becoming increasingly important in safeguarding the supply chain by proactively identifying and mitigating vulnerabilities, thereby preventing potential breaches and insertion of malware. Audits and scans are not only important for security but also for quality assurance; scans and audits can detect bugs and performance issues. This proactive approach is also cost-efficient, as early detection and resolution of issues prevent expensive post-deployment fixes. Equally important, frequent audits and continuous scans build a culture of security and help shift security expertise left, driving more secure coding processes. Additionally, audits ensure license verification, ensuring that third-party components are used legally and ethically. Lastly, in the era of agile development and DevOps, continuous scans can become a mandatory part of CI/CD pipelines. This ensures that the software remains deployment-ready and free from critical vulnerabilities.
Conclusion: Supply Chain Security is Really Just Security
Implementing these five tactics and strategies will dramatically reduce supply chain security risk by baking accountability and transparency into your SDLC. All things being equal, supply chain security is pretty much the same as application security and secure software design. Some of the practices recommended here are nascent, but all are becoming common and even required by auditing and compliance organizations. Best of all, the future of supply chain security will make “good” security easier for everyone by automating significant portions of the compliance and tracking process and simplifying code audits and analysis. Supply chain security is a win-win for everyone, making teams more efficient and secure, and making software run better.
About the Author
Jenn Gile is Head of Product Marketing, F5 NGINX. NGINX, now part of F5, improves the performance, reliability, and security of websites and applications.
Featured image: ©silverkblack
