Press Release
With the release of President Biden’s Executive Order 14028 on “Improving the Nation’s Cybersecurity” from May 2021 the US public and private sectors have been alerted to the significant cybersecurity risks within our software supply chain. As of the March 2023 release of the National Cybersecurity Strategy, which will shift liability for software products and services to promote secure development practices, it’s evident that software security needs to be elevated across all organizations.
In this episode, your host John Verry, Pivot Point Security CISO and Managing Partner, sits down with Tim Mackey, Head of Software Supply Chain Risk Strategy at Synopsys, to explore what better software supply chain security means for software development and more.
In this episode, join us as we discuss:
- Defining an SBOM what it can include depending on stakeholder needs
- The value of SBOMs for both software developers and their clients
- Market drivers for improved software supply chain security
- Software composition analysis and its role in mapping dependencies and identifying vulnerabilities within code
- How the NIST Secure Software Development Framework (SSDF) supports initiatives to improve software supply security
To hear this episode and many more like it, we encourage you to subscribe to the Virtual CISO Podcast.
Just search for The Virtual CISO Podcast in your favorite podcast player or watch the Podcast on YouTube here.
To stay updated with the newest podcast releases, follow us on LinkedIn here.
See below for the complete transcription of this episode!
Intro Speaker (00:05):
Listening to the virtual CISO podcast, providing the best insight on information security and security it advice to business leaders everywhere.
John Verry (00:19):
Hey there, and welcome to yet another episode of the virtual CISO podcast with you as always, John Verry, your host, and with me today, Tim Mackey. Hey, Tim.
Tim Macke (00:28):
Hey, John.
John Verry (00:29):
How are you today?
Tim Macke (00:31):
I’m doing well.
John Verry (00:32):
Yeah. You told me it’s the end of the day. Not, not to expect your A game is, is is sort of like what you said when we were warming up here, right?
Tim Macke (00:38):
Yeah. It’s, it’s almost beer o’clock, so, we’ll,
John Verry (00:40):
Fine. <Laugh> and and anyone who’s a listener to the podcast knows I never bring my a game, so we should be matched up pretty well. <Laugh> always start easy. Tell us a little bit about who you are and what is it that you do every day.
Tim Macke (00:54):
So I have the glorious title of being head of software Supply Chain Risk Strategy at Synopsis. So that’s a mouthful, and eventually I’ll be able to have it like roll off the tongue quite nicely. But it’s basically a reflection of the work that I’ve been doing for the last two years that for practical purposes started when President Biden issued his executive order on cybersecurity and said, Hey, g Whiz, but we need to get better at this folks. And I’m, I’m gonna start wielding some pretty big sticks. And that itself was an outgrowth of the architecture, product security roles that I’ve had in the past. Long history with open source going back couple decades. The grays come through, through honest grief. So just have fun with software and fun, interesting ways to communicate the risks that are inside of software.
John Verry (01:47):
And I hope they pay you by the letter for your job title <laugh>. If not, that’s what you should negotiate next time.
Tim Macke (01:54):
So I once had a Biore at a conference by the, the, the big voice that does the BF Doess. And I really wanna somehow get the recording of that because someone in, in their infinite wisdom, put my entire bio, which is like three paragraphs long, and the poor gentleman had to read the whole
John Verry (02:12):
Thing. Yeah. There’s nothing, there’s nothing worse than having, you know, like I always tell people, give me the shortest bio you possibly can. Yeah. Here’s a moderately intelligent guy to talk about information security. Boom. That’s a, that’s a good
Tim Macke (02:24):
Bio. I, I do stuff and things with security.
John Verry (02:26):
Yeah, exactly. I I think that’s probably the most accurate bio you could have. So, so you mentioned it’s bureau clock. What kind, you know, what’s your drink of choice?
Tim Macke (02:37):
So right now it’s more of an eagle rare ooh, just have eagle
John Verry (02:41):
Rare 10, 10, 17, you know. Okay. Have you found a bottle of the 17? It’s
Tim Macke (02:45):
Indicat? No, I have not.
John Verry (02:46):
It is a, it is a unicorn bourbon. I found one bottle. I’ve been drinking bourbons for about a dozen years, and in that entire time, I found one bottle and I gave it to a friend as a gift, which I, I regret to some extent. <Laugh>.
Tim Macke (02:59):
No, ev every now and again, I end up over in Ireland or over in Scotland, and I will try and find something that you can’t get in the US and bring that back.
John Verry (03:08):
Yeah. Some great Irish whiskeys.
Tim Macke (03:10):
Yep.
John Verry (03:11):
There’s some great Irish whiskeys. Oh, you and I could definitely enjoy a drink together. Then. <laugh>, so you mentioned software security, which is what we’re here to chat about. And you know, anyone that’s in this space has probably heard the term software bill of materials more in the last year than they have in the previous decade or sbam, right? I mean, that, that term I think originated around 2010, but it’s certainly s related. So can we start simple define what an sbam is, please.
Tim Macke (03:41):
This is a really, really important definition point because there are lots of people who are running around saying, oh, I need an sbo, I want an sbo. It’s somehow magical because everybody’s talking about it. And what they don’t realize is that an sbam is quite simply a list of the dependencies that a piece of software has on something else. And that could be a piece of open source, that could be a commercial third party library, that could be an internal library. Technically speaking, you could extend it out to also include things like data providers. So it gives a view of the world as to what this piece of software needs in order to function or how it was built using, well, basically supply chain elements.
John Verry (04:26):
Yeah. One of the thing, you know, it occurred to me the other day when I was chatting with someone that they really didn’t understand that concept of what an sbam is about. Right? So when you, when you think about it, you know, I can, I’m a terribly bad Python programmer, but I like to play around sometimes <laugh> and like, I might like, you know, so let’s say I wanted to just every day go down to a, go to a particular website and download a table, you know, do a little data processing on that table and send myself an email, right? Simple little task that you might do. I could probably do that in 50 to a hundred lines of code. However, I would, you know, I would import pandas, I would import beautiful soup, you know, so despite the fact that I’m writing an application with 50 lines of code, I might be connecting that with libraries or packages, whichever term the different languages used that have tens of thousands or a hundred thousands of lines of code in them, right? I mean, that’s, that’s the thing that I don’t think people who are not programmers fully understand.
Tim Macke (05:31):
I, I would completely agree with that. And, and Python’s a good example of a modern language that for practical purposes, you don’t have to worry about a lot of functionality. You can worry about what makes your thing unique. No, JS is another good example. We can go into Rust, we can go into Go line for practical purposes, all of these languages and all these frameworks have allowed us to do very quick innovation. These are the things where you don’t have to think about, well, how do I secure a webpage? Well, there’s a library that worries about that for me. How do I actually listen for a web request? Well, there’s a library that does that for me. How do I go and parse the strings and bring out all of the parameters? Well, there’s a library for that. Now I need to save it to a database. Well, there’s a dozen libraries for that. And very quickly you can get yourself into the hundreds, if not thousands of libraries, depending on the type of application that you’re creating. And the reality is, from a security perspective, all of the design decisions, all of the testing decisions that those libraries had, well, they’re not the same as what your code has. Mm-Hmm. <affirmative>. But if they’re bad, your code is gonna fall victim to it somehow, some way.
John Verry (06:45):
Yeah. That’s the crazy thing, right? I can write 50 lines of perfect code, but I’m relying on, you know, 10,000 lines of code in libraries that I don’t know what was done there. That might be vulnerable. Hence, I have an, I have a vulnerable application. Okay, cool. Because I, yeah, that was, I was talking with the guy and he just wasn’t fully getting it. And I, I said that to him, and he just kind of went, I could see lights go on <laugh>. So, so this Hess bomb thing has become like, you know, everywhere how many president
Tim Macke (07:14):
Yeah. And, and in fact, I blame President Biden for
John Verry (07:16):
I was, that was what I was just gonna ask you. Let’s talk about what is driving that interest, right? Why are we, why are we here talking about abus?
Tim Macke (07:24):
So, couple reasons. First and foremost, if we have an executive order from a president that suddenly uses technical terms and uses them kind of correctly, <laugh>, this should be our opportunity to pay attention. Whoever the ghost writer was, and I have some pretty good ideas as to who the ghost writer was, did a fantastic job of educating the world on the types of risks that could be within a software supply chain. And they used examples like SolarWinds and CAE and Code Cup and so forth. These are all things that, well, you quite honestly don’t expect a US president to know anything about independent of what, whatever their background might be. Like. This is, this is something where you go and have people go worry about it underneath the covers, that forced everyone to go and say, oh, wait a minute. Esba M appears 38 times in this document.
(08:18):
That’s an obtuse amount of reference to SBO m I need to pay attention to it. Which meant that a lot of software security companies reinvented themselves overnight. Zero Trust was also mentioned in the executive order. So all of the network security companies suddenly became zero trust companies overnight because, well, we’re going to attach to this. And the reality is, the executive order did nothing more than say, heads of agencies, here’s some problems, go think about them and tell everyone how you’re going to fix it. So NIST and N T I A and OM B and all of the alphabet soup, that is the government that suddenly brought it into the public’s frame of reference. But for practical purposes, what got lost in the shuffle is that there is no single SBO m there are different pieces of data that are important in different scenarios.
(09:08):
So we even have SBO m being referenced in the omnibus bill back in December. So a spending bill has an SBO M reference in it because they decided that they were gonna modify the FDA’s regulations to require an SBO m vulnerability disclosures and vulnerability informations with any new pre-market filing that’s different than what President Biden was talking about, but it’s all related mm-hmm. <Affirmative>. And so as people start to connect this SBO M concept into some real requirement, they’re forced to actually start asking the question of, well, what could I do with this thing? What is it really going to enable me to do better, faster, stronger,
John Verry (09:52):
Mm-Hmm. <Affirmative>. Yeah. Talk a little bit about, so, you know, one of the things that the presidential executive order did as well, you know, is he directed, if you will, the NIST to come up with an approach to this, right? So they came up with, you know, what we would commonly refer to as the SSD F or Secure Software Development Framework. You know, and it was documented in NIST special publication 800 dash two 18. Talk a little bit about the SSD F and how that interplays, if you will, with SBOs.
Tim Macke (10:23):
So the SSD F existed before the presidential executive order, but it needed to be revised as a result of the executive order. And effectively what it does is it sets out some outlines for how you might prepare an organization to start doing secure development. How you would go and do the types of testing that are going to be necessary, do vulnerability response, and effectively say, here I am going to create a piece of software, and it’s going to be adherent to some level of security acumen that is going to be defined by nist. Whether you follow NIST or you don’t follow nist, at least here’s a rubric for success. One element in the s SDF is an sbo. So without having an sbo, you can’t go and claim that you’re performing all of the various tasks inside of the SSD F and the SSD F is quite expansive in its expectations.
(11:23):
It includes things like how you might go and construct a CI pipeline or how you should secure developer environments, the use of multifactor with source control systems the types of testing that you need to perform, depending on the type of application, how you’re going to have separation of release artifacts from test results so that you can avoid scenarios like SolarWinds, where things came together in unfortunate ways. So the, the fact that this s SDF framework exists is effectively a baseline for how organizations who might not necessarily be following all of these elements can actually mature into becoming more secure development organizations in a reasonable period of time.
John Verry (12:07):
Right. Probably fair to say the s SDF is more akin to a good recipe for a good software development life cycle, and of which one component of that would be a generation of an
Tim Macke (12:17):
Sbam. Exactly. Exactly. Perfect.
John Verry (12:19):
So like you mentioned, it would be pretty easy for a complex application to have dozens, hundreds, maybe even thousands of different libraries and dependencies. So, you know, generating an SBO m manually while it is, I guess possible, would probably be alright. Maybe it’s not possible.
Tim Macke (12:40):
Oh, no, no, no, no,
John Verry (12:41):
No, no. I mean, it’s possible, possible, but painful
Tim Macke (12:43):
For specific reason. The number of SBOs that I’ve seen that are in a CSV file that someone is manually editing the contents of in Excel is shocking.
John Verry (12:55):
I, I, I know I, I’ve seen them too, and I don’t trust them as far as I, as far as I can throw them. Right. You know, it’s, you know, cuz how are you going to actually maintain that? How are you going to, you know, so while you can do them manually, I think most organizations are starting to recognize that using something referred to as a software composition analysis or SCA tool is, is a better approach. So can you explain how an SCA tool works?
Tim Macke (13:23):
Sure. And as disclosure to everyone I came to Synopsis by way of the Black Duck acquisition.
John Verry (13:30):
Oh, did you? Oh, so yeah, so you’re the perfect person to talk about this.
Tim Macke (13:33):
So SCA stands for Software Composition Analysis, and it’s effectively going to take a look at one of two things, either the source code and identify all of the libraries that are included as dependencies, either directly or indirectly, or it’s going to take a look at a binary and perform the same task. Obviously if you have access to the source code, you’re going to have a greater level of accuracy in the results than if you’ve got a binary. And you kind of have to guess as to whether you’ve got component one point, one point component version 1.1 0.1 versus 1.1 0.2. They might be a little bit fuzzier in terms of being able to identify that sort of thing. But fundamentally, it’s looking at what exactly are the list of dependencies for the application, creates a bill of materials, and then underneath the covers it’s going to map that bill of materials back to a knowledge source of some form. That is typically representative of all of the activity that’s happened in the land of open source. So you get, ah, I’ve used open SSL 1.01 J and I really shouldn’t be using j I should be on something newer. Then you start to marry in security information from the national vulnerability database, and you can get a, a bit of a picture as to what the security governance practices are within a development organization when it comes to open source.
John Verry (14:59):
Okay. So there’s a value, there’s a dual facing value to an S bum. One, there’s value to me is the developer at the company producing the software, and then there’s gonna be value to the people that are receiving the sbam. Let’s talk about the value to me as a developer. What is that value?
Tim Macke (15:19):
So as a developer, the first thing you really want to do is make certain that you’re choosing components that are properly maintained, that don’t have any outstanding security issues, and that whose license actually aligns with whatever your organization says is the correct set of licenses to use. And so that can get into the reciprocity of code and whether or not, for example, the organization expects to go and publish all of the source code or not. So simple governance answer for the license compliance side of the equation. You can set policies to say, well, you know what, I shouldn’t be using a library that hasn’t been maintained in three years.
John Verry (16:02):
So that would be so, oh, sorry about that. Keep going.
Tim Macke (16:04):
No. Or a library that has outstanding unpatched vulnerabilities in, so basically gimme something that’s, that’s new. It’s not like six versions behind. Because if you needed to update that, if you get too far behind, you’re effectively taking a whole lot of functional changes that you might not expect just to say patch a cbe.
John Verry (16:25):
Yeah. So when I’ve been in like the black duck software and user interface, right? You guys break down the three types of risks, right? Vulnerabilities, licensing, and operational. So you were giving examples of each of those three types of risk, I believe there.
Tim Macke (16:38):
Exactly. Exactly. And there are different types of risks that you can overlay on top of it, but fundamentally it’s a case of how do you do risk mitigation? And if I’m a developer, I might want to have that in my IDE so that I know that, hey, this component is good. And my canonical example from the No JS world is, do I like buffer, safe buffer, safer buffer or safest buffer?
John Verry (17:02):
I’m guessing safest <laugh>. No,
Tim Macke (17:05):
Actually you probably want safe buffer because it’s, it’s more recently
John Verry (17:08):
Made, but it’s, but it’s got an s at the end that has to be the best choice.
Tim Macke (17:12):
Exactly.
John Verry (17:12):
I mean, you know, it’s him. I mean, that was a trick question.
Tim Macke (17:15):
<Laugh>. now the real interesting question, John, is how many different versions of that do you have? Do you have all four of them in your application? And you might actually have all four if you don’t know where things came from.
John Verry (17:29):
<Laugh>. that’s interesting. And so vulnerabilities, I think for anyone listening are pretty easy to understand. That’s poorly written code, that it is likely to lead to an exploit of the application because the library is vulnerable. You talked about operational, I think that’s fairly easy to understand. You know, that would be where maybe this library is no longer being maintained, or maybe the community is a very, very small community. And you might say, should I, you know, count on something where I’ve got a library that’s being maintained by a single individual and it hasn’t been touched in two years? Right. That would be a, an operational risk. Right? And you’d say, I might be better off finding a different library there. Licensing is one that I always get a little confused by. So can you explain what licensing risk is?
Tim Macke (18:14):
So all software has some form of license associated with it, series of rights and obligations. And within an open source space, the rights usually include things like, I can use this in any type of application that I want, and I’m free to do a bunch of things with it. It’s the obligation side of the equation that starts to get a little bit funky for most people. So, contrary to popular belief, just because it’s on the internet doesn’t mean it’s free. There is in fact a set of rules and one of the rules could be that if you incorporate my software into your product, you have to go and publish not just a copyright of mine or an attribution back to me, but potentially the entire source code that is associated with what I’ve now become part of. So publish the entire source code of the application.
(19:14):
For some organizations, that’s exactly okay, and the world is moves on and this, this is not a problem, but for other organizations, that’s a bridge too far. They want to retain access to their intellectual property, so they don’t want to be publishing the source code. So the license that I may have put that more restrictive license means that maybe for that organization, my code as good as it is, is the wrong code for them. It just doesn’t fit their worldview. And so it is quite simply a set of, you can almost think of ’em as contractual requirements of here’s a set of rights that I’m granted, here’s a set of obligations are the various elements compatible with each other now across all of the dependencies that are in the application so that there’s no encumbrance on the end result.
John Verry (20:05):
Okay. So that’s gonna, that effectively keeps you out of legal issues. Right? So we’re, we’re helping people with, you know, with security issues, legal issues and operational issues.
Tim Macke (20:16):
Exactly.
John Verry (20:17):
Okay. So we talked about the value to the person creating the software. Let’s talk about the value to the person receiving the sbo m or in a be best case digital sbo m so what, what, what would be the value to the person receiving it?
Tim Macke (20:35):
So the question is less about what’s in the SBO M because the SBO m itself has limited information. It’s got the list of dependencies and it may have license information, and that’s it. Vulnerability information is another document that’s related to it. So the way I like to think about it is, an SBO M is an enabling technology. It forms an anchor point to say, this is what this application looked like at the point of its release. Now you have a vulnerability data feed that’s beside it. You can have attestations conformance statements, data flows API endpoints. All of these things could now be mapped into the SBO in a way that allows for someone who’s on the receiving end to go and answer important questions. Like, well, how well tested was this application? Can I use it in an environment that might be highly critical, say a banking application or some form of critical infrastructure?
(21:35):
Was it actually designed by people who are within the realm of people that I can do business with? So when you start dealing with governmental scenarios, you might have scary companies or scary countries or scary individuals that shouldn’t be contributing code to this type of application. So you can start to do a lot of analysis around what’s happening in that application and the type of security practices that are employed by the entity that is producing that esba and that software, obviously you can go and bring it into a larger system to do some continuous monitoring for new vulnerability disclosures, disclosures and make that part of an overall patch management effort. But in terms of the, how well suited is this application to run in my environment with my context, that’s something that you can really do well when you have an SBO m that is what I tend to refer to as robust because that’s how the the FDA defines it and is truly comprehensive and accurate.
John Verry (22:42):
So let’s say that I’m the, you know, c i s O of a a bank and I’ve got, you know, thousands of applications in my application inventory, and let’s say I was lucky enough that all of those applications provided me with a digital sbam so that I know all of the individual components within those applications. Talk a little bit about how Log four J might have looked a little bit different for those four guys.
Tim Macke (23:08):
So I can tell you exactly how it would’ve been <laugh> been different <laugh>. You would’ve been able to know with a simple query, which applications had log for shell exposure, including all of the versions sprayed that happened while the log for Shell experience was being solved. Then you could have had a proactive ticket both to the internal development teams, but also a proactive outreach to all of the suppliers to say, what was the mitigation put in place? What are your plans for remediation of this? What are your timelines? And actually had a very process behind it. So effectively shortening the time to identification from being, say, couple weeks where you’re querying everybody in the organization as to, well, tell me the status of your application all the way down to maybe an hour or two for identification, and then the remediation time taking however long it needed to take.
John Verry (24:08):
Right? Yeah. To me, that’s where, and I know it’s gonna be a while before we can get to that kind of a point, but to me, as a security practitioner, that’s when I look at and say, that would be exciting that somebody would have instantaneous access to understanding where their risk is. You know, they can put their own compensating control mechanisms in place if they need to, you know, they can be proactive in reaching out to the vendors. Yeah. It, it, it would’ve made life a a lot less of a fire drill for a lot of people.
Tim Macke (24:33):
A a and the interesting thing is, is that at that point in time, we had one customer who had basically bought into our full story around how you should do things with respect to SBOs, and they were able to identify within their client base, they were essentially a managed service provider. All of the impacted log for J installations, all the applications, fix, all of them produce a blog post and a video in less time than it took most people to wake up from their slumber that morning.
John Verry (25:06):
<Laugh>. That’s really cool.
Tim Macke (25:08):
And, and, and it is like only found out about the blog post maybe three or four days later. It’s like, yes, this is the way it’s supposed to be.
John Verry (25:17):
Yeah. How, just as a, you know, someone who lives eats and breathes this every day how long do you think it’ll be before, you know, we approach that that level as an industry? Is it, you know, it’s certainly years, is it more than years?
Tim Macke (25:33):
So I I I, I think it’s going to come on us very quickly mm-hmm. <Affirmative> and I think we’re going to be somewhere in the next 24 months, maybe as short as 18, maybe as long as 36, but not much longer than that. That most enterprise level organizations, so let, let’s say your, your mid-size businesses and higher will be operating with an SBAM centric mindset for their application procurement and governance. And partly that’s going to be because, well, we had the Biden Harris cybersecurity strategy from a week or so ago that said that while the US government is gonna use its purchasing power to kind of uplevel the AppSec and overall security and cyber capabilities of their suppliers, which when you start looking at how that nests out very quickly, you end up with almost the entirety of the US software producers, right. Encompassed. So I think, I think we’re two years.
John Verry (26:36):
Wow. I, I hope you’re right. Should esba generation be something that is baked an organization’s development pipelines?
Tim Macke (26:45):
Yes. Categorically it should be something that is in fact, I would say that there we should think of it as multiple phases of sbo m So the developers need to have their sbo m we need to have something that represents the packaging side of the equation, and we need to have something that represents the running state. And now you can actually start to say, this is the set of changes that development team are producing. I wanna make certain that my operations teams understand the implications of those changes. And if I need to do a quick patch for something, so let’s say I need to swap out log for J and I’m just going to do that in the VM or in the container image itself, because it’s just the easy way to, to swap it out. I can actually say, my running instances is this, however, I know that I have a development dependency to go fix that. So I can ex at least in the operation side, accelerate remediation or accelerate mitigation.
John Verry (27:44):
So I’m not sure I fully understand. So we’ve got the developers, right? Yep. And, and obviously what we’re trying to do with the developers, make sure they’re not writing vulnerable code and make sure that they’re as early as possible, making good decisions about the components, the libraries that we’re using.
Tim Macke (27:58):
And those decisions are going to impact the people who are running the software. Right.
John Verry (28:02):
So when you say packages, define packages, cause you said, I just wanna make sure I followed the train. You had developers, so packages, packages
Tim Macke (28:09):
The libraries that developers bringing in to make the application work.
John Verry (28:12):
Oh, you said package is not packages
Tim Macke (28:14):
Yes. Packages.
John Verry (28:16):
Oh, sorry, I thought you said packages and I thought it was a term that I wasn’t Oh,
Tim Macke (28:19):
No, no, no. Sorry. Okay.
John Verry (28:21):
I will
Tim Macke (28:21):
Bring
John Verry (28:22):
For that <laugh> that in my, my, my, my ears would be fair to blame as well. <Laugh>. And then so from an on the operations side, what we’re trying to do is they would use that same software bill of materials to know what their responsibilities are going to be in operations. Is that, you know, to, so that they can plan accordingly,
Tim Macke (28:44):
Partly, but also to give them an opportunity to say, Hey, wait a minute, you’ve changed the risk profile of this application. I can’t accept this because, and here’s an example of how that can play out. So let’s say for the sake of argument that we’ve got a web application and somebody has this wonderful idea to ensure that there’s a spell checker in that web application mm-hmm. <Affirmative> mm-hmm. <Affirmative>. And so the developer goes and finds a fantastic spell checking thing that is powered by chat G P T or some other AI system. The initial implementation says, sure, I’m just gonna put it in these couple of areas. The world works fine, we’re happy. Then somebody else decides that it would be a fantastic idea if that was applied to everything so that we can have proper spell checking. What they didn’t realize was that the security questions, the responses were now being sent over to this cloud service because they were being spell checked.
(29:47):
What are the ramifications of that to the operations team? They now have made a leakage issue. So if there’s a way for them to know that there’s a set of changes in here that will not be acceptable for whatever governance reason, ideally the developers know that beforehand, but we’ve all seen non-functional requirements that Right. Are of the compliance issue that Neo have the rework. So we’re never gonna solve that problem completely. But if we have the ability for that s om during its development life cycle to also be communicated over to the operations team, they have a fighting chance of saying, wait a minute, this doesn’t make any sense to me. We can’t
John Verry (30:26):
Work. I gotcha. So it’s sort of a belt and suspenders when threat modeling Exactly. Risk assessment doesn’t work the way that it’s supposed to.
Tim Macke (30:33):
Yeah. And so we effectively end up creating a little bit more of a
John Verry (30:36):
Closed loop loop and
Tim Macke (30:37):
Yep. And so then when we start doing some tabletops, we can say, wait a minute, this thing here, well, I need to go and mitigate that because we’ve made a change as a result of maybe a legitimate requirement, maybe the regulatory requirement. Or maybe it was just a product owner who said, Hey, this looks really cool, we need to do this.
John Verry (30:55):
That’s pretty cool. I didn’t think of that.
Tim Macke (30:57):
Yeah. So, and so this is really one of these things where as we go through this SBO m world today, we always think about it in terms of, Hey, I can understand open source vulnerabilities, but the real challenge is to start saying, well, if I don’t use the word open source, and I don’t use the word vulnerability, what other kinds of things can I do if I only knew what was inside this software?
John Verry (31:21):
Mm-Hmm. <affirmative> and, and just to be clear, right, open source or non-op, open source, you know, commercial libraries, right. You know, the sbam situation is still the same. Right. We wanna make sure that any Yeah, because I mean we’ve, we’ve talked open source quite a bit and I don’t want people to just get left with the idea that sbam is only about open source libraries, right? It’s about any library that we’re using, any component we’re using.
Tim Macke (31:44):
Correct. It, it’s, it’s literally anything that we have a dependency on. Okay. And so the way I like to look at it is it’s open source, it’s commercial, third party libraries, it’s contracted software because who knows what the practices are within the the development shop that you’re contracting. It could also be APIs and anything else I
John Verry (32:03):
Was gonna just, I was just gonna ask, I was just gonna ask you that. Right. You know, and, and API is something that would be part of an sbam, right? If you’re reliant on a particular API
Tim Macke (32:14):
Or savvy, and today it’s not part of the specification, but once you start saying, let’s remove open source from the table and say what else we can do, you can very quickly end up in a position where you’re starting to ask these questions and, and if nothing else, you want to create the opportunity to have a mapping of here’s my APIs and the data flows. They’re going outta the APIs, here’s my SBO m what component is actually doing that? What component is supporting that traffic flow? Because as an example, there might be a phone home mechanism you didn’t know about.
John Verry (32:44):
Mm-Hmm. <affirmative> makes sense. We covered everything. We beat it up pretty good. Anything we missed? Anything you wanna close with?
Tim Macke (32:55):
So the, the only thing that I want to say just as an SBO M journey kind of experience is that there’s an awful lot of tools out there that will generate SBOs. There are far fewer ones that generate SBOs that are adherent to either of the s Spdx or Cyclone DX specification. Mm-Hmm. <affirmative>, we’re very much in a garbage and garbage out mode. So the first order of business, I would say, for anyone who’s starting down this SBO M path is when you pick your favorite SBO M generation tool, and there are many to choose from, take its output, take it over to the respective validator tools that are created by the s p Spdx or the Cyclone DX community and see if it’s a valid sbo. If it isn’t, move on to the next tool. Just don’t even bother trying move on to the next tool because you’re going to invest more time trying to make the tool work when you should be worrying about how you actually go and do the analysis of the software that you’ve got to generate a legitimate
John Verry (34:01):
Sbo. Right. You don’t need more work than <laugh> than than the tool’s already gonna kick off for you. Yeah. Because you’re gonna find, if you’ve never run, run Black Duck software before, you know it’s gonna, it’s gonna give you some work to do cuz it’s gonna find some things that are wrong. And the last thing you need is you’re trying to sit there and manipulate a a digital SBO m to get it to be, you know, it that it can be read by your customers. I mean, actually, if you really think about it, you can invest in this software and you’re investing in this software, you know, in large part to satisfy a client demand. And then when you hand off the, the SBO m if it’s unreadable, you’ve got an unhappy client and you haven’t met their demand.
Tim Macke (34:39):
Exactly. Exactly.
John Verry (34:40):
So, and you’ve been, you’ve been modest. Just to be very clear and a reminder, Tim works with Synopsis, you know, synopsis purchase Black Duck software. Black Duck software is probably the longest tenured f organization in the software composition analysis space. And synopsis’s tools are best in class, right? I mean, you know, if you look at all of the, the Gartner Magic quadrants and Forester Waves and everything of that nature, synopsis sort of stands alone up in that upper, you know, clear differentiator. Arguably, I I think easily arguable probably the best software application testing company in the world, you know, between your software composition analysis tools, your, your, your covarity SaaS tool, white hat DA tool, and a missing one. What’s the other one? I asked Seeker
Tim Macke (35:25):
Seeker and defense for Fuzzing.
John Verry (35:27):
Yeah. So yeah, I mean it’s a great portfolio of, of, of tools that work together in a, in a nice way. So cool. So hopefully did your homework <laugh> you look confident. So I think you did give me a, a fictional character, a real world person you think would make an amazing or horrible ciso or if you prefer software developer, head of software, something like that.
Tim Macke (35:48):
So my horrible ciso, my horrible software developer would be Tony Stark.
John Verry (35:55):
<Laugh>, I don’t
Tim Macke (35:58):
Know. He is so not a team player.
John Verry (36:01):
<Laugh>, I mean, penny would disagree, I think. Well Penny would probably agree. <Laugh>. Alrighty. If folks wanted to get in touch with you or with Synopsis to talk about Black Duck software
Tim Macke (36:19):
Synopsis.Com I am at Tim intech on Twitter, much as we still use Twitter. And the Synopsis Twitter account is at synopsis spelled with a y, not an I.
John Verry (36:33):
Okay. And Tim intech is there an H on the tech?
Tim Macke (36:36):
There’s an H on the tech. All right, ch
John Verry (36:40):
All right. Sounds good man. Well, listen, this was fun. Thank you for coming on. I appreciate it.
Tim Macke (36:43):
Thank you, John.
