The Secure Software Self-Attestation Saga Continues

If you have been paying attention, you know that the U.S. Federal Government is on a crusade to drive improvements in the software supply chain and is championing secure software development.

They’ve rolled out a series of memos, frameworks, guidance and requirements, all deriving from the Cybersecurity Executive Order (EO) section 4, which focused heavily on the software supply chain.

For those late to the party, we’ve covered many of these topics previously and I recommend starting with the following resources:

• Cybersecurity Executive Order (EO)

• OMB Memo 22-18 Enhancing the Security of the Software Supply Chain through Secure Software Development Practices

• NIST Secure Software Development Framework (SSDF)

• My article discussing 22-18 and SSDF

• My article discussing CISA Secure Software Self-Attestation Form

The originally published 22-18 memo set off a series of timelines associated with agencies needing to collect self-attestations (and in some cases potentially use a third party assessor 3PAO) along with CISA publishing a draft self-attestation form that software suppliers would provide to the government attesting that they are following the specified NIST SSDF practices.

However, due to challenges, such as the self-attestation form still being in a draft format, collecting industry feedback, along with agencies and industry hustling to prepare and respond to the new requirements OMB recently issued memo 23-16 “Update to Memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices”

In this article, we will step through some of those updates and key takeaways.

First off, lets be clear that this is not the Government backing away from their commitment to secure software development practices among their supplier base. It opens by plainly stating “This memorandum reinforces the requirements established in M-22-18, reaffirming the importance of secure software development practices”.

Extension of Attestation Collection

One thing the memo does is extend the timeline for Federal agencies to begin collecting attestations from their software producers and suppliers. It still applies to software developed after September 14th 2022 as well as software developed prior that:

• Has a major version change/update after September 14th 2022

• Is utilizing CI/CD

• Is delivered as-a-Service (e.g. SaaS)

It does however extend the timeline from the original date to now being:

• For critical software (as defined by NIST), is 3 months after the attestation form released by CISA is finalized, beyond its draft form

• For all software subject to the requirements delineated in 22-18, six months after the forms CISA forms final approval

Clarifying the Scope of M-22-18 Requirements

Third Party Components

As we have discussed extensively in the blog, and in the book “Software Transparency”, which I recently published with Wiley, the majority of modern codebases are composes of open source software (OSS)/third-party components, with estimates ranging from 60-80%, based on sources such as Synopsys and others. Furthermore, 90%+ of codebases consist of some level of OSS/third-party components, with an equally large share having at least one high level vulnerability or more.

However, despite the widespread adoption of OSS and its use in modern applications and software, most organizations have a poor understanding of the OSS in their software and products and they often put the onus on the OSS contributors/maintainers when it comes to security of said components, attempting to treat them as suppliers themselves, when they are not.

As we have discussed extensively, such as in our “Supplier Misnomer” article, OSS maintainers are not suppliers. You use their software and components as-is and you’re responsible for the security of your end product, including the OSS you integrate into it.

The M-23-16 OMB memo reiterates this, leveraging an economic concept known as “least cost avoider” and points out that

The memo emphasizes that the best practices and methodologies required in 22-18, derived from SSDF extend to the utilization of OSS and proprietary third-party software components. This includes activities of course such as secure build and development environments and logging and monitoring trust relationships, but also “maintaining provenance data for internal and third-party code; and maintaining trusted source code supply chains”.

This means software suppliers selling to the Federal government must understand where their software comes from, including the origins of third-party components, and that those components are coming from trustworthy and vetted sources.

To clearly define “provenance” we will leverage a definition from one of the leading software supply chain security frameworks, Supply Chain Levels for Software Artifacts (SLSA). It defines provenance as:

Another worthwhile example to site is the OWASP Software Component Verification Standard (SCVS) which has specific controls and maturity levels for controls such as pedigree and provenance, which can be seen in a table below:

The big takeaway here is that software suppliers/producers selling to the Federal government will be responsible for all of the components in their products, including the OSS components they include. This means they need to understand the vulnerability footprint of those components, the level of maintenance and sustainability among the component maintainers and the provenance of the components (e.g. where they actually originate from).

None of this is a trivial matter, especially in the robust and diverse world of OSS.

It puts the onus on the software suppliers to account for third-party components in their products, rather than placing the onus on OSS maintainers as well as not placing the burden on the Federal government to understand the vulnerabilities and origins of components in a product as well.

This transparency and data can and will all be communicated through the artifact known as a Software Bill of Materials (SBOM), which has gained tremendous industry attention and one we have discussed extensively throughout other articles. You can find out more about SBOM’s at the CISA website here.

Freely Obtained and Publicly Available Proprietary Software

One interesting aspect of the memo is that it covers proprietary software that is “freely obtained and publicly available”.

This creates a unique scenario where vendors may, and do, give their software away for use, perhaps as part of a “freemium” model where they upsell to paid versions over time, or offer accompanying services at cost to those using the free software.

Under this clarification, freely obtained and publicly available proprietary software would be exempt from 22-18 and the associated SSDF practices and attestation, despite the obvious reality that freely available software still can be vulnerable, exploited by malicious actors, and impose risks on consuming agencies.

That said, it presents an interesting conundrum in the sense that agencies cannot ask vendors that give something away to meet SSDF practices and OMB memo security requirements and self-attestations when there is no money changing hands and the product/software was given away for free.

This emphasizes the need for agencies to have accurate software asset inventories, including freely obtained proprietary software and SaaS, each of which introduces cybersecurity risks, even if they are painless financially (free).

