The standards agency said an attestation from the vendor themselves would be sufficient when screening for cybersecurity, unless an agency’s risk calculus suggests otherwise.
Federal procurement officials should err on the side of accepting declarations software vendors make about their products, in part to address concerns about cost and the protection of intellectual property, according to the National Institute of Standards and Technology.
The recommendation came in one of five documents NIST published Friday to meet its obligation under Executive Order 14028. The order was issued in response to a hacking campaign called ‘SolarWinds,’ after a government-contracted IT management firm that adversaries leveraged to infect their targets, including federal agencies, with malware.
“Accept first-party attestation of conformity with [Secure Software Design Framework] practices unless a risk-based approach determines that second or third-party attestation is required,” NIST wrote in guidance for federal officials with procurement responsibilities. “First-party attestation is recommended for meeting the EO 14028 requirements.”
The standards agency explains that ‘first-party’ or ‘self’ attestation is where the vendor itself vouches for their software, whereas second-party attestation involves a review by agency staff purchasing the software, and third-party attestation—the subject of the Defense Department’s Cybersecurity Maturity Model Certification—involves an independent verifier of conformity with the necessary security practices. DOD initiated CMMC after it determined first-party attestations were an unreliable indicator of contractor security.
The Secure Software Design Framework itself—a NIST special publication that is also aimed at government producers of software—is not particularly new. It started as a white paper that’s been around in draft form since July, 2019. NIST revised the document to serve as its basis for software development evaluation criteria and also cites it in material that will inform pilot projects on creating consumer labels for software and the connected devices that make up the internet of things, as also required by the EO. Visibility into the level of an entity’s adherence to the framework would determine if an entity uses established security best practices like “multi-factor, risk-based authentication and conditional access” in its systems.
The framework for secure software development lays out options for software producers—based on their individual risk factors—that includes use of the minimum elements of a software bill of materials. SBOM proponents, including top government officials, view it as a crucial tool for addressing vulnerabilities like one found in open-source software library log4j. But SBOMs have received pushback from some major providers of government software who claim concerns over the loss of their intellectual property.
NIST also details how agencies should think about asking for artifacts, which are generally described as evidence of conformity with security practices listed in its SSDF. The agency describes “low-level” and “high-level” artifacts. But where low-level artifacts refer to items “generated during software development,” and can include log entries, source code vulnerability scan reports and testing results for a particular piece of software, NIST says, high-level artifacts “may be generated by summarizing secure software development practices derived from the low-level artifacts.”
According to NIST, that means “a publicly accessible document describing the methodology, procedures, and processes a software producer uses for its secure practices for software development” would qualify as a high-level artifact.
“Asking for low-level artifacts for a particular software release is not recommended for meeting the requirements of EO 14028,” NIST said. The Commerce Department emphasized that its minimum recommendations may not be enough to meet some agencies’ other requirements.
“Understanding low-level artifacts requires the agency to expend considerable technical resources and expertise in analyzing them and determining how to consider them within the context of the broader secure software development practices,” NIST wrote, adding, “Low-level artifacts often contain intellectual property or other proprietary information, or details that attackers could use for hostile purposes, so accepting low-level artifacts gives the agency additional sensitive information to protect.”
The agency also noted that “agencies requiring greater visibility into [contractor] practices may increase costs for software producers, and thus may increase product prices.”
Industry and government stakeholders weighed in with NIST on development of the guidance, including through virtual workshops last summer. The document will now feed into recommendations the director of Office of Management and Budget, and other major department heads must make to the Federal Acquisition Regulatory Council by May that could result in changes to contracting language.
