CISA software supply chain security form omits SBOMs
Federal suppliers now have a self-attestation deadline amid ongoing efforts to secure software supply chains. But SBOMs' spotlight is fading and big risks remain, experts said.
Nearly three years after a presidential executive order on software supply chain security, CISA's self-attestation form for federal government software suppliers was finalized this week. But some experts said it leaves out key items, such as any mention of software bills of materials.
The Biden Administration's Executive Order 14028, issued in May 2021, called on the Cybersecurity Infrastructure and Security Agency and other departments to re-evaluate the software supply chain security of their federal suppliers. The executive order was followed by a broader National Cybersecurity Strategy designed, in part, to shift liability for supply chain attacks to software vendors rather than users.
Development of CISA's standard self-attestation form for software producers began with memoranda in 2022 and 2023. The final version was published March 11, 2024. Critical software providers will have three months from that date to submit the form. Producers of software created or modified after Sept. 14, 2022, except open source components directly downloaded by federal agencies, must submit the form within six months or the federal government will no longer use their products.
This milestone and the deadlines that come with it show that software supply chain security has made progress since the high-profile attack on users of SolarWinds IT monitoring software in 2020, industry watchers said.
"Most folks at that time weren't even paying attention to the software supply chain," said Chris Hughes, chief security advisor at software supply chain security vendor Endor Labs and a Cyber Innovation Fellow at CISA, although he emphasized he didn't participate in developing the form and does not represent CISA. "A lot of momentum has been gained in just a few years."
However, Hughes, other private sector leaders and industry analysts have expressed concerns about changes to the CISA self-attestation form since its initial draft. Most prominent among them is the omission of software bills of materials (SBOMs) -- machine-readable lists of components that make up software products and their provenance that can be used to evaluate security vulnerabilities they might contain.
The initial draft of the CISA self-attestation form and a previous CISA memo stated that "software producers may be asked by agencies to provide additional attestation artifacts or documentation, such as a Software Bill of Materials (SBOMs)." But that language was gone by the publication of this week's final version. Instead, the form now has a place for the optional attachment of "artifacts/addendum" at the end.
"This is concerning in terms of broadening adoption of SBOM as a key mechanism for increasing software transparency," said Katie Norton, an analyst at IDC. IDC's "DevSecOps Adoption, Techniques, and Tools Survey 2023" found that 58% of 311 organizations were expanding, piloting the use of or using SBOMs in production for their applications.
But "for this rate of adoption to grow significantly, organizations need some level of incentive," she said.
Hughes also expressed concern that the final version of the form requires that "the form must be signed by the Chief Executive Officer (CEO) of the software producer or their designee, who must be an employee of the software producer and have the authority to bind the corporation," rather than simply requiring the signature of the CEO.
"That opens the door to a C-suite skirting the responsibility … and putting this on a product manager or someone else to sign and … maybe making whoever signs a scapegoat," he said.
In a 2023 ESG survey, SBOMs ranked well behind other software supply chain security tools in use by enterprises.
Whither SBOMs?
During early discussions of software supply chain security in the wake of Biden's executive order, SBOMs were a strong point of focus. While SBOM development continues, it hit snags and roadblocks over the last year as competing standards efforts and confusion about government requirements reared their heads.
In the meantime, other aspects of software supply chain security have become more prominent for enterprises and blended with the broader category of application security posture management (ASPM), Norton said.
"I have watched a number of vendors that originally called themselves 'software supply chain security platforms' pivot to ASPM," she said. "I have also had several tell me part of the reason for this was they were finding it challenging to find line items in [enterprise buyers'] budgets for software supply chain security."
This trend was reflected in recent research by TechTarget's Enterprise Strategy Group (ESG), where SBOM generation ranked far down the list of software supply chain security tools in use for enterprises. According to ESG's online survey, 22% of 368 IT pros in North America between November and December 2023 reported they were generating SBOMs, behind several forms of code, container and open source software scanning. Just 19% were ingesting SBOMs. The survey was conducted on behalf of application security vendor Data Theorem.
"People realize their importance [and] regulations are a key driver for adopting SBOMs, but only a fraction are using tools to generate SBOMs. And of those, a fraction have it as a mandatory part of their software development process. Most are on a case-by-case basis," said Melinda Marks, an analyst at ESG. "Those using the SBOM tools do find it is useful for software supply chain security, but they have challenges generating the SBOMs even if they have SBOM tools."
Marks said she's not concerned by CISA's self-attestation form leaving out SBOMs.
"It is interesting that there is not a mention of SBOMs, but I think that just reinforces how SBOMs are not the cure-all for software supply chain security," she said. "It's the quality of your overall supply chain security program that will make you successful in mitigating risk and responding to threats or attacks."
A CISA spokesperson said this week that the agency continues to support the use of SBOMs but did not address why they were left out of the self-attestation form. CISA has championed SBOMs and hosted annual SBOM-a-Rama events, including one last month, to further development of the tech.
Hughes said he's hopeful that SBOMs might reappear in future versions of the form as technology matures.
"I think it'll definitely evolve," he said. "[The government] needs to get in a position to even start requesting, receiving them and reviewing all these forms. There's a lot of new administrative infrastructure to get in place for the agencies to actually get started."
Open source software supply chain work advances
Concerns about the self-attestation form and the maturity of software supply chain security don't end with SBOMs.
"There are still a variety of software supply chain attack techniques -- malicious implants, third party components, digital signature manipulation, exposed secrets, memory exploitation, etc. -- that are actively being leveraged [by attackers], but that CISA's requirements do not account for," wrote Charles Jones, director of product management for ReversingLabs, a software supply chain security vendor, in an email to TechTarget Editorial. "Additionally, as proven time and time again through vendor security questionnaires, written attestation without substantive evidence or testing to verify a vendor's claims does very little in the way of effectively managing cyber risk."
However, industry watchers also cited another recent publication by CISA about recent efforts to secure open source software supply chains as a sign of growth in the industry.
CISA's work with open source package repositories to foster adoption of the Principles for Package Repository Security developed with the Open Source Security Foundation (OpenSSF) caught the eye of one enterprise IT pro.
"It's impressive to me that they were able to get almost every major package management ecosystem to participate and commit to making material improvements," said Josh Koenig, chief strategy officer at WebOps provider Pantheon Platform. "The gold standard would be to have all packages signed, with strong security measures as a hard requirement for all maintainers. We're not there yet, but it sounds like real progress is being made across the board."
Koenig predicted that both the public and private sector will be motivated by factors beyond government regulation to continue shoring up software supply chain security.
"We have plenty of customers leveraging our platform to do their own supply chain inspection for the code that powers their websites," he said. "Big corporate IT orgs are, rightly, super paranoid about some rando marketer hiring a local digital agency and, three months later, someone is holding their website hostage because they built something with insecure libraries."
This is concerning in terms of broadening adoption of SBOM as a key mechanism for increasing software transparency. … For [their] rate of adoption to grow significantly, organizations need some level of incentive.
Katie NortonAnalyst, IDC
Elsewhere in the open source software supply chain world, a knowledge graph database for cloud-native components and vulnerability tracking -- an aspect of SBOM generation that has long been a hurdle for the technology's development -- officially joined the OpenSSF as an incubating project.
In the public sector, experts also largely praised fresh guidance from the National Institute of Standards and Technology (NIST) for securing CI/CD pipelines. The NIST guidance acknowledges that its recommended practices remain aspirational for most enterprises. Some controls it recommends, such as the verification of input and output files for code compilers and linters, are also not yet commonly available from commercial and open source tools.
"The guidance from NIST … is key in helping organizations look at their software supply chains more holistically," Norton said. "While devices, servers and applications are typically covered in depth within an organization's visibility and monitoring programs, CI/CD pipelines tend to get less security attention and have little to no scrutiny of logs to verify what is executed when building, testing and ultimately deploying an application."
Beth Pariseau, senior news writer for TechTarget Editorial, is an award-winning veteran of IT journalism covering DevOps. Have a tip? Email her or reach out on X, formerly known as Twitter, @PariseauTT.
