Talking Software Supply Chain with Steve Springett

Welcome to the AppSecEngineer podcast! In this episode, we have Abhay in conversation with Steve Springett from ServiceNow! Tune in to listen to him talk about software supply chains, and what it means to effectively secure them. Steve shares his experience using the software project management tool Maven, and how difficult it was to develop a secure CI/CD pipeline, particularly as projects ballooned in size and scope.

AppSecEngineer Podcast with Steve Springett

Abhay - Welcome to this episode. For me, this is a very special episode because this is being filmed with somebody that I really respect in the Application Security Industry so to speak. The person I'm talking about is a leader in the Software Bill Of Materials and the Source Composition Analysis space. Not only does he have an extensive amount of experience in this place. He's also built some extremely world-class tools and Open Source tools that support and nurture this space. With me, I have Mr. Steve Springett. So welcome Steve. Welcome to the podcast. Glad to have you here. 

Steve - Thanks for having me. I appreciate it. I'm always glad to catch up with you. 

Abhay - Thanks so much. So Steve before we get started, I always ask all of my guests this question, how did you get your start in security? And what kind of brought you to security? Because a lot of times people don't start in security. So just tell us your origin story, Marvel style.

Steve - Yeah.. I actually got into Physical Security before I was actually in Information Security. I was doing Access Control Systems for banks and high rises here in the city of Chicago. And it wasn't until I started doing some really, really early web development in '94 or so that's up and through, up and through that.. that 2000 era that organizations actually started bringing in security into their vocabulary. And you know, I was responsible for putting up some of the first airline reservations on the internet. That's a long time ago, but it wasn't until around 2008 or so, where I was working for a French software company out in Scottsdale, Arizona.

And I was hired for this whole pharmaceutical supply chain thing where you were tracking raw materials up through the manufacturing process, wholesale distribution up to your pharmacy shelves, that entire supply chain, which there were so many really fascinating use cases. That's where I really started to get into security.

I started doing Static Analysis, started with fortyfive version 2.5, I think, that had been, you know, using fortyfive ever since . But that's really where I kind of got hooked on the whole supply chain thing just because it's so fascinating, It's just a big market. It is not just one thing to concentrate on. It's a very big picture.

Abhay - So one of the first questions that I want to ask you,  and I think you are the best person to answer this question. What does Supply Chain Security mean to you? Because we've seen this word being bandied about quite a bit, right? We've had these massive breaches that everybody talks about that are supply chain based. We had SolarWinds that's supply chain based, everybody talks about Supply Chain quite extensively. What do you define as a Supply Chain? And what do you mean by Software Supply Chain so to speak? 

Steve - Yeah, you know, I look at the Software  Supply Chain as..  It's kind of like the macro. It's looking at, you know, if you look at SCA. SCA solves a very, very small, very specific problem. And it's very reactionary in the way that it solves it. So it's not a strategic type of thing that most organizations should actually start with. But when you step out, you know, a good 10,000 feet , you're not only looking at the libraries and stuff that you're pulling in and all the contributors to those libraries. But you're looking at other things. You're looking at SDKs. You're looking at compilers and compiler flags. You're looking at repositories and in Version Control Systems, which are all inherently broken. You're looking at Build Servers and, and, and if you have a CD pipeline, you're looking at how you distribute that.

And where you distribute that. And then how those artifacts are then retrieved. So you're taking a much further step back with a much wider lens and looking at the more holistic, how everything actually communicates. And the interesting thing about that is that when you start looking at everything that could potentially go wrong, you quickly realize there's not one or two or three different products that you can just slap in here and say, I have a secure software supply chain.

It's not the way it works. In fact, I would argue that it's impossible to deploy any kind of product to solve this. It's really you know, I look at software supply chain is really a truly cross-functional requirement that every business, every organization needs to kind of adopt.

So it's more about processes and, and teams, internal teams working together to identify areas of risk. Whether that risk is coming from internally, whether it's coming from your suppliers , your business partners, even your customers in some cases. So it's really this whole cross-functional thing with a very big lens and looking at a lot of different types of problems and you can go into rabbit holes in each one of these, these little domains, but it's fascinating. The amount of things that are inherently broken which is why I think software supply chain is going to be, you know, such a hot topic for, for the foreseeable future. 

