Executive Order (EO) 14028, Improving the Nation’s Cybersecurity was released last year in May.
September 19, 2022
Executive Order (EO) 14028, Improving the Nation’s Cybersecurity was released last year in May pushing security and integrity of the software supply chain. On September 14th, a memorandum was sent out to the heads of the executive departments and agencies, with actions, responsibilities, and a timeline to comply with the new NIST guidance. Let’s do a quick break down of the memo and discuss the importance.
Firstly, the memo requires all federal government agencies to ensure that all software obtained must comply with the NIST guidance. This includes both new software as well as software that has gone through a major version release. The guidance provides “recommendations to federal agencies on ensuring that the producers of software they procure have been following a risk-based approach for secure software development.”
1. Consistent with the NIST Guidance and by the timelines identified below, agencies are required to obtain a self-attestation from the software producer before using the software.
A “self-attestation” is a document that meets the “conformance” set forth by NIST. Conformance in this context means that the the software producer has met the requirements and is providing evidence with the attestation document. This document needs to be retained by the agency and will be collected in a central agency system (within 120 days of the memo).
If a producer cannot attest, they must identify the gaps and mitigation that have been set forth and provide a Plan of Action & Milestones (POA&M) on how they plan on meeting it in the future. The other option is to get certified by a Third Party Assessor org. If the assessment passes, the “self-attestation” document is not needed.
Finally, the “self-attestation” document needs to have the at minimum the following requirements:
- Software producer's name- Description of the product/products- A statement attesting that the software producer follows secure development practices and tasks that are itemized- Depending on the criticality of the product, a third party assessment may be required along with the "self-attestation" document
2. Agencies may obtain from software producers artifacts that demonstrate conformance to secure software development practices, as needed.
Along with the the attestation, software producer may also be required to provide Software Bill of Materials (SBOMs) in a data format defined by NTIA. Depending on the agency, further supporting artifacts that attest the integrity of the source code or vulnerability scans may also be needed to be provided.
Federal agencies have been given a timeline to meet these requirements and software producers need to be prepped to provide such conformance documentation in the coming months.
The federal government is taking software supply chain security very seriously and is mandating agencies to follow strict requirements to mitigate the risks. While this memo puts an urgency for the supplier to the federal government, they are still not moving quickly as they could. The wide spread attack vector that is present with software supply chain attacks need to be addressed quickly and with proper remediation. The open source community has already come together and started to provide a path forward long before this federal mandate. SLSA (Supply chain Levels for Software Artifacts) was created to allow for software producers to create this attestation documents that provide evidence that prove they are following all the requirements set forth by NIST and the various SLSA levels. As more and more agencies require more in-depth attestation documents to be provided, it becomes necessary to automate this process. Build tools such as FRSCA (Factory for Repeatable Secure Creation of Artifacts) make it easy for software vendors to build their artifacts in a secure manner and provide tamper proof and signed attestation for all the steps they are taking for NIST conformance.
While this change is going to cause many software producers to rethink the way they are building our their artifacts and the attestation documents they need to provide, it does not have to be a hard transition. The “self-attestation” allows for even smaller companies, without significant resources, to comply without needing to go through a long and expensive audits and third-party certifications. The open source community and Kusari have been hard at work trying to ensure that security and attestation generation is baked in to their process. So software producers do not have to worry about have they will meet these new requirements and at the same time fix bugs and add features to the products they are selling.
Further Reading:
No older posts
No newer posts