Tony Turner -- Threat Modeling and SBOM

0:00Chris RomeoTony Turner is the CEO and founder of Ops-Wright, a new type of cybersecurity company disrupting security engineering for critical infrastructure. I found Tony via a talk he did on threat modeling in SBOM. Topic caught my attention, so I reached out to have a conversation. We talk about threat modeling in SBOM, the value proposition of SBOM, security engineering in SBOM, and cyber-informed engineering. This is something you'll want to learn about. I'd never heard of it before, but it could also help us in building more secure applications and products both. We hope you enjoy this conversation with Toni Turner. How do you create security champions?

0:47Tony TurnerSecurity Journey brings together 2 powerful approaches to provide application security education to help developers become security champions and produce safer applications. Security Journey training content extends beyond developers to reach the entire SDLC, creating a security-first organization. Learn more about our enterprise security training at securityjourney.com.

1:07Chris RomeoHey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo, CEO of Curve Ventures and one of the co-hosts here. My good friend Robert Hurlbut joins us as well. Hey, Robert.

1:36Robert HurlbutHey, Chris. Yeah, Robert Hurlbut, and I'm a principal application security architect and threat modeling lead at Acquia, and really glad to be here with you to talk about another great application security topic.

1:48Chris RomeoYeah, I mean, getting into a style of threat modeling or a way of thinking about threat modeling that's different than anything else I've ever learned or heard about before. is something that's always super exciting for me because, you know, we do this podcast because we want to learn and we bring people on who can help teach us things and we can ask questions and then everybody in the audience gets to take part as well. So I'm super excited to have Tony Turner here with us today. Tony, we don't give our audience— or sorry, our audience— we don't give our guests much time to get warmed up. We just throw you right in and say, what's your security origin story or how'd you get started in this crazy world of security?

2:26Tony TurnerThanks, Chris. So, so I'm currently the CEO of a cybersecurity software company called OpsRite that focuses on security engineering software for critical infrastructure. But like, the path that I took to get here was far from straightforward. If I go back, you know, 25, 30 years ago, I was an English major. I was a combat correspondent in the Marine Corps. I got out and I was You know, writing stories for like the local city magazine downtown, you know, Hawaiian Tropic Beauty Contest at, you know, so-and-so's bar and that kind of stuff. As far away from cybersecurity as you could probably get, right? And the guy that ran, the guy that ran the local company scammed me and a bunch of other people out of a bunch of money, took the advertising revenue and skipped town. That was kind of one of my first exposures to the concept of fraud and crime as a victim. And then kind of fast forward as things went on, I found myself naturally gravitating towards technology roles. Wasn't trained, didn't go to school for it. You know, developed web pages for my dormmates in college for beer money and, you know, stuff like that. It just, it was just a thing. It was easy. It came easy to me. And, you know, kind of as time went on, I found myself in more and more tech roles. And, you know, I guess about 20, 20 Many-plus years ago, it kind of, as the advent of, you know, the malware and worm activity and these kinds of intrusions into our organization's infrastructure started to become more and more prevalent, it was really pain, right? And I tell people all the time that the best way to change behavior is to encounter pain and change course. Like, no one changes anything unless they have a reason to change the thing. And for me, it was shifting from, I'm just going to be an IT guy, to, I'm going to learn how to secure the environment so that I can avoid that pain and that other people can avoid that pain. I'm a generalist, really. I kind of reinvent myself every few years. I don't know if it's out of boredom or what, but it seems like I'll spend 3 to 5 years diving deep on the topic, whether it's network security. I was deep in the application delivery and WAF space for a number of years doing exploitation. Ran the OWASP WAF-IC project for a number of years, still technically run that. And then for the last, I guess, really for like last 5 or 6 years, I've been more focused on critical infrastructure security, specifically defense and electric power. And really for the last several years in supply chain security, and most recently with my new company focused on the concepts around cyber-informed engineering.

