The Cybersecurity and Infrastructure Security Agency recently released the longawaited secure software development framework (SSDF) attestation form. This action automatically restarted the clock on the Office of Management and Budget’s requirement that all critical software must be attested within 90 days and all other software must be attested within 180 days of the finalized form.
Concurrently, CISA launched the repository for software attestations and artifacts
(RSAA), a web portal where CISA expects federal agency representatives and
software producers alike will “be able to review and upload software attestation
forms, artifacts, and make organization-specific annotations to entries in
accordance with their job responsibilities.”
What happens on the first business day following the 90- and 180-day waiting
period, June 10 and Sept. 9, respectively, is now in the hands of acquisition teams
and authorizing officials. The SSDF attestation requirement forced on industry will
either be ridiculed as another form of compliance theater or heralded as a pathway
to an accelerated issuance of an authorizations to operate (ATOs) and greater cyber
resiliency across the massive swath of government procured products and services.
Unlike the Federal Risk Authorization and Management Program (FedRAMP)
program that predominantly focuses on cloud service providers, OMB has made it
clear that SSDF attestations cover all software including firmware, embedded and
cloud service offerings. The software that powers anti-lock brakes in a forestry
service pickup, that powers the microwave in the Department of Veterans Affairs
hospital break room, that powers the palm readers to access classified areas, and
everything else in between now must be attested to following the SSDF before the
government will buy. The hope is that by adopting this broad definition of software
the government’s buying power alone will profoundly influence and reshape the
cybersecurity behaviors of all software producers.
In fact, even those software producers that already have offerings listed in the
FedRAMP marketplace likely have additional work to do to achieve SSDF
compliance before they can attest. Specifically, the FedRAMP moderate and high
baselines, largely based upon the National Institute of Standards and Technology’s
Special Publication 800-53, do not explicitly require the supply chain risk
management family’s provenance control, SR-4. However, the SSDF extensively
focuses on provenance, with each of the four SSDF groupings including explicit
tasks that can only be satisfied by creating and securely managing trusted telemetry
to establish an irrefutable set of provenance data.
The SSDF definition for provenance is pulled straight from NIST SP 800-53: “The
chronology of the origin, development, ownership, location and changes to a
system or system component and associated data. It may also include personnel
and processes used to interact with or make modifications to the system,
component or associated data.”
The time has arrived for acquisition teams and authorizing officials (AOs) across
the federal landscape to collaboratively decide how important cyber resiliency
actually is to the constituents they serve. At first blush, a vendor filling out a PDF
form, self-certifying compliance and shoving the data into a bespoke repository
hosted by CISA could appear to offer little in the way of cyber resilience. This is
true only if acquisition teams and authorizing officials let this happen.
AOs now have a clear pathway to achieving something they’ve wanted for
decades: more input earlier in the acquisition cycle, or “shifting security left,” as it
is colloquially referred to. AOs have been afforded the opportunity to define and
establish resilience on “Day 0” of an acquisition instead of trying to bolt it on after
the fact like they largely do today. Under the auspices of Executive Order 14028,
Improving the Nation’s Cybersecurity, and through the software producer’s own
SSDF attestation, AOs can now collaborate with acquisition teams and stipulate
the types of provenance data they want to access to prior to the RFP’s publication
in the Federal Register.
In some cases a software bill of materials (SBOM), a provenance mechanism that
is generated at the end of the build process, may be sufficient. In other cases, AOs
may desire access to a more robust set of trusted telemetry captured across the
totality of all software build processes in so-called compliance pipelines, from
code commit through artifact creation. In both situations, any software producer
attesting SSDF compliance must have this provenance data to comply with SSDF
task Protect the Software 3.1: “Securely archive the necessary files and supporting
data (e.g., integrity verification information, provenance data) to be retained for
each software release.”
OMB cannot allow CISA to measure success of the SSDF attestation requirement
solely through the number of PDF forms submitted. Instead, the success and value
derived from the government through software producer SSDF attestations should
be measured by monitoring and reporting on how many requests for proposals now
ask for specific types of software provenance data. AOs and acquisition teams
must be educated and expected to more closely collaborate and define what level
of provenance data they seek through the RFP process. After all, once the software
producer submits their SSDF attestation form, producing the trusted telemetry is as
simple as taking existing metadata, zipping it up and uploading it into the RSAA.
The Biden administration has invested significant time and energy into
cybersecurity, publishing well over a thousand pages of guidance related to
securing the software supply chain and linked explicitly to CISA’s secure by
design initiatives. In 2023, the Justice Department reported it was party to 543
settlements and judgments exceeding $2.68 billion under the False Claims Act. It’s
time for AOs and acquisition teams to use the tools they’ve been given and
demand access to provenance data artifacts in their RFPs. Any software producer
that responds that they cannot provide the data or that assembling the data is too
complicated and time consuming after filing their SSDF attestation has likely run
afoul of the False Claims Act. Come Sept. 9, 2024 when all software requires
attestation, industry will be watching to see if SSDF attestation is headed towards
compliance theater, or if federal employees have started using these SSDF
attestations to achieve the true goal of EO 14028.
Jason Weiss is the chief operating officer of TestifySec and a former chief software officer for the Defense Department
Foundation for origin data through software attestations set
Jason Weiss, the chief operating officer of TestifySec, explains why CISA’s repository of software data must be more than ‘compliance theater.’
The Cybersecurity and Infrastructure Security Agency recently released the longawaited secure software development framework (SSDF) attestation form. This action automatically restarted the clock on the Office of Management and Budget’s requirement that all critical software must be attested within 90 days and all other software must be attested within 180 days of the finalized form.
Concurrently, CISA launched the repository for software attestations and artifacts
(RSAA), a web portal where CISA expects federal agency representatives and
software producers alike will “be able to review and upload software attestation
forms, artifacts, and make organization-specific annotations to entries in
accordance with their job responsibilities.”
What happens on the first business day following the 90- and 180-day waiting
period, June 10 and Sept. 9, respectively, is now in the hands of acquisition teams
and authorizing officials. The SSDF attestation requirement forced on industry will
either be ridiculed as another form of compliance theater or heralded as a pathway
to an accelerated issuance of an authorizations to operate (ATOs) and greater cyber
resiliency across the massive swath of government procured products and services.
Unlike the Federal Risk Authorization and Management Program (FedRAMP)
program that predominantly focuses on cloud service providers, OMB has made it
clear that SSDF attestations cover all software including firmware, embedded and
cloud service offerings. The software that powers anti-lock brakes in a forestry
service pickup, that powers the microwave in the Department of Veterans Affairs
hospital break room, that powers the palm readers to access classified areas, and
everything else in between now must be attested to following the SSDF before the
government will buy. The hope is that by adopting this broad definition of software
the government’s buying power alone will profoundly influence and reshape the
cybersecurity behaviors of all software producers.
Download our Insider’s Guide where we provide information, insights and advice you need to better understand and use AWS Marketplace to address your cybersecurity needs, sponsored by Carahsoft.
In fact, even those software producers that already have offerings listed in the
FedRAMP marketplace likely have additional work to do to achieve SSDF
compliance before they can attest. Specifically, the FedRAMP moderate and high
baselines, largely based upon the National Institute of Standards and Technology’s
Special Publication 800-53, do not explicitly require the supply chain risk
management family’s provenance control, SR-4. However, the SSDF extensively
focuses on provenance, with each of the four SSDF groupings including explicit
tasks that can only be satisfied by creating and securely managing trusted telemetry
to establish an irrefutable set of provenance data.
The SSDF definition for provenance is pulled straight from NIST SP 800-53: “The
chronology of the origin, development, ownership, location and changes to a
system or system component and associated data. It may also include personnel
and processes used to interact with or make modifications to the system,
component or associated data.”
The time has arrived for acquisition teams and authorizing officials (AOs) across
the federal landscape to collaboratively decide how important cyber resiliency
actually is to the constituents they serve. At first blush, a vendor filling out a PDF
form, self-certifying compliance and shoving the data into a bespoke repository
hosted by CISA could appear to offer little in the way of cyber resilience. This is
true only if acquisition teams and authorizing officials let this happen.
AOs now have a clear pathway to achieving something they’ve wanted for
decades: more input earlier in the acquisition cycle, or “shifting security left,” as it
is colloquially referred to. AOs have been afforded the opportunity to define and
establish resilience on “Day 0” of an acquisition instead of trying to bolt it on after
the fact like they largely do today. Under the auspices of Executive Order 14028,
Improving the Nation’s Cybersecurity, and through the software producer’s own
SSDF attestation, AOs can now collaborate with acquisition teams and stipulate
the types of provenance data they want to access to prior to the RFP’s publication
in the Federal Register.
In some cases a software bill of materials (SBOM), a provenance mechanism that
is generated at the end of the build process, may be sufficient. In other cases, AOs
may desire access to a more robust set of trusted telemetry captured across the
totality of all software build processes in so-called compliance pipelines, from
code commit through artifact creation. In both situations, any software producer
attesting SSDF compliance must have this provenance data to comply with SSDF
task Protect the Software 3.1: “Securely archive the necessary files and supporting
data (e.g., integrity verification information, provenance data) to be retained for
each software release.”
OMB cannot allow CISA to measure success of the SSDF attestation requirement
solely through the number of PDF forms submitted. Instead, the success and value
derived from the government through software producer SSDF attestations should
be measured by monitoring and reporting on how many requests for proposals now
ask for specific types of software provenance data. AOs and acquisition teams
must be educated and expected to more closely collaborate and define what level
of provenance data they seek through the RFP process. After all, once the software
producer submits their SSDF attestation form, producing the trusted telemetry is as
simple as taking existing metadata, zipping it up and uploading it into the RSAA.
The Biden administration has invested significant time and energy into
cybersecurity, publishing well over a thousand pages of guidance related to
securing the software supply chain and linked explicitly to CISA’s secure by
design initiatives. In 2023, the Justice Department reported it was party to 543
settlements and judgments exceeding $2.68 billion under the False Claims Act. It’s
time for AOs and acquisition teams to use the tools they’ve been given and
demand access to provenance data artifacts in their RFPs. Any software producer
that responds that they cannot provide the data or that assembling the data is too
complicated and time consuming after filing their SSDF attestation has likely run
afoul of the False Claims Act. Come Sept. 9, 2024 when all software requires
attestation, industry will be watching to see if SSDF attestation is headed towards
compliance theater, or if federal employees have started using these SSDF
attestations to achieve the true goal of EO 14028.
Jason Weiss is the chief operating officer of TestifySec and a former chief software
officer for the Defense Department
Read more: Commentary
Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.
Related Stories
Software development and continuous testing are the wind beneath the F-35’s wings
White House extends secure software attestation deadlines, offers clarifying guidance
CISA’s draft attestation form raises key questions about software security push