OMB memorandum pushes federal agencies to enhance security of software supply chain, driving a sense of urgency

With last month’s rollout of the Office of Management and Budget (OMB) memorandum, the U.S. government brings in new security requirements that federal agencies must comply with when dealing with software supply chain security. Built on President Joe Biden’s Executive Order 14028, the move aims to bolster the cybersecurity posture of federal systems and provide safeguards from the relentless threats and attacks launched by the nation-state and criminal hackers seeking to steal sensitive information and intellectual property from such environments.

Federal agencies will be required to seek attestations for software they currently use and will use in the future. They will be required to ensure that all third-party software they use complies with secure software development standards and guidance issued by the National Institute of Standards and Technology (NIST). Additionally, it encourages developers to employ a risk-based approach to software development tailored to their particular software and development environments.

Federal agencies must obtain self-attestation from software developers before running third-party software on government networks. They must also obtain the Software Bill of Materials (SBOMs) from their software producers and document processes to validate code integrity. In addition, the measure pushes federal agencies to use only software provided by software producers who can attest to comply with government-specified secure software development practices.

Federal agencies have until Jun. 11, next year, to collect letters of attestation from their software providers for critical software and another three months to collect letters for all other software in use. The timeline essentially pushes all contractors to develop and implement a plan to ensure they have sufficient assurances from their software component producers to execute attestations requested from their agency partners. 

Industrial Cyber reached out to industry experts to detail those elements that SBOMs must include to ensure that federal agencies know what vulnerabilities exist in their environment while assessing how workable these initiatives are on the ground across these agencies.

“Depending on who you ask, you’ll get different answers regarding the necessary elements of an SBOM and if these should include vulnerabilities,” Eric Byres, founder and chief technology officer at aDolus Technology, told Industrial Cyber. “The current SBOM standard advanced by CISA does not include vulnerability information; it is simply a comprehensive, nested list of ingredients.” 

“Vulnerability information — including whether or not a vulnerability is exploitable — is communicated via a separate, companion document called VEX (Vulnerability Exploitability eXchange),” according to Byres. 

“There are obvious and compelling reasons for maintaining a ‘church-and-state’ separation between SBOMs and vulnerabilities,” Byres said. “The SBOM for a given software package is fixed and doesn’t change. But vulnerabilities tied to the components within are in constant flux as researchers (and adversaries) expose new ones. It’s unlikely software suppliers could issue new SBOMs every time new vulnerabilities are reported. It’s too much effort and would create a versioning nightmare, he added.

Moving to workability, Byres said that with SBOMs providing definitive lists of ingredients, and VEX documents detailing which ingredients contain vulnerabilities (and whether or not they are exploitable), “we have the fundamental building blocks to secure the software supply chain. By keeping the model simple and modular, it’s workable. We’ve already seen these tools prove their effectiveness in real-world scenarios such as the Log4j crisis, where one of our clients was able to respond in hours rather than days or weeks thanks to SBOMs and VEX,” he added.

Byres also added that these requirements don’t just apply to brand-new software. They include legacy products if any significant modifications are made. And it isn’t just open source software that is the focus — it is all software. “Finally (and perhaps most important for the OT market), suppliers can’t just put software in an embedded device (like an industrial computer) and dodge the requirements. In fact, all sensors, controllers, and network devices need to follow these guidelines,” he added.

The OMB cites the guidance developed by NIST and National Telecommunications and Information Administration (NTIA) with regard to EO14028, Tobias Whitney, vice president of strategy and policy at Fortress Information Security, told Industrial Cyber. “In July of 2021, NTIA posted ‘The Minimum Elements for a Software Bill of Materials,’ which NIST recognizes as an effective means to comply with EO14028. 

He pointed out that the NTIA states on the NIST website that ‘SBOM capabilities are currently nascent for federal acquirers and that the minimum elements are but a key, initial step in the SBOM process that will advance and mature over time.’

Whitney said that given that most federal agencies have very little background in terms of SBOMs, the expectations are not high that vendors will be responsive to the SBOM requests. “Federal acquirers should further consider that effectively implemented SBOMs are still subject to operational constraints,” he added.

Liran Tancman, CEO and co-founder of Rezilion, told Industrial Cyber that one essential element is dynamic capability. “In the software landscape, change is constant. With every change in code, software versions, and stages of the SDLC, new vulnerabilities can be introduced, which cybercriminals can exploit if they are not identified and fixed quickly.” 

“In order to achieve this contextual view, it is essential for agencies and organizations to combine the SBOM and VEX and get the actual risk present in their environment,” Tancman said. “VEX is a machine-readable artifact that tells you which vulnerable components in an environment are actually exploitable. The objective of the VEX is to provide information for organizations to use and prioritize their remediation efforts. This contextualization is provided by the software vendor with a machine-readable artifact with justification values of why a particular component is not affected by a specific vulnerability and therefore not exploitable.”