This Twitter meme stolen from my friend, co-founder of Chainguard, Dan Lorenc pokes fun at the obvious situation this creates.

Federal Contractor Developed Software

Federal agencies employ massive armies of Federal contract staff. If agencies develop software directly rather than buy it from a software supplier, it is done so through Federal contractors, from large organizations such as Booz Allen Hamilton, Leidos, GDIT down to small disadvantaged businesses such as women, minority-owned or Service Disabled Veteran Owned Small Businesses (SDVOSB)’s.

M-23-16 states that agency developed software remains “out of scope” of 22-18 requirements and any attestation collection requirements.

Where things get unique is that 23-16 states that:

While I’m not a lawyer, this seems to set the expectation that agency developed software is expected to leverage NIST SSDF as appropriate but there will be no 22-18 (which includes NIST SSDF practices) and attestation collection requirements?

It goes on to say that any concerns around whether software is considered “agency-developed”, as opposed as being procured from a software supplier or not should be determined by the CIO, since they are in the best position to determine whether the agencies specification and supervision of the contract meet the above defined standard.

This puts a massive onus on CIO’s, who are already juggling a myriad of other objectives such as digital modernization, zero trust, cloud migration, authorizing official duties and more, to now also additional discern across the agencies entire portfolio of software being developed by Federal contractors is considered “agency-developed” software or not.

I could this causing a lot of confusion, stress and frustration, as well as a bias for considering things “agency-developed” to avoid the addition burden of 22-18 and attestations from suppliers (Federal contractors developing software in this case).

The use of POAM’s by software producers submitted to Federal agencies

For those unfamiliar with the term POAM, it stands for Plans of Actions and Milestones (POAM), and is defined by NIST as follows:

POAM’s essentially equate to non-compliant controls and/or known risks and deficiencies which are documented by an agency along with an identification of the tasks needing to complete them and the resources to ensure they get completed - aka Plans of Actions and Milestones.

Understanding that no software producer will be able to immediately meet all of the defined SSDF practices and requirements laid out in 22-18, the memo along with 23-16 support the use of POAM’s for software suppliers to be able to identify deficiencies in their attestations to the Federal government and create POAM’s to define why the practice can’t be met, what compensating controls are in place to mitigate risks, and what tasks and resources will be necessary to address the deficiency and by when.

The use of POAM’s was already codified in 22-18 but OMB took it further in 23-16 and stated that:

This means agencies can continue to use software from suppliers that have deficiencies with 22-18 and SSDF compliance but they must not only submit the POAM’s to the agency to be approved but the agency must also submit the POAM’s to OMB to review as well.

On one hand this creates an addition level of oversight to ensure agencies are properly having their suppliers document compliance deficiencies and compensating controls, but it also creates a massive paperwork toil on OMB to address as they will inevitably be receiving thousands of these across the Federal Civilian (FedCiv) ecosystem of agencies and their massive supplier base and OMB, who is several levels disconnected from the actual software and supplier will now need to subjectively determine if the POAM’s and compensating controls are sufficient.

I hate to say it, but while this activity on the surface gives the perception of additional oversight, it ultimately creates a massive paperwork compliance process and workflow for the suppliers/agencies/OMB and likely does more to make us feel good than actually mitigating real cybersecurity risks. The challenge of course is if we went with the alternative of no oversight, there would be a lot of creative activities occurring by agencies who don’t want to stop using software from suppliers, even if it isn’t meeting SSDF practices and 22-18 requirements.

There’s also the challenge that POAM’s present themselves, which is they often go on un-remediated indefinitely, with implementation dates and details just being extended over and over. Anyone with experience securing Federal IT systems under the Risk Management Framework (RMF), which also makes use of POAM’s will be all too familiar with this scenario.

The guidance does state that:

This essentially creates a scenario where theoretically the agency will discontinue using software, even if it is supporting critical business and operational activities, but has insufficient documentation. One can’t help but feel a bit skeptical that this will occur, and rather it is likely the producer will be brow beaten until they pencil whip enough sufficient documentation to ease concerns.

We need to keep in mind that contracts will be on the line, which impacts suppliers revenues, and the SSDF practices, along with accompanying gaps and deficiencies will all be self-attested to by suppliers, a situation we have already seen play out with the Defense Industrial Base (DIB) via NIST 800-171 which originally used self-attestations but then advanced to third-party audits/assessments under 171 and soon CMMC due to numerous examples and scenarios proving that suppliers were either lying, or innocently attesting to security controls they simply weren’t doing. But don’t mind me, I may be what one would call a skeptic when it comes to self-attestations.

Agencies are able to file for extensions and waiver requests through a website known as MAX.gov and OMB will be reviewing/approving these as well as designating a lead in scenarios where POAM’s from a supplier are impacting numerous agencies, to avoid duplication of effort, and of documentation.

Key Dates

The OMB M-23-16 closes with a table capturing the key dates originally published in M-22-18 and now updated here in 23-16. Please find the table below.

Now What?

Where we go from here remains to be seen. That said, one thing is clear and that is that the U.S. Federal government is adamant about driving improvements in the software supply chain when it comes to security and they’re willing to use their procurement and purchasing power to initially drive requirements to their immediate software supplier base.

While these emerging requirements aren’t perfect, we are dealing with an incredibly complex ecosystem with a variety of stakeholders of differing maturity, resources and interests and the Government is making efforts to foster a level of transparency in the software supply chain that historically hasn’t existed, and I’m an advocate for further transparency and driving the adoption and codification of secure software development practices of suppliers providing software to our Federal agencies and Department of Defense (DoD) mission owners.