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

Welcome to Tech Transforms sponsored by Dynatrace. I'm Carolyn Ford. Each week, Mark Senell and I talk with top influencers to explore how the US government is harnessing the power of technology to solve complex challenges and improve our lives. Hi, thanks for joining us on Tech Transforms. I'm Carolyn Ford here with Tracy Bannon for another So What episode. Hey, Trace. So today, we welcome Allan Friedman.

Thanks so much for having me.

Well, it is great to have you. Like I said, I've been a fan for a while. And so in the introduction, we started talking about SBOMs and how they're growing in prevalence. And I feel like they're probably something that has been a big part of your world and yours to trace for a long time. But For us on the other side of things, they seem to be exploding recently. That's a bad pun, but it's true. Like, I'm seeing I'm seeing mentions of SBOM everywhere, especially since the cybersecurity executive order included them in there. So, Allan, as a person who coordinates the global cross-sector community efforts and SBOM materials as CISA.

1st, will you please briefly explain what an SBOM is and why they were included in the EO?

Fair. So, first, great to be here. Big fan of both of your respective works, and well, so the idea of an SBOM, it is actually kind of obvious, which is we should know what's in the software that we make, that we buy and that we run. In fact, when I explain this to people who are maybe tech execs, but not at all in the security space. But then we just wait. We don't already have this.

That was my response. I'm like, what do you mean we have to mandate this?

It's kind of is bananas. So I keep on my desk a Twinkie. It's it's it's a delightful metaphor, because, you know, it's it's everyone always chuckles about the Twinkies, but, you know, this comes with a list of ingredients. And it's kind of crazy that we expect more transparency from a nonbiodegradable snack Then we do, from the software that runs our organizations, our critical infrastructure, our national security systems. And so the model here is to try to make this a reality. Isn't a new idea. People have been talking about it for Almost 2 decades now. A lot of it started in the open-source world.

For those of you who like number strings, it's executive order 14 028. It's a long executive order. About 30 pages if you printed out, but one of the sections is basically about software security and software supply chain, and it says you gotta be this high to sell to the government. What are the levers the government has to improve the overall quality of software? Well, We can't we can't tell the entire world this is a secure software security requirement, but we can say to be bought by the US government. And as you both know, the US government buys a lot of stuff. And so, that really was the task. Most of those requirements were pretty basic. Things that we would really hope were already in place, which is things like have a separate dev environment from build environment and yeah.

Gosh. Are you using MFA in your environments? Things like that. SBOM was really the newer piece. So that got a disproportionate amount of attention because it has Forced organizations who don't have this vis build visibility to think about how they're going to understand their supply chain.

Yep. It's it it shocked me when I realized how prevalent lack I I still go back and call it dependency management from a year ago. How is it that we could not know the very things? And part of it has been to your point on that proliferation of software, the proliferation of libraries. It used to be. It was a lot more difficult 15 years ago to bring down a library to get it into your organization to be able to leverage it from an open-source perspective or even a paid-source perspective. It's a lot easier now, and it's a lot easier for a dev to do an MPM. Right? To do a to do poetry, to do some kind of pull, to bring down packages. Mark And the sheer proliferation, becomes very scary to your point.

It becomes very scary just to understand even what's on a developer's workstation, let alone your entire value chain, the entire, stream that goes across. Mark With the SBOM and with the mandates and with some of the subtle, changes that are taking place right now around attestations. Do you see SBOM losing any of its momentum Now that there's an it's self-attestation play at play?

Mhmm. Sorry. Wait. What do you mean by self-attestation? Are you talking about, like, AI-generating stuff. What do you mean?

Nope. No. Easy easier than that. If I don't have there's a lot of crunchiness. There's still there's still arguments and conversations going on. I'm sure, Allan, I'm hoping to ask you some questions on this. SBOMs are mandated, but not necessarily mandated for everybody. And there are still situations where companies, organizations, vendors are saying, not yet.

And so there's an out. The out is to kinda sign and say, we attest that we have everything taken care of. So it's a mark It's a Band-Aid of sorts, and I'd love to, you know so you're trusting as opposed to seeing.

