Recently the U.S. government, through the Enduring Security Framework (ESF) Software Supply Chain Working Panel, released the second in a series of three guidance documents to improve the security of the software supply chain. The first document addressed developers, and the final one is for customers.
In this article, we take a deep dive into the guidance that software suppliers can take to improve the security of the software they distribute. The guidance will help organizations who supply software establish a security baseline if they haven’t already - a vital step.
As the authors point out, the "supplier also holds a critical responsibility in ensuring the security and integrity of our software. After all, the software vendor is responsible for liaising between the customer and the software developer. It is through this relationship that additional security features can be applied via contractual agreements, software releases, and updates, notifications and mitigations of vulnerabilities."
We could not agree more - it is why we do what we do. But what steps can software suppliers take?
We have summarized it here for you, including what steps your organization can take.
The guidance defines a software supplier as an "intermediary, between the developer and customer" and suggests they retain primary responsibility for:
Define what checks are required before delivering software, ensure the checks are completed, and notify customers of vulnerabilities, mitigations, and end-of-life support. Everyone in the software development life cycle (SDLC) should be aware of these requirements and why they exist. Making it easy to implement is vital for adoption and compliance.
Some recommendations to implement this include:
In order to protect all forms of code from unauthorized access and tampering, grant the minimum required privilege to everyone throughout the SDLC.
Some recommendations to implement this include:
Verifying software release integrity by digitally signing the code throughout the SDLC enables recipients to verify and trust the origin and integrity of the code.
Recommended actions include:
Organizations should have an archival strategy that specifies major and minor releases and mandates when software should be archived, how long it is kept, and where it should be stored. This is important for disaster recovery and forensic investigations during cyber incidents. Ensure the archives are access-controlled, persistent, and read-only, and automating it into the SDLC can ensure compliance.
Security requirements must be accurate and complete, the code must satisfy these requirements, and any exploitable vulnerabilities should be addressed. Some steps to achieve this include:
Ensure your third-party software and components, whether used in the organization or with other products, comply with security requirements. If possible, convey the requirements to the supplier via contractual agreements, including vulnerability disclosure/mitigation and incident reporting. Additionally, maintain a read-only vault of approved third-party software and don't allow non-approved software to be used.
Adequately configure the compilation and build processes so that adversaries with access to software processes and tools can't insert malicious software into components and the executable code isn't compromised. This includes proper configuration of full or incremental builds.
Recommended steps include:
All software should include operational and security functionality, and any human-readable code should be reviewed to help identify vulnerabilities and verify compliance with all requirements. Each is important for a robust security assurance program.
Executable code should be tested to identify vulnerabilities and verify compliance with security requirements. In order to facilitate this, suppliers should deliver software that permits customer access to information and resources for which they are authorized. They should also prevent access to information for which they are not authorized.
Use, and keep up-to-date, threat models for all critical software components and all systems in the build pipeline. Test plans should cover each requirement and include code coverage. Baseline levels of code coverage should be achieved on all code that is checked in and before new code is committed, and security testing should be part of every software component's QA plan.
To thwart inadvertent installation of software before all security checks are in place or properly configured, require minimal access as the default when software is installed. Customers can explicitly enable additional access when required.
Suppliers should remove or remediate any known vulnerabilities provided to customers, and customers should demand transparent information regarding the origin and security of the software.
Here are some recommended controls:
SaaS applications pose a different risk. Organizations should implement a stringent security policy toward SaaS applications, including a mechanism to monitor and scan third-party applications which are directly connected to the cloud.
The guidance is categorized into four main areas:
At Sonatype, we are passionate about security, and we turn that passion into tools to help organizations protect software through the entire SDLC. For instance, we invented an artifact repository for versioning and archiving releases, we have advanced policy controls to automate policy enforcement and compliance, infrastructure as code rules to enable developers to find and fix cloud misconfigurations, and more.
Sonatype's complete software supply chain platform can:
We are also active in helping shape policy recommendations and helping improve open source projects through the OpenSSF and other efforts. We encourage you and your organization to join us. Working together ensures the whole SDLC is as secure as it can be. Together, we will stay ahead of the adversaries.