Abhay - Right, that was very interesting. There are a couple of points that I want to kind of deep dive into from what you said there. First of all when you said that , when you spoke about products and I think a lot of products are going to be a little cheesed off by what you just said, which is, Hey, you know what I can't use products to solve this? What do you mean by that specifically? And when I ask you that question, what I mean is how would a company go about starting off doing this process well? What would be your definition of doing this well? How would I start doing this well and where should I go after I start doing this well? I mean, I hate to use this term but unfortunately that comes up, the maturity model journey of this sort of thing for companies can start looking at from a supply chain perspective.

Steve - That's a really big question, but the OWASP Software Component Verification Standard attempts to address this . It's a joint effort myself . I was part of it. I had a co-author from Fujitsu, a subsidiary, as well as another co-author that pretty much does just National Security type of things.

And we came up with the OWASP SCVS standard, which is really interesting because it tries to focus on a lot of automation. So I don't think whatever as organizations do, I think whatever they end up doing needs to be automatable, right. You can't have any kind of success in any kind of manual process.

It's just not going to work, especially as our supply chains get much larger and much more complex. But first is just knowing what you have. Inventory and surprisingly that's a very hard problem to solve. If you look at all the SCA vendors for example and you actually do an evaluation in terms of not what vulnerabilities they find. That part is actually easy. When you're actually trying to identify the thing in the first place. SCA tools are not designed to identify an accurate inventory. They are designed to identify risk and in most cases being close enough is good enough. So if I'm off a couple versions on this one component because of XYZ, that's okay because that component still has this vulnerability, so I'm okay. 

But that's not okay when you're looking at the much larger picture. You actually have to know what exactly you have, including all the modifications thereof. So ultimately, open-source is the ultimate supply chain and organizations will fork things and modify things and, and redistribute things and repurpose things and repackage things.

And, you know, it's, it's really up to us to kind of figure out what all those modifications were because is it just that modified thing now? Or have I created something new? And in many cases you're actually creating something new and that then goes out in the market and that thing that it was originally derived from also is part of that risk. And, now the world doesn't know that. So actually knowing what you have is truly a hard problem to solve, but before then you kind of have to lock down your build systems. If you're using any kind of build system out of the box , you're doing it wrong. I remember spending about two years just locking down Maven.

You know, take Maven, it took us an organization two years just to lock down Maven so that we actually had repeatable builds. So that we knew when we actually put software through a pipeline, what you actually get out at the end is actually what you expected to get out the end, right. And that means, you know, hardening your CI servers because those, especially the on-premise ones are just inherently insecure. In fact, most development tools are inherently insecure just because they're designed to get developers productive quickly, right. That's where the focus is. They're not designed to get developers productive quickly and securely. That's not necessarily what the tools are designed to do.

So we have to lock down, build servers. We have to lock down SDKs and all the configuration files on developer machines. And we have to lock down DNS and internal repositories and all kinds of other things, just to be able to have some kind of confidence at the end, what we think we're actually building is what we actually get. And that's a really hard problem to solve. And, and most organizations that I've ever, you know, talk with they don't actually go to that extra length. And when you don't go to that extra length that's where supply chain things actually start to bite you, right. You pull things from your internal repository thinking that you're the only ones actually writing to that repository and then boom. Now, now you've got a backdoor and whatever it is that you're distributing and now you're compromised to potentially millions of people.

Abhay - Now, I'm going to kind of hone in on a couple of points that you've mentioned. You're especially focused on, on Inventory. So from what I understand and pardon me, if I'm making a few gaps here, it may be obvious to someone like you. One of the points that I think of when I think about Inventory and Source Composition Analysis that inventory is Software Bill of Materials and Source Composition Analysis is the study of Vulnerabilities of your Inventory. So is that first of all correct?  And if yes , what have you done to sort out these two issues? You can talk to, I mean, talk about your project specifically and how your projects specifically have addressed these issues, because, I know you have definitely done things in these two spaces; how you've addressed them? what have you essentially focused on? what were your goals while trying to address these two possible even disparate issues.