5:21Chris RomeoSo, and so when you, when you mentioned kind of in the context of working with critical infrastructure, you know, cyber-informed engineering, is your focus on trying to secure the code that's being written and going into the critical infrastructure or critical infrastructure itself, or kind of what is, what's the lane that, that you're kind of focused on there?

5:45Tony TurnerThe scope is very large. And cyber-informed engineering really speaks to the cyber-born impacts to critical infrastructure, but— or rather, the cyber causes of harm in critical infrastructure. But the controls that need to be implemented are not necessarily all cybersecurity controls, right? They may be engineered manual safeguards, physical security-related things as well. And this scope, we may be talking about an entire site, like I'm building a new substation, I need to make sure my substation is secure. And really what we're really talking about there is securing the critical function, not securing a piece of software or securing a product. Because at the end of the day, organization doesn't really care about product security. They care about whatever their function is and making sure that their functions are resilient and they can fulfill their mandate. But the answer is software is certainly part of that.

6:48Chris RomeoCool.

6:51Robert HurlbutSo to jump into our topic today, Tony, what's an SBOM? We've heard this term out there and people are talking about it more and more, but what is it and what are the types?

7:05Tony TurnerSo an SBOM, or software bill of materials, has obviously exploded onto the seen recently based off of, you know, the efforts of President Biden over the last couple of years in the executive order, as well as just industry kind of coalescing around this concept that we need software transparency. We need to know what's inside the software. And probably the best analogy is to think of it as like an ingredients list, like what you might see on a box of cereal, right? You go to the grocery store, you buy a box of Cocoa Puffs, and you can make an informed decision as a consumer by looking at the ingredients list Am I okay with what's inside this thing that I'm about to eat? But software has always been kind of a black box to consumers. Many times vulnerabilities that are 10, 15 years or older just hanging around in firmware or software that we rely on every day and we have no idea. We just kind of go through life blindly assuming that everything's okay because we have a trust relationship with our vendor and surely our vendor would never put us at that kind of risk, right? As far as types of SBOMs, the type— when people talk about types of SBOMs, they're really talking about when the SBOM was generated or from what data the SBOM was generated, right? So am I generating the SBOM from my source code, including a bunch of cruft that might be in there that gets dropped as part of the build process, right? Or is it part of my build? Is it from the finished product? Is it a reverse-engineered SBOM? Is it a runtime SBOM, meaning I may have included system libraries that my application relies on? If I'm doing an SBOM from source, they're not in my source code, but they're on your machine. And they're all part of this holistic understanding of how that piece of software actually works. The advantages of doing that means I get a much more accurate picture of what's running inside my software. The disadvantage of that is it may not be a scalable way to do SBOMs. Because now I need to look at it on every single system because you may— the two of you may be running the same software and using different versions of the same software library that gets pulled into that piece of software. And so if I look at Robert's machine and he's running a vulnerable version, but Chris is running a newer version of that system library, I may make an inappropriate assumption about where the, you know, are you vulnerable, yes or no?

9:35Robert HurlbutRight.

9:38Chris RomeoSo, Tony, when you think of the value proposition of SBOM, like, I'm curious to hear from your perspective as somebody who's been working in this space for a long time and studied it, really dove deep into it. You know, as we were talking in the prelude to hitting the record button, I feel like I'm a bit of a pundit in the world of SBOM, and it may be just because I don't I haven't thought deeply enough about kind of where we're going with this. And so, I'd love to understand kind of from your perspective, like, what is the value proposition? What's the endgame that we're heading towards with SBOM?

