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:
Enforce role-based access control with segmentation of duties and least privilege, including vetting personnel.
Verify each individual's development system conforms to all security requirements, including full-disk encryption, complex passwords, patch management, antivirus and intrusion detection, AI-based endpoint protection platforms and endpoint detection and response, data loss prevention, etc.
Ensure all environments have the same security protections as other critical network capabilities.
Limit access to corporate-issued or approved development systems.
Conduct security reviews of third-party software that is utilized.
Deliver digitally signed code and associated files using a code-signing system that protects signing keys and uses hardware protection.
Foster a strong security culture and implements periodic reviews and adjustments.
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:
Implement a verifiable build process as a checkpoint before signing code. This includes a logically isolated secondary mirror of the production build environment that independently and concurrently compiles and packages code. The hashed results can be verified as a match and signed with a code-signing certificate by a trusted certificate authority.
Protect keys for code-signing from theft.
Include signature validation as part of the security checks.
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:
Follow secure development lifecycle practices and processes.
Perform threat modeling.
Obtain as much information as possible about the software sources and operational environments.
Conduct threat and risk assessments to understand how different deployment scenarios, incidents, and operational errors may impact the security of the software.
Document design and operational assumptions and revisit them periodically.
Establish, enforce, and verify common security requirements between all subcontractors and third-parties and execute any code not meeting the requirements in a separate, minimally privileged environment.
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:
Establish and maintain trusted toolchains.
Automate build processes with resulting scripts and metadata stored in a secure version control system with limited access.
Execute automated build processes in temporary environments that are isolated and free from external influence.
Generate and maintain build manifests.
Secure the compiler settings, notably buffer overflows.
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:
Create a vulnerability assessment team to identify exploitable weaknesses.
Invest in state-of-the-art static and dynamic evaluation tools.
Make it easy for outside individuals to report vulnerabilities in the supplier's products.
Be responsibly transparent about known vulnerabilities.
Track vulnerabilities in the defect tracking tool but limit access to the information.
Eliminate or document any weaknesses found.
Refer to the software bill of materials (SBOM) for third-party software and components associated with the software and upgrade them per established guidelines.
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:
Prepare the organization by establishing and implementing policies that are accessible to everyone.
Protect software by protecting the code from unauthorized access, archiving and protecting each release, and verifying the integrity of software releases.
Produce well-secured software by verifying third-party software's security, analyzing code, testing, configuring the compilation and build process, designing it well, and ensuring software has secure settings by default.
Respond to vulnerabilities by continually identifying, analyzing, and remediating vulnerabilities.
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:
Discover risk the right way with precise and accurate data through advanced binary fingerprinting, contextual data insights, and deep code analysis.
Innovate faster without compromising quality or security with advanced policy controls, continuous monitoring, and infrastructure as code rules.
Protect the integrity of code, delivery pipelines, and operating environments with early warning detection, perimeter control, and behavioral inspection.
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.