So you're just signing that waiver 2 and saying, sure, we trust you, and if we die, our fault?

I wouldn't I wouldn't phrase it that way. I'd rather hear Allan phrasing on it. I don't think it'd

Yeah.

Me. Yeah.

So so so I I I wanna definitely sort of walk through the complexities of the US government requirements because, I know a lot of your listeners are interested in this, and it's complicated enough for us on the inside of the government. But before we do, I wanna talk about Another aspect of sort of losing the special momentum of this Mhmm. Which is the software world is so diverse That for some corners of the top world, SBOMs are already boring. And that's where I want to get for everything, which is to say, this is just A natural part of my build process. I have a modern CIC pipeline. It's built into all my container tools. And so why is everyone talking about SBOM? Let's move on and talk about all the other cool stuff, and the other types of things that, my attestation or my sorry. Excuse me.

My build process can securely generate as I build software. So where I want us to get is to have everyone say SBOM is yesterday's news because we're all doing it. And I know a lot of folks are

10 years ago, I worked for a big system integrator. Our product was insider threat. And, I mean, we did this. We had to. Like, right down to where the code was developed. Like, it had to be developed in certain areas, couldn't be developed in other areas, I think, that, known as the access of evil back in the day. Like so we had to do this a long time ago, which is part of why it was such a surprise to me that this isn't already boring and just a thing.

One is there was a definition of What is an SBOM? So that was the first thing the White House said was, okay. You have to have an SBOM. What's an SBOM? So the US government is going to define this. Candid so candidly, this is a really interesting process. A little behind-the-scenes negotiation and the government is, to the White House, great. We think this is a great step. Mark it'll take us 6 months to do that.

And then the White House comes back and says, great. Thank you. You have 60 days. And, of course, by the time it goes Through all of the public feedback and, the clearance process meant 15 days, so that's always fun. So we've got an executive order. We've got a minimum definition. And then the next step for the broader executive order was for NIST to update their secure software development framework. Great document.

Great for helping organizations get oriented around having a secure software development model. So that's wonderful, and it's a framework, which means it can accommodate a whole bunch of different types of organizations. Mark 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. Can we buy from you or can we not? Are you doing enough or are you not? And so the short-term goal is to say we're going to have a set of self-attestation. Here's a form written in English, not machine-readable language, but plain English or we'll say government English because Yeah.

You know? Yeah.

Even though we try so. That says I attest that I've done these things. You know? I have MFA. I'm using scanning tools for static analysis, etcetera. And then, of course, one of the other things that, OMB did, the one part of the White House said is, Hey. For this 1st wave of adoption, agencies may ask for an SBOM, but they don't have to. But that still means everyone who wants to sell through the government agency needs to be prepared. And so I don't think it has really, and this is getting back to Chris's question from a long time ago now.

Has that really affected how organizations are prepared? I don't think it has. I think both the software providers and a lot of the start-ups and open-source projects that are working with them, still feel like this is something they need to get done. Could we have been better at telegraphing concrete deadlines? Probably. But this is something that everyone sort of sees is going to come, and we're starting to see it in Contract language already. So the Department of State issued a contract that said, hey. You gotta have an SBOM, even for things like cars, you know, hey. Why does the Department of State care about that sort of thing? Well, right. When the UN General Assembly is in New York, it's the United States government that's ferrying around very, very important people.

We need to make sure those cars are secure. And so, right, we do a lot of things. So we we are starting to see, Integration into this and something that I really like is we're starting to see this more and more in private contracts. Right? Government contracts are a huge sector, But it is dwarfed by the fact that most softwares made and sold by the private sector for the private sector.

So for the most part, have you seen a positive reaction to this mandate?

I've witnessed some pushback, and I can say that the arguments have some sense to them. So they're not things that you can easily just dismiss. There are concerns by Some corporations, some companies, some suppliers that say, I don't want to reveal my special sauce. It's okay. So I don't want to reveal because it's really I've taken open source library or open source project x, And I've added a thin veneer, which is a value, but it's a thin veneer. So am I going to lose, Some of my business, am I going to be exposed in some way? So there's an interesting, conversation that has to happen there. The 2nd pushback that I heard is that and I also found a curious second one. Is that first pushback legit? Like, does it really reveal the keys to the kingdom to have an SBOM.