10:11Tony TurnerSo, there's really one primary use case that people fixate on as the value proposition of SBOM, but there are many others. So, but I'll start with the big one. The big one in the room is just vulnerabilities, right? Understanding where we have vulnerabilities in our software. Now, The one thing I always try to caution people to understand is when you look at an SBOM and identify the vulnerabilities, this is the world of potential vulnerabilities in your software because there's quite frequently at times a high level of false positives in the vulnerabilities that are identified from the SBOM. A couple of reasons for that. One being backported fixes. A vendor may have resolved an issue but not updated the version. And the way this SBOM vulnerability identification looks, it's just a simple lookup against the National Vulnerability Database based off of a product version, a component version, right? And so, that component version is not illustrative of what's actually running inside the software. I mean, no one is looking at the code and saying— I mean, the SBOM is not analyzing code. It's just looking at vendor component version and doing some data correlation to say, okay, you might have a vulnerability. The other reason that this happens, especially in open source. I may use an open source component in my product, and I may only need 10% of the functionality of that library that I just pulled in. So if there are 10 functions that can be called in this library, I only use one of them that's not the vulnerable function, I never call the vulnerable function in my code, do I technically have a vulnerable version in my software?

11:52Chris RomeoWell, yeah, Is it—

11:54Tony Turnercan it be affected by a bad guy? Probably not. So we wind up with a lot of noise inside this process. And so it requires some further analysis beyond just saying, do I have a vulnerable component? Do we need to go beyond that and say, okay, yes, I have a potential vulnerability problem, but what now? Like, can it be affected through configuration? Am I actually calling it? Is there a path to the vulnerability? And if so, then I need to make some risk decisions about what I'm going to do about it. And in some instances, it may just wind up being a code cleanup and code quality issue more so than a vulnerability issue. Some of the other use cases that we see, really the original use case for SBOM was licensing, had nothing to do with vulnerabilities, right? Software vendors need to make sure that they're in compliance with all the software licenses that they had to work with. They had to show to other stakeholders that that wasn't a problem. We started to see this in M&A activities where even some VCs are expecting to see, like, what are we actually buying here? And SBOM can help illustrate, like, how much of this is third-party code? How much of this is your code? Did you just throw a fancy UI on somebody's open-source project? That's another use case. Previous jobs, we've even used it to help inform incident response-related indicators of compromise in software based off of SBOMs and other artifacts. But the SBOM is really just one of many attestations that needs to be part of your supply chain discovery and analysis process. It is not the— it's not going to give you the whole picture.

13:38Chris RomeoRight?

13:38Tony TurnerIf you look at like a SolarWinds kind of event, SBOMs would not have identified a SolarWinds problem. Like, it just wouldn't. Anybody that tells you different is lying to you. We wouldn't need things like behavioral analysis to understand what's happening on the network, to understand something's not right here. But then we look at other situations like a Log4j where SBOM is the perfect fit to understand what's going on. Just like everything else in security, there is no silver bullet to any problem that we have in this industry, but it is a tool in the tool belt And we need to be smart about how we do it.

14:09Robert HurlbutSo a little earlier you mentioned cyber-informed engineering, but how does security engineering itself fit into an SBOM? And then also there's this concept of consequence-driven cyber-informed engineering. So can you talk about those 2 topics?

