How to explain the CISA software attestation requirements to your board

For any software company that sells to the federal government or in a highly regulated industry, software supply chain security has recently become an existential boardroom concern.

‍

In the wake of SolarWinds, the White House issued Executive Order 14028 on Improving the Nation’s Cybersecurity, outlining broad support for technologies and initiatives such as software bill of materials (SBOMs), a new standard for secure software development, and support for strengthened federal software procurement rules.

‍

Reading between the lines, it is clear that the federal government has been laying a foundation for defining and enforcing a standard for software security liability, where software producers face legal liability related to security of the software they ship.

‍

It's a frothy policy area that's been puzzling boardrooms at software companies. And while this initial federal activity has focused on vendors selling directly to the federal government, there are potentially longer-term implications for the entire technology industry.

‍

At Chainguard we often get asked for our opinion on how federal policy on software security will unfold. A series of forthcoming blog posts will therefore unpack recent developments so you can give your board a clearer look at the crystal ball.

‍

Secure Software Development Attestation Form

Last month, the Cybersecurity and Infrastructure Security Agency (CISA) released its Secure Software Development Attestation Form, which was a mandatory component for software supply chain security requirements outlined in the Office of Management and Budget’s (OMB) Memorandum M-22-18 (September 2022). The Memorandum requires that all federal agencies and any third-party vendors that provide software for government systems or information meet the NIST SP 800-­218 and the NIST Software Supply Chain Security Guidance.

‍

If you’re struggling to recall the lyrics to “How a Bill Becomes a Law” or the plot to “Mr. Smith Goes to Washington”, you’re not alone. Most organizations are spinning at what this means for them and exactly when they’ll need to have a plan to meet these requirements that were charted out almost two years ago. And you are likely being asked by your C-Suite and Board Members what the plan is to meet the deadlines in order to sustain revenue from crucial government contract work or to avoid fines, or even criminal charges. As the disclosure states: “Providing this information is mandatory. Failure to provide any of the information requested may result in the agency no longer utilizing the software at issue. Willfully providing false or misleading information may constitute a violation of 18 U.S.C. § 1001, a criminal statute.”

‍

For CEOs and C-Suite leaders whose organizations will be mandatorily required to submit these self-attestation forms, it means they are now on the hook for the security and integrity of software developed by their teams whether its first-party or third-party code. Software supply chain is now officially a boardroom and C-Suite problem to bear. But the initial pain will be felt by software developers and engineering and platform teams scrambling to understand what software is where, how it's secured and how it's used across their organizations.

‍

Here’s what you need to be thinking about:

‍

No More Passing the Buck

“Verify that acquired commercial, open-source, and all other third-party software components comply with the requirements, as defined by the organization, throughout their life cycles.”

‍

Open source software and third-party code have become integral parts of many software systems. While they offer many benefits such as cost savings, faster development cycles, and access to a wider range of functionalities, they also introduce security risks.

‍

Today, many vendors do not feel they are responsible for the open source/third party code in their systems and are quick to point the finger at an open source software project when something goes wrong. Most recently, we saw this when the OpenAI founder blamed a popular open-source library they were using for a security incident with their chat history. Open source comes with no warranty, and is never to blame for the failure to use it correctly.

This form is the first to draw a line in the sand holding organizations accountable for any third party code they are pulling into their ecosystem – including the responsibility of managing known vulnerabilities and maintaining end of life software. This shouldn’t be a surprise to anyone, but it will likely cause a shock to the industry as they’re confronted with years of bad practice around how they consume open source. This ecosystem challenge is one of the founding reasons why we started Chainguard. We know the burden here is on organizations to open source responsibly, and we’re working on providing this better way.

Treat your build systems like production systems

“Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security: Decrease the number of security vulnerabilities in the software and reduce costs by eliminating vulnerabilities before testing occurs.”

‍

I may sound like a broken record, but there is no longer a viable excuse for not treating your build systems like production systems.

‍

