Transcript
Hi Mike Matchett with Small World Big Data and we're here today talking about security again. Actually, we're going to dive a little bit into software security and what's going on there, particularly if you have a slightly more complex development environment where you may not have a good understanding of what's in every package, particularly open source packages. They have nested, they go on forever. It's a recursive nightmare. Sometimes you just even know what you have, much less if you've got vulnerabilities coming along. How do you find that? We've got an answer for you today. Just stay tuned. Hey Neil, welcome to our show. Glad to have you here. Uh, tell us just a little bit about, uh, first about Anchore. What what's what's the concept here? What is what is an SBOM. Let's start there. Okay. Well, thank you very much for having me. Um, SBOMs are software bills of material or bill of materials. They're very simply just a list of all the software that you have in an application or a service or, you know, any, any piece of The software that we scan, we can generate an SBOM for. And it's just a means to provide transparency. It just helps you see what's in there most. You know, mostly these days applications consist of, you know, roughly 20% of code you're writing in, the 80% of a lot of open source that you're downloading from GitHub and everything else here. And so SBOM s just allow you to see all the stuff that you didn't realize you were using. Sometimes you declare things explicitly, but a lot of the times the things you are asking to include will be pulling in their own things into. So SBOMs just wrap up the whole thing, give you the total list of everything that you've you've used or is built into an application. All right. We're going to come back to, I think, some of the great things you're doing with SBOM s and some of the problems with that other people might face naively dealing with them. But first, I just want to ask you personally, there's a lot of different problems in the market. There's a lot of challenges. There's a lot of corners. One could really dig into why kind of this inventory of libraries aspect, what draws you to that and why is that? Why is, you know, what's going on there. What's the energy. Yeah. So I mean, SBOM s are a means to an end. Um, and the end is trying to sort of. It's a little bit closing the barn door after the horse has bolted. We've we've spent the past, what, 20 years trying to evangelize or I have been evangelizing open source and being excited about being part of the ecosystem and sort of seeing its ubiquity. But what I think has happened over the past few years is there's been so many security issues which have not been minor. They've been major where these are like, you know, the door is open, you're letting the burglars in, and it's because of open source flaws, because we've been so, um, sort of unconcerned about the security of of the open source ecosystem. So SBOM s are a way to try and help address some of those security concerns, which have gone from sort of being niche to being like a board level concern. And we saw this with obviously Log4j2, and there's been another number of other, um, security issues that have come up around open source since. So. Anchore and you know, how we, we use SBOM s, which is one part of our product is. Yeah. It's my way of trying to fix the fix the problem. I feel like maybe I helped create over the past few years. All right. So it's really about leveraging open source and making that world work. When when when when a developer and I've done done some development when I include a library that's open source, obviously I can list that myself because I know what I added, right? I required it and it went in there. But as you're saying, one of the issues is that package in turn can require other things. And then you get this descending, uh, spaghetti of of overlapping requirements and to the fact that you can have multiple versions of the same low level library in your code, not know it. And so when someone says, hey, do you have Log4j of this version? And you're like, no, no, no, this is, this uses this one. But then you dig a little deeper and you're like, oh yeah, it also you're also using that. Oh yeah, yeah, it's over here too. And then get down, get down pretty deep. Um, so let's, let's look a little bit at, you know, what can happen then. Um, or you know, what needs to happen. Uh, it's not simply sufficient, though, to have a list, right. You have to be able to do something with it and apply some intelligence to it and analyze it. How did how do you. How do you help people go forward with that and say, okay, you've got your you've got your snapshot of what's in there now what. So yeah, I mean, it's fair to say at the moment when a lot of people think of SBOM s, they're sort of it's maybe it's come up because now they're, they're now expected to give them to their consumers or their partners. Or certainly if you're selling to government, the government is starting to say, you know, you must produce these things before we buy from you. But we look at them as slightly different as they're they're essentially snapshots or documents of your, your software and every sort of moment in time and across different locations. And so we take SBOM s as every time a developer commits a piece of code that generates a new SBOM , every time you build that package, it generates a new SBOM , and every, every time you deploy it. And so by capturing these things across time and space, you can look for differences. You can look for the variations. You can start to see, well, who brought something in and why did they bring it in. Do they mean to bring it in. Um, was it intended or not? And, um, to track the evolution of these things. And so when you do have a situation like Log4j2 and you're sort of saying, do we have it? And, you know, I mean, we saw it in Log4j a lot of people going, no, no, we don't use it. But no, you do. You have it everywhere. This allows you to sort of track back and see, well, how pervasive is it? Where is it included? And you know, who is responsible for deciding to put that piece of software in the first place? So with our approach, our approach, which is SBOM powered software composition analysis, we think we can allow you to ask these questions in response to, you know, whatever the next open source insecurity is that gets publicized. All right. Let's let's let's slow down their software composition analysis. Right. You try to sneak that one by me, uh, in order in order to in order to do that, you have to have some way to know what the vulnerabilities are in the world. I mean, imagine, imagine. That's a pretty onerous task when they're all open source packages. How would someone even know what to be looking for? Yeah, well, you know, it's exactly right SBOM s just tell you what you have, they don't tell you what the problems are. So I mean, we have some open source projects as well as our commercial product, which absolutely gives you that security insight on top. And so we pull and aggregate all of the vulnerability feeds that we can find around the internet. There's there's a lot of them, both good and bad from vendors and from third parties. And so yeah, we bring those in, we normalize them. And that's definitely the very first thing you do with a set of bombs is say, what vulnerabilities do I have? But security issues aren't just about known vulnerabilities. They're also about, um, you know, the general health of a package are using like the right version are using something which has been well maintained. Um, are you using something where, um, you know, there is some security process around how how updates are made to it. So SBOM start to allow you to answer these questions. And we provided means to sort of get that overall security insight from from your SBOMs. But absolutely, vulnerabilities are, you know, the first step and still the most important thing. I mean, it's the it's the entry level hygiene equivalent to enabling two factor authentication with your accounts is scan your software for vulnerabilities. And it's absolutely what all of our customers are doing. All right. Let's examine that a little bit. So the structure here is there is some open source packages that you guys offer and support. Um Swift I think Swift, if I'm not wrong and correct gripe, you'll have to spell that one for me. Also have a gripe. Group uh, that help someone just do. If they want to do their own scan, they create their own SBOM. It's it's not it's not something that's an IP protected thing. You can go do it. Uh, but then what you're doing is wrapping that with a set of more, uh, enterprise level services, tracking vulnerabilities from across the internet, applying those to the SBOM s. Tell us a little bit more about that enterprise, that Anchore enterprise and what what features and values that has. So the key thing is Syft and Grype, which are very popular tools. You can download them from from GitHub. You know, they operate on a level of one artifact. You give it one container image or one git repo, and it will generate the SBOM with Syft, and then you'll get a list of vulnerabilities with Grype. But if you're trying to do that in a complex software development organization with multiple teams and projects, you know you want to store this data. It's not about doing a one time scan of and throwing away the results. You want to be able to do that across, as I said, every single commit, every single build, every single deployment and store that data. So you can then do the kind of analysis that I referred to earlier where if you want to do some, um, you know, excavation or archeology of what went on, um, you can do because all the data is persisted, which is the key thing of an enterprise. We persist the data and then give you the workflows on top to build it into reporting or querying or, you know, notifications to developers to tell them to fix things in response to a policy that you may have created. And there's some policy engine support and workflow in that Anchore enterprise as well. Yeah. That's right. So, you know, a large part of this is is compliance. And this has kind of been interesting over the past few years. Certainly in US government, um, starting around 2022, started to get wise to sort of like the risk of open source within their own operational environments. Never mind, you know, the sort of the private sector. And so, um, compliance sort of, uh, controls started to change and sort of mandate various things that you had to do and, um, around the use of open source. And so, um, you know, FedRAMP is a good example of, you know, things that commercial organizations follow, but there are standards that government agencies also have to follow. So our software tells you if the software you're using, the versions you're using, the configuration you're using, are you meeting those standards, yes or no. So a large part of an enterprise is is monitoring and enforcing those compliance standards. Yeah. I mean FedRAMP would be an example of something that gets, you know, I'm a former intelligence officer for the Air Force. You use Air Force here. Uh, back in my day, though, we wouldn't have let open source anywhere near the vault. Right? It just it just wasn't a thing. It wasn't even a thing back then. Uh, but you. But you knew that. But today, uh, yeah. That's right. It's just a completely different world. You have to know. You have to be able to go in inventory. You have to be able to audit. You have to be able to look for vulnerabilities, and you have to be able to react and respond. I think that's probably the more key thing is we no longer have these big fortified walls keeping everything out. Exactly. That's right. And so, you know, I think this is where the past couple of years has said that the sort of like the the penny dropped where developers were choosing to use open source because it was free and it was convenient. But, you know, the executives didn't have to worry about those choices. They do now because essentially it's created a massive attack surface inside their organizations. And that's true for everyone, including the government as well as, you know, every fortune 500. So nobody is not using open source anymore as they. And that's a good thing. And it's a bad thing. It's a scary thing. Yeah. So we've definitely gone from IT ops to DevOps. And now this is really a key part of DevOps, right? I think you were DevSecOps. Yeah. Is is sort of the. Devsecops DevOps. Phrase. We've got to put security first because I'm a security guy, but that's. Yeah, that's a good point. On there. All right. Cool. So let me just let me just ask you sort of look forward question where does this where does this go. What what happens. Uh, you know, what happens next is particularly, you know, with the explosion of people doing things like AI and doing things like global supply chains and doing things like that, how does what do you what do you think are going to be some of the new challenges we're going to have to face in this supply chain of software? Yeah, I mean, you know, part of the challenge of AI, especially before you using copilot, is like, that's not making the decision about what software to use on your behalf, right? Do you use copilot to declare dependencies? And, you know, no one's vetting them. No one's checking them. There's no discretion being used. And so the use of AI in software development is sort of exacerbating just this general problem of software being brought in without anybody vetting it. So, you know, that's only adding more fuel to the fire here. Um, so that's definitely an issue. I mean, you know, there are geopolitical concerns around now as well. Open source is a global practice. Um, but, you know, increasingly governments have all all all, you know, um, parts of the world are sort of want to know more about, well, where is the software coming from and who's creating it, and can we trust the people who wrote it. And so there's there's a large geopolitical aspect to it too. Um, but again, this is why our approach is that I don't know what the problem is going to be. You know, this year, next year. It's hard to predict these things. But if you have the data, if you've stored it and you've and you've used it and you see it as an asset, these bombs, it puts you in a much better position to to react to whatever the next problem du jour is. All right. So I know there's open source and obviously people could download something and kick the tires on a single thing, but if they want to look at the Anchore, uh, enterprise features and start to say, hey, I've got a complex software developed environment, maybe we're not doing everything we could be doing. Where would you recommend that someone start to learn a little bit more about this and dig in, and what steps would you say they should take? So definitely look at the open source projects which are sift and grip under github.com slash Anchore. Um, great place to just if you want to get a very, you know, easy way to sort of just playing with some of the technology here. Obviously on Apple.com you'll find more information about our product. But I do encourage people to join our webinars. We tend to run quite frequent webinars to introduce people to S. So explain what you can do with them, how it connects to things like, you know, DevSecOps or compliance standards. So those are good places for whether you're a beginner or somebody who's looking to implement something practically. I would say that's a good place to start. And, you know, we can make a little bit of a prediction that this is not just for the biggest of environments anymore. As open source spreads. It's definitely coming down the pyramid. Uh, definitely going to be enterprise and mid-range and like, challenging everybody soon enough if they're not already. If you have a business critical piece of software, it has open source in it. So you need to be aware of that. You need to be on top of it. Uh, thank you for being here today, Neil. I look forward to what's coming next in this, uh, this is, uh, at first seems like a, you know, like a shopping list. But there's a lot of things going on here under the hood that help people get ahold of their environment and stay on top of it and keep the bad guys out. Thank you for reminding us of this. And do come back and tell us. Tell us what's happening next. Will do. Thank you for having me. All right. Take care folks.
