This is a joint blog post with third-party security attestation company Schellman, where Sully Perella and Christian Baer work with software providers in highly regulated areas like SOC, PCI, ISO, HIPAA, HITRUST and FedRAMP. Following are key takeaways from a recent conversation between Perella and Baer, and Chainguard CEO and co-founder Dan Lorenc.
It has been a tough assignment for CISOs to try to keep up with the firehose of regulatory activity around software supply chain security that began with the White House’s Executive Order on Improving the Nation’s Cybersecurity in response to the SolarWinds incident three years ago and then continued with the introduction of the National Institute of Standards and Technology’s (NIST) Secure Software Development Framework (SSDF).
Though there has been a lot to digest, now, in the aftermath of Log4j security gains, most CISOs have come to understand the importance of adopting supply chain security best practices like software signing, and we’re seeing a tremendous industry effort to drive concepts of provenance into the software development lifecycle. But developments in other areas like SBOMs (software bills of materials) remain more ephemeral, making it easy to get lulled into a sense that any coming regulatory waves are still far away.
But this April, the Cybersecurity & Infrastructure Agency (CISA) published a request for comment on a newly proposed Secure Software Self-Attestation Form - a development that should have every CISO taking a hard look.
The attestation form is a very specific implementation and could drastically change how liabilities for insecure software are applied, and as many companies are assuming that finalization is imminent and are taking steps to align themselves with the underlying requirements, let’s take a closer look at some of the key takeaways that should be on your radar.
What is security self-attestation?
If and when this form is finalized, secure software self-attestation would require organizations that wish to sell – or continue selling – software for government use to attest to their own best efforts to abide by the principles of the SSDF. According to the form: “This self-attestation form identifies the minimum secure software development requirements a software producer must meet, and attest to meeting, before their software subject to the requirements of M-22-18 may be used by Federal agencies. This form is used by software producers to attest that the software they produce was developed in conformity with specified secure software development practices.”
While these are the high-level areas, the requirements are grounded in NIST SP 800-218, Secure Software Development Framework—as such, to meet the intent of the self-attestation, companies need to comply with the SSDF.
Self-attestation creates much-needed incentive
For decades, we’ve seen software suppliers selling to the government while skirting security recommendations - even when required by processes like PCI, SOC, FedRAMP, or even cybersecurity insurance providers. And while it represents an important step in the evolution of regulation, this NIST SSDF framework – together with the White House decrees – could not alone compel companies to follow these industry-standard best practices.
Still, this administration has made it clear that the responsibility – read; liability – for securing software needs to shift from the user to the provider, and whether you want to consider it a carrot or a stick, security self-attestation is a very specific incentive that – in much more specific language – does put the onus on software suppliers to the federal government to take the right security measures outlines in NIST’s SSDF framework.
What are “reasonable” steps?
The self-attestation form insists on “reasonable” steps, in the context of two specific provisions:
But what exactly does “reasonable mean?
Similar to HIPAA which allows covered entities and business associates to use a HIPAA-compliant or aligned security program as a reasonable basis to reduce liability if a breach occurs, it also seems rational to infer that if you implement the NIST SSDF in 800-218, you’ll be better protected should something happen.
But the degree to which you met SSDF practices in a “reasonable” manner remains to be seen. In the same manner that an organization must define how risk is quantified (i.e. low, medium, high, critical, etc.) the term "reasonable" needs to have parameters applied – for now, the pragmatic approach is to follow the NIST SSDF.
Third-party assessors can help with self-attestation.
If self-attestation does indeed become the standard for certifying software supply chain security, many CEOs and boards might still prefer a third-party attestation model as a defendable basis for their program.
The form explicitly allows software vendors to use an authorized FedRAMP Third Party Assessment Organization (3PAO) — like Schellman — to validate their software development practices and attach the findings to the self-attestation form. As part of this additional assurance around the assertions made by the software provider, the 3PAO should assess the development practices against the form’s areas of focus, as well as NIST 800-218.
Working with an authorized FedRAMP 3PAO could make this process easier for vendors, as their assessor is accredited by the federal government to conduct cybersecurity assessments—in fact, Schellman is already conducting these assessments for several of our clients today.
There are still a lot of questions on how the government will use the attestations
No matter how CISOs decide to proceed regarding their organization’s attestation, agencies have been directed to start collecting them for critical software no later than three months from the date CISA’s self-attestation form is finalized and six months from the finalization of the form for all other third-party software (per M-23-16, Update to Memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices).
Yet for all the positive reception for a self-attestation model, questions are swirling around how agencies will actually ingest these forms. SBOMs are required for both on-premise and cloud software, but what are agencies going to do with those? While there seems to be broad agreement that getting these self-attestation artifacts in place is important, ultimately they won’t be impactful if the agencies don’t know what to do with the information—the ongoing management of third-party software is not easy, and no existing framework provides a functional concept to meet this need.
Part of what’s not clear is how agencies will use these self-attestations to understand the risks of particular components or supplier software. Programs like FedRAMP were designed so agencies don’t have to duplicate efforts to understand those risks, so it will be interesting to track the same consideration as this self-attestation evolves.
Smart CISOs will parlay self-attestation with FedRAMP efforts
Speaking of FedRAMP, the 800-53 Rev 5 update contains a lot of new language around software supply chain security—where previously FedRAMP primarily focused on production, Rev. 5 represents real progression towards evaluating the components in software supply chains and whether providers are performing all the required scanning. Now that FedRAMP has added additional security controls around supply chain, we can see a lot of intersections between the new self-attestation requirements and the software supply chain security hurdles that are being baked into the FedRAMP process itself.
Smart CISOs are going to try to figure out ways to parlay the FedRAMP process with this software security self-attestation journey, which will be made easier because there is an actual path to combining these efforts through partial mappings between the SSDF back to 800-53.
What next?
Integrating efforts is an option for those organizations required to self-attest, but those that aren’t could take the opportunity to evaluate their SDLC and leverage the SSDF as a competitive advantage to ultimately promote their security practices and posture.
In order to help vendors with the security of their SDLC, Schellman has launched the Schellman Software Security Assessment (S3A) – a service that features different options that can be tailored to an organization’s needs. The S3A could be a good opportunity for vendors who are looking to take the first step in assessing their software practices against the SSDF.
CVE triage and vulnerability management are major pain points for organizations who are going to have to comply with the self-attestation form, or who are currently renewing or undergoing FedRAMP certification. Chainguard Images are a suite of hardened, minimal container images that are frequently rebuilt and contain a minimal attack surface and can help organizations looking to comply with the upcoming software self-attestation requirements or FedRAMP authorization.
If you’d like to learn more about the topics discussed in today’s blog post, register for our upcoming webinar on Tuesday, September 12 with Schellman and Chainguard leaders.
Further Information
