Software companies that sell commercial software products to
federal agencies soon must begin attesting to their compliance with
guidance designed to enhance the security of the software supply
chain. Under a new White House Office of Management and Budget
(OMB) memorandum issued September 14, federal
agencies must require software “producers” (i.e., the
developers of software) to confirm their compliance with specific
guidance created by the National Institutes of Standards and
Technology (NIST). The OMB memorandum implements the software
supply chain enhancements first suggested under Executive Order
(EO) 14028, Improving the Nation’s Cybersecurity, on
which we’ve previously commented.
For purposes of the memorandum, the term “software”
includes firmware, operating systems, applications, and cloud-based
software, as well as products that contain software. The new
requirements apply to software developed after the memorandum’s
effective date (more on this below), and to existing software if
modified by major version changes. Once the policy is in full
effect, federal agencies may only use software if the software
producer has attested to compliance with the NIST guidance, subject
to certain limited exceptions. The purpose of the new requirements
is to protect federal information systems from cyberattacks by
ensuring the integrity of software acquired by the government. The
policy can be traced to the SolarWinds compromise that impacted
multiple U.S. government systems and other similar security
incidents.
When do the new rules take effect?
Under the scheme set forth in the OMB memorandum, agencies have
90 days (or until December 14) to inventory their existing software
and 120 days (until January 14, 2023) to develop a process for
communication with software vendors. Agencies must begin collecting
attestation letters for “critical software”1
within 270 days (by June 14, 2023) and for all other software
within 365 days (by September 14, 2023). In other words, within the
next year, any software company seeking to sell its products to the
federal government will need to assess and come into compliance
with the NIST guidance. Note, however, the memorandum does permit
agencies to request extensions of the above deadlines. If past is
prologue, the implementation timeline may well be expanded beyond a
year.
What is the relevant NIST guidance?
The two publications collectively referred to as the “NIST
Guidance” in the OMB memorandum are the NIST
Special Publication (SP) 800-218 – Secure Software
Development Framework (SSDF) and the NIST Software Supply Chain Security
Guidance.
NIST SP 800-218 provides high-level guidance on how software
producers can integrate security into the software development life
cycle. The framework consists of four recommendations, each broken
down into a series of more specific practices and more well defined
tasks, followed by examples and references. The recommendations
are:
- Prepare the organization, by ensuring that the people,
processes, and technology are prepared to perform secure software
development. - Protect the software, including all components from tampering
and unauthorized access. - Produce well-secured software, with minimal security
vulnerabilities in each release. - Respond to vulnerabilities, by identifying residual
vulnerabilities and responding appropriately to address those
vulnerabilities and prevent similar ones from occurring in the
future.
The publication takes the form of a chart, mapping out each
recommendation, practice, and task. The executive summary clarifies
that not all practices apply to every use case, and that
organizations should adopt a risk-based approach to determine which
practices are relevant, appropriate, and effective to mitigate the
threats to their software development practices.
The NIST Software Supply Chain Security Guidance provides
additional direction, aimed primarily at agencies, to assist in
integrating the SSDF into procurements. The guidance clarifies that
although open-source software freely obtained by federal agencies
falls outside the scope of the framework, open-source software that
is bundled, integrated, or otherwise used as part of any
third-party software purchased by agencies is covered by the SSDF.
Additionally, the guidance applies to both on premises and
cloud-hosted software. The guidance further recommends that
agencies:
- Use the SSDF’s terminology and structure to organize
communications about secure software development requirements. - Require attestation to cover secure software development
practices performed as part of processes and procedures throughout
the software life cycle. - Accept first-party attestation of conformity with SSDF
practices unless a risk-based approach determines that second or
third-party attestation is required. - Request high-level artifacts demonstrating conformance, when
needed.
How do I provide an attestation?
The Department of Homeland Security’s Cybersecurity and
Infrastructure Security Agency (CISA) has been directed to work
with OMB to establish a “common form” suitable for use by
multiple agencies. The form will provide a minimum level of
assurance that the vendor followed NIST Guidance, and will include
the software producer’s name, a description of the product or
products the statement covers, and a statement attesting that the
software producer followed NIST recommended secure development
practices.
Alternatively, a vendor may obtain a third-party assessment,
provided by a certified FedRAMP Third-Party Assessor Organization
(3PAO) or another assessor approved by the agency, in lieu of
attestation. The OMB memorandum suggests that use of this process
might be especially useful for open source software, or products
incorporating open source software.
Beyond the simple attestation form, agencies may also request
artifacts in future solicitations, such as a complete Software Bill
of Materials (SBOM), depending on the criticality of the software
or the agency’s determination of need.
To facilitate information sharing with the government, within
the next two years CISA will establish a government-wide repository
for software attestations and artifacts. As needed, CISA also will
publish updated SBOM guidance for federal agencies.
What if my software does not fully comply?
In exceptional circumstances, and only for limited durations,
agencies may seek a waiver of specific requirements from OMB, which
will review the requests on a case-by-case basis. OMB will post
specific instructions for submitting waiver or extension requests
within 90 days.
If a software producer cannot attest to its conformance with one
or more practices from the NIST Guidance, the requesting agency
shall require the software producer to identify those practices to
which they cannot attest, document measures in place to mitigate
risks, and require a Plan of Action & Milestones (POA&M) to
be developed. The POA&M and other documentation will not be
posted publicly by either the vendor or the agency. If the software
producer supplies this documentation and the agency finds the
POA&M satisfactory, the agency may use the software despite the
producer’s inability to provide a complete
self-attestation.
What if my company does not develop software, but uses
third-party software in its products?
The scope of the attestation requirement extends not just to
stand alone software and cloud-based software-as-a-service
offerings but also to other products that incorporate third-party
software. Under the process as described, the attestation must come
from the software “producer” itself. But companies that
incorporate third-party software into their own products will have
a vested interest in ensuring compliance by their essential
software subcontractors, as the end products incorporating the
software may not be sold to the government absent an attestation
(or use of an alternative assessment methodology, or an agency
waiver).
Conclusion
By requiring software producers to attest to compliance with the
NIST Guidance, the government aims to ensure that companies
undertake a risk-based approach to secure software development,
which ultimately will help ensure the overall security of federal
information systems. Given the deadlines, all companies that sell
(or want to sell) software to the government, whether directly or
through resellers or other channels, should quickly assess their
compliance with the NIST Guidance, develop action plans to address
any gaps, and carefully document their activities. Some companies
may be required to rethink development strategy for new products or
major version upgrades. As with all recent government cybersecurity
initiatives, dates may slip and the contours of the requirements
may change around the edges, but the basic policy directive here is
clear, and software producers that intend to keep the U.S.
government as customers need to get on board. In addition,
contractors whose products rely upon or incorporate software will
need to ensure that the vendors upon which they are dependent are
fully engaged in the attestation process.
By implementing the policy through an attestation form rather
than a contract clause, the government is making sure software
producers are directly involved in the process, and are legally
liable, under False Statements and False Claims Act authority, for
any misrepresentations or misstatements. This was surely a
deliberate decision to reinforce the seriousness of the issue and
to help ensure more widespread compliance. As with any attestation
or certification requirement, the new policy brings with it the
potential for enforcement actions, whether initiated by the
government or by False Claims Act qui tam relators.
Software vendors therefore should pay particular attention to their
compliance assessments and the representations that they make going
forward.
Footnote
1. A prior OMB memorandum directed NIST to issue
guidance of security measures for “critical software,”
defined as any software that has, or has direct software
dependencies upon, one of more components with at least one of
these attributes:
- is designed to run with elevated privilege or manage
privileges; - has direct or privileged access to networking or
computing resources; - is designed to control access to data or operational
technology; - performs a function critical to trust; or
- operates outside of normal trust boundaries with
privileged access.
Because of the generality of this update, the information
provided herein may not be applicable in all situations and should
not be acted upon without specific legal advice based on particular
situations.
© Morrison & Foerster LLP. All rights reserved