Steve - Right. So, yeah, you know, I haven't seen a definition of SCA that actually , I think that actually truly embarks what describes, what, the tools actually do. I like to look at the approach and how they do it. So instead of like describing SCA, you know, we're all looking at third-party open source components.

I like to step back and describe how these tools do it because that actually makes a big difference. SCA tools, like I said earlier, are designed to identify risk and not necessarily to create that accurate inventory and they do so by either doing Binary Analysis, looking at the files themselves.

They look at the coordinance. They'll look at , you know, maybe the file hash or maybe the AST, a fingerprint, whatever method of analysis they use, it's some kind of binary thing or they look at the manifest and in both cases, both of those are educated guesses. You're looking at something, I see evidence of this thing

therefore it is that thing. In a lot of cases, yeah, that's going to be true. But again, open source is the ultimate supply chain and organizations will and continue to make modifications for things and you know, change things, redistribute things, rename things and what you think you have may not necessarily be true.

So if you actually start the other way, so SCA looks more of a reactionary type of thing where it's, it's really easy to get the tools installed. There's a bunch of commercial vendors in the space. But don't expect a complete 100% accurate inventory from these tools. I've done my own bake-offs so to speak.

And none of them really got above 90 some odd percent in terms of their accuracy. And that's just for component identity. That's not even talking about vulnerabilities yet. But if you approach the problem from the opposite perspective, if you start asserting what that inventory is, and you actually have a portable mechanism that actually describes what that inventory is and you put it through your pipeline,now developers can have control over what that inventory is. So if they've actually made that modification to that thing, they can actually describe that modification to that thing who made it? what the modifications were ? what components it was derived from? so you have a much more accurate representation of reality.

And if there's any kind of corrections that need to be made as well, you can add those as well. But you also when you have that inventory that is portable now, which is really what SBOM or Software Bill Of Materials is really about. It's a portable way to describe your inventory and your and, and who you got things from. But when you have an SBOM in your software supply chain, now you can, you can start adding more full stack things. If I'm producing a Docker container, well, I can describe the, the libraries and applications and OS packages and the operating system that is in that container.

If I am also distributing an IoT device or if I'm distributing a medical device , I can describe that entire stack and in many cases, if I'm describing an automobile, it's going to have multiple software stacks. I can describe all of them. So it tries to address, I guess, a much wider picture.

Once you actually start doing an inventory first approach rather than an inventory last approach, which is currently what most SCA tools do today.

Abhay - So one of the things that , of course, that you have been working on and I think, and I see a lot more traction to this that has happened over the last couple of years, because I've been following your work on GitHub and other forum is CycloneDX, right. So CycloneDX is your Software Bill of Material Standard that you've created and it's open source. It's available for people to use. Now, could you talk a little bit about CycloneDX; how it started, how it's going, what do you see as the future for that project? Because I think that for me is, let me explain where I'm coming from on this, because the way I see it, a lot of people, it seems extremely important as I listened to you now and as I talk about it with clients and you know, people who I train, but a lot of people don't understand this concept. 

So what is this meant to solve? And what did you want to do with it when you started off? how is it going and where do you see this going? So that's my next question. 

Steve - I think a lot of the projects that I'm involved with whether it's CycloneDX or like Dependency- Track or whatever. I think a lot of the projects that I'm involved with in this space is really kind of a reflection of frustration actually.  There were requirements that I've had since 2013 that the industry hasn't actually addressed. We would call that a market failure. Most people weren't asking for these things, therefore the market wasn't creating them. It's one of the reasons why some of the work that Allan Friedman from the National Telecommunications and Infrastructure Administration is looking at Software Bill Of Materials, it's the reason why that group exists. But a lot of the work that I've been doing over the last decade has really been driven out of, out of that.

