Interview with government IT “Reformer” John Weiler
By Deb Radcliff, editor of TalkSecure, sponsored by CodeSecure and syndicated at Security Boulevard & YouTube
Starting in February 2025, the U.S. Army will require software bills of materials (SBOMs) for new software contracts. The requirements apply to all “covered computer software,” whether developed by government agencies, contractors, or commercial off the shelf (COTS) vendors. This includes all layers of technology from defense business and operating systems to battlefield operations to combat vehicles, field equipment, and beyond.
“Whether IT or OT, it’s all software. Software ate IT a long time ago.” John Weiler
While most commercial IT vendors stand ready to comply, the U.S. Army may need to stand down on the February deadline, contends John Weiler, Agile Master and CXO, CoFounder of IT-AAC, (IT Acquisition Advisory council—a congressionally-charted “do tank” tasked with reforming the Federal technology acquisition system).
The reason? The Army is not yet able to process and vet vendor-supplied SBOMs and vendor-provided attestations, he explains.
Critical Capabilities
“The Army, which is probably the largest consumer of IT in the world, carries lot of critical capabilities that the DoD relies upon. Yet, the Army doesn’t have a great success record, either,” he said during our interview.
To help streamline the IT acquisition process, the IT-AAC studied root cause analysis on DoD IT acquisitions and installations gone wrong, conducting 75 workshops and evaluating every major program failure—a lot of them in the Army, he noted.
“We keep finding the same patterns. That is, we’re rushing through the requirements and assessment process while trying to get to delivery,” Weiler explained. “But in the rush to buy, we are missing opportunities to identify risk that will impact failures down the road, after systems are in production.”
Anticipating this shortcoming, Weiler and his team at IT-AAC helped write assessment requirements for DoD IT acquisitions in partnership with DARPA (Defense Advanced Research Projects Agency), the CIO (Chief Information Officer) of DoD, Secretary of State, and experts from other agencies. The team also worked with industry leaders in automobile and other safety-critical sectors, as well as tapping leadership at CIA, NSA, and other three-letter agencies with strong records in cyber security and agile innovation.
Bloated Bureaucracy, Limited Resources
Weiler credits these assessment requirements and other guidelines and resources as ready and useful for military IT acquisitions. The holdup, though, is funding and manpower. And red tape.
Despite its size, the U.S. Army Cyber Command, is short on resources just like every other government agency. So, he asks, who is going to assess and validate vendor or contractor assertions against billions of lines of code across hundreds of applications? “We don’t have a robust tech assessment process functioning across DoD. We don’t have the staff. And who’s going to pay for it?” Weiler asks.
Ultimately, he sees an outside third-party stepping in, such as NIST (National Institute of Standards) or Carnegie Mellon. But that won’t happen before the February deadline.
Not surprisingly, the IT-AAC team also noted another common failure common across the U.S. government: Bureaucracy. The average cycle of new IT acquisition being four years (about the same time it takes to hire new staff), it makes sense that the commercial sector runs far ahead of government with software innovation and SBOM readiness.
To that end, Weiler and the IT-AAC team are currently urging the government to tap proven IT leaders including the Army CIO (who came from the intelligence community), and Army Chief of Staff, to drive integration of SBOMs with more agile acquisition practices in order to mature the Software Development Lifecycle and embrace full DevSecOps.
Faster, Better
Weiler iterates that, whether considering OT, cloud apps, or the underlying chips and operating systems behind them, the U.S. government is required, by law, to first assess any viable commercial applications. Commercial vendors not only are more agile, but generally more secure because their products undergo rigorous and continuous user testing while in the field, Weiler explains.
“If you have a commercial item, you have a better outcome because that code is used by tens of thousands if not millions of customers. And the customers provide feedback. With a contracted company developing custom code just for the Army, you have only the one customer,” he says.
“Commercial software bears less risk and costs, and vendors provide more robust SBOMs and attestations because they’re required by law to provide that to the government.” John Weiler
When they do develop custom programs, government agencies and contractors rely more heavily on open source than commercial vendors do. But the government mostly uses “free” open source, which is more risky, he notes.
Many open-source libraries are rife with malware installers, vulnerable code, and other risks. Yet, Weiler adds, there is no mechanism to enforce secure management of these libraries, even with profitable hosts like Linux, to ensure the safety and security of their libraries and code.
This presents a huge national security risk, particularly for the U.S. Army. “The Linux Foundation has over 250 Chinese contributors, the largest pool of any national interest in open-source code,” he says. “Just let that sink in a moment.”
Don’t Trust, Do Verify
For all software code, whether it be open source, COTS or custom, integrating SBOMs and attestations into the U.S. Army acquisition cycle is just the beginning of what looks to be a long, evolving process. Because, without trusted, third-party validation, there’s no way to enforce penalties. To that end, he suggests bringing up an organization for government systems akin to the TCIA (Telecommunications Industry Association).
“We’ve made recommendations to the White House to put some teeth into Executive Order 14028, but we have a long ways to go,” Weiler surmises. For now, without proper vetting, and without an enforcement mechanism, he predicts that the February 2025 cutoff date for SBOMs with Army contracts is “going to bomb.”
Resources:
Generate your own SBOMs on third-party code using CodeSonar’s advanced Binary Composition Analysis (BCA).
IT-AAC reports and data sheets: https://it-aac.org/reports/