14:29Tony TurnerYeah, sure. So I'm going to raise it up a little bit higher level to just talk about the system engineering process as a whole, of which security needs to be embedded inside, right? So, if we think about traditionally how we approach system engineering in a very kind of waterfall-style approach, right, we have a very rigorous process to define the concept of operations, define requirements. We go through this very rigorous design process until we get into like a build, test, deploy, operate kind of phase, right? That's very cyclical. cyclical, right? If you kind of, like, compare that to a more agile, iterative deployment or a DevOps style, we have a much more, you know, continuous delivery model. But regardless of what your approach is to doing engineering in general and defining the thing that you're going to build and doing all the checks to make sure that what you built is what you thought that you were going to build, right? There are certain security decisions that need to happen along the way, whether it's a human looking at a thing or whether it's just automagically performed inside your CI/CD pipeline, right? And the SBOM is part of one of those steps that needs to happen in that engineering flow. I need to know what I'm building. I, as a product supplier or product manufacturer, I have a certain amount of liability for the risks that I create for the downstream consumers of whatever product that I build. If I don't know what's in my product, how can I possibly ensure my customers are not going to have to take on some risk from using my product, right? And I think by and large, I think many suppliers have had some degree of understanding of this, especially for their own stuff, probably less understanding for their open source stuff other than just the licensing side of this. But the consumer has not had any visibility into this to understand what's in our software. So the cyber-informed engineering is a methodology proposed by the Department of Energy to enforce a secure-by-design approach to doing engineering to make sure that we can provision secure systems Many times in critical infrastructure, these systems are in place for 20 to 30 years or more. There's not a lot of opportunity to fix things once they're in place. All you're left with is just Band-Aid the problem. And I think we're starting to understand as an industry that these Band-Aids, number one, are costly, especially with the economic position that the industry's in today. I think CISOs are looking for opportunities to reduce costs, reduce spend, consolidate platforms. And that's very much aligned with the need for security by design because we reduce the need for Band-Aid solutions if we design things securely. Securely in the first place. There's a lot more that goes into cyber-informed engineering, and I won't go too much deeper into that. Happy to talk more about that later if we have time. But the consequence-driven cyber-informed engineering is really the how of the cyber-informed engineering. Cyber-informed engineering, or CIE— I'll use that abbreviation just to save some oxygen— is really the what. It's a series of 12 principles that really guide the thinking process of how we do engineering, like design simplification. That's not a prescriptive control, right? That's not like a NIST 800-53 or 800-218 or some other kind of prescriptive control. It's how do I think about my design so that I'm simplifying it, so that I'm reducing the complexity and making things more secure? How do I engineer controls so that I fail, my term, fail gracefully, right? Consequence-driven cyber-informed engineering is a way to go through, it's essentially a 4-step process that starts with identification of the consequences. So, this model is very much about reducing the consequences of failure, addressing the black swan-style events, right? The things that organizations just can't survive or are so painful that they're going to create massive, massive impacts for the organization. It's not about stopping every single last problem. You probably are going to use a standard controls framework approach to do the cyber hygiene aligned with a CIE-style approach to really address the really important things, right? So, it starts with consequence identification, then it goes through systems-to-systems modeling, which is directly related to what we're going to talk about with with the BOM-based threat modeling, right? And then doing some targeting, just think like a red team exercise. Now that I understand what could go wrong, now that I understand how the systems relate to each other and all the system interdependencies, right? Like, I don't have to attack the system directly if I can attack one of your dependencies, right? Now I'm going to target these things. Now, once I understand how they can be targeted, let's wrap this thing up with an understanding of what protections need to be put in place to make sure the bad guy can't create those consequences. consequences, right? That's really what CIE is all about.

19:50Chris RomeoYeah, this is the first time that I've ever bumped into cyber-informed engineering. And so, I guess I have so many questions, but the first question is, as I'm looking at this, it's kind of housed by the Idaho National Laboratory. It's like a kind of feels like it's— is this a critical infrastructure only thing, or is this something that we could apply to just generally creating products inside of tech companies?

20:22Tony TurnerYou could apply it in any environment. It's starting as a critical capability for critical infrastructure. It was called out— DOE issued a national strategy around CIE this last summer. And if you look at the US national strategy document that was just released, what, a month or so ago, there is a call out to CIE in there, but specifically around new investments in distributed energy resources, green energy, all the new solar and wind investment that's going to be coming into the nation's infrastructure. So, even the White House understands the need for CIE to be embedded in a new infrastructure. Now, the one thing I will say, the reason why CIE is so important in critical infrastructure, not just because of the impacts there, Because these are some of the most complex systems of systems kind of implementations that you see, as opposed to many IT systems. I'm not saying they're not complex, many are, but I think we have a much more product-centric view of our technology universe inside the IT side of the house than we do on the OT side of the house. So, the principles can certainly be applied, but I think you wind up with more kind of traditional application security look on the IT side and product security-centric solutions. It certainly makes sense to go down that road, but as an industry, we're really starting on the critical infrastructure side of the house because that's where the need is greatest.

