Thanks to many factors like the rise of the cloud infrastructure, the abundance of prebuilt open-source code, and process improvements in DevOps, innovating with software is happening faster than ever.
The software supply chain is the assembly line for these technological innovations and can be thought of as any combination of code, tools, and processes used to develop and deliver software to customers. Society relies on them as the backbones holding together each digital connection. Our reliance on these software supply chains is growing, and unsurprisingly, so is the attractiveness of attacking them. Foreign governments and criminal hacking groups view software supply chains as poorly protected and full of many opportunities to carry out attacks like the SolarWinds and Codecov breaches. The severity of these breaches, number of victims, and types of access or data gained has been devastating.
US Government Enacts Executive Order Improving the Nation’s Cybersecurity
In response to these strategic attacks on software supply chains and the threat they pose to security of critical government data and systems, the United States has created new compliance requirements. Executive Order 14028, enacted on Sept. 14th, 2022, requires and defines minimum standards and actions organizations must comply with to help prevent software from becoming compromised and harden the nation’s software supply chain. Any organization selling software, products containing software, applications, operating systems, or firmware to a US government agency must comply with this guidance.
There have been four best practice guides for software-supply chain security published. But the official guidance to follow in order to accurately demonstrate compliance is The Secure Software Development Framework NIST 800-218 which was developed by NIST (The National Institute of Standards and Technology).
The Secure Software Development Framework requires software producers to build security strategically into their process no matter the software delivery lifecycle model used (agile, waterfall, DevOps etc) and apply security in a way that makes sense to operational maturity.
There are 42 specific compliance requirements needed to achieve compliance with the NIST framework. Each can be mapped to a high-level software supply chain security objective in one of these four categories:
- Preparing the organization: Securing code by ensuring that people, processes, and technology are prepared to perform secure software development.
- Protect the Software: Protect all components of software from tampering or being accessed unauthorized.
- Produce Well-Secured Software: Produce well-secured software with minimal security vulnerabilities in its releases.
- Respond to Vulnerabilities: Identify existing vulnerabilities in software and remediate to prevent similar ones from occurring.
Adopting the framework helps reduce the number of vulnerabilities released in software, mitigates the impact if a software supply chain is exploited, and addresses the causes of vulnerabilities. It also makes organizations approach security comprehensive from two different viewpoints, as both a software producer and software purchaser.
Everyone is Impacted
Every organization that sells or consumes software is a link in the supply chain. Therefore, the executive order has a domino effect. To expand on this, some businesses do not directly contract with the government and don’t need to comply as a supplier. However, their customers can now only use software components or open-source materials that are also compliant with NIST guidance.
Timeline for Compliance
There is no time to waste. The deadlines set forth by the order are ambitious.
- By January 12, 2023: Notification from CIOs in charge of software that is supplied to any government organization must be sent to all software vendors they utilize of compliance requirements.
- By June 11, 2023: Software deemed “critical” to the US Government is required to fully comply and attest.
- By September 14, 2023: All other software supplied to a US Government agency or vendor must comply and attest.
Global Implications
While this executive order only applies to the United States Government, it is a leading indicator of what to expect from other nations following suit. The guidelines developed by NIST are a glimpse at what types of specific security standards organizations can expect to be regulated as software supply chain strategy increasingly impacts national security.
Achieving Compliance with Executive Order 14208
Luckily, compliance with the Executive Order will be one of many natural benefits of adopting software supply chain security practices. These four comprehensive steps conveniently incorporate all the software development and attestation components needed to comply with the executive order, rolling secure development and compliance into a “few stones, multiple birds” methodology.
- Secure Development Environment and Process: Ensure secure configuration of development environments and complete accompanying attestation.
Knowing what and where to apply security is a great place to start. This requires visibility of an organization’s software development infrastructure to know where to surgically implement processes and tools needed to release software with confidence. Securing development environments requires control over who has access to code repositories, CI pipelines, or artifact registries and leverage a least privileged access mantra across the entire SDLC. Securing the tools that are used for development environments is also a key component. This is achieved by scanning for vulnerabilities and license issues on every build, which prevents malicious add-ons occurring that can be exploited.
A comprehensive software supply chain security solution like Aqua ties together people, tools, and process, making these security best practices intuitive parts of the development flow and leveraging automation for speed and reporting.
- Secure Code: Ensure sources of code are trusted and that code vulnerabilities have been remediated and complete accompanying attestation.
Verifying that source code written is secure and trusted is most typically done by leveraging code scanners that detect vulnerabilities, secrets, malware, and more. They help identify vulnerabilities early in the development process. This is commonly known as shifting security left when a developer is still writing the code, and it’s easiest and cheapest to fix. The best code scanners find vulnerabilities, plug into a developers IDEs and CI/CD, can run against binaries, and have a low number of false positive rates, which create an entirely different set of problems to deal with.
Compliance with the executive order requires remediation of known code vulnerabilities. This effort should be prioritized according to severity. Once code sources have been verified and the slate has been cleaned from any known vulnerabilities, an organization is ready to become proactive in their software supply chain posture management, maintaining compliance. Again, policies automation and intelligent notifications in this process help ensure that developers are not slowed down while incorporating all these best practices.
- Software Bill of Materials: Maintain provenance data for internal and third-party code and keep on hand a current SBOM for every product release.
A Software Bill of Materials (SBOM) provides a list of components a piece of software contains and is required to meet compliance. It tells users if the software is safe to include in their environment, and it holds third-party suppliers accountable for the quality and security of their product. Most importantly, it illuminates the proprietary and open-source dependency tree and makes the inevitable response to CVEs a proactive task.
When a new vulnerability or software supply chain attack is discovered, teams must determine risk exposure by examining every component in all software developed and used. For example, when verifying if a critical application contains a newly compromised open source library. Speed and response depend on how quickly teams can find and pinpoint affected artifacts for remediation.
- Open-Source Health: Maintain data integrity and provenance of all in use open-source software.
Open-source code receives many callouts in the NIST guidance and rightly so because vulnerabilities that pop up in open source are hard to identify, track, and remediate. Open source constitutes a whopping 70-90% of modern software solutions, and it’s one of the trickiest parts of ensuring software integrity. Given its growing use, it must be a prominent factor in security strategy.
Quality of software depends on the health of open-source projects, their authors, and other critical indicators. Maintaining integrity is done by scanning all open source with SCA (software composition analysis), setting up automation to block any known bad components with known vulnerabilities from being introduced to the code, and constantly monitoring for new vulnerabilities.
Aqua’s Software Supply Chain Security Solution was built to ensure end-to-end security and integrity of the entire software development lifecycle. It enables software providers to quickly meet and attest to the Executive Order to secure software development component requirements within 30 days of deployment and includes reporting and management capabilities for initial and ongoing compliance attestation.