I have these basic requirements and there weren't any commercial solutions to address them. But I think to answer your question about CycloneDX specifically , CycloneDX started in 2017 and it started as a, just a very simple way to describe what Inventory I had and what type of Inventory it was. Was it an application? Was it a library? Was it a framework? Library versus Framework. Actually it has... that's important information. It goes to , you know, whether or not something is, is highly coupled versus, you know, loosely. So, there's some interesting things that you can do with making that distinction, but you have other types of components as well.

But it was really just a way to, from a security first perspective, describe that Inventory. There wasn't really anything in existence at the time. There was a.. the only thing that remotely came close was SPDX from the Linux foundation, but security wasn't really in their vocabulary. They were primarily focused on license and intellectual property use cases.

So when you're looking at security, security is typically how you get in the door of a lot of organizations. And once you're in that door, you know, license and all these other types of use cases, you know, try to, clamor on. But I went first and foremost with a security first approach, and I went with an approach that was very , I guess , aligned with a lot of the automation that everyone in our space is doing right. So that, that meant instead of having the object model that was ideal, it meant having an object model that was ideal for automation, right. And you'll see some architectural decisions in CycloneDX that, you know, it has a very simple model just because we want it to be modifiable and correctable throughout your .. throughout your, your build pipeline.

But CycloneDX started in 2017. It's had a couple of different revisions since then. We're currently up on version 1.2. We are planning 1.3. And we're also going to be launching some really interesting initiatives beginning in February, I think. So the project is growing.

It is now more popular than the thing it was originally created for, which was the original purpose. I just didn't know if it was going to be successful or not, but it was originally created for  OWASP Dependency-Track, but now it's, it's supported by multiple commercial vendors. It's supported by, you know, a lot of different security tools, starting to be supported by CMDB and more traditional IT types of systems.

And it's been referenced in a lot of different types of articles regarding Software Bill Of Materials. It's one of two viable, in my opinion, two viable standards that exist today for Software Bill Of Materials, CycloneDX being the only one with a security first approach.

Abhay - One of the things with you, with CycloneDX is that it's gotten a lot of traction with GitHub actions and I see a lot of folks who've written integrations for GitHub actions. That's always heartening to see. So I definitely encourage people to check out CycloneDX. I like it a lot because I think it standardizes a lot of disparate pieces of information. One of the things that I want, this is kind of segwaying into my next question to you. One of the things that I've always seen with Software Bill of Materials or , you know, subsequently with Source Composition Analysis is that the Package Manager plays a big role. The Package Manager of the local build system, you known, Maven,

a CheeseShop, NPM, whatever, right. And some of them get it right. For instance, NPM gets it righter than others. I'm not saying it's perfect, but I'm sure compared to maybe the Python ecosystem, I think NPM is head and shoulders above. But what I, what I want to know from you is how important is the Packaging or the Packaging Ecosystem of a language or that, you know, are on, on a particular framework or a set of frameworks so to speak, how important is that? How is it something that is, Hey, you know what, there are ways around this and we can still solve this or is the Package Manager a 60- 70% influencing factor in the way we do or the quality of the inventory that we have as part of our supply chain.

Steve - Yeah... that's... that's also a really interesting question. And it sounds like you've had some experience with some inaccuracies in some inventory, which can be true for sure. But Package Managers play a very role in not just producing accurate Software Bill of Materials, but in, in the wider supply chain conversation as a whole.

And I'll talk about that in just a moment, but you know, if you want to know with certainty, what component, what inventory you have starting with a Package Manager allows you to go from 0 to 80%, really, really, really fast with minimal effort. So that is going to give you the biggest bang for your buck is just starting with a Package Manager.

If you're dealing with , you know, if you're working on ecosystems like C, C++ that typically haven't used Package Managers, guess what? There's Package Managers that have been there for the past decade, there's multiple Package Managers for, for those things , for those languages.

