In the past, we’ve written a lot about FedRAMP certification and the way the Ignyte platform can help you with record-keeping and the overall process. We’ve largely glossed over the role that the third-party assessment organization plays, hand-waving it as a relationship you build between your chosen 3PAO and your own organization.

As a certified 3PAO, however, we do have a unique insight into this process. We can help you glimpse behind the curtain at some of the specific processes, like the SBOM Attestation, and what you need to know about it. So, let’s talk about it!

What is Secure Software Development Attestation?

The federal government, as time goes on, is taking cybersecurity more and more seriously. Every year, new rules, new regulations, new improvements to frameworks, and new requirements are issued. For example, the recent DoD memo that turned the concept of equivalency on its head.

To be clear, this isn’t a problem. It can be a hassle, and it means you always have a moving target to reach and maintain, but we live in a world of rapid technological advancement; to stay static is to fall behind, and to fall behind is to fail. When failure can mean compromised software and systems, the government doesn’t want to take any chances.

This is where CISA, the Cybersecurity and Infrastructure Security Agency, comes in. CISA is a component of the Department of Homeland Security and is in charge of cybersecurity and infrastructure throughout the government’s supply chains. It has existed in some form since 2007 but was not officially founded as CISA until 2018. Since then, it has had a significant impact on government and government contractor cybersecurity.

One of the more recent efforts by CISA is the formalization and adoption of the Secure Software Self-Attestation Form, and the concept of Secure Software Development itself.

Secure Software Development is itself a framework developed by the government on top of a set of standards that are themselves developed and maintained by our good friends, the National Institute of Standards and Technology. In this case, the SSD framework is outlined in NIST Special Publication 800-218. If you’re interested, you can read that publication here.

Recently, two things have happened to shake up this space. The first is the 2021 Executive Order from the White House, Executive Order on Improving the Nation’s Cybersecurity. This EO kickstarted the process of developing newer security standards that have led to the SSDF.

The second is the recent finalization of the Secure Software Development Attestation Common Form. This form was finalized and published on March 11, 2024. While drafts of this form have existed for a while, the final release of the form has initiated the compliance timeline. Agencies now must start collecting attestation letters for software they use. Critical software has a deadline of June 8, which has already passed; non-critical software has a deadline of September 8.

Along with the common form, CISA has started a repository for attestation documents. This is the RSAA, or Repository for Software Attestations and Artifacts. This is a location where software developers can upload their attestations and related documents.

What are artifacts? The Secure Software Development Framework defines two kinds of artifacts, low-level and high-level. Low-level artifacts are specific results generated through the software development process, recording the actions taken. These can be things like scan results, test results, and security assessments. They also include software source code.

High-level artifacts are more like summaries of the development practices in use by your organization. These include things like white papers, webpages, and organizational narratives. They are consistent with and supported by the low-level artifacts. Taken together, high-level and low-level artifacts provide a comprehensive picture of your software development practices.

Due to the often-sensitive nature of this information, this is why the Repository is closed to the public and requires approved access.

The repository exists to be a central location for these documents and to minimize the need for any given service provider to submit the same documents over and over. If you’re familiar with FedRAMP, the way a CSP might need to achieve multiple different ATOs for different Agencies, the Repository is meant to be closer to a P-ATO. A company that provides software used by numerous agencies (say, Microsoft, for example) can upload their attestations to the Repository once rather than once per agency they work with. After all, the software is the same across agencies.

What is the SBOM?

The SBOM is the Software Bill of Materials. It is, essentially, a complete and comprehensive list of each and every component of a software product. The concept of the SBOM has quite a history divorced from the government, but has been adopted by the government and outlined.

The origin of the SBOM goes back to 2009 when two formats for the document were developed.

• SPDX, the Software Package Data Exchange, a standard focused primarily on licensing.
• SWID, the Software Identification Tags, a set of structured meta-data tags describing a piece of software and its phase in the software deployment life cycle.

Both of these standards comply with the specifications laid out by NIST.

Over time, additional standards were developed, such as OWASP in 2017. The executive order linked above, in 2021, prompted NIST to develop additional standards for software development security, and their response was the Secure Software Development Framework.

As part of the SSDF, NIST requires that contractors provide an agency with an SBOM, either directly or by publishing it on a public website. One critical note, however, is that while the NIST outlines the requirements for the data that should be in the SBOM, it does not specify the format it must take. SPDX, SWID, and other formats are all valid as long as they comply with NIST minimums.

SBOMs have certain specific minimum elements that are required for each part of a piece of software. There are three categories, and a set of minimum elements for each.

• Data Fields: Document baseline information about each component that should be tracked: Supplier, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp.
• Automation Support: Support automation, including via automatic generation and machine-readability, to allow for scaling across the software ecosystem. Data formats used to generate and consume SBOMs include SPDX, CycloneDX, and SWID tags.
• Practices and Processes: Define the operations of SBOM requests, generation and use including: Frequency, Depth, Known Unknowns, Distribution and Delivery, Access Control, and Accommodation of Mistakes.

