Episode 104
EPISODE SUMMARY
Subscribe or listen now: 
Joseph Carson:
Hello, everyone, welcome back to another episode of the 401 Access Denied Podcast. I'm the host of the show, Joe Carson, chief security scientist and advisory CISO at Delinea. It's a really pleasure to be here with you. And I've got a very important topic, something that I've been keeping an eye on for a number of years now, and I've got the best person on the show to really take you through that experience. Allan, welcome to the podcast. If you could give us a bit of a background about who you are, what you do, and some things about yourself.
Allan Friedman:
Sure. Thanks so much for having me. My name is Allan Friedman, I'm with the Cybersecurity and Infrastructure Security Agency in the United States. We're America's civilian cybersecurity agency responsible for protecting both the government and indeed the broader general population inside the US and partnering with our international peers. I'm a failed professor who got suckered into joining government about seven or eight years ago and trying to find and help coordinate on issues like vulnerability disclosure, and IoT security, and, of course, software bill of materials where government can't solve it alone but government can help be a catalyst for helping to drive progress in the security of software.
Joseph Carson:
Absolutely. It's very much a big ... A public-private partnership in order to collaborate together. You also the offer of the book as well which is one of my favorite books. Tell us about the book that you co-
Allan Friedman:
Sure.
Joseph Carson:
Co-wrote.
Allan Friedman:
See, I keep a copy on my shelf.
Joseph Carson:
Yes.
Allan Friedman:
I keep a copy of the Korean translation on my shelf.
Joseph Carson:
Okay.
Allan Friedman:
And I'll admit, it is now 10 years old so this came out in 2014. Cybersecurity and Cyberwar: What Everyone Needs to Know is ... Co-author was a guy named Peter Singer, he's an excellent sort of national security expert and popularizer of concepts. Really it was one of the first books as a cybersecurity one-on-one primer that explains some of the basics on tech, which, of course, you out there probably don't need to know, but it also walked through a lot of the core policy issues, governance issues, incentives issues that we're still dealing with today.
Joseph Carson:
Yeah, absolutely. I found it a fantastic read so I was wondering-
Allan Friedman:
Oh, well thank you.
Joseph Carson:
I think that's actually one of the first times I met you was actually getting a signed copy of the book many conferences ago. But I definitely recommend ... We'll make sure the readers have a link so they can go and take a look if they haven't read it already. We're here to talk about a very important topic which is something that we've had numerous conversations on. It's really building a lot of momentum in the industry as well which is the SBOM, which the software bill of materials. Can you tell us, what ultimately is SBOM? And what does it mean and what's the background?
Allan Friedman:
Sure. So an SBOM is basically a list of ingredients for software. Of course, it's more complex with that but it starts with the idea. That to me it remains bananas that in 2024 most of us build, and buy, and acquire, and use software without knowing what's in it, right? You can't go to the store and buy a piece of candy without it coming with a list ingredients. Why do we expect more out of a snack than we do out of the software that runs our organizations, our governments, our national security systems, our critical infrastructure? Now, making that a reality is, of course, a little more complex.
Joseph Carson:
Yeah, absolutely. I mean, I've been in the building software industry for 20 years, and you'll always have lots of components whether it being proprietary or third party or different sources that you're using, libraries, that ... Even whether it's just part of the operating system or part of other applications that you're trying to deliver that does a certain functionality whether it be encrypted communications, or rather it being ... Doing authentication and authorization of signing in. A lot of those use a lot of components that you may not be creating yourself. And absolutely you bring up a very important area is that when you're ultimately shipping that you want to know everything that's in there, whether it's the stuff that the vendor who's delivering the software has created, and also what other components they might be using. One of the big ones I remember was a Log4j was that was when everyone's running around going "Whoa. Am I even using it or not?" And it was built into a lot of vendor software. Is that something that also drives the need as what it comes to patching those pieces?
Allan Friedman:
The log for J helped my cause a lot, right? A lot of us remember dealing with that and spending the Christmas holidays hunched over our tiny little travel laptops. In my case, it was my sister-in-law's guest bedroom. It really exposed the idea that you need to know what you have because if nothing else, it helps you respond so much more efficiently. The organizations that had SBOM capabilities already implemented. This was something that was fairly straightforward to deal with. And even if you just had a pile of this SBOM data at the time, it was a morning's worth of scripting rather than two weeks of searching websites, calling customer support, and some things like that.
More broadly, we've seen a focus in attention to software supply chain. Maybe some of that's good news actually that attackers are starting to go after supply chains because our software has gotten much better. We'll use that as the positive spin that we are better at software security than we used to be. We need to sort of track all of these different new vectors into our supply chain. And, of course, the other piece is as we continue to build software on top of software on top of software and identify risks, the risk that's identified may be found in very common pieces of software, major pieces of tech that we all use.
But so many organizations use relatively uncommon piece of software, right? So if you're a scientific organization, maybe they're only 10,000 other instances of this piece of software on the planet. The likelihood that there's going to be a CDE in that piece of software, pretty small. However, that piece of software almost certainly uses other software that may be vulnerable, and may be outdated, may have other risks, may have contributors from countries that your country wants to know about, et cetera. And so having that visibility into the supply chain is important and it's getting more important every day.
Joseph Carson:
Absolutely. As you mentioned supply chain, we're living in the world of supply chain and everything is being brought together. I think it's so critical even when you start to understand about all the makeup. I think we had the conversation about me being at Estonian. I remember going in, I always had to talk about software to find networks. I was like "This is what we need to be doing, we need to know all the software that's running in the network." Estonian's approach was like "No, let's let service to find network." I really intrigued. I just thought that was interesting because it was then taking all of those pieces of software and figuring out what does it all come together to create. What service result we can deliver at the end?
To your point, when you have a good understanding of all the inventory, and the versions, and the assets for the organization, it does help you to really react not just faster but also more intelligently when you need to either update those or to apply fixes and bugs when certain vulnerabilities do come out. Ultimately, what's the intention? What's the value that ISFAM provides to organizations that follow it?
Allan Friedman:
We can think of the value as hitting across the entire supply chain and lifecycle of software. So let's start at the end. You've got the operator of the software, you've got a lot of software running on your network. We know security 101, you can't defend what you don't know about, right? And if you go to something like the cybersecurity framework, which a lot of the world has adopted, right, step one or even step zero is understand what you have.
Then once you know not just this is the blinking box but this is what's inside the blinking box, you can better understand the risks. And it also helps, by the way, for areas where a patch may not be available, or you to test it because its blinking box is keeping grandma alive. But there's still other things you can do, right? You can segment your network, you can tune your IDS. You can work with threat intelligence to say, "Well, I'm going to leave this on the network, but the second we see an exploit in the wild pull on that custom-built kill switch."
But there's a lot of things we can do at the operator level to respond to novel risk but let's work backwards a little bit. So before you have someone operating that ... Someone who's making a decision to choose that piece of software whether they're signing an SLA for a cloud platform, they're buying something and putting it on their network, they're selecting to use an open source project, and this is where you really need that visibility of one, why would you trust someone who couldn't give you this? That should give big red flags. If you ask for an SBOM and they say, "Oh, we just don't know it," giant red warning label. But it also allows you to do that work on list analysis of what am I getting into? Obviously, for security, are there known vulnerabilities that you want to ask about? Are there concerns about sourcing? We're starting to pay attention to where your software comes from.
But there's also non-security issues. There are a couple of folks out there today that will look at an SBOM and give you a metric of technical debt, right? If you're about to subscribe to a cloud application, you're one of 10 users right now, and you realize they're using a six-year-old framework. Well, they're going to have to refactor that and that may be expensive. If you're bearing 1/10 of that cost you should know about it. You may still say it's worth it but you should know that.
We have the operators, we have the choosers, and then we get back to our developers. Where the value of knowing what you're shipping still one, helps you understand the risk, helps you respond in new concerns, but also gives you that global picture. There are vendors out there, especially in things like the OT world, where people have done teardowns and said "There are seven or eight versions of the same library, even this product." So that's a wildly inefficient development process. So you can turn this again, not just for security but into dollars and cents into better quality software.
Joseph Carson:
Absolutely. It reminds me of a lot of the cases for backwards compatibility. That's one of the reasons why you end up with so many versions of libraries is that there's one version out there that just needs to be able to deal with this old system that we've got. That basically that library is what makes it work. If you even look at a lot of operating systems, the backward compatibility goes back 20 years years in order to support some of those older integrations.
And I think that sometimes, to your point, is that when you get into that situation it does stop you from really moving forward faster because you end up having all of these legacy technical debt that just holds you back. And at some point in time you have to make that decision, when do you cut it off? When's that life cycle ... When do you decide to end of support it and move forward with basically fewer libraries, and also fewer vulnerabilities, the whole thing? I mean, is this something that's really a US-focused initiative and framework? Is it a framework or is it something that we're thinking about as a best practice? Is it something drifting from the US or is it something that globally is being adopted?
Allan Friedman:
Sure. It is definitely not a US concept, it's not an American-driven concept. In fact, if you sort of trace the roots of it, it goes all the way back to Japanese industry and the Deming supply chain revolution. Those of you who have been part of the DevOps revolution for a while know that in the early aughts, the inspiration for ... The great leap forward for software came from heavy industry, right, we were pulling all of these lessons from aluminum manufacturers. SBOM is very similar which is it goes back to heavy manufacturing. The Toyota Revolution that Japanese industry catalyzed but the rest of the world soon got on board of saying, "I need to pay attention to who my suppliers are and what the risks are in that supply chain." The idea had been around for a while. Some folks at OWASP were kicking it around. Josh Corman from I Am The Cavalry was talking about it. Jeff Williams from OWASP. A number of other people.
What we did in the US government was say, "It's time to actually move forward on this idea. And it can't just be one corner of the ecosystem, it can't just be modern application development and leaving embedded systems behind." And we had already seen movement from the healthcare regulators, medical device regulators in the United States. If it was just a healthcare solution, well, a regulator can compel action but that doesn't ... So what we did in the US government, we're starting at NTIA and now in CISA is to say, "Let's try to pull together people from across the entire software world, different sectors, and also the creators and the users of software and say, what does transparency look like in the supply chain? How do we make progress?"
We've had international participation from the beginning. So I run some weekly meetings. A great guy from JPCERT who joins in the middle of the day US time which is middle of the night in Tokyo. And in fact, we here at CISA just launched the global government expert forum on SBOM where we're working with 14 partner government agencies around the world, in Europe and Asia, to make sure that we're all on the same page. One of the things we definitely don't want is to have an American SBOM and a Japanese SBOM, and then a NESA SBOM, and things like that.
Joseph Carson:
You end up with lots of inconsistencies, and lots of different results, and different frameworks which sometimes don't integrate together those. My understanding is a lot of the work you're doing is making sure the policy's consistent across the board. Is that we're focusing on that collaboration not just between private and public partnerships but also multi-government, multinational stakeholders, that we're all on the same page, we all add the things and experience it together. So I think that's the significance. Is it going to become something like a standard that is put in place? What's the ultimate result here? What would be the-
Allan Friedman:
For me the ultimate result is, three years from now I want almost no one to be talking about SBOM, right? I want it just to be a natural part of how all software is developed, it should just fall out of your build process. And then on the consumption side, just all it ... It should be built into all of the tools on the user side, right? It should be built into your vulnerability management, your asset management, your CMDB, and things like that.
Joseph Carson:
Okay.
Allan Friedman:
How do we get there? Well, there are a couple of things that we can do. It's important to acknowledge what government can't do. What government can't do is we're not going to make the tools, right? And the good news is there are lots of folks who are building SBOM tools. Those of you who've been aware of software licenses know that people have been focused on tracking use of open source for a decade, two decades. So there are tools out there, there are more open-source tools coming online every day. And, of course, there are lots of great proprietary tools. Depending on what you need, there's something out there to help you generate the SBOM data. There's a docker command called sbom. You know what it does? It gives you an SBOM.
Allan Friedman:
Now, will that work for the organization that is building complex, $30 million operational technology that has hundreds of subsystems now, right? It's going to be a little harder. And, of course, thinking about the legacy side, it gets a little more tricky as well. What we've tried to do is help define the basics of what is an SBOM and then continue to refine that. Then we have SBOM data formats. Again, we didn't want to create these. And the good news is that there are two out there, they're both great. CycloneDX is created by OWASP. SPDX has been around even longer, that's from the Linux Foundation. Both of them have new versions coming out very soon. Both of them are open source, both of them are great community with lots of tools that are out there. The bad news is that for a long time they fought publicly which wasn't great for the mission. But I think we're seeing more and more people say, "You know what? It doesn't matter, right? Pick the format that you like the best but make sure that we have interoperability."
Joseph Carson:
Interoperability is very key. It's one of those things that it becomes crucial in these areas.
Allan Friedman:
It is, right? And I don't think it's the government's job to pick a winner in a standards fight. We don't have the best track record of doing that. What we do want to do is just create an ecosystem where it shouldn't matter, right? We know that any large organization's probably going to get SBOMs from both. Most tools can now support both. And in fact, one of the things that we've done here in the US government is actually help create a tool that can translate between them.
Joseph Carson:
Okay.
Allan Friedman:
It's open source so it can also be built into other applications. So that's called protobom, it's available on GitHub. It'll be formally launched at the North American Open Source Summit. Pretty excited about that.
Joseph Carson:
Fantastic. No, that's great news. Just facilitating and letting ultimately interoperability in choosing what works best because lots of software ... When you get into OG environments, sometimes those systems are run not just for five years but 25 years. So they have very long life cycles. And it's important to make sure that we are able to manage multiple types of scenarios. And so ultimately, organizations will likely choose the one that best facilitates or works with the tools that they're more familiar with as well. What types of organizations should be looking to consume this as long term?
Allan Friedman:
Sure.
Joseph Carson:
Who should be thinking about it? Who does it apply to?
Allan Friedman:
I hate to say it applies to everyone but it really does, right? If you use software in your organization, and you're at a sufficient level to say, "You know what? I already have an asset management program," then you should start to be paying attention to this, right? I always want to acknowledge that there are plenty of people in the world who simply are not yet ready to worry about this. And this is true for all sorts of data security issues, right? Do I need a threat intel program? Do you have an asset management firm? I think I said this at my first RSA talk. If you don't have an asset management program leave right now because nothing I will say in the next 30 minutes will be more important than you...
Joseph Carson:
Okay. You can't even have a security strategy unless you have a corporate asset.
Allan Friedman:
Right. Correct.
Joseph Carson:
If you don't know what you actually have running in your environment how can you trust the problems? Ultimately, you're starting to have not just security program issues or vulnerability threat intelligence issues but you're also starting to have licensing and compliance issues which all of these basically feed from having a very good understanding of all the components of those in your business. It all starts with asset management, the foundation of everything.
Even years ago I remember having the ... That was my job as an asset inventory discovery, and there was a large transportation organization ... I never forget this. That they came and they said, "We need 120,000 licenses of your software." "Are you sure? Let's go check. Let's see. Are you really sure you only need 120,000? We suspect it's probably a little bit more than that." They go, "No. Look at our spreadsheet." It's like "We've got 120,000 assets" and we're like "Are you really sure?" And so after a while we agreed, let's do the discovery. Let's go and just find out what's out there. And we end up finding that they had 140,000 assets. Just even thinking about that, that's 20,000 more assets in the environment than they even knew that existed. And it resulted in numerous things. That their systems were running old software, they were unpatched, they were not being managed, the software was unlicensed. Even just getting into the point where the energy consumption alone paid for the deprivationing, and security, and update.
Allan Friedman:
Wow.
Joseph Carson:
Just the energy saving of those systems alone. And what was ultimately happening-
Joseph Carson:
To your point is, part of the whole life cycle is that people get new devices, old devices moved onto the desk a little bit to the left. There's a piece of older software that I need to go and use because it only works with that version or that, let's say, file version that we're using because the newer versions didn't support anymore so they had that backup to go to in order to ... Whether it was in editing or manufacturing and stuff that only worked in that area so they just kept it just as backup.
But also they used it in order to do personal things like surf the web. The surprise, when you actually went into the cost of that whole thing: energy, licenses, deprivationing, it was huge. I mean, you think 20,000 devices, that's a large enterprise for many organizations alone just for that number of machines. For me, that was a real experience that I had that really highlighted ... When I heard about the whole moving and the acceleration of SBOM, I was so excited because it solves that fundamental, that type of challenge that organizations have had to-
Allan Friedman:
It really does. And so what's the starting point, right? As a user of software and especially as an acquirer of software, today no one should be buying software without asking for SBOM. This isn't a new phenomenon. Some of the listeners may know Sounil Yu, he's a strong theorist in cybersecurity. For a while he was, I think, Bank of America's research CISO. And this was eight or nine years ago, right, before SBOM became a common thing, he would ask for an SBOM. Now, you could have faxed him a handwritten list because he wasn't looking for the data, he just knew that if a software supplier didn't know what was in their software the total cost of ownership was going to be much higher, right? Forget security, again, this was dollars and cents.
Joseph Carson:
Absolutely.
Allan Friedman:
And so the first thing is, if you don't have an SBOM why not? And what are you going to give me in exchange for not having an SBOM? What are the security assurances? Are you not going to be on the price? Are you going to promise faster updates? All the things that you need to worry about for that? Now, I also am always very careful to not overstate the maturity of this space. There's a cliche in cybersecurity, building the plane while flying it and that is what we're doing here. There are SBOM generation tools out there of all kinds. You can go to source, you can build tools, you can do post-build, binary analysis. But one of the questions I get a lot these days is well, I have an SBOM now what do I do with it? I like that question a lot because-
Joseph Carson:
What's next?
Allan Friedman:
A year or two ago no one was asking me this question because no one had SBOMs. Today there are a number of tools that will help you do two things, manage your SBOMs, right? Get them, I've got different versions, right? The data plumbing is always the hard part of InfoSec, it's not the sexy part. But we're going to see more progress in that. A couple of major vendors and tools and there's some great startups that are doing SBOM management.
And then, of course, actually using the data. We use the term consuming SBOMs. Because again, an SBOM by itself, it's just data, it doesn't fix a thing any more than a CDE number fixes a vulnerable computer, right? But it does allow effective management. So turning that data into intelligence, into action. Again, we're starting to see more tools out there today. Very simple ones are just matching to known badness, right? This is what's in the software that's on my network, this is what's in a vulnerability database, what should I be worried about?
But there's also a lot more great intel coming up so depending on what you're worried about. Are you worried about your supply chain depending on open-source projects with less than three maintainers? What I call the ukulele problem. Because I hate the bus problem it's very gruesome. How much of my supply chain depends on someone never learning that it's a lot more fun to learn to play the ukulele than it is to maintain open-source software? You can turn that data into intelligence, and what you can do with it is limitless. What we're starting to see is more and more companies, even in this venture capital environment, get funding to use that to integrate that data into the broader security mission.
Joseph Carson:
Absolutely. You triggered an important point in my head as well is that ... What you think about as well as organizations is that it will also determine how critical that application then becomes in your business as well from a critical classification. Because when you're an organization, you might be using something that may not be critical, may not be for the business it's just something that's functional. And if there's a problem with it it may not have a massive impact.
But the more you start rising up, and that application becoming something that your business is depending on, then you should be actually thinking about, from a classification perspective, is that you do want to have the SBOM, you do want to ask the question, you do want to understand the product. If this application has something that's critical, whether it from a technical debt issue or a vulnerability issue, that could have a very, very serious impact to the business. Going forward, when you're thinking about actionable, you want to make it manageable. Having that classification of software in the business, this means is that where's your exposure from a business perspective as well and mapping that back into SBOM.
Allan Friedman:
This is a mature risk model. So, for example, in the United States dairy farmers spend a lot of time worrying about the cost of fuel. Why? Well, because they need to make sure that their automated milking machines can always run, and they have generators and backup generators. Right? The same thing is true for software. As you say, this piece of software, if there was ever a major attack or supply chain attack ... We all remember the attack against SolarWinds. What would that do to my organization? And then you can start to work backwards and you can start to say, "Okay, I've got eight applications. Oh, it turns out they're all using this broad suite of Python mathematical libraries now. And it turns out that those aren't super popular elsewhere so maybe I'm going to throw some money to the developers and make sure that they're set up to have coordinated vulnerability disclosure and things like that."
Joseph Carson:
Absolutely. What's next? Where's the future lie? What follows SBOM? What do you do after it and what's the future behold?
Allan Friedman:
For SBOM itself we're starting to see this become mainstream and integrated into regulation and contracts, right? Obviously, a lot of people are worried about government because government's got a government. SBOM is explicitly included in the Cyber Resilience Act which is all but finalized in Europe. Japan has been moving forward in this direction. The United States has sort of set out with an executive order now three years ago saying, "Eventually all software the US government buys is going to have debt." And we're starting to see it more in contracts that are written between private actors which is, of course, a much broader sect. And that part makes me happy to sort of seeing how this is integrated into the automotive sector, and into the finance sector, and things like that.
Where we go next is to say, how do we automate more aspects of thinking about our software development and supply chain? So an SBOM is an example of a software development artifact. It's a piece of metadata that tells me something about my software and how it was created. I think that's good in the future of software supply chain and software assurance is saying, "Rather than just rely on long complex standards, especially process standards where I have to pay a consulting company, please watch how I develop my software. Did we think about risk? Yes, we watched them. They were in that conference room and they thought about risk. Please give us a very large check to say that you thought about risk."
Instead, what we can do is start to look for specific outcomes from specific processes so SBOM is a great start. But there's lots more that we're going to see from how we gather open source, how we keep it protected in a repository, the code is drafted and assembled. We recently saw someone saying, "Hey, we can actually detect how much of the software is gen AI produced and not gen" ... "And written by humans."
Joseph Carson:
Oh, that's interesting.
Allan Friedman:
Getting some info on tracking that. And then how it's built and maintained. So I think that is going to be the future. And in fact, as the US government has implemented our software security requirements, we've created a repository for across the US government to track what are called the self-attestation forms, that's the sort of handwritten human language piece, and artifacts which will include SBOMs moving forward. One of the next steps that I'm excited to push for, and I'll be rolling ... Announcing this in my RSA talk in May, is work on end-of-life and end-of-support-
Joseph Carson:
Okay.
Allan Friedman:
Which again, similar to supply chain. It's an issue that most of us were aware of but we need to actually have greater transparency around better machine automation and then integrating that automation-friendly data into how we manage that risk.
Joseph Carson:
Absolutely. I think that will also ultimately change your buying process when you think about that is that one, you know of the life cycle of what we're expecting in years to come and how much you're going to have support ability and maintainability. That becomes an important factor. And we've seen that playing around in the mobile landscape quite often. Hardware support, and software support, and how long that you will ... How long will the hardware be around for? About then what about software updates and how does that software continue? That excites me. And I'm really definitely looking forward to being in the audience for that talk so it's exciting. Where's the place that people can go get resources on this? I know that on the CISA site there's a great page that covers SBOM. What are some other resources...
Allan Friedman:
So glad you asked, yes. Cisa.gov/sbom is where we try to collect all of that information. We host, about twice a year, what we call an SBOM-a-rama, a chance to bring together the global community so we hear from different governments, we've heard from Japanese government, the German government, the European Commission. We hear from different sectors: finance, automotive, healthcare. As well as get an update on the community work that we try to facilitate. One of the things we do at CISA is provide this sort of neutral global venue where people can say, "Here's something that I don't understand." Either people can help them or they can say collectively, "Yeah, let's work on that." So, for example, one common question is, how do I think about the quality of the metadata for ... In an SBOM? And when it says, for example, "I should've hatched." Well, how should I take that hatch? Because if you and I take hatches differently it's pointless.
Joseph Carson:
Because they're not using the same format.
Allan Friedman:
Exactly.
Joseph Carson:
Then it becomes very difficult to match and to understand what's the correlation.
Allan Friedman:
And so we are going to be restructuring that community work very soon so now is the perfect time for anyone to get involved. And you can send us a note at SBOM, at cisa.dhs.gov, or just go to CISA, C-I-S-A.G-O-V/SBOM.
Joseph Carson:
Fantastic. We'll definitely make sure that those links are in the show notes so that people can just find them easily as well. We'll also add as well references to your book as well because I always do think that people will get a lot of value add. Allan, it's always great listening to you. I think it's one of those difficult areas in the industry because it's sometimes not on the forefront of people's priorities but I think it's critical. And as we mentioned, it's very much the foundation, you can't do many things unless you get the core part of this done correctly. And it gets into asset inventory and understanding ultimately your software supply chain into where everything that you're running in the business that your business could be very dependent on. Any final words of wisdom? What's your ultimate vision of success, your words?
Allan Friedman:
I'll tell you, one piece of success we've already seen is people are saying the SBOM for blank, right? What does SBOM look like for AI and ML? We're going to meet up at RSA to work on this. Cryptographic build materials. People start to worry about post-quantum tracking, we need to subtract that data. So we're starting to see that model. But really it comes down to people keeping one very real question in their head which is, why on earth would you source software if you or the person who made that software didn't know what was in it and didn't have a way of finding out? And that's really where we've gotten a greater appreciation of. All the rest is just data and implementation. It's not completely solved but there's plenty of room. And also just one final note, a great area for startups. If you have an idea in this space, please think about how to do it. Always happy to chat with anyone interested.
Joseph Carson:
Absolutely. What's the easiest way to contact you if people want to follow up? Social media? What's...
Allan Friedman:
Social media, it's basically just my name as one string. Every so often I'm still on Twitter, I'm on Mastodon, on Bluesky, LinkedIn. Feel free to reach out. Of course, SBOM@CISA.dhs.gov will get to me as well.
Joseph Carson:
Fantastic. It's always enlightening and very insightful for me when ... Listening to talk about this ... A subject so passionately and with so much experience and knowledge. Many thanks for joining me on today's podcast. And for the audience, definitely, this is something that should be a priority. This should be something you should be looking into, you should be starting to think about it if you already haven't got a strategy or program around it in your organization and start asking the questions. Allan, many thanks for being on. Hopefully get to catch up with you again.
Allan Friedman:
Thanks, man. I'm a big fan of all your work.
Joseph Carson:
Many thanks. Thank you very much. So for the audience again, tune in every two weeks for the 401 Access Denied Podcast. I'm here to really bring you world-leading experts to really educate you and providing knowledge on very important topics in the security industry. So all the best. Take care and thank you.
Hello, everyone, welcome back to another episode of the 401 Access Denied Podcast. I'm the host of the show, Joe Carson, chief security scientist and advisory CISO at Delinea. It's a really pleasure to be here with you. And I've got a very important topic, something that I've been keeping an eye on for a number of years now, and I've got the best person on the show to really take you through that experience. Allan, welcome to the podcast. If you could give us a bit of a background about who you are, what you do, and some things about yourself.
Allan Friedman:
Sure. Thanks so much for having me. My name is Allan Friedman, I'm with the Cybersecurity and Infrastructure Security Agency in the United States. We're America's civilian cybersecurity agency responsible for protecting both the government and indeed the broader general population inside the US and partnering with our international peers. I'm a failed professor who got suckered into joining government about seven or eight years ago and trying to find and help coordinate on issues like vulnerability disclosure, and IoT security, and, of course, software bill of materials where government can't solve it alone but government can help be a catalyst for helping to drive progress in the security of software.
Joseph Carson:
Absolutely. It's very much a big ... A public-private partnership in order to collaborate together. You also the offer of the book as well which is one of my favorite books. Tell us about the book that you co-
Allan Friedman:
Sure.
Joseph Carson:
Co-wrote.
Allan Friedman:
See, I keep a copy on my shelf.
Joseph Carson:
Yes.
Allan Friedman:
I keep a copy of the Korean translation on my shelf.
Joseph Carson:
Okay.
Allan Friedman:
And I'll admit, it is now 10 years old so this came out in 2014. Cybersecurity and Cyberwar: What Everyone Needs to Know is ... Co-author was a guy named Peter Singer, he's an excellent sort of national security expert and popularizer of concepts. Really it was one of the first books as a cybersecurity one-on-one primer that explains some of the basics on tech, which, of course, you out there probably don't need to know, but it also walked through a lot of the core policy issues, governance issues, incentives issues that we're still dealing with today.
Joseph Carson:
Yeah, absolutely. I found it a fantastic read so I was wondering-
Allan Friedman:
Oh, well thank you.
Joseph Carson:
I think that's actually one of the first times I met you was actually getting a signed copy of the book many conferences ago. But I definitely recommend ... We'll make sure the readers have a link so they can go and take a look if they haven't read it already. We're here to talk about a very important topic which is something that we've had numerous conversations on. It's really building a lot of momentum in the industry as well which is the SBOM, which the software bill of materials. Can you tell us, what ultimately is SBOM? And what does it mean and what's the background?
Allan Friedman:
Sure. So an SBOM is basically a list of ingredients for software. Of course, it's more complex with that but it starts with the idea. That to me it remains bananas that in 2024 most of us build, and buy, and acquire, and use software without knowing what's in it, right? You can't go to the store and buy a piece of candy without it coming with a list ingredients. Why do we expect more out of a snack than we do out of the software that runs our organizations, our governments, our national security systems, our critical infrastructure? Now, making that a reality is, of course, a little more complex.
Joseph Carson:
Yeah, absolutely. I mean, I've been in the building software industry for 20 years, and you'll always have lots of components whether it being proprietary or third party or different sources that you're using, libraries, that ... Even whether it's just part of the operating system or part of other applications that you're trying to deliver that does a certain functionality whether it be encrypted communications, or rather it being ... Doing authentication and authorization of signing in. A lot of those use a lot of components that you may not be creating yourself. And absolutely you bring up a very important area is that when you're ultimately shipping that you want to know everything that's in there, whether it's the stuff that the vendor who's delivering the software has created, and also what other components they might be using. One of the big ones I remember was a Log4j was that was when everyone's running around going "Whoa. Am I even using it or not?" And it was built into a lot of vendor software. Is that something that also drives the need as what it comes to patching those pieces?
Allan Friedman:
The log for J helped my cause a lot, right? A lot of us remember dealing with that and spending the Christmas holidays hunched over our tiny little travel laptops. In my case, it was my sister-in-law's guest bedroom. It really exposed the idea that you need to know what you have because if nothing else, it helps you respond so much more efficiently. The organizations that had SBOM capabilities already implemented. This was something that was fairly straightforward to deal with. And even if you just had a pile of this SBOM data at the time, it was a morning's worth of scripting rather than two weeks of searching websites, calling customer support, and some things like that.
More broadly, we've seen a focus in attention to software supply chain. Maybe some of that's good news actually that attackers are starting to go after supply chains because our software has gotten much better. We'll use that as the positive spin that we are better at software security than we used to be. We need to sort of track all of these different new vectors into our supply chain. And, of course, the other piece is as we continue to build software on top of software on top of software and identify risks, the risk that's identified may be found in very common pieces of software, major pieces of tech that we all use.
But so many organizations use relatively uncommon piece of software, right? So if you're a scientific organization, maybe they're only 10,000 other instances of this piece of software on the planet. The likelihood that there's going to be a CDE in that piece of software, pretty small. However, that piece of software almost certainly uses other software that may be vulnerable, and may be outdated, may have other risks, may have contributors from countries that your country wants to know about, et cetera. And so having that visibility into the supply chain is important and it's getting more important every day.
Joseph Carson:
Absolutely. As you mentioned supply chain, we're living in the world of supply chain and everything is being brought together. I think it's so critical even when you start to understand about all the makeup. I think we had the conversation about me being at Estonian. I remember going in, I always had to talk about software to find networks. I was like "This is what we need to be doing, we need to know all the software that's running in the network." Estonian's approach was like "No, let's let service to find network." I really intrigued. I just thought that was interesting because it was then taking all of those pieces of software and figuring out what does it all come together to create. What service result we can deliver at the end?
To your point, when you have a good understanding of all the inventory, and the versions, and the assets for the organization, it does help you to really react not just faster but also more intelligently when you need to either update those or to apply fixes and bugs when certain vulnerabilities do come out. Ultimately, what's the intention? What's the value that ISFAM provides to organizations that follow it?
Allan Friedman:
We can think of the value as hitting across the entire supply chain and lifecycle of software. So let's start at the end. You've got the operator of the software, you've got a lot of software running on your network. We know security 101, you can't defend what you don't know about, right? And if you go to something like the cybersecurity framework, which a lot of the world has adopted, right, step one or even step zero is understand what you have.
Then once you know not just this is the blinking box but this is what's inside the blinking box, you can better understand the risks. And it also helps, by the way, for areas where a patch may not be available, or you to test it because its blinking box is keeping grandma alive. But there's still other things you can do, right? You can segment your network, you can tune your IDS. You can work with threat intelligence to say, "Well, I'm going to leave this on the network, but the second we see an exploit in the wild pull on that custom-built kill switch."
But there's a lot of things we can do at the operator level to respond to novel risk but let's work backwards a little bit. So before you have someone operating that ... Someone who's making a decision to choose that piece of software whether they're signing an SLA for a cloud platform, they're buying something and putting it on their network, they're selecting to use an open source project, and this is where you really need that visibility of one, why would you trust someone who couldn't give you this? That should give big red flags. If you ask for an SBOM and they say, "Oh, we just don't know it," giant red warning label. But it also allows you to do that work on list analysis of what am I getting into? Obviously, for security, are there known vulnerabilities that you want to ask about? Are there concerns about sourcing? We're starting to pay attention to where your software comes from.
But there's also non-security issues. There are a couple of folks out there today that will look at an SBOM and give you a metric of technical debt, right? If you're about to subscribe to a cloud application, you're one of 10 users right now, and you realize they're using a six-year-old framework. Well, they're going to have to refactor that and that may be expensive. If you're bearing 1/10 of that cost you should know about it. You may still say it's worth it but you should know that.
We have the operators, we have the choosers, and then we get back to our developers. Where the value of knowing what you're shipping still one, helps you understand the risk, helps you respond in new concerns, but also gives you that global picture. There are vendors out there, especially in things like the OT world, where people have done teardowns and said "There are seven or eight versions of the same library, even this product." So that's a wildly inefficient development process. So you can turn this again, not just for security but into dollars and cents into better quality software.
Joseph Carson:
Absolutely. It reminds me of a lot of the cases for backwards compatibility. That's one of the reasons why you end up with so many versions of libraries is that there's one version out there that just needs to be able to deal with this old system that we've got. That basically that library is what makes it work. If you even look at a lot of operating systems, the backward compatibility goes back 20 years years in order to support some of those older integrations.
And I think that sometimes, to your point, is that when you get into that situation it does stop you from really moving forward faster because you end up having all of these legacy technical debt that just holds you back. And at some point in time you have to make that decision, when do you cut it off? When's that life cycle ... When do you decide to end of support it and move forward with basically fewer libraries, and also fewer vulnerabilities, the whole thing? I mean, is this something that's really a US-focused initiative and framework? Is it a framework or is it something that we're thinking about as a best practice? Is it something drifting from the US or is it something that globally is being adopted?
Allan Friedman:
Sure. It is definitely not a US concept, it's not an American-driven concept. In fact, if you sort of trace the roots of it, it goes all the way back to Japanese industry and the Deming supply chain revolution. Those of you who have been part of the DevOps revolution for a while know that in the early aughts, the inspiration for ... The great leap forward for software came from heavy industry, right, we were pulling all of these lessons from aluminum manufacturers. SBOM is very similar which is it goes back to heavy manufacturing. The Toyota Revolution that Japanese industry catalyzed but the rest of the world soon got on board of saying, "I need to pay attention to who my suppliers are and what the risks are in that supply chain." The idea had been around for a while. Some folks at OWASP were kicking it around. Josh Corman from I Am The Cavalry was talking about it. Jeff Williams from OWASP. A number of other people.
What we did in the US government was say, "It's time to actually move forward on this idea. And it can't just be one corner of the ecosystem, it can't just be modern application development and leaving embedded systems behind." And we had already seen movement from the healthcare regulators, medical device regulators in the United States. If it was just a healthcare solution, well, a regulator can compel action but that doesn't ... So what we did in the US government, we're starting at NTIA and now in CISA is to say, "Let's try to pull together people from across the entire software world, different sectors, and also the creators and the users of software and say, what does transparency look like in the supply chain? How do we make progress?"
We've had international participation from the beginning. So I run some weekly meetings. A great guy from JPCERT who joins in the middle of the day US time which is middle of the night in Tokyo. And in fact, we here at CISA just launched the global government expert forum on SBOM where we're working with 14 partner government agencies around the world, in Europe and Asia, to make sure that we're all on the same page. One of the things we definitely don't want is to have an American SBOM and a Japanese SBOM, and then a NESA SBOM, and things like that.
Joseph Carson:
You end up with lots of inconsistencies, and lots of different results, and different frameworks which sometimes don't integrate together those. My understanding is a lot of the work you're doing is making sure the policy's consistent across the board. Is that we're focusing on that collaboration not just between private and public partnerships but also multi-government, multinational stakeholders, that we're all on the same page, we all add the things and experience it together. So I think that's the significance. Is it going to become something like a standard that is put in place? What's the ultimate result here? What would be the-
Allan Friedman:
For me the ultimate result is, three years from now I want almost no one to be talking about SBOM, right? I want it just to be a natural part of how all software is developed, it should just fall out of your build process. And then on the consumption side, just all it ... It should be built into all of the tools on the user side, right? It should be built into your vulnerability management, your asset management, your CMDB, and things like that.
Joseph Carson:
Okay.
Allan Friedman:
How do we get there? Well, there are a couple of things that we can do. It's important to acknowledge what government can't do. What government can't do is we're not going to make the tools, right? And the good news is there are lots of folks who are building SBOM tools. Those of you who've been aware of software licenses know that people have been focused on tracking use of open source for a decade, two decades. So there are tools out there, there are more open-source tools coming online every day. And, of course, there are lots of great proprietary tools. Depending on what you need, there's something out there to help you generate the SBOM data. There's a docker command called sbom. You know what it does? It gives you an SBOM.
Allan Friedman:
Now, will that work for the organization that is building complex, $30 million operational technology that has hundreds of subsystems now, right? It's going to be a little harder. And, of course, thinking about the legacy side, it gets a little more tricky as well. What we've tried to do is help define the basics of what is an SBOM and then continue to refine that. Then we have SBOM data formats. Again, we didn't want to create these. And the good news is that there are two out there, they're both great. CycloneDX is created by OWASP. SPDX has been around even longer, that's from the Linux Foundation. Both of them have new versions coming out very soon. Both of them are open source, both of them are great community with lots of tools that are out there. The bad news is that for a long time they fought publicly which wasn't great for the mission. But I think we're seeing more and more people say, "You know what? It doesn't matter, right? Pick the format that you like the best but make sure that we have interoperability."
Joseph Carson:
Interoperability is very key. It's one of those things that it becomes crucial in these areas.
Allan Friedman:
It is, right? And I don't think it's the government's job to pick a winner in a standards fight. We don't have the best track record of doing that. What we do want to do is just create an ecosystem where it shouldn't matter, right? We know that any large organization's probably going to get SBOMs from both. Most tools can now support both. And in fact, one of the things that we've done here in the US government is actually help create a tool that can translate between them.
Joseph Carson:
Okay.
Allan Friedman:
It's open source so it can also be built into other applications. So that's called protobom, it's available on GitHub. It'll be formally launched at the North American Open Source Summit. Pretty excited about that.
Joseph Carson:
Fantastic. No, that's great news. Just facilitating and letting ultimately interoperability in choosing what works best because lots of software ... When you get into OG environments, sometimes those systems are run not just for five years but 25 years. So they have very long life cycles. And it's important to make sure that we are able to manage multiple types of scenarios. And so ultimately, organizations will likely choose the one that best facilitates or works with the tools that they're more familiar with as well. What types of organizations should be looking to consume this as long term?
Allan Friedman:
Sure.
Joseph Carson:
Who should be thinking about it? Who does it apply to?
Allan Friedman:
I hate to say it applies to everyone but it really does, right? If you use software in your organization, and you're at a sufficient level to say, "You know what? I already have an asset management program," then you should start to be paying attention to this, right? I always want to acknowledge that there are plenty of people in the world who simply are not yet ready to worry about this. And this is true for all sorts of data security issues, right? Do I need a threat intel program? Do you have an asset management firm? I think I said this at my first RSA talk. If you don't have an asset management program leave right now because nothing I will say in the next 30 minutes will be more important than you...
Joseph Carson:
Okay. You can't even have a security strategy unless you have a corporate asset.
Allan Friedman:
Right. Correct.
Joseph Carson:
If you don't know what you actually have running in your environment how can you trust the problems? Ultimately, you're starting to have not just security program issues or vulnerability threat intelligence issues but you're also starting to have licensing and compliance issues which all of these basically feed from having a very good understanding of all the components of those in your business. It all starts with asset management, the foundation of everything.
Even years ago I remember having the ... That was my job as an asset inventory discovery, and there was a large transportation organization ... I never forget this. That they came and they said, "We need 120,000 licenses of your software." "Are you sure? Let's go check. Let's see. Are you really sure you only need 120,000? We suspect it's probably a little bit more than that." They go, "No. Look at our spreadsheet." It's like "We've got 120,000 assets" and we're like "Are you really sure?" And so after a while we agreed, let's do the discovery. Let's go and just find out what's out there. And we end up finding that they had 140,000 assets. Just even thinking about that, that's 20,000 more assets in the environment than they even knew that existed. And it resulted in numerous things. That their systems were running old software, they were unpatched, they were not being managed, the software was unlicensed. Even just getting into the point where the energy consumption alone paid for the deprivationing, and security, and update.
Allan Friedman:
Wow.
Joseph Carson:
Just the energy saving of those systems alone. And what was ultimately happening-
Joseph Carson:
To your point is, part of the whole life cycle is that people get new devices, old devices moved onto the desk a little bit to the left. There's a piece of older software that I need to go and use because it only works with that version or that, let's say, file version that we're using because the newer versions didn't support anymore so they had that backup to go to in order to ... Whether it was in editing or manufacturing and stuff that only worked in that area so they just kept it just as backup.
But also they used it in order to do personal things like surf the web. The surprise, when you actually went into the cost of that whole thing: energy, licenses, deprivationing, it was huge. I mean, you think 20,000 devices, that's a large enterprise for many organizations alone just for that number of machines. For me, that was a real experience that I had that really highlighted ... When I heard about the whole moving and the acceleration of SBOM, I was so excited because it solves that fundamental, that type of challenge that organizations have had to-
Allan Friedman:
It really does. And so what's the starting point, right? As a user of software and especially as an acquirer of software, today no one should be buying software without asking for SBOM. This isn't a new phenomenon. Some of the listeners may know Sounil Yu, he's a strong theorist in cybersecurity. For a while he was, I think, Bank of America's research CISO. And this was eight or nine years ago, right, before SBOM became a common thing, he would ask for an SBOM. Now, you could have faxed him a handwritten list because he wasn't looking for the data, he just knew that if a software supplier didn't know what was in their software the total cost of ownership was going to be much higher, right? Forget security, again, this was dollars and cents.
Joseph Carson:
Absolutely.
Allan Friedman:
And so the first thing is, if you don't have an SBOM why not? And what are you going to give me in exchange for not having an SBOM? What are the security assurances? Are you not going to be on the price? Are you going to promise faster updates? All the things that you need to worry about for that? Now, I also am always very careful to not overstate the maturity of this space. There's a cliche in cybersecurity, building the plane while flying it and that is what we're doing here. There are SBOM generation tools out there of all kinds. You can go to source, you can build tools, you can do post-build, binary analysis. But one of the questions I get a lot these days is well, I have an SBOM now what do I do with it? I like that question a lot because-
Joseph Carson:
What's next?
Allan Friedman:
A year or two ago no one was asking me this question because no one had SBOMs. Today there are a number of tools that will help you do two things, manage your SBOMs, right? Get them, I've got different versions, right? The data plumbing is always the hard part of InfoSec, it's not the sexy part. But we're going to see more progress in that. A couple of major vendors and tools and there's some great startups that are doing SBOM management.
And then, of course, actually using the data. We use the term consuming SBOMs. Because again, an SBOM by itself, it's just data, it doesn't fix a thing any more than a CDE number fixes a vulnerable computer, right? But it does allow effective management. So turning that data into intelligence, into action. Again, we're starting to see more tools out there today. Very simple ones are just matching to known badness, right? This is what's in the software that's on my network, this is what's in a vulnerability database, what should I be worried about?
But there's also a lot more great intel coming up so depending on what you're worried about. Are you worried about your supply chain depending on open-source projects with less than three maintainers? What I call the ukulele problem. Because I hate the bus problem it's very gruesome. How much of my supply chain depends on someone never learning that it's a lot more fun to learn to play the ukulele than it is to maintain open-source software? You can turn that data into intelligence, and what you can do with it is limitless. What we're starting to see is more and more companies, even in this venture capital environment, get funding to use that to integrate that data into the broader security mission.
Joseph Carson:
Absolutely. You triggered an important point in my head as well is that ... What you think about as well as organizations is that it will also determine how critical that application then becomes in your business as well from a critical classification. Because when you're an organization, you might be using something that may not be critical, may not be for the business it's just something that's functional. And if there's a problem with it it may not have a massive impact.
But the more you start rising up, and that application becoming something that your business is depending on, then you should be actually thinking about, from a classification perspective, is that you do want to have the SBOM, you do want to ask the question, you do want to understand the product. If this application has something that's critical, whether it from a technical debt issue or a vulnerability issue, that could have a very, very serious impact to the business. Going forward, when you're thinking about actionable, you want to make it manageable. Having that classification of software in the business, this means is that where's your exposure from a business perspective as well and mapping that back into SBOM.
Allan Friedman:
This is a mature risk model. So, for example, in the United States dairy farmers spend a lot of time worrying about the cost of fuel. Why? Well, because they need to make sure that their automated milking machines can always run, and they have generators and backup generators. Right? The same thing is true for software. As you say, this piece of software, if there was ever a major attack or supply chain attack ... We all remember the attack against SolarWinds. What would that do to my organization? And then you can start to work backwards and you can start to say, "Okay, I've got eight applications. Oh, it turns out they're all using this broad suite of Python mathematical libraries now. And it turns out that those aren't super popular elsewhere so maybe I'm going to throw some money to the developers and make sure that they're set up to have coordinated vulnerability disclosure and things like that."
Joseph Carson:
Absolutely. What's next? Where's the future lie? What follows SBOM? What do you do after it and what's the future behold?
Allan Friedman:
For SBOM itself we're starting to see this become mainstream and integrated into regulation and contracts, right? Obviously, a lot of people are worried about government because government's got a government. SBOM is explicitly included in the Cyber Resilience Act which is all but finalized in Europe. Japan has been moving forward in this direction. The United States has sort of set out with an executive order now three years ago saying, "Eventually all software the US government buys is going to have debt." And we're starting to see it more in contracts that are written between private actors which is, of course, a much broader sect. And that part makes me happy to sort of seeing how this is integrated into the automotive sector, and into the finance sector, and things like that.
Where we go next is to say, how do we automate more aspects of thinking about our software development and supply chain? So an SBOM is an example of a software development artifact. It's a piece of metadata that tells me something about my software and how it was created. I think that's good in the future of software supply chain and software assurance is saying, "Rather than just rely on long complex standards, especially process standards where I have to pay a consulting company, please watch how I develop my software. Did we think about risk? Yes, we watched them. They were in that conference room and they thought about risk. Please give us a very large check to say that you thought about risk."
Instead, what we can do is start to look for specific outcomes from specific processes so SBOM is a great start. But there's lots more that we're going to see from how we gather open source, how we keep it protected in a repository, the code is drafted and assembled. We recently saw someone saying, "Hey, we can actually detect how much of the software is gen AI produced and not gen" ... "And written by humans."
Joseph Carson:
Oh, that's interesting.
Allan Friedman:
Getting some info on tracking that. And then how it's built and maintained. So I think that is going to be the future. And in fact, as the US government has implemented our software security requirements, we've created a repository for across the US government to track what are called the self-attestation forms, that's the sort of handwritten human language piece, and artifacts which will include SBOMs moving forward. One of the next steps that I'm excited to push for, and I'll be rolling ... Announcing this in my RSA talk in May, is work on end-of-life and end-of-support-
Joseph Carson:
Okay.
Allan Friedman:
Which again, similar to supply chain. It's an issue that most of us were aware of but we need to actually have greater transparency around better machine automation and then integrating that automation-friendly data into how we manage that risk.
Joseph Carson:
Absolutely. I think that will also ultimately change your buying process when you think about that is that one, you know of the life cycle of what we're expecting in years to come and how much you're going to have support ability and maintainability. That becomes an important factor. And we've seen that playing around in the mobile landscape quite often. Hardware support, and software support, and how long that you will ... How long will the hardware be around for? About then what about software updates and how does that software continue? That excites me. And I'm really definitely looking forward to being in the audience for that talk so it's exciting. Where's the place that people can go get resources on this? I know that on the CISA site there's a great page that covers SBOM. What are some other resources...
Allan Friedman:
So glad you asked, yes. Cisa.gov/sbom is where we try to collect all of that information. We host, about twice a year, what we call an SBOM-a-rama, a chance to bring together the global community so we hear from different governments, we've heard from Japanese government, the German government, the European Commission. We hear from different sectors: finance, automotive, healthcare. As well as get an update on the community work that we try to facilitate. One of the things we do at CISA is provide this sort of neutral global venue where people can say, "Here's something that I don't understand." Either people can help them or they can say collectively, "Yeah, let's work on that." So, for example, one common question is, how do I think about the quality of the metadata for ... In an SBOM? And when it says, for example, "I should've hatched." Well, how should I take that hatch? Because if you and I take hatches differently it's pointless.
Joseph Carson:
Because they're not using the same format.
Allan Friedman:
Exactly.
Joseph Carson:
Then it becomes very difficult to match and to understand what's the correlation.
Allan Friedman:
And so we are going to be restructuring that community work very soon so now is the perfect time for anyone to get involved. And you can send us a note at SBOM, at cisa.dhs.gov, or just go to CISA, C-I-S-A.G-O-V/SBOM.
Joseph Carson:
Fantastic. We'll definitely make sure that those links are in the show notes so that people can just find them easily as well. We'll also add as well references to your book as well because I always do think that people will get a lot of value add. Allan, it's always great listening to you. I think it's one of those difficult areas in the industry because it's sometimes not on the forefront of people's priorities but I think it's critical. And as we mentioned, it's very much the foundation, you can't do many things unless you get the core part of this done correctly. And it gets into asset inventory and understanding ultimately your software supply chain into where everything that you're running in the business that your business could be very dependent on. Any final words of wisdom? What's your ultimate vision of success, your words?
Allan Friedman:
I'll tell you, one piece of success we've already seen is people are saying the SBOM for blank, right? What does SBOM look like for AI and ML? We're going to meet up at RSA to work on this. Cryptographic build materials. People start to worry about post-quantum tracking, we need to subtract that data. So we're starting to see that model. But really it comes down to people keeping one very real question in their head which is, why on earth would you source software if you or the person who made that software didn't know what was in it and didn't have a way of finding out? And that's really where we've gotten a greater appreciation of. All the rest is just data and implementation. It's not completely solved but there's plenty of room. And also just one final note, a great area for startups. If you have an idea in this space, please think about how to do it. Always happy to chat with anyone interested.
Joseph Carson:
Absolutely. What's the easiest way to contact you if people want to follow up? Social media? What's...
Allan Friedman:
Social media, it's basically just my name as one string. Every so often I'm still on Twitter, I'm on Mastodon, on Bluesky, LinkedIn. Feel free to reach out. Of course, SBOM@CISA.dhs.gov will get to me as well.
Joseph Carson:
Fantastic. It's always enlightening and very insightful for me when ... Listening to talk about this ... A subject so passionately and with so much experience and knowledge. Many thanks for joining me on today's podcast. And for the audience, definitely, this is something that should be a priority. This should be something you should be looking into, you should be starting to think about it if you already haven't got a strategy or program around it in your organization and start asking the questions. Allan, many thanks for being on. Hopefully get to catch up with you again.
Allan Friedman:
Thanks, man. I'm a big fan of all your work.
Joseph Carson:
Many thanks. Thank you very much. So for the audience again, tune in every two weeks for the 401 Access Denied Podcast. I'm here to really bring you world-leading experts to really educate you and providing knowledge on very important topics in the security industry. So all the best. Take care and thank you.