21:58Chris RomeoMakes sense. And OT, you mean operational technology, right? Which is more just for those people that don't know, that's— I think of OT as like the systems, networks, and whatnot that are required to operate the critical infrastructure. Is that a fair assessment of OT?

22:16Tony TurnerYeah, the industry gets super hung up on, you know, is it cyber-physical systems? Is it SCADA, which is something else, but falls within that bucket of industrial control systems? Operation technology, from where I sit, tends to be a parent category to the industrial control systems that may include non-industrial systems, say in healthcare, hospitals and some of those things. The way I typically define this stuff is compute systems that have the ability to impact our physical world. So that could be an IoT, an industrial IoT device. You know, it could be, you know, the insulin pump. It could be, you know, it doesn't have to be a substation or a nuclear reactor, right? There's a lot of other ways that computers are starting to affect our day-to-day life and have the ability to affect physical and many times safety outcomes.

23:17Robert HurlbutOkay. So, you mentioned about threat modeling, and that's certainly a topic of interest for us. What's the role of SBOMs in threat modeling that you see?

23:35Tony TurnerSo, The SBOM part of the conversation is a piece of this, right? When I think about the exercise of threat modeling, one of the inputs that's required in order to threat model a system is to understand the system. If I don't know how the system works, it's really hard to understand how threats have the ability to impact the system, right?

24:03Chris RomeoYeah.

24:04Tony TurnerPrimarily, I'm looking at What are my opportunities to influence this system, interact with this system, an interface that I can talk to? Maybe these are internal interactions that are driven by code. Maybe these interactions that are driven by machine learning or some sort of AI model that can influence a system. That too is part of your threat modeling. But I think traditionally we've been thinking about basic network-based connections, I have an exposed port on, you know, HTTP serving up on 80 or 443. Like, what can someone do to that? What's the difference between an unauthenticated user versus an authenticated user? You know, fast forward to today's world where we have APIs all over the place. So, you know, what kinds of APIs am I exposing and what types of APIs am I consuming, right? All of this has the ability to influence the risk factors for a system, right? Things are getting far more complex. I mean, average applications are consuming tens or more external APIs, maybe even hundreds of APIs or more in some instances. And trying to wrap your brain around that can be really, really challenging. And so, the industry has kind of coalesced around this concept of a SaaS BOM or a software as a service BOM. I mean, think about the SBOM. SBOM only describes a product, or maybe even just part of the product, right? But if I have a SaaS application that's consuming 10 external APIs, well, there's 10 other SBOMs sitting behind those APIs, right? Now, I think when we first started going down this road, we were thinking, well, SaaS BOM is just going to describe all the things. Wow, that is an unscalable monstrosity that will just— unlikely to happen in the near future, right? Like, are you really going to coordinate your SBOM between 11 stakeholders and have them all supply information so you can create this complete picture of the application? And oh, by the way, those guys, they're also consuming upstream APIs, and on and on and on. So now 100 vendors, 1,000 vendors. I mean, it's just, it's an unscalable mess. Like, it's just never going to happen. So the industry is kind of focused more on Let's define what our software is interacting with. It's very similar to the concept of a threat model, right? In that the SBOM is really describing services, right? Services that are exposed or consumed, data flows, the directionality of data, what kinds of data, data classification even can be passed as part of this SaaS BOM. Is it PII? Is it something confidential? Is it proprietary? Is it open? Whatever. Is it encrypted? Is it authenticated? All these things are really super valuable. In my mind, the SaaS BOM sits at the core of this concept of using BOM data to threat model, and then SBOM winds up being part of that understanding, obviously from a software standpoint. The H BOM, or the hardware bill of materials, you know, all the physical components that are in it. When I think about When I think about an asset, I have a hardware base and I have software that sits on top of the hardware. And if I'm not looking at the system holistically, I may miss some critical risk factors for that. That asset is part of that overarching system. So when I can combine the software bill of materials, the hardware bill of materials, and the SAS BOM, and maybe multiple HBOMs and SBOMs along with the SAS BOM, then I start to get a very complete picture of how that system functions. And I can look at the individual risk factors and bring it all in and then evaluate things holistically to understand this. The good news is that even though we have multiple documents that we need to look at here, the SBOM formats have given us the ability to link these SBOMs together, the concept of a BOM link. So now the tooling is not at the place today where we can do this at scale. I mean, we're very early days in the days of SBOM. SaaS BOMs are kind of this conceptual thing that people are talking about and people are doing. They're certainly being produced by people, right? But if you look at the supply chain product landscape, You're not seeing a lot of people asking for SaaS BOMs and really operationalizing this need beyond a few very mature organizations that are doing this stuff today. In my research, I've mostly been using the tools that are available and in many instances using manual process to stitch these things together. It's ugly, but it's workable.

