US federal government documents on software supply chain security have been confusing and may even impose unrealistic timeframes for compliance, industry experts warn.
Software supply chain security has quickly become a top priority for enterprise IT teams and vendors following major security incidents such as the breach of SolarWinds and the Log4j vulnerability, as well as a 2021 Presidential Executive Order on cybersecurity.
In response, some government agencies have begun creating general guidelines for secure software development, such as intelligence.
It took IT pros some time to digest the 64-page document, but one IT pro posted a pointed DevOps-based critique of the guidance this week. He pointed out how the document runs counter to Agile and DevOps principles, such as small incremental changes, rapid deployment speed, and cross-functional roles within development teams.
Bryan FinsterDistinguished Engineer, DevOps Unicorns
“It’s an insane collection of good ideas mixed in with really bad ideas,” wrote Bryan Finster, distinguished engineer and value stream architect at defense firm Defense Unicorns, in a Sept. 20 LinkedIn post. “It’s absolutely clear that the people who wrote it don’t understand continuous delivery (they think it’s automation), nor do they understand how bugs are propagated downstream.”
Other cybersecurity experts agreed with these criticisms, pointing out that the best practice guide also contradicts the technical definitions published by the government in at least one area — it refers to “open-source and commercial software products” as if they were separate categories The US Department of Defense designates open source as commercial software, said David A. Wheeler, director of open source supply chain security at The Linux Foundation.
“I have to admit I’m a little conflicted,” said Wheeler, who emphasized that his comments were his personal opinions and were made official on behalf of the foundation.
The document contains some statements Wheeler was pleased about, such as guidance that software should conform to cryptographic standards. The document recognizes that such standards need not necessarily match those established by the National Institute of Standards and Technology for federal government use.
Other technical quirks left him scratching his head, Wheeler said, like the recommendation to limit developer systems to development operations only, with no other activities performed on them, such as email or Internet access.
“In high-security situations, you might want to have a specialized computer in a virtual machine if that virtual machine doesn’t have internet access,” Wheeler said. “But the developers certainly don’t.”
Federal SBOM statements are considered contradictory and confusing
Last year’s executive order kick-started software bill of materials (SBOM) development. These machine-readable lists of the software components and dependencies that make up an application were mentioned in the executive order to ensure transparency of federal software vendors and to shore up software supply chains. The order was followed last week by a memo from the White House Office of Administration and Budget, which reiterated that federal agencies may require SBOM from software vendors depending on the criticality of the application.
Those mandates were as expected, but several industry organizations have sounded the alarm about legislation currently going through Congress as part of the National Defense Authorization Act (NDAA) of 2023. Earlier this month, a group of organizations consisting of the Alliance for Digital Innovation, the Software Alliance, the Cybersecurity Coalition and the Information Technology Industry Association issued an open letter to senior congressmen objecting to the SBOM requirements in the bill .
In its draft, the law provides for “contradictory requirements for certifications and notifications,” according to the open letter from the groups. “In one case, the provision requires a certification that the items in the BOM are free from vulnerabilities or defects, and in another case it requires a mitigation plan for any identified vulnerabilities.”
Any such vagueness and inconsistency could provide a way to circumvent the intent of requirements, which is to strengthen software security, said Daniel Kennedy, an analyst at S&P Global.
“The idea that continuously updated software can be vulnerability-free is not a realistic goal,” Kennedy said. “There are gaps between identification and remediation, and patch availability and application, and while these gaps can be the result of inattention, they can also be a function of an appropriate approach to testing the impact of a software patch prior to deployment in an environment . “
Wheeler said he expects many of the semantic kinks in the NDAA bill to be worked out or addressed by the Department of Homeland Security (DHS) follow-up guidance on relevant contracts also called for in the bill.
But as written, the NDAA would also impose a 180-day deadline to meet SBOM requirements after this DHS release, which Wheeler says is far too short a timeframe given the state of SBOM technology.
“Generating SBOM is something the software industry in general hasn’t done, except in specific cases,” he said. “This is a big shift in the software industry and I think we’re going to get there [but not] reasonably in the timeframe they envision here.”
Some issues in SBOM, such as Issues such as support for rapidly changing cloud-native applications remain largely unresolved, although projects to address these issues are underway. But even the most mature SBOM technology struggles with the fundamental problems of transitive dependencies, where nested layers of software components make visibility difficult, and false positives and false negatives in vulnerability detection.
It may be that the 180-day requirement is eliminated before the bill passes the Senate, or that the DHS interpretation of “best effort” accepts SBOM at the 180-day deadline, Wheeler said. Worst-case scenario, Wheeler said he fears that too short a timeframe for compliance could hurt public perceptions of SBOM’s effectiveness.
“I’m afraid that’s going to really hurt because then people are going to be like, ‘Oh, SBOM sucks and it’s not reliable,'” he said.
The security confusion in the software supply chain increases the risks for the time being
Adoption of SBOM is likely to progress, but in the meantime, confusion over how to implement software supply chain security presents its own risk.
“Nobody knows exactly what to do,” said Dan Lorenc, co-founder of the Sigstore project and co-founder and CEO of software supply chain security provider Chainguard. “There’s a whole bunch of things that purport to solve part of the problem and don’t actually do it.”
To clear up this confusion, Chainguard this week launched a free developer training resource on all aspects of software supply chain security called Chainguard Academy. But it will probably take about a year before external examiners are trained in concepts like SBOM and formal certifications in this area are available, Lorenc estimates.
“We want to evolve to actual certifications over time, but compliance frameworks are still shifting,” he said.
This week also saw the first generally available release of Chainguard’s Enforce Supply Chain Security Policy Orchestration product, which helps ensure only trusted container images run in Kubernetes clusters.
According to Katie Norton, an analyst at IDC, this type of “Day Two” operation is a broad area of SBOM technology that is still nascent.
“The biggest problem with SBOM isn’t generating them, but … how are SBOM stored and shared?” she said. “To be really useful in the event of a vulnerability like Log4Shell, a company needs to be able to aggregate all of its SBOMs and be queried.”
Beth Pariseau, Senior News Writer at TechTarget, is an award-winning IT journalism veteran. She can be reached at [email protected] or on Twitter @PariseauTT.