How a software bill of materials can help solve our supply chain woes

The U.S. is facing a reckoning with regard to cybersecurity. Government agencies, hospitals, energy and oil pipeline companies are struggling to fend off ransomware attacks. Nation-states have compromised the software supply chain via the SolarWinds and Pulse Connect Secure attacks. If that weren't bad enough, a new Senate report found that two years after the State Department, Social Security Administration and five other agencies failed to meet basic cybersecurity standards, there had been only "minimal improvements" in the security efforts.

Government officials are feeling the heat and responding. Lawmakers have proposed more funding to respond to big cyberattacks, and the Biden administration released a cybersecurity Executive Order with security requirements to protect federal networks, including security measures for critical software and the minimum elements for a software bill of materials (SBOM).

Despite the good intentions of the EO, it's hard not to be cynical, given how the machinery in Congress runs. Many of the EO provisions will require funding and support that doesn't seem feasible anytime soon. For example, incremental funding will be required for additional multi-factor encryption and endpoint detection technologies that will be necessary to comply with the EO.

Other elements of the EO are more likely to see the light of day. Creating a Cyber Safety Review Board to look into cyberattacks has precedent in the National Transportation Safety Board, which investigates all major transportation disasters. Establishing SBOMs to improve software supply chain transparency for both technology vendors and government customers is also within reach. Code that is compromised during the build phase of the software development life cycle is increasingly at the center of today's cyberattacks.

Furthermore, attacks targeting open-source supplier ecosystems are also rapidly increasing, as seen recently by the widespread "dependency confusion" attacks, which take advantage of a flaw in the way some public open-source repositories house software packages. It's never been more important to understand the quality and security of upstream code that feeds digital supply chains and is shipped into downstream production environments. Transparency with respect to this supply chain dynamic is critical because of the pace at which new zero-day vulnerabilities are constantly being discovered and exploited, as seen with the recent Kaseya ransomware exploit.

In light of these realities, the SBOM provision of the EO makes a great deal of sense because it would cost-effectively improve transparency for key stakeholders up and down the digital value-stream. As the software equivalent of a list of ingredients seen on food labels, an SBOM would reveal the provenance of direct and indirect dependencies contained in a particular piece of software. This information would expose areas of potential weakness and increase the trust level for the tech industry and the federal government, which heavily rely on open-source components to run business operations and build products today.

Until very recently, a big hurdle to broad adoption of SBOMs in federal software supply chains was the lack of formal guidance and standards. This has now been resolved with the National Telecommunications and Information Administration's July release of SBOM minimum elements. Standardization efforts have been underway for years, so the effort is not starting from scratch. There are at least three SBOM data elements standards efforts: Software Identification (SWID) Tagging championed by the National Institute of Standards and Technology, the Software Package Data Exchange, sponsored by The Linux Foundation; and CycloneDX, sponsored by a group of vendors including Sonatype and Veracode with support from other companies.

SBOM skeptics have raised the possibility of unintended consequences associated with too much transparency pertaining to third-party dependencies commonly deployed within mission critical software. If good actors have transparency, so do bad actors. Indeed, information is powerful and it's potentially a double edged sword. No one is naive enough to think an SBOM is a magic bullet for solving all cybersecurity issues, but most software engineering and security professionals generally agree that it's an important step in the right direction.

Cybersecurity is an incredibly complicated issue, and dramatically improving one's security posture is no easy undertaking. It's incredibly hard work that involves technology, people and process. Getting it right will require years of additional effort and substantial investment. Despite this sobering reality, I applaud the EO, and specifically the SBOM mandate. An SBOM requirement vastly improves the government's security posture and is the first step in keeping untrusted software out of the critical systems that underpin federal government operations and securing government systems from nation-state attackers.