Policy Patches: An Update on Software Security Regulation

So far, 2024 has been another very busy year for U.S. cybersecurity regulation. Among the top priorities has been software security, as we previewed early this year. Companies that sell software to the federal government or provide enterprise software or IT services, especially to U.S. critical infrastructure, are likely to be impacted by evolving regulations and policies. This post follows up on some of the major software security initiatives underway in the federal government and suggests ways for companies to prepare for possible new mandates.

Secure Development Practices: Federal Government Expands Attestation Expectations

We noted in April that the Cybersecurity and Infrastructure Security Agency (CISA) had finalized a “Common Form” for Secure Software Development Attestation to support the attestation requirement established by the Office of Management and Budget in its September 2022 guidance memorandum M-22-18. The Form provides a method for agencies to obtain attestations that software producers are using the National Institute of Standards and Technology (NIST) SP 800-218 Secure Software Development Framework. After CISA finalized the Common Form, agencies began requiring attestation forms for “critical software” in June 2024, and another deadline looms in September for all other software. As we predicted, seeking attestation without a uniform Federal Acquisition Regulation (FAR) rule has led to a fragmented and, frankly, confusing landscape for contractors. Some agencies, such as the General Services Administration (GSA), have issued clarifying guidance specifying who must provide attestations and in what context (i.e., for new contracts and when agencies exercise contract options). GSA also issued a memo with guidance for its popular FedRAMP cloud services program. But not all agencies have done so.

Some agencies, such as CISA, have directly contacted companies whose software the agency believes it is using and asked for attestations. We are also seeing some contractors seek to obtain attestations from their own subcontractors, although the Common Form indicates that software producers are not obligated to collect attestations from their own suppliers or subcontractors. A FAR rule to provide clarity and uniformity continues to be developed with a goal of releasing a Notice of Proposed Rulemaking in summer 2024, but as of this writing, the draft rule has been reviewed by the White House Office of Management and Budget and returned to agency procurement staff for revisions. In this uncertain environment, companies should be on the lookout for Secure Software Development Attestation requests from agencies or customers and carefully consider their government and commercial contractual obligations. If they have not already done so, software producers who sell to the federal government should be reviewing NIST’s guidance and evaluating whether they could attest to the practices – and if not, what remedial action would be needed to do so in the future.

CISA and ONCD Continue to Focus on “Ecosystem” Changes

In addition to leading up the Secure Software Development Attestation Common Form proceeding, CISA has been using its bully pulpit to advocate for large-scale changes to software development practices that shift costs and liability to software developers. CISA Director Jen Easterly argued recently, “We don’t have a cybersecurity problem. We have a software quality problem.” CISA’s “Secure by Design” initiative has continued to produce guidance, including a new series of “alerts” focusing on types or classes of vulnerabilities. CISA has also partnered with the FBI to provide guidance for government agencies, and with industry groups for commercial customers, to facilitate discussions with software producers over those producers’ security practices. CISA used the spring 2024 RSA Conference to roll out a voluntary “pledge” for enterprise software manufacturers that has garnered 194 signers of all sizes and types as of this writing. The agency also continued its work on open-source software, following up on its fall 2023 “roadmap” with joint research publications and announcing future work on measuring trustworthiness in open-source components. CISA also issued a steady stream of software and hardware vulnerability alerts.

Meanwhile, the Office of the National Cyber Director (ONCD) released a May 2024 “Version 2” of the National Cybersecurity Strategy Implementation Plan that highlights ongoing and planned activity. ONCD will continue its efforts to develop a software liability framework, recognizing that legislation would likely be needed to do so. ONCD convened a legal symposium on software liability in March 2024, and plans to continue to offer public engagement opportunities to gather feedback. ONCD also previewed in its Implementation Plan that a software liability regime would include an “adaptable safe harbor framework.” In addition to its work on software liability, ONCD recently released a summary report of an August 2023 Request for Information on open-source software security that outlines federal government partnerships with the open-source community. In the report, ONCD advocates for steps to secure open-source projects and repositories and reiterates support for promotion and implementation of Software Bill of Materials (SBOM). Lastly, the White House is working on an additional Executive Order on secure software development that it hopes to issue by the end of 2024.

Agencies Move to Institute Requirements for Software Bill of Materials

The National Cybersecurity Strategy Implementation Plan also notes that CISA and other Sector Risk Management Agencies will seek to advance the use of SBOM to “collect data on the usage of unsupported software in critical infrastructure.” CISA has been facilitating an SBOM community effort to develop guidance, while federal agencies are increasingly inserting or proposing SBOMs as a condition of funding or contract. For example, the National Telecommunications and Information Administration’s Public Wireless Supply Chain Innovation Fund requires projects awarded grant funding to include an SBOM or Hardware Bill of Materials, while the FAR Council’s October 2023 proposed rule on cyber threat and incident reporting included a proposed requirement for contractors to develop and maintain an SBOM for any software used in performance of a contract. It remains to be seen whether these individual agency pushes will reach a critical mass over the next several months, and observers will be watching closely to see whether the SBOM requirement is included in the final FAR rule.

What Can Organizations Do to Prepare?

  • Assess current practices against the NIST Secure Software Development Framework and CISA’s Secure by Design pledge. Many software producers who sell to the government have been working to prepare for the attestation requirement for some time, but the piecemeal rollout has made both assessing an individual company’s obligations to its government and commercial customers, and ensuring compliance, more challenging. The ongoing FAR rulemaking will establish more uniform procedures and practices, but industry expectations are adapting now based on government requirements and guidance. As SBOMs and other secure development practices become more widely required for government contractors, their use is likely to be adopted into enterprise business-to-business contracts, which will in turn present risk if organizations are not ensuring that they are using industry best practices.  
  • Consider expanding compliance programs. The adoption of the attestation requirement and increase in federal government use of SBOM provides more details around what the government expects from its suppliers. The federal government has continued to leverage the False Claims Act to address cybersecurity deficiencies, making compliance all the more important.
Wiley Connect

Sign up for updates

Wiley Rein LLP Cookie Preference Center

Your Privacy

When you visit our website, we use cookies on your browser to collect information. The information collected might relate to you, your preferences, or your device, and is mostly used to make the site work as you expect it to and to provide a more personalized web experience. For more information about how we use Cookies, please see our Privacy Policy.

Strictly Necessary Cookies

Always Active

Necessary cookies enable core functionality such as security, network management, and accessibility. These cookies may only be disabled by changing your browser settings, but this may affect how the website functions.

Functional Cookies

Always Active

Some functions of the site require remembering user choices, for example your cookie preference, or keyword search highlighting. These do not store any personal information.

Form Submissions

Always Active

When submitting your data, for example on a contact form or event registration, a cookie might be used to monitor the state of your submission across pages.

Performance Cookies

Performance cookies help us improve our website by collecting and reporting information on its usage. We access and process information from these cookies at an aggregate level.

Powered by Firmseek