If someone gives you the algorithms go ahead. Go

ahead, Al. So there we have a couple of responses to that. One is no one cares about using Libsyn. Right? For Large projects, the vast majority of what's in your SBOM does not. Two, SBOMs don't have to be public, which means you can share them directly with your customer.

And then 3, something that we've built into, our public understanding of SBOM, is the idea of known unknowns. And this is not just because of Concerns about trade secrets, but also the tooling that we're using

May not be perfect yet. And so the acknowledgment that Here's what I'm telling you, and there is incompleteness at this chunk of your dependency tree. Tell your customer that, and then they can say, that's fine. We just want some basics. Or they can say, tell us more, Or they can throw a third-party analysis tool at it. Mhmm. Or they can negotiate a contract that says You have a heightened sense of responsibility for everything that's in your supply chain that you don't tell us about. There are lots of solutions here.

The importance is that we're building around this and for this.

So your first is to Trace ...

Go ahead, Carolyn. Not as big of a deal as people are trying to make it out to be.

I think that there's there's some merit, but it hinges on the second thing that Allan should. And that is I should be able to share it with you. If I'm selling to Carolyn Ford Industries, I'm giving Carolyn Ford Industries the software that you've purchased or that you have licensed and the SBOM. I'm making an assumption. This is the 2nd issue that I've encountered that there is a lack of confidence that who I am giving my SBOM, that they can properly secure it. So I'll give you my SBOM, Carolyn, but I'm not sure that your own practices are secure enough to keep my SBOM secure. So while I agree with Allan wholeheartedly that I should be able to keep it private, so it only goes to my consumers. There is some trepidation, and the world is filled with breaches right now.

Every day, another breach that we're off, You know, listening to and reacting to and maybe getting desensitized to. That was the 2nd pushback. I'll give it to you, but can you secure it? Can you promise me? Right? And so we're we're talking about a lot of handshakes, a lot of trust, a lot of verification that has to go on here. We have to build a lot of trust in a situation where we haven't always had as much trust as we've had in the past.

Is securing it problematic because it's not just, what I buy it. I look at it. Everything looks good. Now I can put it away in a vault. It's I have to share it with my developers so the developers can make sure this piece of code's not allergic to something in there. It's broader?

Broader? I could breach? What if I decided that I don't like Carolyn Ford Industries, and I'm going to breach Carolyn Ford Industries and go after your secret sauce, which is based on some other secret sauce? It is a bit contrived. They're just arguments that are out there that we hear verbalized in the public conversation.

So from that perspective, there isn't a risk there. The other end of the spectrum, we've got automated malware. Right? Spray and pray, Giddies, ransomware, all this stuff. And they're not using an SBOM either. They're using automated tools looking for vulnerabilities. And you know who needs the road map there? Is the defender. Right? Where is this on my network? We talk about the list of ingredients reference. I stole this analogy from, Josh, Corman, instead of may contain nuts, you need may contain struts.

Where is this going to be on my network? Is there some risk space in the middle? Fully willing to acknowledge that there might be, but we sort of want a better conversation about that. So, Carolyn, to your initial question, what's the pushback? The thing that tickles me is, right, there's the DC lobbyist pushback, which is Change bad. And, one, we often see it coming from trade associations that are funded by companies that are already pushing out SBOMs. So it's right. You just don't want regulation. I get it. That's their job. The job of the DC office is to push back its regulation Even though the company is already doing this.

And where we're you know, it got to a point recently that the Atlantic Council had to write a, 5 or 10-page essay documenting some of the lobbyists' complaints and how silly they were. And what I love is they combine 2 great things that I'm a huge fan of, SBOM and Taylor Swift. It was a Taylor Swift themed, essay, that just sort of basically said, you know, people who are working on SBOM should just shake it off. So, yeah. That was a lot of fun.

Are they a big lift to create? Is and is it something that AI can do. And if AI gets involved, like, Now does that open up a new vulnerability? That was a whole string of questions.

