Unraveling SBOM Challenges: AI, Transparency and Policy Perspectives in Software Security

Meet the man on a mission to make software bill of materials (SBOMs) boring. In this So What? episode, Tracy Bannon and Carolyn Ford sit down with Allan Friedman the Senior Advisor and Strategist at the Cybersecurity and Infrastructure Security Agency (CISA). Allan tells us about how he is working to change how all software on the planet is made and sold, no big deal right? Join us as we dive into the world of SBOMs, xBoMs, and Secure by Design.

Key Topics

• 03:59 Track open source licenses, establish shared vision.
• 08:47 Discussing US government requirements, diversity in software.
• 12:07 Framework helps organizations with secure software development.
• 13:49 Organizations unaffected, prepare for impending software changes.
• 17:40 Concerns about sharing software with potential security risks.
• 20:59 Concerns about network security and regulatory pushback.
• 24:14 Enhanced security measures save thousands of hours.
• 27:53 Applying AI and data bombs in conversation.
• 32:38 Discusses the importance of SBOM in cybersecurity.
• 36:29 Rewriting global code is a complex task.
• 39:39 At RSA, little focus on secure design.
• 41:53 Organization's need for SBOM, call to action.
• 43:55 Cooking for diverse family, diverse food requirements.

Challenges and Implementation of SBOMs

Self-Attestation for SBOMs

Allan Friedman explained that there is currently a self-attestation model for SBOMs, where companies can sign a form stating that they have implemented SBOMs, rather than providing the actual SBOM data. This allows flexibility for organizations that are not yet ready to fully comply. However, it means buyers have to trust the attestation rather than seeing the SBOM details directly.

Secure Software Development Model Compliance: "The challenge there is turning the framework back into a compliance model. Because, again, at the end of the day, everyone wants to think about things. Right? Understand your risk, but you still need to make that yes or no decision."— Allan Friedman

Tracy Bannon noted some companies have concerns about sharing their SBOM data with customers, worrying that the customer may not have secure enough practices to properly protect the SBOM. Allan Friedman explained SBOMs do not need to be public - they can be shared privately between supplier and customer. Known unknowns in the SBOM can also help address concerns about revealing proprietary information.

Debate About the Risk of Sharing SBOMs as a Road Map for Attackers

Allan Friedman argued that sophisticated attackers likely do not need the SBOM, as they have other ways to analyze and reverse engineer software. Automated attacks also do not leverage SBOMs. He noted defenders actually need the visibility an SBOM provides into components and dependencies. There may be some risk of exposing attack surface, but the benefits seem to outweigh that.

The Importance of SBOM for Product Security: "If we had this, we had SBOM across our products today, it would save us thousands of hours a year Because whenever the next Log4j comes out, if you have a centralized machine readable, scannable system, It's not that hard." — Allan Friedman

Allan Friedman noted there has been some lobbyist pushback against SBOM mandates, often coming from trade associations funded by companies already implementing SBOMs. He said while healthy debate is good, many of the lobbyist complaints seem misguided or overblown.

The Potential Role of AI in Creating SBOMs and Its Implications for Security

Carolyn Ford asked whether AI could help automate SBOM creation, especially for legacy systems. Tracy Bannon cautioned that AI is not yet at the point where it can reliably generate code or understand large complex contexts. AI may eventually assist, but currently is not ready to take on SBOM tasks. As AI is software, it needs to be secured using the same best practices as other code.

Tracy Bannon explained SBOM implementation may be harder for organizations with large legacy codebases and multiple complex or siloed systems. However, even newer companies can struggle if they have not built SBOM processes into their SDLC. Allan Friedman noted while costs exist, especially for older systems, SBOMs ultimately save defender time and money.

Benefits of Better Engineering Processes

Allan Friedman said some organizations view SBOM mandates positively, as it gives them budget and justification to reengineer antiquated processes. Overall, SBOMs provide incentives and reasons to follow modern secure software practices.

Tracy Bannon emphasized that any mandated change involves costs, which need to be acknowledged. But driving adoption of SBOMs and secure development practices is still an important improvement goal. Organizations should be supported in this transition.

Government Requirements and Standards

Complexities of US Government Requirements for Software

Allan explains that the executive order issued requirements that all software sold to the US government would need to meet certain security practices, like having separate development and build environments and using multi-factor authentication. While these may seem basic, turning the NIST framework into concrete compliance requirements has been challenging. The government pushed for a quick definition of SBOMs, while agencies said it would take months. There's a need to balance the push for progress with the realities of implementing changes across complex legacy systems.

Open Source License Tracking: "And if you're an organization, you need to track which open source licenses are you using both in your open source and your code because there are strong rules for some of them."— Allan Friedman

For some parts of the software world, Allan notes that SBOMs are already considered standard practice. Modern developers with continuous integration pipelines can easily generate SBOMs automatically. The challenge is bringing along the organizations still using legacy tools and processes. Widespread adoption will take time. The goal is for SBOMs to become a boring, expected part of software delivery that doesn't require much discussion.