Tancman said it will require a critical look at current tools and strategies and, in many agencies and organizations, an investment in dollars to update technology and processes. “Critical infrastructure in particular often operates with older, legacy technologies that cannot properly defend against modern-day threats. With tight budgets, federal agencies and critical infrastructure organizations will need to do some reevaluation of where their time and dollars are allocated if they want to truly be able to manage risk today,” he added.

Flagging the minimum requirements set forth by NTIA, Thomas Pace, co-founder and CEO at NetRise, told Industrial Cyber that the SBOM itself does not mandate vulnerability information as a required field. “This is because vulnerability information is dynamic so mandating this information was feared to only provide a snapshot in time vulnerability identification posture. Since the component name, version of the component, etc. is mandated, however, the next logical step is to identify the vulnerabilities using this information, which is what many are doing.” 

Pace pointed out that the elements required here would include but not be limited to, the number and type of vulnerabilities, available exploit data as well as any VEX documents that may be available. “These initiatives can be workable, but are undoubtedly more difficult within critical infrastructure due to the lack of visibility of those devices and the technical challenges around firmware analysis vs. software analysis,” he added.

With the rollout of these requirements, it is important to get a measure of how agencies and organizations respond to implementations brought upon them as part of E014028 released last May, and the current memo. Further, it is prudent to look into any uncovered areas which need to be improved or worked upon.

Whitney said that there is not enough guidance on how to use SBOMs. Most of the work regarding SBOMs is to help securely manage, distribute, and coordinate with vendors, but most purchasers are not aware of their ultimate benefit and how SBOMs may help their procurement and security programs. “That is where additional supplemental guidance is needed and we are coordinating with groups like NATF to develop practical asset owner-oriented guidance for sector-specific use cases,” he added.

“The key benefits SBOMs provide are improved and more accurate vulnerability management, patch management, and incident response processes,” according to Whitney. “Demonstrating how SBOMs can improve these security processes will ultimately increase the OMB memo’s adoption and value to participating agencies.”

Byres said that it is encouraging to see the momentum building around SBOMs and supply chain security. “Rather than moaning or resisting, the industry as a whole seems to be embracing these requirements. There is growing appreciation that well-resourced, nation-state adversaries are focusing on our software supply chain’s soft underbelly. And this awareness is driving a sense of urgency among those working in critical infrastructure.”

He added that more work needs to be done in the smaller organizations —  local water utilities, municipal or rural electric utilities, small manufacturing, etc. “These folks usually don’t have the in-house cybersecurity staff to properly respond to the new mandates. They will need funding support of course, plus tools to automate all the activities they can to reduce the burden on limited resources,” according to Byres.

“The other area to be worked on is building the infrastructure to securely distribute trusted SBOMs and VEX documents to the organizations that need them. No large critical infrastructure operator wants to have to download SBOMs from hundreds or thousands of suppliers,” aDolus’ Byres said. “They also don’t want to have to sift through tens of thousands of SBOMs from a large supplier when they only are using a few products. So there is a lot of interest in services that can securely aggregate SBOMs from multiple suppliers and then tailor the feed to exactly the products that a facility has deployed.” 

Byres further pointed to a requirement to address this need by government agencies spelled out directly in Section III C.2. that reads – ‘CISA, in consultation with GSA and OMB, will establish a program plan for a government-wide repository for software attestations and artifacts with appropriate mechanisms for information protection and sharing among Federal agencies.’ Clearly, CISA is being given marching orders to solve this for the government, while industry will look to private enterprise for a solution, he added.

The executive order was an incredibly positive step in the right direction, Pace said. “What we have seen is much more interest from federal agencies of all types around software transparency and more specifically software supply chain security as a byproduct of that transparency. Multiple areas need to be improved upon such as vulnerability contextual analysis and solving complicated technical problems such as firmware analysis of critical infrastructure devices,” he added.

The OMB memorandum said that the global supply chain faces relentless threats which can potentially compromise the integrity of government systems, and conduct other acts that impact the U.S. government’s ability to safely and reliably provide services to the public. It is vital to assess whether the document will be able to prevent attacks from adversaries, and what gives this document an edge over earlier federal measures.

“We need nearly 100% compliance with the OMB memo to start building the protections and processes needed to mitigate the risk of zero-day vulnerabilities and exploits,” Whitney said. “This is the first, but necessary step to build databases of components / SBOMs to enable purchasers to develop the vulnerability management and incident response processes to mitigate the risk of the nation-state and critical actors.” 

Without SBOM repositories, organizations will not be prepared to rapidly mitigate recently revealed vulnerabilities and exploits, Whitney said. “The industry will continue to depend on the vendor’s outreach and coordination actions, which can cause critical delays in safeguarding systems,” he added.

