Government

Industry groups push back against new rules for federal software vendors

Industry groups are pushing back against proposals to require software bill of materials and vulnerability disclosures from DHS vendors.
article cover

Francis Scialabba

· 4 min read

Proposed cybersecurity rules in the 2023 National Defense Authorization Act (NDAA) would strengthen software supply-chain security and hold developers more accountable for bugs in their products, experts say—but they’ve run into industry opposition.

Language in section 6722 of the House version of the NDAA passed in July would create new requirements for vendors selling software to the Department of Homeland Security—with potentially sweeping effects on procurement across the federal government. First, those vendors would be required to keep a software bill of materials (SBOM), accounting for all code that went into the product. Proponents argue that this provision creates records that can alert users to newly discovered defects that might affect their software, including vulnerabilities like the Log4j bug that could be deeply buried in code.

The return on investment for SBOMs is “incalculable,” Thomas Pace, co-founder and CEO of firmware analysis company NetRise, told IT Brew. “If we look at the number one critical security control that everybody agrees on, [it’s] asset inventory. ”Why would we not apply that same principle to the software that is running on all of our devices?”

The second major provision would require software vendors to certify that products are free of known defects or vulnerabilities, such as those identified in NIST’s National Vulnerability Database or other such databases picked by CISA. That language includes a loophole a mile wide, as vendors would only need to present a plan to fix or mitigate the bug, and DHS can determine how much risk it’s willing to take on for those issues that aren’t mitigated. But the language is designed to impose the same kind of accountability on software developers as the government imposes on other kinds of vendors.

“The spirit of it is to raise the bar a little bit,” Luke Tenery, a partner at StoneTurn, told IT Brew. “To make sure it’s known [and] documented, that there’s an expectation that there’s some level of rigor to secure software development, and working to remove and address vulnerabilities.”

Four industry groups wrote a letter to the House Armed Services Committee protesting SBOM rules they saw as “vague and internally inconsistent,” as well as arguing the requirement to identify and develop fixes for known vulnerabilities is at odds with other federal efforts. According to Nextgov, the pushback appears to have had an effect, with GOP Rep. Mike Gallagher telling the audience at a Foundation for Defense of Democracies event lawmakers are trying to “internalize and meet [software makers] halfway” by modifying the language “substantially.”

Top insights for IT pros

From cybersecurity and big data to cloud computing, IT Brew covers the latest trends shaping business tech in our 4x weekly newsletter, virtual events with industry experts, and digital guides.

Michael Daniel, president and CEO of the Cyber Threat Alliance, told IT Brew via email that the federal government’s purchasing weight could push the market toward SBOM adoption. Legislation, Daniel said, could spur government and industry to agree to solutions on logistical and “process issues” like standards or correlation of SBOM data to vulnerability databases.

“What format will SBOMs use?” Daniel asked. “How and when do we automate them? How often should companies update them? Right now, we don’t have answers to these questions, and it will mean that if this provision goes into effect too rapidly, we could end up with SBOMs in Excel spreadsheets, pdfs, and Word documents, all in slightly different formats and not easily shareable, searchable, or manageable.”

Tenery told IT Brew that opposition from software industry groups is likely related to concerns “that there is some kind of new shift of liability” that vendors would take on, as well as increased costs and time to market. But he mentioned that another element may be that vendors are worried about taking on responsibility for third-party software components they didn’t build.

“I think a big part of it, that may not be being said here, is how reliant…software developers are [on] other third parties or sources, meaning: open source software [or] other third party developers,” Tenery said.

“Going back in time and generating SBOMs for everything that has ever been written is wildly challenging,” Pace told IT Brew. “But we can draw a line in the sand and say, ‘Moving forward, we need to have an SBOM, and there are very, very easy technologies in place to make that possible.’”—TM

Do you work in IT or have information about your IT department you want to share? Email [email protected] or DM @thetomzone on Twitter. Want to go encrypted? Ask Tom for his Signal.

Top insights for IT pros

From cybersecurity and big data to cloud computing, IT Brew covers the latest trends shaping business tech in our 4x weekly newsletter, virtual events with industry experts, and digital guides.