Timeline and Process Following the Executive Order

The 2021 cybersecurity executive order mandated the use of SBOMs but didn't define what they were. After pushing for a faster timeline, the government issued a minimum definition of SBOMs within 60 days. NIST then updated their secure software development framework with guidance. The next step is moving from framework to compliance model, with self-attestation as a starting point until more formal requirements are in place across agencies.

The executive order mandated SBOMs but didn't define them, so the government had to quickly issue a minimum definition of what constitutes an SBOM. This was a challenging process that required balancing perspectives from across government and industry. The public and private sectors need a shared understanding of what SBOMs are as adoption spreads.

Concerns and Solutions

Concerns From Corporations and Suppliers About Revealing Proprietary Information

Allan acknowledges there are concerns from some corporations and suppliers that providing an SBOM could reveal proprietary intellectual property or special sauce in their software products. Many organizations want to avoid exposing their competitive advantage or secret methods. Allan says the SBOMs do not need to be public - they can be shared directly and privately with the customer purchasing the software. There are also ways to designate known unknowns or gaps in the SBOM data.

The Importance of Software Bill of Materials (SBOM): "We're building the plane while we're flying it."— Allan Friedman

Tracy raises the concern she has heard that requiring companies to share SBOMs with customers could potentially expose their intellectual property if those SBOMs are not properly secured. She notes there have been many high-profile data breaches lately. This means vendors may be wary about sharing an SBOM with a customer if they lack confidence in that customer's data security practices. There needs to be trust between the entities exchanging SBOMs.

Claims Regarding the Majority of SBOMs Content Not Being Secretive

In response to concerns about IP exposure, Allan argues that for most large software projects, the bulk of what is contained in an SBOM does not represent core proprietary IP or secret sauce. As an example, he says that just listing common third-party libraries used does not reveal a competitive advantage. So fears may be overblown about SBOMs leaking meaningful intellectual property.

Given the valid concerns around proprietary code exposure and SBOM generation limitations, Allan advocates for the concept of designating "known unknowns". This would allow software providers to specify areas of the codebase or supply chain that have incomplete SBOM data due to proprietary restrictions or tooling gaps. Known unknowns enable transparency about the boundaries of SBOM coverage.

Software Supply Chain Security and SBOMs

Buffer Overflows and Memory Unsafety in Programming Languages

Allan Friedman explained that a large percentage of vulnerabilities arise from memory issues. Buffer overflows are a simple example, but there are thousands of variants that allow attackers to execute malicious instructions by tricking a system into accessing attacker-controlled memory regions. This memory unsafety occurs primarily in languages like C and C++ that lack memory safety protections.

Given the risks from memory unsafety, Friedman discussed CISA's vision of pushing more secure software development through the use of memory-safe languages. Languages like Rust and Go provide memory safety protections that prevent common categories of vulnerabilities. However, rewriting major legacy codebases will take time. CISA is exploring partnerships and incentives to accelerate adoption of memory-safe languages over the long term.

Group Dealing With a Large ADA Code Base and Other Languages

Tracy Bannon noted that some organizations, unfortunately, cut budgets by avoiding automated testing in favor of manual testing. But requirements like SBOMs remove excuses to not invest in automated processes and improved engineering.

Tracy Bannon mentioned there are ongoing conversations with the Department of Defense around extending the SBOM concept to data through "data bombs." While AI and algorithms are software, data artifacts like model cards and data cards also need supply chain transparency.

Bannon highlighted that she works with a group managing a complex codebase including not only a substantial amount of ADA, but 13 other languages layered onto the system. This exemplifies the challenges of legacy systems.

Friedman explained that CISA's director and CISO have been pushing the secure by design initiative to make software more inherently secure out of the box. He provided examples like moving away from hardening guides and instead selling software locked down, with optional integration instructions.

About Our Guest

Allan Friedman is a Senior Advisor and Strategist at the Cybersecurity and Infrastructure Security Agency (CISA). He coordinates the global cross-sector community efforts around software bill of materials (SBOM). He was previously the Director of Cybersecurity Initiatives at NTIA, leading pioneering work on vulnerability disclosure, SBOM, and other security topics. Prior to joining the Federal government, Friedman spent over a decade as a noted information security and technology policy scholar at Harvard’s Computer Science Department, the Brookings Institution, and George Washington University’s Engineering School. He is the co-author of the popular text Cybersecurity and Cyberwar: What Everyone Needs to Know, has a C.S. degree from Swarthmore College, and a Ph.D. from Harvard University.

Episode Links

• Executive Order on Improving the Nation’s Cybersecurity
• CISA’s Software Bill of Materials (SBOM) Page
• CISA Blog from Christine Lai and Dr. Jonathan Spring
• Allspice Dram in Cocktails