28:59Chris RomeoSo, when you think about, like, when we think about the process that we would go through to perform threat modeling, let's just use a SAS BOM as our core thing that we're looking at. Like, you kind of— I'm going to try to tease out a little bit what I think I heard you say, just make sure kind of that I'm spot on here. So, I would use the SAS BOM and all of the other component pieces that it provides together. And then, the threat modeling process is to consider the interconnections and everything that I can take away from the SAS BOM to be able to derive a list of potential threats. Am I going in the right direction here from your perspective as far as how threat modeling fits into this?

29:42Tony TurnerYeah, I mean, I have to start with a system understanding. Until I understand how the system fits together, I'm kind of spinning my wheels trying to threat model anything. So, not only understanding how the system works, but how the system is supposed to work. What is it supposed to do? How do users engage with it in normal operations? And what are the potentials for bad actors to engage with the system in ways that are undesirable? But until I understand what the system is and what its function is, how it's supposed to be operated, a lot of those things that are part of that core systems engineering lifecycle, For instance, I developed a security engineering maturity matrix that I open-sourced actually about a week ago. And we took the Department of Transportation's engineering lifecycle, which is pretty mature. It's a very waterfall-ish kind of flow. But again, I don't really care when this stuff happens, just that this stuff does happen. And there's really not a lot of activity around security that needs to happen inside the engineering process in that flow. So, we actually added the threat modeling step as an important step that needs to happen after the high-level design and before you finalize the final design. Because I think that's really where in the process this happens, right? I have to have enough understanding to be able to threat model the thing, right? But I need to do that before I finalize the thing that I'm going to build. It has to happen early enough in the the process that I actually have the ability to influence the outcome of the system that I'm building.

31:25Chris RomeoNow, you also mentioned there were some tools that you used as well as kind of manual processing of these things. Any tools you could point folks to that they could potentially use to try to perform threat modeling of a SaaS BOM?

31:42Tony TurnerYeah. So, the first thing I'll call out, and I only touched on this very briefly in my presentation at S/4, but But Irius Risk, which is one of my favorite threat modeling tools, fantastic tool. If your viewers have not checked it out, I highly recommend checking it out. I'm a big fan of the work that they do. They open-sourced a threat modeling language, I don't know, a year or so ago, the Open Threat Model, which is a really fantastic way to describe your threat models. And so when we can go from the data that's in the SBOM to the description of the system in using OpenThreatModel or something else, that's one potential option. Now, I'm not aware of any tools that help you do that, right? You're going to have to kind of stitch together your own solutions, which is why I like things like PyTM, which is a Pythonic threat modeling. It's an OWASP project. And it too does not accept the BOM input. So again, you're going to have to do some work to integrate your SBOMs. But the thing I do like about PyTM is it does apply things like CWE categories to evaluate those weaknesses in your software. And it is a software-based framework that can be— it's a standalone application, or it can be used as a library that you can pull into your own software projects to do threat modeling as code that uses its own descriptor language. It doesn't use open threat model. And so some of the work I've been doing is how do I go from BOM to PyTM to produce an open threat model document? Because that's going to give us the best extensibility and translatability of threat modeling information so that I can use that document in another system like Arias Risk or something else, right? And I think looking at kind of these data interchange formats like OTM, and really kind of coalescing around, okay, as an industry, this is how we're going to communicate threats, whether it's OTM or something else, I don't care. But I think we all need to get behind these concepts as an industry. And even if you look at the SBOM space and this concept, I won't go too deeply into this, but the concept of a vulnerability exploitability document or vulnerability exploitability exchange, which is—

