SBOMs Will Come to IBM i, Eventually
June 7, 2023 Alex Woodie
The Biden Administration’s push to make software bills of material (SBOMs) mandatory may not be moving ahead as quickly as hoped. But the SBOM requirement is still marching ahead for federal agencies and the vendors who supply them with software – running on IBM i or any other platform – with a major self-attestation deadline.
The federal government’s SBOM push began back in 2018, when the National Telecommunications and Information Administration’s (NTIA), an agency within the Department of Commerce, spearheaded SBOM work with private-sector partners in an attempt to get better visibility into security vulnerabilities.
The SBOM movement got a big boost in May 2021 when, faced with the growing cybersecurity threat of so-called supply chain attacks such as the SolarWinds hack, President Biden signed Executive Order 14028, which directed the National Institute of Standards and Technology (NIST) to publish guidance on practices for software supply chain security.
Since then, the work on SBOMs and the security of software supply chains has taken off, as federal agencies, led by the Cybersecurity & Infrastructure Security Agency (CISA), worked with industry players to hash out what the final regulation should look like.
Much of the discussion has revolved around SBOMs themselves. An SBOM is a formal document that lists all of the components that go into a particular piece of software. Just like a regular bill of materials that lists what’s been packed into a box or loaded onto a pallet, an SBOM would list every single component that goes into that piece of software, ranging from open source software to commercial packages to in-house developed libraries. (RPG programmers working with ancient spaghetti code may be starting to taste last night’s dinner at this point.)
If we could give developers easy access to detailed information about the original sources of code, the thinking goes, then they would be better prepared to track whether security vulnerabilities exist in their product. What’s more, the developers would be better able to respond when problems arise, and to prioritize remediation work when patches are needed.
As if on queue, the Log4j security vulnerability hit at the end of 2021, highlighting the brittle and recursive nature of modern application development. The Log4j vulnerability was (and continues to be) a prototypical supply chain vulnerability, in so far as the Log4j utility is so widely used by Java developers, but so few people are involved in its maintenance and really know what’s going on under the covers. If a SBOM requirement had been in place before the Log4j vulnerability was discovered, then perhaps organizations would have been better informed about the risk inherent with relying so heavily on other people’s code.
Unfortunately, the Log4j episode also exposes the downside of a SBOM requirement. It’s not uncommon for open source packages to incorporate other open source packages, which in turn rely on other open source contributions, to such an extent that the idea of documenting the dependencies – let alone being able to do anything about them – becomes a hopeless morass of information with no clear direction forward. In other words, open source software is already in such widespread use that requiring detailed tracking could be an exercise in extreme tedium without much, if any, payback.
That’s not to discount the risk of supply chain vulnerabilities. A survey released Monday by Veracode found that nearly 82 percent of applications developed by public sector organizations had at least one security flaw detected over the last 12 months. The comparable figure for private sector organizations is 74 percent.
A nearly 10 percent difference in the rate of security flaw discovery between public and private sector organizations is significant, says Chris Eng, Veracode’s chief research officer. “Efforts by the government to close the gap are necessary and should continue,” he says in a press release. “As stewards of public safety, agencies have a responsibility to close this gap and strengthen security to protect the nation and its citizens.”
An example of a SBOM in the machine-readable SPDX format. (Image courtesy NTIA)
The federal government is marching forward with its secure software supply chain requirement, which is forcing software vendors to take action. The NIST spells out some of the specific requirements in EO 14028 Section 4e in a February 2022 paper, which states:
“When a federal agency (purchaser) acquires software or a product containing software, the agency should receive attestation from the software producer that the software’s development complies with government-specified secure software development practices. The federal agency might also request artifacts from the software producer that support its attestation of conformity with the secure software development practices described in Section 4e subsections…”
It goes on to list these requirements for conformity to secure software environments:
- Using administratively separate build environments
- Auditing trust relationships
- Establishing multi-factor, risk-based authentication and conditional access across the enterprise
- Documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software
- Employing encryption for data
- Monitoring operations and alerts and responding to attempted and actual cyber incidents
Other requirements include the use of “automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code,” as well as “employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release.”
Last year, the deadline for self-attestation of SBOMs, which required “critical software providers” who do business with the government to attest to their conformity with secure software development practices, was set for this Sunday, June 11.
That had big software vendors feeling a bit squishy. In December, a big tech lobbying group representing Amazon, Apple, Cisco, Google, IBM, Intel, Mastercard, Meta, Microsoft, Samsung, Siemens, Verisign and others pleaded with the White House’s Office of Management and Budget to see the light on SBOMs.
“We ask that OMB discourage agencies from requiring [SBOM] artifacts until there is a greater understanding of how they ought to be provided and until agencies are ready to consume the artifacts that they request,” they wrote.
Alas, it seemed to have the desired impact, and the federal government appears has relented on the deadline. The new deadline is three months after the finalization of the “common form” for “critical software providers,” while everybody else has six months. It’s not clear exactly how that translates into a hard date, but it give big software vendors who do business with the feds a bit more time to get their SBOMs lined up.
This isn’t an IBM i-centric story, obviously. But as IBM i applications are being used by the federal government – and because these sorts of regulations have a way of trickling down into the private sector over a period of time – it’s something that IBM i vendors and customers may want to have on their long-range radar screens in any case.
RELATED STORIES
Critical Log4j Vulnerability Hits Everything, Including the IBM i Server