All of this, as well as greater details about all of the above, is outlined in the document titled The Minimum Elements For a Software Bill of Materials (SBOM) found here.

It’s worth mentioning that SBOMs are not unique to the federal government the way many other elements of various frameworks are.

• The EU Agency for Cybersecurity recommends using SBOMs in their Guidelines for the Security of the Supply Chain for the Internet of Things.
• The UK National Cyber Security Centre recommends using SBOMs to understand associated risks.
• The Australian Cyber Security Centre recommends using SBOMs in their Information Security Manual.

Even ISO/IEC recommends using SBOMs in their international standard on vulnerability disclosure.

Is an SBOM a Required Part of CISA Secure Software Development Attestation?

Surprisingly, the answer here is both yes and no.

CISA’s SSDF requires that you provide information relating to the software development of any software you create to the clients who use your software whenever a government agency is involved. SBOMs can be uploaded to the Repository as part of the overall attestation package.

However, NIST/NTIA/CISA and the other organizations involved in SSDF do not mandate the specific use of SBOMs or even one of the specific formats. The SBOM formats are acceptable and effective, but they are not mandated. If you wish to use a proprietary format for the same information, you can, so long as that information exists and is usable.

That said, 99.9999% of the time, it’s going to be a much better idea to use SBOM than to make your own format. There’s no reason to reinvent the wheel when you’re building a bicycle, after all.

Where do 3PAOs Come In?

When you’re seeking compliance with the Secure Software Development Framework, you need to generate documentation about your software for use by your clients, and that means generating an SBOM or something like it.

There are two ways you can generate and submit this information. The first is through self-attestation, and the second is through a 3PAO.

There are only a couple of differences between these two options. Regardless of which you choose, you need to generate documentation and artifacts and submit them to the appropriate locations, which, in the case of government contractors, means to the Repository.

The primary differences are:

• With self-attestation, your organization does all of the work, develops the paperwork and documentation alongside any artifacts generated by the process, and certifies it all. Your CEO/COO signs off on it, and the documents are uploaded to the Repository.
• With 3PAO attestation, your organization works with a 3PAO like Ignyte to develop the paperwork and documentation alongside any artifacts generated by the process. Your CEO/COO signs off on it for the purposes of the 3PAO’s records, and the 3PAO certifies the SBOM and other documentation for the Repository.

Essentially, when working with a 3PAO, you leverage the experience of the 3PAO to speed up, streamline, and authenticate the documentation, artifacts, and process. With self-attestation, you have a lot more room to get something wrong until an audit comes down the pipe.

Additionally, working with a 3PAO opens up more opportunities, including the option to further continue working towards some other certification, like FedRAMP or CMMC.

How Long Does an SSDF Attestation Take?

There’s no simple answer to this question. The developers of a small web-based cloud tool will have a very different scope than a company like Google or Microsoft.

That said, in our experience working as a 3PAO to help cloud service providers develop their SBOMs and attestations, assemble their artifacts, and submit their documentation, it generally takes around 50-60 hours of work. However, note that this is for relatively small and mid-sized service providers, as well as those providers that have automation and tools in place to harvest relevant information.

If your organization is much less rigidly organized, does not have automation tools in place, or is significantly larger, it will take longer than that. A very simple provider might take less, but rarely. There’s a certain baseline amount of work that needs to go into the entire process regardless of how smooth the process is, and filling out the paperwork is always going to be time-consuming.

The time estimate is for the activities of documenting secure practices of software development, supplier risk evaluation if development is not a core part of your business offering, and the creation of an SBOM for internal use if not for submission externally.

Does Your CSP Need an SBOM or SSDF Compliance?

Up until recently, with the publication of the Common Form, SSDF compliance was recommended but not required. Now, with that publication, compliance is now required, and the deadlines are looming.

If you develop software that any government agency or contractor uses, you will need to comply with SSDF. If you are not a software developer but provide services to the government or a government contractor, you will need to ensure that your suppliers comply with SSDF. This is all meant to help prevent another massive supply chain attack like the recent SolarWinds attack.

How does SSDF compare to FedRAMP? They are complementary initiatives. SSDF is for supply chain security and secure development; FedRAMP is for active security, intrusion prevention, and monitoring. They cover different aspects of the same overall concept of security and are, therefore, both frequently necessary or mandatory for working with the government.

If you need assistance navigating these tricky nested requirements, or just want an expert to help you develop your attestation documents, we’re here to help. At Ignyte, we have an expert team that has worked with many companies to develop these attestations, as well as the documentation for many different security frameworks. We’re always open to questions, so reach out and contact us today!

*** This is a Security Bloggers Network syndicated blog from Ignyte authored by Max Aulakh. Read the original post at: https://www.ignyteplatform.com/blog/security/sbom-attestation-by-3paos/