34:08Robert HurlbutYeah.

34:10Tony Turneryou know, around whether vulnerabilities are exploitable or affected, the software is affected by a vulnerability. One of the biggest challenges the industry has right now, I think, is just agreeing with each other on how we're going to communicate this information. You know, these format wars occur. It's beta against VHS all over again as it comes to SBOMs and VEXs. And like, just, we could just come to agreement on how we're going to talk about these things and describe these things.

34:39Robert HurlbutYeah.

34:40Tony Turnerand adopt them across the board will reduce a lot of complexity for people that are trying to incorporate these concepts into the program.

34:46Chris RomeoSo, when I'm going to— we had another question about CycloneDX, but I'm— so, does CycloneDX, like, what gets me is SaaS BOM. Like, I've seen some of the tooling, I've played around with some of the tooling that I think is also under the same heading of Steve Springett's projects in OWASP to generate SBOMs, but that was really just like pointing an S pointing at a, you know, a Node package file or something and then using that as input. But so like, is SaaS BOM, is that something I have to stitch together myself or is that something that like, are there open source tools that will generate a SaaS BOM for me?

35:31Tony TurnerI am not personally aware of any open source tools that do this, but certainly there are many commercial tools, especially when you look at like the interactive application security testing space, like what Contrast Security does, because they're inside the application. They can see the calls the application is making. And remember, the SAST BOM is around services. So I need something that understands how the application works, either because I'm living inside the application or I'm tracing the code flows inside the application through a static analysis vector. So either you need to understand the code or I need to be inside a runtime or something in order to get that level of visibility. There are some other vendors. I talked to a company, I'm trying to remember the name of the company right now that I was talking to at RSA last year, but they were very focused on securing APIs. And this whole, like, I used to do a lot of work in the web application firewall space, which is kind of turned into WAP, you know, web application and API protection space these days. There's a ton of API protection vendors that are spinning up. I haven't talked to too many directly, but I think that is where you need to be. That's kind of what you need to be looking at, right, to understand where these services are. Now, as far as producing the SAS BOM document from that, I'm not aware that too many of these folks are natively supporting SAS BOM document generation inside their platform. So you may have to export data outside of that and then transform that data into a SAS BOM format. Now Steve tells me that there are some— that he's working with some folks that are generating SAS BOMs as part of their process, but I don't know if that's a manual process, if they've written some proprietary code to do it, or if there's a commercial tool out there that I'm just not aware of. But again, this is still relatively new. space. If it's not out there today, it will be out there soon.

37:34Chris RomeoYeah. Okay, cool. So I guess, Tony, from a key takeaway or call to action, I do want to mention the book that you and Chris Hughes have written. And let the record show, Tony did not mention it. I did. And I'm one of the hosts, so I can mention books as much as I want. So just quickly tell us what the name of that book is and kind of when folks can can find that available?

37:59Tony TurnerSo, it's available for preorder now on Amazon. It's called Software Transparency, and it has a long subtitle, which I always say incorrectly, so I won't try. But it's a great book, in my opinion. Obviously, I'm one of the co-authors, so I'm biased, that covers more than just Software Bill of Materials, SBOM. We do have, we have a whole chapter on SBOM, but it is not a whole book on SBOM. We're really focused on the concept of software supply chain risk as a whole, how the industry is tackling it, how SBOM fits into it, how other attestations fit into this picture, the whole concept of vulnerability management. We got a whole chapter on both NVD as well as VEX and some of the challenges that the industry is facing and kind of the directionality of this cloud, DevOps, and even operational technology, how supply chain risks impact legacy software. Because I think the industry at large is focused on what we're building today and forgetting that we have a whole bunch of stuff sitting out there that is very risky, that's not going away for the next couple decades. So, how do we secure supply chains for that stuff? as well.