Uh-huh. No. And these are these are these are exactly the sort of questions we should be asking, not just from computer security perspective, but also from a public policy perspective. And part of the challenge is what we're trying to do is change how literally all software on the planet is made and sold. So there's incredible diversity there. At the modern end of Software engineering, you know, type of things that you and Tracy have been talking about for years. This should be pretty easy. Right.

If you're using a modern toolchain, if you're using modern languages, if your sources are built on package managers, if you're not doing a ton of backporting, this is pretty straightforward. Not only are there tools out there, but they're open-source tools. They're free tools. And it should be something that, you know, you have a new build, you have a new SVOP. The same way that building software for those organizations isn't a big deal, it was true for SVOP. Mark That is not true for everyone. And interestingly enough, this is one of the few areas in security which actually put smaller and newer companies at an advantage, not a disadvantage, because those smaller and newer organizations are likely to have this. Take a moment to feel sorry for your giant defense contractor or your global manufacturer who has Twenty different divisions, each of which has different tools, each of which has different ways of storing data, and they need to track this across all their organizations.

Now the head of product security for one of the world's largest industrial control system manufacturers has said, If we had this, we had SBOM across our products today, it would save us thousands of hours a year Because whenever the next log for Jay comes out, if you have a centralized machine-readable, scannable system, It's not that hard. If you have to go to each business unit and each business unit has to do these manually, Then you're talking about real cost. So if you're thinking about implementation cost in a properly engineered world, It's a one-time cost to build this capacity, whereas the cost of not having it is an infinite budget item. And one thing I'll say Is I've talked to some organizations who when they are told it is a regulatory compliance, say, this is amazing. Now I have an excuse to get budget to reengineer my processes, and that's perhaps one of the things that I'm I'm most excited about. We're always very careful about pushing a regulation. But if someone can use the compliance budget to do the thing that they've always wanted to do for better engineering, that's win-win. Mhmm.

I wanna add a little piece here to expand this. It's not limited, Carolyn, to defense as set to our big dip, our our defense industrial base and these massive organizations. It is part of a fintech. Mark It is part of, our health care and our insurance providers, our massive organizations, because they have decades of technology. So if you have anything that's brownfield, I use the term brownfield meaning it already existed. Could only be a year old. It doesn't mean it had to be 30 years old or 50 years old, but anything that's already preexisting, you're talking about rejiggering. You're talking about reapplying things to a process that May not be broken but might not be the most effective.

So we are talking about driving everyone Towards improvement, driving everyone towards that improvement, there's a cost. And it's okay that there's a cost, but it just has to be acknowledged. And to Allan's point and to your point, Now we can take it out of a different budget, and a budget that people are less likely, right, to cut out. The way that we used to say, well, we're not gonna do that additional round of automated testing. No. I've got this testing team. Therefore, we're not going to spend the money. We're gonna cut that from this budget And no longer do the automated testing.

Instead, we're just gonna have those manual testers who've been doing it in the past. We are not going to have a leg to stand on To say, I'm not going to do that.

So for the brownfield stuff, can't we just plug in a cyborg and tell it to scan it and tell us everything that's in it. So,

I mean, there is a whole, industry that has grown up in the binary analysis tool, especially for embedded systems where there's a lot of legacy code. And they are definitely using, various shades of AI and ML. They've been doing it for a long time. It's not it's not all the magic. You know? Does a chatbot solve this problem? Chatbot won't solve this problem. But having, everything just as simple as as fuzzy matching. Right? I've got a snippet Of these this machine code, how do I figure out what this can map to from my giant library of legacy C code, that's where you sort of start to see this, doing some, intelligent matching and intelligent prediction.

So let me take you on just a quick little side tangent for just a moment, and Carolyn will probably reel me back in. I live in a world of xBoMs, so we are now applying them. Yes. AIBOMs, that's fine. But we're also applying them to data and part of conversations that are happening with the Department of Defense around, specifically around the army, around dataBOMs, which Allan are really data cards from quite a few years ago, but they're all software. Algorithms are software. Data only exist Because there is software in the mix from that perspective, I'd like to get your quick thoughts on how this SBOM concept and construct is starting to be applied in a lot of other areas. Do you see that bifurcation maybe slowing things down? I'm looking for How do we keep things going at speed? Right.

