Attesting to secure software development practices

It’s been almost three years since President Biden issued Executive Order 14028, and while we’ve heard vendors talk about “compliance with EO 14028” for about that long, the reality is that industry hasn’t had anything to comply with—until now.

On March 11, CISA published the Secure Software Development Attestation Form as part of its obligations under OMB memo M-22-18 and the successor OMB memo M-23-16. Publication of the Self-Attestation form starts a clock in which any providers of software for use in critical infrastructure have 90 days to provide a completed form, and all other providers of software to the U.S. government have 180 days to do the same.

Like most government requirements, and the Self-Attestation form is a requirement, there are penalties for noncompliance. The form needs to be signed by someone within the software provider’s leadership team, potentially the CEO, and false statements are punishable under 18 U.S.C. § 1001, which covers False Statements made to the U.S. government. What this means is that any software producer that might be tempted to simply respond “Yes” to all questions should think twice about doing so.

Obviously, if you’re required to attest to software development practices, it’s helpful if those practices are well known and well understood. This is where the Self-Attestation form makes life easy, as software providers are expected to follow a subset of the NIST Secure Software Development Framework (SSDF) activities. The 42 activities in the SSDF also have line-of-sight to other standards like IEC 62443, and maturity models like the BSIMM.

This then means that for organizations that have benchmarked their software development policies, processes, and workflows against a NIST-referenced standard or model, attesting to the elements in the Self-Attestation form should be simple. For those businesses that are pursuing a FedRAMP Authorization, the Self-Attestation form allows for a FedRAMP 3PAO Assessor to provide an independent attestation that can be used in lieu of self-attestation.

How consistent are your secure development processes?

But what about all those businesses whose software is in use within the U.S. government but aren’t FedRAMP authorized? Some might feel that the risk of making a mistake when self-attesting isn’t worth taking. Given that there are far more than the 328 FedRAMP-authorized applications running within the U.S. government, a trustworthy attestation process needs to exist. Ideally, it should identify whether the corporate policies governing software development are consistently followed by development teams.

This is where Black Duck comes in. Black Duck is an independent provider of BSIMM assessments and has been delivering BSIMM assessments for over a dozen years. Since a BSIMM is a reference for the NIST SSDF, and knowing that the Self-Attestation form has been coming for the last year, it stands to reason that we’ve created an SSDF Readiness Assessment to assist customers in measuring how confident they should be in their ability to deliver secure code.

The SSDF Readiness Assessment is part of the overall Black Duck strategy for software supply chain security and risk management. Using an SSDF Readiness Assessment, customers can confidently determine where any gaps in their AppSec programs might be, where inconsistent implementations might exist, and where consistency results in secure software products. If the future of your business depends upon an accurate understanding of your software development practices, processes, and workflows reducing that business risk, is solvable with an SSDF Readiness Assessment.