What Does the Cybersecurity Executive Order Mean For Your Agency’s Software Bill of Materials?

By Hayden Smith, Senior Engineer, Anchore

We’ve all seen the headlines – continuous security breaches have spurred new mandates and compliance protocols everywhere we look. Now, there’s an executive order (EO) on cybersecurity requiring a Software Bill of Materials (SBOM) for critical software along with a National Institute of Standards and Technology (NIST) declaration that nearly every component is critical. These are all good things that are going to make our nation safer with sound software development practices. Let’s unpack what’s involved and what the EO means for your agency.

What’s an SBOM?

SBOMs are used to create a complete inventory of the open source and commercial software components that are used in your software codebase. They list all the build packages and dependencies, their size and the licenses associated for each, as well as other metadata, like which developer created them. These lists are useful for detecting malicious packages and determining the vulnerabilities that may exist. Creating SBOMs is not only a best practice but a critical piece of cybersecurity.

Take many of the recent software attacks. Bad actors have used unauthorized dependencies or malware to get into a software container image where it then quickly spreads throughout an environment. By incorporating SBOMs into your development or deployment process, your team will have visibility into each software component and can discover any malware or suspicious code package before it is deployed. SBOMs are something every agency should be doing for all code development – whether they use containers or not.

Where we stand

The EO recognized the important role that SBOMs play in rooting out buried malware. Now, every agency needs to have the processes and tooling to generate SBOMs. This isn’t practical as a manual process because complex software can have hundreds of different packages; generating SBOMs takes an automation tool that integrates with the existing stack. The good news is that many options and solutions are already available commercially.

As an industry, we’re early in the adoption cycle and a standard for SBOMs has not yet been identified. A good standard will have a set ontology, shared language, detailed information and a consistent look. I suspect one of the front-running open-source formats will be identified for government use, and then existing system integrators and vendors will follow that standard for their SBOMs.

What’s next

SBOMs are changing how software is built by double-checking for hidden problems and creating a universal ingredients list of a software build that can be shared across platforms and organizations. Early adoption benefits the organization and reduces the risk of unfavorable components that can open a door to an attack. Implementation of an SBOM is one area you won’t want to delay.

This is only the beginning of the conversation. Check out these key resources online where you can expand your learning:

1. The Linux Foundation’s Software Package Data Exchange (SPDX) is an internationally recognized open standard for reporting SBOM information. The site contains tutorials and open-source tools and resources.

2. CycloneDX is another SBOM standard site with many use cases, examples and tools.

3. This vendor-agnostic white paper from Anchore, a software container security company, is a good explainer on software supply chain security and an educational piece for agencies.

4. My earlier blog for GovLoop’s Featured Contributors program about the Air Force’s Platform One project.

5. This Featured Contributors blog, meanwhile, details the cybersecurity EO’s key points.

Interested in becoming a Featured Contributor? Email topics you’re interested in covering for GovLoop to [email protected]. And to read more from our summer/fall 2021 Cohort, here is a full list of every Featured Contributor during this cohort and a link to their stories.

Hayden Smith is a senior engineer with Anchore, a software container security company. Currently, Smith leads developer projects across the Defense Department (DoD) and numerous federal agencies to help government organizations adopt DevSecOps best practices. His work includes building and automating Platform One, a collection of hardened and approved containers for use across agencies.

Smith’s dedication to advancing safe cloud-native development practices has been able to guide, empower, equip and accelerate DoD programs through their DevSecOps journeys. Prior to joining Anchore, Smith was a DevOps and infosecurity technologist with Booz Allen Hamilton, where he worked extensively on FedRAMP compliance. You can connect with Anchore on Twitter and LinkedIn.