Because we're in a good direction if we don't get crazy.

Thanks. So one, it's always flattering to become, the Uber of whatever. Right? Once your analogy is taken off that everyone wants to copy it, that's a good sign. Right? It means you won the market share. The XBON model, and is something that we're kind of excited about. It's the idea that, okay, I have software bill of materials, but I want Hardware. I want AI. I want all these other things.

And by the way, this is starting to be implemented in both CycloneDX and SPDX as the 2 dominant data formats. There are 2 challenges. 1 is how do we maintain a modular architecture March so we can tweak 1 as it advances without tweaking the other, and 2 is some of those other things are really hard. Mark CISA is releasing through our national risk management centers, ICT supply chain risk management task force. March you want acronyms? That's NRMC's ICT, SCRIM TF. Yeah. Yeah. We go.

We got that on the whiteboard here. Some Basic guidance on hardware build materials, and it's really a framework. Why? Because hardware's really hard. Right? You can't take ash of a dim. How do you actually show that something is not counterfeit? How do you how do you determine That okay. Someone way upstream of me didn't switch factories without telling me. Because that happens all the time. Right? It's people ship in SKUs, Not in, not in very specifics.

So not to say it's not a great idea. I think it is. It's something we need to get to for all kinds of risks And all kinds of quality and efficiency reasons. It's not just about security. But we also need to be Comfortable with the fact that it'll be a couple of years before we get there, and so we wanna make sure that we don't tie everything into 1 big immutable data structure That gets committed because, frankly, the US government and, we work very closely with our friends in DOD, But, they in particular have a pretty bad reputation of building, the perfect thing. You know? I've tried to program in Ada. It's wonderful. Ada is a great language.

They just spent, you know, 15 years trying to build it, and no one ended up using

Actually, you might find it funny, Allan, that a group that I'm working with, actually is dealing with a huge ADA code base as well as 13 other languages that have been scabbed onto this incredible and it's actually a very resilient, well used, system, but I was floored, that there is that that much, still well, there are still developers that are working at that. So

So all this talk and, like, even you're bringing up these different languages, which I honestly, it's kind of going over my head a little bit, but, it makes me think about this idea of secure by design. And it seems like I know, Allan, you said it's not all about security and efficiency. It is also about efficiency. But it seems like these xBoMs, all of them, are necessary in order to be secured by design.

They're a result of it, not Right. If I am building and designing something that is secured by default and by design and in-depth, Then these xBoMs are a natural output from them. They're not they're not the jump start because of it. They're a nice manifestation.

Mark Tracy, that's really well said. Right? It's SBOM is something that's cheap and easy to do if you have good processes, and it's a pain if you don't. So it's a very good signal of communicating that. And, you know, my PhD is actually on applied economics, and so, right, we talk about efficient signals, and that's one of the things we want. But the secure by design initiative, is a bigger piece. SBOM is definitely part of that, but this is something that has really been pushed, by CISA's director, director Jen Easterly, and, Bob Lord, who many of your audience will know, is sort of, He's the CISO CISO. Right? He often does a lot of, you know, direct the point. And, the director has Really starts with the, you know, the old seventies automotive, analogy that a lot of folks in security have used over the years, which is mark Cars didn't use to be safe, and we just assumed that if there was an accident, well, that's just the cost of driving.

And a similar approach is for modern IT products. We're just like, yeah, use IT products. You're gonna have breaches. It just it's a natural part of using software. It's just too complex to secure. And That doesn't make sense that, you know, we're still living with that model. And so trying to push and change this idea of How do we make it so that if I buy a product and I plug it in today and it's brand new, we know that security flaws are going to emerge. But how do we make sure that the things that we're plugging in today aren't insecure out of the box? And so there are a number of different pieces in that model, by design and default.