So , you know, I am really encouraging others to adopt them. In terms of Package Managers outside of just the whole SBOM thing, Package Managers typically also use repositories and I'm not talking about the, the decentralized ones, like Go and that sort of thing, which is a conversation in and of itself, but having a centralized repository is a very good thing for security. In fact, I will not use any ecosystem that doesn't have a centralized repository. It's ludicrous to even think that. If you think about, you know, buying pharmaceuticals or buying food , we always know where food or where that specific drug came from in the event that something happened in the manufacturing process that tainted, whatever that was so that we can recall it, right. We don't want people to get sick. We don't want people to die. So we actually recall those things from our software supply or from our, from our, from our physical supply chains; not having that centralized repository that most Package Managers also rely on , gives that not having that prohibits us in, in many cases from recalling software components, from our software supply chain, which means that others are potentially going to use this years and years and years down the road, even though we've known for the past couple of years, that this thing is bad, it should have been pulled from the shelves, but because there's no central repository, we can't do it.

So, good luck everyone. So having not only the Package Manager but that centralized or Package Repository in my opinion is really important. I know there's a lot of negative things that come with a centralized repository. You know, there's things for governance , you know, many commercial entities end up supporting it. So there's possibly conflicts there. You know, and there's all kinds of other kinds of motivating factors but I, I think that the benefits of having that kind of ecosystem far outweigh the cons of, of not having that, right. I want the ability to have components recalled so that, you know, no future projects ever use them again.

Abhay - Yeah. So my next question is going to be around the future, right? So one of the things that scares me constantly, and I keep looking at this, for instance, one of them, I do a lot of serverless coding. I do a lot of Lambda stuff.

We have layers, you have new ways of introducing code into your Lambdas. You have new ways of extending them. The cloud native world has kind of taken the supply chain to levels that you may not have imagined when you first got into the industry. We're looking at Kubernetes. We're looking at the clouds. We're looking at not just one cloud, right.

We have multiple clouds. We have their own sets of disparate ecosystems, their own deployment patterns. What do you make of this? And I mean, do you think we are first of all, what do you make of this? And second thing is, do you think we're coming to some sort of a way to address this because I see a lot of gaps, right.

For instance, in the Kubernetes world, I don't see very many unified products or unified solutions to address this. Neither do I see that in the cloud world itself, right, when you are directly on the public cloud, I don't see it. Do you see, first of all, is your experience different and where do you think this is going?

I mean, are we dealing with a much more complex supply chain, which are not yet well addressed or are we dealing with yes, we are dealing with complex supply chains, but there is definitely a lot of good stuff that's happening, etc. So what are your thoughts on the future?

Steve - Yeah.. so like I guess one of the things that the SCA products in general can't address that a SBOM can, is  APIs, right. What are the APIs that are also components? It's just they're, they're serialized differently. What are the third-party APIs that my application relies on? Because that should be part of my inventory as well, as well as, you know, what kind of data classifications are going back and forth on those APIs? Is authentication required as across the trust boundary.

All that kind of information can be described today in Software Build Of Materials, specifically CycloneDX. So I think, I think there is some room there for a little bit of growth for the SBOM use case, but SBOMs are, are really used to describe the inventory of that thing.

 It's, you know, it's not necessarily designed to solve all security problems but it does do a good job in the inventory regarding like the, the overall stack of stack of stack thing that we are going down , you know, I think there's going to be , you know, I think Software Supply Chain, just because it's constantly in the news every other month, somebody gets popped.

You know, I think there's going to eventually come a point where some of these tools start baking in a lot of security things into the tools themselves ; build tools, for example, that produce SBOM and build tools that describe, well, this, this... this component actually talks to these other things.

Did you know it actually talked to those other things because these are the things that it actually talks to. So I think you're going to start seeing some, some integration to provide some of that visibility for security guys, but, you know, I think we're, we're as always, we're going to be playing catch up to what the.. in the cloud native industry is doing, which is, which is truly unfortunate.

But as we keep on going in that direction, we still have, you know, the, in my opinion, the, the, the growth industry is really about embedded devices, right. And they're connected to all these things, these, these multi-stack cloud native things that you're describing. We have just a bunch of smaller devices and whether that is embedded implantable medical devices inside of people, whether that's the 30 or so computers that are in your car, or, you know, that are controlling stoplights . I think the amount of devices that communicate with this multi-stack world is also , you know, going to continue to escalate and  we actually have a lot of solutions today to address things like the Inventory and Software Supply Chain things for those.