39:17Chris RomeoOkay. So how about a key takeaway then, or a call to action for our listeners, you know, based on the conversation that we had here? Like, is there something, is there something our listeners should be doing, something you want to point them to that they should be reviewing and learning and understanding to be better prepared to deal with these software supply chain and other supply chain issues, you know, into the future?

39:40Tony TurnerI think the number one call to action that I would have at this point in time, yes, we need better tooling. Yes, we need better understanding of execution, but we still have a lack of transparency and a lack of data to even do anything with. And it's kind of one, we got to solve one problem at a time. And in my opinion, the most important thing that we as an industry need to think about is embedding these practices into contracting and demanding this transparency from our suppliers. We can't wait for the regulations to come to us. We have to take a risk-based approach here and understand that this lack of transparency is creating a blind spot in our risk understanding. And it's very hard to make informed decisions when you don't know what it is that you're dealing with. And we've got to get— I've done a lot of work in third-party risk management, supply chain risk management, and by and large, the contracting process, even if there is a third-party risk management office, is usually extremely siloed from your security architecture and security operations side of the house. So, we've got to get these folks to talk to each other and make sure that these requirements are embedded in these contracts. And we need the support of the business, especially for the, what I call, too-big-to-fail vendors, right? Like, you know, Intel Spectre meltdown is a great example of that, right? Like, Are you going to kick every computer out of your shop that has an Intel chip? No, heck no. But we need to think about how are we going to handle these risks? And we need to have a concerted and collaborative plan and effort and execution strategy, along with all the governance and other boring things that most of us cybersecurity people don't like to think about too much. But this is all important. This is how we affect change. This is how we're going to get forward traction. and get action out of our suppliers. And then in parallel, we have to think about, okay, once we get this level of cooperation, what are we going to do with it? And I think another bigger conversation that we as an industry need to have, and I'm sure some people out there, some vendors out there won't thank me for making this point, but one of the questions that I think we need to ask ourselves is, does the consumer need the raw software bill of materials, or do they need a trusted attestation that tells them what they would learn themselves if they were to process these software bill of materials, right? Because I think we're pushing an awful lot of effort off on the end consumers that maybe they are not well suited to do. Now, you may not trust the vendor, That's fine. But what about a third party that this is their bread and butter? This is all they do. Do you trust them? I would hope so. And I think that's probably— and I'm biased because I came from a vendor that did exactly that. I don't do it anymore. I don't have any, you know, I don't have a dog in that race. But I think that's the right approach as an industry. We need to figure out where do we want to place our trust? Right? And do so intentionally, do so intelligently, and manage the expectations of what we're expecting to do as we're engaging with their supply chains and manage that risk.

43:09Chris RomeoVery good. Well, Tony, thank you for being with us today and sharing knowledge and facts and information and stuff about SBOMs and how threat modeling Can be interwoven in here. And, you know, I'm glad I learned about the cyber-informed engineering and consequence-driven. I'm going to go do some more digging into that because now it made me start thinking about, are there principles here that we can apply, you know, just like you said, bigger than ICS? Can we use these same ideas elsewhere? And, you know, you're saying that, yeah, you think we can. And so, I think there's an opportunity for all of us to learn some more about this and figure out how do we include this in the things that we're doing? How do we build better software as a result of understanding principles like this? So, thanks for sharing that with us, and we look forward to having another conversation with you at some point in the future about some other topic.

43:59Tony TurnerWell, thanks for having me on the show, Chris, Robert. It was great. I enjoyed our pre-show conversation as well as our on-show conversation. Love to chat anytime. So, thanks again.

44:11Chris RomeoThanks, Tony.