SBOM is one of them. One of the things that I really like for sort of large pieces of software and large appliances, the Large tech appliances is the idea of getting away from a hardening guide. Right? So right now, if I buy major software, mark Here's your software. And by the way, if you wanna do it securely, you're gonna have to do all these other things. It's like, would you like to buy This oven, and then would you like the 8 additional steps so it won't blow up your house? So let's flip that equation, which is to say, Here's the software. It sold you in lockdown mode. Here's an interoperability guide so that you need it to connect with this. Great.

Right? Software, The point of software isn't to be secure. It's to do stuff. But let's sell the guides too, make it interoperable as needed, And the rest of it stays locked down. And it also has some longer-term pictures in Secure by Design. Bunch of people have noticed, recently that if you look through the list of all vulnerabilities out there, an embarrassing amount, Conservatively half are from memory issues, and some estimates are even 90%.

What do you mean?

That's a little high, but, that basically take advantage of the fact that if you can trick a computer to executing A part of memory that contains instructions that you, the attacker, have submitted, you can take over a system. Mark Right. So buffer overflows are the simple version, but there are thousands of variants, some of which I think Tracy even discovered. And this is memory unsafety. It happens in memory unsaved languages. C and c plus plus most notably. And so setting up a long-term vision of how do we make sure that we are using memory-safe languages like Rust Mhmm. Like Go Rust.

For our ecosystem. Now this is a huge undertaking. Right? Rewriting a global code base of a huge chunk of software, not gonna happen overnight, even for individual organizations. Right? You know, the office manufacturers that we all know and love, a lot of their software is written in c. Are they gonna rewrite their code base overnight? Absolutely not. So laying out that agenda of thinking critically, and this isn't just an engineering thing, and it's not just a policy thing, although incentives are gonna be a huge piece of this, but it's also something that we're working with our colleagues at, the National Science Foundation and DARPA To explore how do we automate this. And, Carolyn, to anticipate your next question, AI automatic code rewriting is definitely not the. Tracy is violently shaking her

head. What? I know that just from using AI to try to write a paragraph of, you know, not I don't wanna say pros, but just just to just to write. It doesn't it doesn't work that way. Consider it's not there

yet, and It will be incredible, and it's not there yet. And we've got a ways to go, and it's not there yet. Will it be helpful? It will be amazing, but we're not there yet. And I'm gonna just keep foot stomping and foot stomping and foot stomping because folks Are assuming because they've gone and they've used chat JPT, and they've asked a couple of questions and got something that sounded confident in well-formed English That in fact, it's great. No. It's it's not there yet.

If you know anything about your subject, oftentimes, it's crap. Yes.

That's that's true. No different for code. No different for generation of code. No different for understanding large context. There are some fantastic ways that we can use it, but I don't wanna take Allan down that raw rat hole because that will be another fantastic hour plus.

Will, I do. And by the way, we have some great AI folks here at CISA, and I do wanna plug a blog post recently written by Christine Lai and, Jono Spring, My 2 colleagues here at Cisco, software must be secured by design, and AI is no exception. AI is software, and so the same things. And by the way, that also means we need transparency. We need model cards. We need data cards, and we need to improve both of those ideas, so that they're machine-readable. Because right now, they're both great solutions, but they're really not built for automation.

It's funny that you mentioned that because I literally reported on that On Friday morning for a little snippet that I do called 505, and we do about 2 minutes on it. And we were talking about the point of view that, AI is just software, and so all of this goodness needs to be applied. I will put up my own pitch out here. I'm an architect. I'm a software engineer. So it has been driving me batty, driving me crazy at all of the attention that we're placing to after the software is built. We're attesting to these things. We're looking at after it's built.

And so when the secure by design guidance came out, Last year at RSA, the big, security. Right? It's the paramount, the preeminent, cybersecurity, conference. I walked the floor, and I saw essentially 0 about architecture, 0 about, secure by design. This year, CISA had a booth, and And I have my picture. I have my stolen stickers, secured by a design. So from my vantage point, Any way possible that we can help people to move things towards the origin, to be thinking about things from the very beginning is absolutely positive. And all of these downstreams are wonderful manifestations that help us to manage it and help us to audit it and help us to what might be watching these things when something happens.