Unfortunately, a lot of those smaller, embedded things, still rely on a lot of bad practices. A lot of legacy development type of methodologies, C and C ++ without any kind of Package Managers , modified, you know, libraries without necessarily any kind of providence or pedigree in terms of what it is that those components are and where they were derived from.

So there's a lot of maturity in the embedded space that I think needs to happen. But I think, you know, I think it's going to be really interesting because on one side you've got all these smaller devices and the explosion of those on the other side, you've got all the cloud things that are escalating to support all this, these smaller devices and security guys are, are kind of in the middle trying not to get squished. But I think, you know, because it's, everything is constantly in the news. There's been a lot of efforts  more collaboratively between organizations to start sharing things. There's a big movement for software transparency.

For example, that's led by Allan Friedman from the National Telecommunications and Infrastructure Administration. It's ..It's part of the US Department of Commerce. It's a multi-stakeholder thing. It's a multi-country thing. There's folks from Japan and Australia and various parts of Europe and elsewhere that are participating in these, in these efforts.

But there's other efforts going on as well, especially sector specific efforts like healthcare and energy and, and all these other types of verticals. So I think there's going to be a continuation of collaboration knowing that a vendor or vendors are not capable of actually solving this problem.

It really takes, it really takes people. It takes collaboration to make any kind of, kind of improvement. So I think we're going to see , we're going to see a lot of more of these, these cross-functional collaborative efforts going forward as well. That would be my hope anyway.

Abhay - Coming in, slightly changing gears a little bit. I want to talk about the vulnerability. Now, we've spoken about SBOM, we've spoken about Inventory a bit. When it comes to vulnerabilities itself, right. So, a lot of us today say, at least I'm saying this kind of distribution of databases, especially when it comes to vulnerabilities, right. We have the CBE. Then we have Rust that's maintaining its own database and is always maintaining its own dataset. Where do you see this going because we are adding a lot of languages as well. Every two months there seems to be something new. Out there that is Elixir. There's v lang. There is Nim. I mean I don't even need to tell you that the language ecosystem is expanding as the needs for specialized development expand as well. What do you see, first of all, what are your thoughts on the centralization and how good the centralization of vulnerability databases are today and where do you see it going? Where do you think we're headed towards in the near and long-term future? 

Steve - Yeah, that is also a really interesting question. You know, so the, the NVD, the National Vulnerability Database , hasn't been able to keep up with the volume of vulnerabilities in a very long time. There's also a lot of inaccuracies in all their data. So I can't tell you the number of times that I've found inaccuracies in their data and, you know, you just send an email to them and they'll correct it. It. But the NVD was created in a completely different time, right. I mean the early CVEs are from the late nineties. And it , you know, that was a completely different era that was before the, you know, the, the, the open source thing kind of exploded.

That was obviously way before the cloud and all that sort of thing was ever a thing. So , you know, as a result, a lot of their processes that are used to identify what software is, isn't inherently flawed. It doesn't actually scale and it doesn't meet the needs of open source today, let alone in the future.

So the NVD, for example relies on this, this, this thing called a CPE or Common Platform Enumeration. It's a way to describe what it is, who the vendor is? Who the.. who the.. what the name of the application is and what the version of that application is? And there's some other things you can do in there as well, but those are the three primarily fields that actually

are all human created fields. So none of those fields are actually created through automation. I like to use JBoss as a really good example. JBoss for the Java or from the non-Java folks is a bunch of libraries and, and server-type functionality in the Java ecosystem. The project identifies itself as org.jboss and then whatever the component name is. In the NVD, it's identified as the vendor being red hat.

So if you're relying on automation, guess what? There's three fields and all three fields are going to be inaccurate for most JBoss components. You can't scale vulnerabilities , identification if, if the system that you're relying on does not use the naming conventions that are native to that particular ecosystem.

So CPE was a way to originally describe , you know, like I said, a vendor-named version of mostly commercial software. And I think it's still viable in many cases to be used that way, although they are looking to change over to SWID or Software ID tags . We're still kind of at the, at the community,