In recent years, several high-profile security incidents have highlighted the risks of not taking this approach seriously. One such example is the now infamous SolarWinds attack, which was a supply chain attack on the software build system used by SolarWinds. The attackers were able to compromise the build process and inject malicious code into the software updates that were distributed to SolarWinds' customers. Another example is the security incident at CircleCI, a popular cloud-based continuous integration and delivery (CI/CD) platform. In May 2020, CircleCI disclosed that a third-party actor had gained unauthorized access to its build environment and potentially accessed user data, including API tokens and access keys. This incident demonstrated the importance of securing not just the software being built, but also the build infrastructure itself.

‍

As stated in the self-attestation form organizations will not only have to answer questions like “am I running log4j, what versions, and where?”, you’ll also need to be able to answer “what compiler was used to build my app, what version, and what hardening flags were passed to it?”, and “Which build system was used for this binary? What patches were applied to it at the time?”. This isn’t going to be doable with spreadsheets and manual screen-scraping, organizations are going to have to massively improve their infrastructure.

‍

Software Bill of Materials (SBOMs) will help here, but we know that aren’t being widely used today and that vulnerabilities happen everywhere along the software development lifecycle.

‍

Integrity takes center stage

The term integrity shows up 37 times across the self-attestation form in each of the major sections. Ultimately it states, vendors will now be responsible for signing and verifying the signatures of all components they use, including commits, artifacts, and more.

‍

The software supply chain is a complex network of vendors, components, and dependencies, and attacks often occur at the gaps and vulnerabilities within this chain. Signatures, hashes, and digests can provide a means of verifying the authenticity and integrity of software components. We’ve been saying for a long time that software integrity and provenance are critical to stopping a significant portion of the attacks happening along the software supply chain, it was the reason I helped cofound Project Sigstore – an open source suite of tools for signing, verifying, and protecting software. Sigstore enables developers to validate that the software they are using is exactly what it claims to be using cryptographic digital signatures and transparency log technologies.

‍

Today, very few organizations with confidence can say that they know where every piece of software that is running in their environments came from, let alone that it is from a source they trust. Solving for this is going to take a significant amount of time and resources and it will be near impossible for organizations to self-attest to having this in place near term.

‍

Fortified software delivery

There is no silver bullet product for software supply chain security. But there are things you can start doing today to make sure you are ready to comply with the upcoming self-attestation form. The first step is to know what software you are running, where it's running, how risky it is and how to fix it. Once you have this single pane of glass view into your workloads, you can start to enforce policies for software security best practices across your development teams such as cryptographic signatures and SBOMs to improve the integrity of your software as required by CISA’s form. Here’s how Chainguard solutions can help:

‍

Chainguard Enforce helps you address step 1, providing full visibility into what’s in your software supply chain. When it comes to the self-attestation requirements, Enforce provides organizations with this critical information– you no longer have to guess or hope, you know what software is where, how it's used and if it's safe. For software integrity and verification, Enforce provides capabilities to create policies for requiring signatures and SBOMs for all software artifacts. The platform also allows you to improve time to remediation when new vulnerabilities are disclosed because you have visibility into where vulnerable software is running in your environments.

‍

At the ground-level, CVE triage and vulnerability management is a major pain point for organizations who are going to have to comply with the self-attestation form. What can you do? Use hardened, minimal container images that are frequently rebuilt and contain a minimal attack surface. These are the core benefits of our Chainguard Images product, which are minimal container images that only contain what is required to build or run your application, delivering on average a 97.6% reduction in CVEs. Recent Chainguard Labs research found that popular container images used for most software built today, when not updated, accumulate one known vulnerability per day. If organizations are going to certify they comply with CISA’s self-attestation form and maintain the required software security posture, one vulnerability per day can cost infinite time and resources from developer and engineering teams to ensure an organization’s compliance. There is a better way, and Chainguard Images can help.

‍

Tool for reading the self-attestation form

Following the release of the self-attestation form, I found myself struggling to read and digest the PDF. To help myself and hopefully others avoid this confusion and help streamline understanding I converted the documents into fully-clickable markdown and published it on GitHub. The controls in the SSDF table are linkable, so you can reference individual entries, like this one about commit and code signing.

‍

Chainguard is currently working on a comment response and would love to hear from others in industry about how they are reading and reacting to this initial draft. All responses are due by June 27th, 2023. You can view the original RFC from DHS CISA here.