Pace said that there is likely nothing that will arrest relentless threats from nation-state and criminal actors. “However, the first step to being able to do this in a more effective manner is to gain as much visibility as possible into the software supply chain.” 

“It is less about ‘how and why’ something happened and much more about ‘where else can this happen?’, this is a very difficult to almost impossible question to answer,” Pace said. “The edge this document gives is more so around the goal and ambition of the document more so than the document itself. This is a fundamental problem that is finally getting the attention that it deserves. Addressing these issues solves many downstream problems as well, addressing the shaky foundation in which all software exists,” he added.

Byres said that there is no silver bullet that will ‘arrest’ relentless threats from nation-state and criminal actors. But this OMB memorandum does provide the tools to respond to these threats, he added. 

“The challenge that OT defenders have been facing for the past 20 years is that they have been operating in the dark when it comes to what software is actually in the products they are using,” according to Byres. “The bad guys are not under similar limitations – they can reverse engineer any product they want without meaningful risk. These requirements provide transparency between users and suppliers,” he added.

“If there is anything we know in cybersecurity it is that cybercriminals strive to always be one step ahead of the organizations they target,” Tancman said. “Nation-state hackers are no different and the United States is always a prime target for attack. The memorandum provides a critical first step to knowing what software threats you have. But more importantly, we need to see this transformed into action in the form of remediation of those vulnerabilities.”

The memo requires software producers to now attest to compliance with the NIST guidance, so companies that want to sell their software to the government will need to assess and attest to their compliance with NIST guidance, according to Tancman. “This may mean some (many) will need to revise their strategies in order to address gaps in their current compliance posture, their development process, and their process for making version upgrades. It also has implications for contractors whose products rely upon or incorporate software, they will need to make sure the vendors they depend on are following the attestation process.”

Tancman said that all of this means software producers will be on the hook to be more involved in the process of ensuring their products are secure. It goes further than past measures because it sends a message about the severity of software supply chain security and puts some degree of accountability on software vendors. It also includes the potential for enforcement actions against vendors who do not pay attention to their compliance assessments and the representations that they make, he added.  

Another critical aspect is to look into the feasibility of federal agencies complying with the NIST guidance when using third-party software on the agency’s information systems or otherwise affecting the agency’s information, while also analyzing whether software providers are aware of the vulnerabilities they often push to end users.

Software providers are not very aware of the open-source vulnerabilities or the vulnerabilities of their supplier’s technologies, Fortress’ Whitney said. “This memo will begin forcing suppliers to become much more aware of the vulnerabilities they might introduce to purchasers. The key next step will be for vendors to ‘certify’ their software components are free from known vulnerabilities.”  

Whitney also pointed out that the NIST also states ‘maintain readily accessible and digitally signed SBOM repositories, and share SBOMs with software purchasers directly or by publishing them on a public website.’

“Establishing SBOM repositories are essential for transparency for all involved parties,” according to Whitney. “By having updated repositories that are sector-specific, enable asset owners and suppliers to more effectively mitigate component-level vulnerabilities through mitigation activities that are specific and relevant to industry processes.”

Tancman said that government agencies and critical infrastructure organizations are often behind when it comes to the tools they are using due to their legacy technology. “But this directive puts much of the onus on the agencies’ partners and requires them to take responsibility for their own products.”

Addressing if software providers are aware of the vulnerabilities they often push to end users, Tancman said that if they were, one would expect vulnerabilities not to be as prevalent as they are. “Unfortunately, the rush to ship code often leads to insecure products. While companies are expected to ensure that their products are free of vulnerabilities, we see daily that is often not the case. That’s why it is essential to build security into the software development process,” he added.

Vulnerabilities should be detected and remediated in both production and development to give the best possible chance that the final product is secure before it is pushed to end users, Tancman added.

Pace said that it is much more feasible for agencies to do this for new software being brought in compared to legacy software products. “Many software providers are NOT aware of the vulnerabilities that exist within the software they push to end users. This problem is exacerbated by challenges as they come to dependencies and their artifacts within software and firmware that can introduce risks such as weak credentials and private keys improperly stored,” he added.

“Sadly, software providers are frequently clueless about the third, fourth, fifth-party components embedded in their products,” Byres said. “Developers often embed code of shady provenance — some of it open source of unknown authorship — as an accepted practice in modern software development. When the products are shipped to customers, the vulnerabilities buried in a deeply nested component set off no alarm bells because nobody knows the component is present.”

Byres also said that SBOMs produced from binaries (i.e. executable files rather than source code) can reveal all the components in a software package —  even ones the vendors didn’t know about or document. “Full disclosure – our company uses this technique to produce SBOMs and our customers can create an SBOM with a single click. They find it not only feasible but easy to assess the risk posed by third-party software,” he concluded.