we're still waiting for what should have been announced last year, but they're still trying to figure it out. But I think, because they're, they're still not focusing on how components are actually named in the real world. That's kind of your clue that the relevance of the NVD is going to continue to diminish over time.

I predict that , you know, I think in order for you to have an accurate and scalable Vulnerability Intelligence System or platform, you actually have to describe components in however native ecosystems , you know, whatever the native ecosystem that the component is from.

So if you're describing Maven , you should be able to describe, you know, be a coordinate or via Package URL, for example having, you know, a Maven component be represented as a CPE, it just doesn't make sense because those projects don't use CPE. So now you actually have to have a human being in there to actually make that correlation.

It's just not sustainable. So I think you're going to see the continued erosion of the NVD in terms of its relevance going forward and I think Decentralized Vulnerability Intelligence is going to be the new norm. It's not going to be a norm that many security people want to see happen, but I think it's inevitable.

You have GitHub advisories, you've got friends of PHP. You've got, you know, the stuff that OSS Index from Sonatype is doing. You've got commercial sources, like risk-based security. You've got a lot of really good sources of vulnerability intelligence, and many of these sources have a lot of vulnerabilities that are not in the NVD today.

So, you know, I would beg the question if you're not looking at commercial vulnerabilities in commercial software and you're using just for open source things, the NVD probably shouldn't be your first choice.

Abhay - So I just  thought, we'll have one last question from you and before we head out. So, of course, we're filming this in the new year, 2021 and the last year has obviously been eventful for all of us, all of us on the planet. What are you looking forward to in 2021? What are you doing? What are your next big things that you are going for in 2021? And what are you planning to do? What can we expect from you this year?

Steve - Well, you know, in my, in my open source life I, I'm doing some, some really interesting things. You know, there's some things that I'm working for Dependency- Track that that's going to be exciting.  I'm, I'm experimenting  with a bunch of things that, you know , approaches to solving problems that have never been done before.

Much like version 3.x of the Dependency-Track was one big experiment, you know, can SBOM be both complementary and competitive to SCA tools? The answer was yes and yes. There's a lot of things in Dependency-Track version the 4.x series that are also kind of going to be experimental

right. Because nobody's done this before. So I'm looking forward to that kind of research project and putting that out into the marketplace and just, you know, measuring the results, right. Getting the feedback. I think that's going to be really interesting. The CycloneDX project, there's going to be some really awesome things that we're going to be announcing here shortly and you know, into this year that's really going to be interesting. I think you're going to see a lot more about, I mean, already, we've kind of, you know, the adoption has just exploded. It's like I said, it's more popular than the project that was originally created for. It's absolutely fantastic.

It's, you know, truly a blessing to have something that you've created with a very specific purpose being used for all different kinds of things, especially like these safety, critical life saving things that you just never envisioned , you know, something being used for. So it's kind of humbling to see that.

But, you know, we're going to be doing some really interesting things with CycloneDX this year that I'm really looking forward to. But you know, this is a new year and I'm really looking forward to you know, once the snow melts, I'm going outside and playing with my daughter some more . We didn't go to any kind of parks last year because of COVID. So we moved into a new place. So  I'm really looking forward to a kind of, I guess, a new way of life this year. Hopefully, it's a kind of a renewed start for a lot of things. So , you know, those are the things that I'm looking forward to. 

Abhay - Absolutely. I think most of those sentiments are echoed by all of us.

Absolutely makes a lot of sense because, yeah, this year has been pretty hard on all of us, all of us being at home. So, yeah, I mean, I think one of the things that, of course , I've always been a big fan of your work, so I'm going to be tracking your stuff very closely. And I think folks listening in or watching this will also be interested and I hope they take to Software Bill of Materials and Dependency Analysis with Dependency-Track. And, those of you are interested, both of these are open source projects. Feel free to contribute to that or the Software Component Verification Standard drive that Steve and team are part of  it, OWASP as well. 

With that, we come to the end of this podcast.

Thank you so much for your time, Steve. It was, I think it was an illuminating session at least for me. And I think for a lot of people who're going to be watching this as well once it's up. Thanks so much. 

Steve - Oh! It's a pleasure Abhay