It's just easier to do it right from the beginning. Right? Like, these are lessons I learned from my dad when I was a kid. You do it right from the beginning. It's a lot it makes your life a lot easier in the end.

To Allan's point, not everybody knew what to do, and things have changed. And so we have to keep keep pace with that in large code bases without out that kind of modularity without the decoupling that we want that allows us to get after that piece and address that piece or address that package Because we have these big, you know, we call them a ball of mud, right, or a monolith, that's a lot more difficult to do all the things that we're talking about, all the things that Allan's bringing forward today.

Yeah. So, Allan, time's beaten us, but what is there anything that you want to leave our listeners with? Like, last piece of advice around SBOMs, xBoMs.

So one, everyone should start asking their suppliers for an SBOM. One, it's the old trick. The worst they can say is no. But if they can't give you an SBOM, start asking why. Two, if you're in a software development organization, make sure that you start down this road. And Some of it is pretty straightforward. Right? There are automated tools in GitHub that will give you an SBOM based on your source today.

So, again, If your organization can't do this or isn't willing to, start asking why because that's a very important piece of that as well. And then the other thing from a policy perspective and a technology perspective is there's a cliche that is Always, that is really true. This case, we're just we're building the plane while we're flying it. And so if you're interested in this idea and wanna help, atcisa.gov/sbaum. We have, and or you can send us a note at sbaum@cisa.dhs.gov. We have working groups that are busy trying to tackle some of the big questions here. Hey. How do I move this data around securely? What does SBOM mean for software as a service? How do we promote adoption in my corner of the world? So we've got working groups, and we want your help.

We're designing this to not just be a couple of because, frankly, I haven't touched prod in, like, 15 years. No one wants me designing things, but what we do wanna do is make sure that we're capturing the perspectives of everyone from, You know, bleeding edge container developers to, legacy developers in things that are critical to health and safety like automotive and, health care and industrial control. So if you're interested in engaging or you have opinions Or you just wanna tell us that we've got everything all wrong. That's what we're here for. So, SBOM at cisa.dhs.govorcisa.gov/sbaum. We're we'd love to engage with you.

Alright. So really fast, I wanna get to the Tech Talk questions. So these are just fast, fun questions, totally off-topic. Like the first one since we're in Thanksgiving time frame time period. Do you have a favorite Thanksgiving dish or tradition?

So I'm my family's cook, and like many of us, I've got a very diverse family in terms of food requirements, So I always try to make a little of everything. I have been deep frying the turkey because a lot of Thanksgiving stuff, comes in the oven. And one of the things I'll tell you is I've learned why turkey frying is a southern tradition is because if you have a Thanksgiving in New England, really cold outside to be standing and watching a, standing and watching a mark Also, if you'd like Thanksgiving cocktails, allspice dram is your friend. What is it? I do. Allspice allspice dram. It's an allspice-themed cocktail. It's really great for, Christmas and Thanksgiving cocktails.

This might be my favorite part of the show just because I get really good tips. So, Tracy, you wanna ask the next tech talk, and then we'll let Allan go.

Oh, sure. There are 2 of them, but I'm gonna keep it to What is the piece of technology that you are personally most thankful for?

Oh, that's a fun one. You know, just without giving in any thought, I'm gonna say just the fact that AirPods can magically flow between devices. We're all on a lot of different devices these days, And, you know, both my work and personal stuff are Apple ecosystem, and just having it seamlessly flow has been A nice efficient way to move things.

I love that. Well, thank you very much for joining us, Allan. And I have to say before we close. So you coauthored the book Cybersecurity and Cyberwar. I have to give a plug to our audience. So Allan wrote this with Peter Singer, also one of my favorite authors. It's very accessible. It still applies today.

And one of my favorite parts about it is you end the book, with what can we do. So you build it out what the problem is, you know, and then you talk about the problems and some scary ones. And then you talk about how you know, what we do. Super important book, accessible it's actually kind of a fun read. So I had to give the book a plug, and then thank our audience for joining joining us on tech transforms, and we will talk to you next week. Thanks for joining Tech Transforms sponsored by Dynatrace. For more tech transforms. Follow us on LinkedIn, Twitter, and Instagram.