Are you getting up or hitting the snooze button?
Update as of June 14, 2023: The below blog was posted on June 13, 2023. In a typical hurry up and wait situation, the US Government has hit the snooze button for you. The June 11th date was predicated by CISA delivering an industry-driven standard for software attestations. This work is still ongoing, therefore, OMB issued an update to memo M-22-18 via memo M-23-16 extending the deadline by 3 months for critical software and 6 months for all software AFTER the software attestation standard has been formally defined and communicated. Once that happens a firm date will be published. Please keep this in mind when reading the below. We will continue to update you going forward.
I have a vivid recollection of a moment back in 2009 when my CEO, co-founder, and I convened in our conference room in San Francisco. We engaged in a spirited discussion, pondering the most fitting term to describe the collection of items our pioneering SCA scan solution provided to our customers. At that time, no official terminology like SBOM (Software Bill of Materials) or governmental regulations such as the Cybersecurity Executive Order or the European Cyber Resilience Act had emerged, making this a truly forward-thinking discussion.
Recognizing that our customer base utilized our product to scan their code and catalog its contents for the benefit of their customers or potential acquirers during M&A transactions, we aimed to find a term that resonated. We eventually settled on “inventory,” as it aptly represented an application’s bill-of-materials—akin to what was being practiced in the hardware industry for products composed of multiple parts sourced from various upstream vendors (think about the numerous manufacturers that contribute parts to an airplane or automobile, for example).
Early on, we conceptualized a visionary notion—an overarching artifact called the “software composition statement.” This would be the deliverable of a process where Engineering and Legal leaders would jointly endorse their software application releases, instilling trust in their customers regarding the procedures followed and the reliability of the resulting analysis.
In fact, we even developed a rudimentary mockup, serving as a visual representation of what such a concept could potentially resemble:
From the beginning, we anticipated the market’s progression towards a point where it would be standard practice for software buyers to include contractual provisions in their agreements with software suppliers. These provisions would play a crucial role in ensuring accurate reporting of application composition and dependencies, as well as upholding adherence to industry best practices in secure application development.
During the past decade much work has been done via collaboration from both the public and private sectors to establish mandates, standards, requirements, best practices, and tooling. What we coined as “inventory items” back in 2009 are now known as SBOM parts. Our inventory concept has come to life in the form of a Software Bill of Materials.
This past weekend, on June 11, 2023, we surpassed our first major milestone as expressed in the U.S. Presidential Executive Order on Improving the Nation’s Cybersecurity (EO 14028), and further clarified in September by Memorandum M-22-18:
“Agencies shall collect attestation letters for “critical software” subject to the requirements of this memorandum – Within 270 days”
Hence, the crucial question for software suppliers remains: When the alarm sounded on June 11th, did you spring into action or merely hit the snooze button?
At present, numerous software suppliers may argue that this does not affect them, citing three pivotal reasons:
- We do not sell to the US Government
- Our software is not classified as critical by NIST
- We are not prepared to provide this information or feel like it puts our organization at risk to openly release composition and security information about our products
While all of these points may be valid, we need to explore each objection in more detail.
We do not sell to the US Government
Although that claim may hold some validity, it is important to consider the following scenario, and this is key: If your organization lies within the software supply chain, and your customers rely on your software to deliver their solutions to the US Government, eventually your code becomes part of the software utilized by the US Government. Consequently, your customers will inevitably require your assistance in order to ensure compliance.
The US Government serves as the initial catalyst, setting off a chain reaction with far-reaching implications. Its adoption of these regulations is just the beginning, as numerous other entities are poised to follow suit.
- The European Union (EU) is making significant strides with its Cybersecurity Resilience Act (CRA).
- Last year’s Open Source Software Security Summit in Japan facilitated a broader dialogue that extended to other geographical regions.
- CISA’s recent publication of “Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default” was a collaborative endeavor involving 12 agencies across 7 nations.
- Numerous regulated industries have already implemented comparable requirements for software transparency. These requirements apply to any software involved in controlling products that possess the potential to cause harm to humans (such as cars, planes, medical devices, etc.) or can lead to significant disruptions in human lives if compromised (such as critical infrastructure).
Therefore, the scope of these regulations extends well beyond the US Government, encompassing a wide range of sectors where ensuring the safety and security of software is paramount.
Our software is not classified as critical by NIST
While that may be true, the second major milestone is only 95 days away, and by September 13, 2023, the critical classification becomes moot, and all software sold to the US Government will require an SBOM and attestation.
We are not prepared to provide this information or feel like it puts our organization at risk to openly release composition and security information about our products
Overcoming this particular point of view can indeed pose significant challenges, considering the valid concerns raised. However, it is imperative for organizations to acknowledge the inevitability of eventual compliance. Instead of opting out, I strongly urge organizations to embrace this reality, lean in, and proactively drive innovations that directly address their concerns.
One highly effective approach is to prioritize the implementation of encrypted and signed transmission for SBOM and security data. Additionally, it is crucial to establish stringent controls over data access, ensuring that only entitled parties and authorized users can retrieve it. Although the SBOM industry is still in its early stages of development, numerous vendors are actively working on innovative solutions to mitigate these aforementioned risks.
Ok, we get it, this is important, where do we start with producing software attestations?
- Take a breath, and don’t panic!
- Communicate with your software supply chain partners to understand their needs, capabilities, and limitations
- Identify relevant standards and requirements for your industry
- Assess your controls and ensure they are up to date; implement improvements
- Establish attestation criteria
- Read up on key new technologies:
- SLSA (Supply Chain Levels for Software Artifacts), a comprehensive security framework that serves as a common language for enhancing software security and supply chain integrity
- GUAC (Graphical User Application Composition), a tool that simplifies the process of understanding the composition of artifacts within your applications
- Sigstore, an emerging standard that focuses on signing, verifying, and protecting software
- Engage help; there are many experts available, including Revenera
- Continuously monitor and improve
We now have official terms, like SBOM, VDR, and VEX and mandates that capture the spirit of our discussion from back in 2009.
Our initial concept of the “software composition statement” has evolved into the official “software attestation,” acting as a declaration by the software supplier, aimed at achieving two essential outcomes:
- That the contents of their SBOM and accompanying security reports fairly and accurately represent the composition and security risks for their application (at a given point in time)
- That their organization has adhered to the secure software development practices (SSDF) as outlined by NIST
It is evident that change is imminent. The signs are clear: this movement will eventually encompass the globe, driven by shared goals and objectives. Recognizing and embracing this reality, and taking proactive measures today, is not only advisable but also essential. By acknowledging the evolving landscape of software regulations and the increasing demand for transparency, organizations can stay ahead of the curve and position themselves for success.
