Application Security Podcast

Patrick Dwyer -- CycloneDX and SBOMs

May 3, 2022

Show Notes

Patrick is a Senior Product Security Engineer in the Application Security team at ServiceNow. He is also Co-Leader of the OWASP CycloneDX project. A lightweight Software Bill of Materials (SBOM) standard designed for use in application security contexts and supply chain component analysis.

Patrick joins us to help us understand how CycloneDX fits into the world of protecting your software supply chain. He explains why they started the project, its depth and breadth, how many people are using it, and what is the future for CycloneDX and software supply chain. If you want to understand how to build SBOMs into the applications and products you're building today...enjoy this conversation with Patrick Dwyer.



software, security, dependency, component, sca, supply chain, tooling, vulnerability, project, people, tool, cyclone, problem, run, application, build, patrick, bit, code, support


Chris Romeo, Tiara Sanders, Patrick Dwyer

Chris Romeo  00:00

Patrick Dwyer is a senior product security engineer in the application security team at ServiceNow. He is also co-leader of the OWASP CycloneDX project, a lightweight software bill of material standard designed for use in application security contexts and supply chain component analysis. Patrick joins us to help us understand how CycloneDX fits into the world of protecting your software supply chain. He explains why they started the project, and what is the depth and breadth of it, how many people are using it? And what is the future for CycloneDX and software supply chain. If you want to gain an understanding for how you can apply SBOM into the applications and products that you're building today, check out this interview with Patrick Dwyer.

Tiara Sanders  00:49

You're about to listen to AppSec podcast. When you're done with this, be sure to check out our other show, Hi/5.  

Chris Romeo  00:59

Hey, folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey. Today, I am flying solo because Robert is traveling this great United States that we both live in. Today we're going to talk about SBOMs. But we're going to talk about SBOMs in the context of an OWASP project called CycloneDX. I'm joined by Patrick Dwyer, one of the team members on the CycloneDX project. Before we get to that, we're going to ask Patrick about your security origin story because our listeners sit on the edge of their seats waiting to understand where people are coming from in this great big world of application security. Patrick, I'd love to hear your security origin story.

Patrick Dwyer  01:51

Hey, Chris. Thanks for having me. It started when I was a child; I started getting into computers and messing around with them. Probably one of the key moments was in high school; my computer teacher at the time thought his stuff was secure. He made a joke; you can't hack the server, give it a go; there's nothing you can do. By the following day, the server was offline. He wasn't too happy about it and threatened the entire class with expulsion. I put my hand up and said, Hey, no, it was me, it was just me, but you said give it a go. He stopped right there. After that, we had a great relationship and a lot of respect for each other. It started making me think with that mindset of where things can go wrong. That continued throughout my career. I started as basically a one-man IT department for a small company, set to look after everything, network security servers, all that stuff. I became a software developer by contract. I was doing odd three months, six months, multi-year projects, things like that. That was more come in and cut some code. My next job, I was leading the Dev team for a small government organization and had a lot of stuff we were looking after. That included our cloud environment, basically everything from where to go. At that point, I was like, Oh, the stuff that I've been interested in all this time, I need to get up to speed on it. I'm now responsible for this stuff, and if it gets popped, it's my fault or my problem. That's where I got into AppSec.

Chris Romeo  04:04

Very cool. I'm curious was your handle in high school, Little Bobby Tables?

Patrick Dwyer  04:12

No, it wasn't that.

Chris Romeo  04:15

Everybody's got to have seen that XKCD, we'll put the link in the show. It's a classic one too. I still laugh whenever I see that. Someone will kick it out on social media every six months or so, bring it back into the forefront. You started in IT, did some development, and then made your way to security. You had a chance to experience a little bit of everything. From the IT side, I'm guessing you were doing some administration and then you're coding and then you're making your transition into security. So having that strong foundation of the things that you're going to be discussing with people from a security perspective, you've got some some background and all those things.

Patrick Dwyer  05:02

Yeah, pretty good breadth of knowledge. It's been quite good.

Chris Romeo  05:09

I want to transition into talking about CycloneDX. But I'm gonna ask a really simple question first, because I'm not going to assume that our audience all knows what a cyclone DX even is or what it is. I'm going to go really simple with the first question and just say, can you give us some details and some explanation about what is CycloneDX.

Patrick Dwyer  05:31

CycloneDX is a bill of materials standard, and associated tooling. The way we build software has changed. We grabb all these third-party components and bundle them into our software. The traditional IT asset management of these are the applications we have doesn't really go deep enough anymore, because we've got all these other third-party components in them. It's just a way of understanding what's inside the box, a bit like the food label that lists the ingredients of what goes into your food. It's a pretty basic analogy. We don't build software, the way we put together food, but it's similar to that.

Chris Romeo  06:17

Okay. Where did the name come from then of CycloneDX like it? It's an interesting name, one of the most interesting names in all the OWASP projects, I mean, you've got top 10, ASVS, you got things like that, but CycloneDX sounds like a pretty powerful name.

Patrick Dwyer  06:36

The cyclone part of it is a reference to circular dependencies, and the problems that it can cause you when you're building software. The DX part is bit of a nod to another format called SPDX.

Chris Romeo  06:53

It's like a hybrid, or SPDX and CycloneDX are not the same standard? Are they different?

Patrick Dwyer  07:02

No they're different.

Chris Romeo  07:03

They're different in some ways? We've got two competing standards in SBOM right now, or is there more than two? Or are there more that I'm not aware of?

Patrick Dwyer  07:13

There's certainly more than two formats, but there's two main ones. I've seen sort of widespread adoption. SPDX traditionally has come at it from the Arkansas software license compliance perspective, or a cycle index come in from the security perspective.

Chris Romeo  07:33

Okay. What was the need when this project was started? Why did cyclone DX come into existence?

Patrick Dwyer  07:45

There's a guy Steve Springett, who had a project called dependency track. He was trying to come at the same problems that you use SCA for but in a slightly different way. SCA tools traditionally they're about identifying risk in software. They look at evidence and things like that to try and figure out what could be in there and what vulnerabilities could be in there. If you're building software, you should know what is going into it. He was tackling it from the, all right, well, these are the actual components we've got in our software, and we'll go from there. At the time, there wasn't anything useful for feeding that information into a tool like dependency track. He started the dependency tracks stage and then realized, Now hang on, we need a bill of materials format to collect this information and feed in.

Chris Romeo  08:47

When I think about all these pieces working together, this has really got my brain spinning around a little bit. I have software composition analysis; this is a tool that I can run in a build pipeline; it tells me and even sometimes breaks the build if there's some type of high-risk vulnerability that exists inside of my application. I have CycloneDX, which is going to create a software bill of materials and then perhaps be imported into some other system that's going to aggregate all those things together for me. I guess the million-dollar question is, is CycloneDX a replacement for SCA, or is it complementary to SCA in some way?

Patrick Dwyer  09:35

I think it's complimentary. It's particularly useful because it's a standard format. You can generate them for different ecosystems, but different package ecosystems should share that information between different tools and automation. That's really where the value comes from, where you're sharing this information between different processes.

Chris Romeo  10:02

They have different functions then. I wouldn't use CycloneDX in a build pipeline then? Or would I use it?

Patrick Dwyer  10:07

You would. You create your bill of materials as part of the build process. Then you can do analysis on what's inside your software, similar to what ASI tools do, known vulnerabilities, things like that. But it gives you a much bigger picture of your supply chain. Do I still run my SCA tool in that same pipeline then? Or do I just run my CycloneDX?

Chris Romeo  10:21

Well, depends on what you want to do. There is potentially some duplication of effort, though, if I'm running both of them, or I guess they could be a check and balance to each other? Do they have multiple layers of tooling?

Patrick Dwyer  10:51

SCA tools generally are pretty good. But sometimes the accuracy of what the components are isn't quite 100%. There's certainly some value in doing both.

Chris Romeo  11:05

One of the things you hear people complaining about with software supply chain related tooling is like SCA tools are not as good at determining if you're using a piece of code, like, are you actually using a vulnerable piece of that library? SBOM is not going to help me from that perspective, though, right? It's not going to know, it's just a manifest of everything that's in there. It's not helping me laser focus, I don't really know if that piece of code is being called in a vulnerable way, for example.

Patrick Dwyer  11:37

There is some tooling there which generates a runtime bomb. What's the components that we're using? Like not just what's actually packaged in the software, but what's actually being invoked as well?

Chris Romeo  11:52

That's part of CycloneDX?

Patrick Dwyer  11:55

That's a third-party product that uses CycloneDX format.

Chris Romeo  12:00

It uses CycloneDX format to get to that level. It still relies on the standard format that the OWASP project has put forth to the industry?  

Patrick Dwyer  12:10


Chris Romeo  12:11

Okay, cool. Let's back up for a second; I probably got too excited about CycloneDX and dove in too quickly here; let's pull back up to the 10,000-foot view. Everybody's thinking about the software supply chain, whether you're a CISO, whether you're an AppSec person, or even just a developer who maybe doesn't have security in their title, or security is their primary focus. I feel like everybody's heard about the news stories about SolarWinds, CodeCov, and all the things, it seems like there's an NPM supply chain-related issue once every week now that hits the news. I feel like people know about it; they're hearing about it. I'm just curious to get your take on what is the value that CycloneDX provides to the bigger software supply chain problem?

Patrick Dwyer  13:06

I see it as an enabler. By itself, it doesn't do very much. Really what we're talking about is asset inventory. But if you've got that across your software portfolio, that lets you do some pretty cool stuff, especially at the organization level. When there's a big vulnerability comes out, it's a case of, are we affected by this somewhere, having that accurate asset inventory across your entire fleet of servers, your cloud environment, being able to quickly go, oh, yeah, we've got this component, and it's sitting on this app service in Azua, or maybe it's on this server on-prem. The things that software, some people do continuous delivery, but most people don't do it. You'll have; here's the state of the software in our source code repository; the current build says everything's cool. But we haven't deployed that yet; we're running an older version of that component in production.

Chris Romeo  14:13

I'm also seeing the value then of retrieving SBOMs in the CycloneDX format from the companies you're working with and the services that are being provided to you as well. When you think about a big vulnerability that hits the internet, Security Journey, we provide our platform to our customers. We'll get a bunch of emails from people going; hey, are you using this particular library? There'll be a list of them, and we have a canned response because normally, we're not using whatever library was in question there. If you have an SBOM in the CycloneDX format, if I export that and provide that to you as a component of delivering my service, you can ingest that into your management system. You don't even have to ask me; you're just doing a query of wherever you're ingesting all the information to be able to say, Oh, I know that Security Journey, for example, doesn't use that component. Because the SBOMs have been searched, or the assets that are coming out of it.

Patrick Dwyer  15:17

Yeah, there are a number of good use cases in that respect in terms of sharing between supplier and consumer, especially open-source software; often, companies might do an internal fork. That component might appear to be an old, outdated component, but they could be backporting security fixes for it, things like that. Being able to say to your consumer, hey, we use this component, but we applied the security patch to remediate this vulnerability. Or it could be a case of, yes, we do use this vulnerable component, but we don't call the method that's vulnerable. The vulnerability exists, but don't freak out; it's not exploitable. You can communicate all that information.

Chris Romeo  16:07

What are people using to collect all that? Where are they putting the output of all these SBOMs? Is there like a management system? Are they building custom tooling to import all of the CycloneDX SBOMs from all of my apps? Do they build like a custom dashboard? Is there like an open source project that lets me wrap all this stuff together?

Patrick Dwyer  16:32

OWASP dependency track project is probably the leading SBOM platform out there. There's a bunch of different security vendors that are integrating this capability in their product.

Chris Romeo  16:50

Dependency track, which we've had Steve Springett on before to talk about the project and where it came from. It ingests those the output of CycloneDX running for my JavaScript app, for example, and my Python app, and it ingests all that together, and then lets me do queries and search for certain things then across my whole fleet.

Patrick Dwyer  17:14

It also lets you export it. If we're talking about that vulnerability assessment workflow where all right, we've got a vulnerable component, is it exploitable or not? Dependency tracking then generate output to give to your consumers. As to the outcome of that, and whether, yes, we are exploitable or no, we're not.

Chris Romeo  17:35

Very cool. I'm always so thankful when I think about projects like dependency track and the CycloneDX work that's been done here because you look in the industry, and people are starting companies than selling products that are doing the same things that folks such as yourself are just sacrificing and putting your time and effort into making these things available. I'm always so impressed with folks like yourself and Steve that are operating behind the scenes, you're doing all this stuff, and you're making these things available just to make the world a more secure place. I wish I could say thank you on behalf of the whole community; I'm going to do it anyway; thank you on behalf of the whole community for doing stuff like that, because I know I haven't experienced it, but I just have an idea how much time actually goes on behind the scenes in making this happen. It's not an hour per week, folks; these guys are spending a lot more time to make these things possible and make the world a more secure place. It's a really awesome thing that y'all are doing.  

Patrick Dwyer  18:40


Chris Romeo  18:43

How did you get involved with this then? With the CycloneDX project?

Patrick Dwyer  18:48

It was the job where I became Dev lead at an organization, and I was freaking out a bit because I had a look, and we had a lot of different custom-developed apps and services and integrations, and no visibility across all of those things of the state of them. I went looking for solutions to this problem; I came across dependency track; I thought, Oh, this looks exactly like what I need. Then, of course, you feed it was cyclone dx. Then started using CycloneDX myself. There were a couple of features missing that I wanted. I contributed to them and kept contributing because I'd recently gone from a development heavy role to a role where I wasn't on the tools anymore. It was a bit of a fun thing to do in the evenings to stay sharp coding and went from there.  

Chris Romeo  19:52

Very cool. I mentioned towards the top of our conversation that I forgot to CycloneDX because I was trying to generate some SBOMs, I got into it, and I was like, wow, there's support for a lot of different frameworks and libraries and things here. Tell us about the depth and breadth of this CycloneDX tool, like the tooling that goes behind it, like what languages are we supporting? How wide is this thing?

Patrick Dwyer  20:26

I can't even remember how many ecosystems we support. There's heaps like Go, .Net, Python, Java, Node, there's just yeah, pretty much any modern, popular, INBAR ecosystem is supported. There is containers. Starting to see this stuff be integrated into the native tooling. Docker is now shipping a command that'll build an SBOM for the Docker images. Go has got good, inbuilt metadata capture that enables an accurate SBOM. It's pretty interesting.

Chris Romeo  21:20

When I picked it up, I used the node, Go, Java, and Ruby versions, and I was impressed because I'm like, There's support for all these different things like all these modern frameworks and stuff have support in this tool. Any idea how many people use CycloneDX today?

Patrick Dwyer  21:43

We've estimated at over 100,000 organizations. That's based on downloads of the different implementations, the different Docker images, things like dependency track because that takes CycloneDX, if you're using dependency track, you'd be using CycloneDX. It is a bit hard to estimate, because we're an open-source project, we don't have a customer list or anything like that. That's a reasonably conservative estimate.

Chris Romeo  22:19

Wow. It's having a big impact across the industry then. That's a lot of organizations that are using this. We know, at the end of the day, adoption of SBOM is the answer that we've been working towards. From a vulnerability management perspective, from dependency, tracking, management, and vulnerabilities from that side, it is ultimately the answer. People need to be incorporating it into whatever they're doing.

Patrick Dwyer  22:49

It's been quite interesting. There's been a lot of work in the US federal government making this happen, executive order a little while ago. There's a lot of interest around the world. I'm from Australia. The Australian Cybersecurity Center recently added it to their ISMS. It's something which I thought was a bit of a niche thing is really widespread now.

Chris Romeo  23:20

That's great to hear. What do you see as what's next for CycloneDX? Do you have a roadmap that you're working from and you're trying to, you've got future releases and stuff? Or what is the future of CycloneDX?

Patrick Dwyer  23:38

The two main features that we would be working on for the next release will be support for AI, machine learning, and low code platforms. We've got an industry working group, so we meet with them, talk about the challenges that different folks are having in different spaces, and use that to help prioritize what we do next.

Chris Romeo  24:04

You're somebody who's paying a lot of attention to the software supply chain. How long is it going to take us to get to the point where we get this under control?

Patrick Dwyer  24:19

That's a hard question. Because if you have a look at any of this stuff, a lot of it is inherently broken. It's easy to shoot yourself in the foot. I think it could take quite a while.  

Chris Romeo  24:35

You think a decade? Are we that far away from solving this problem? I hate to declare that and then it'll end up coming true and people say he's the person that set us off on the wrong path here.

Patrick Dwyer  24:47

I don't think it'll be that long. It's not gonna happen overnight.

Chris Romeo  24:56

Less than 10 years though, we should have this thing under control and I don't know, they've been saying we're going to solve SQL injection for 20 plus years at this point, and somehow, it's still out there.

Patrick Dwyer  25:07

Yeah, I think it'll be better. I don't think it'll necessarily be gone.

Chris Romeo  25:12

As the tooling continues to improve and the solutions for managing these things, people that are serious about it, will adopt it. At least you'll have more differentiation between those who are taking it seriously and those who are not doing anything to manage their dependencies and stuff they have. If somebody's listening here, and let's say they're a developer, they're a Python developer. That's what they spend their day working on, and they're wondering how to get started? What would you recommend for somebody who's hearing this? They're like, this CycloneDX thing sounds awesome. I want to use it; I want to learn about it. What advice would you give them here as somebody close to the project?

Patrick Dwyer  25:57

Pretty simple. Pick a project that you're working on and download the tool for that ecosystem and generate an SBOM. Spin up a local instance of dependency track that runs in Docker, so it's really easy to just quickly run and try out. Load your BOM in there and have a look at what's in there; you might be surprised, maybe less surprised, if it is an ecosystem like NPM, where you're expecting to have a bazillion dependencies come in, even though you've only got a couple of direct dependencies.

Chris Romeo  26:29

The NPM, like but wait, I only added three packages; how can I have 25,000 dependencies? How is that possible? We're only partially joking. That level of dependencies that get unlocked, depending on what packages you add, and it starts, the cyclone I get that now. It's circular, continues almost forever and ever too. Give us a single call to action here and a single key takeaway, something that you want to leave with our audience here.

Patrick Dwyer  27:04

Start looking at the dependencies you are using. Even if you don't use CycloneDX, start looking at what you're shipping in your software. Because it might be a third-party component, but it's become part of your software that you're responsible for. They have to pay attention to all of it, you can't ignore what is often the majority of your code.

Chris Romeo  27:29

That's great advice and is a great place to end this conversation as people need to get out and start looking at those dependencies. Patrick, once again, thanks to you for all that you do behind the scenes here to make CycloneDX. Once again, I used it; all the efforts that you all put into this, I had a chance to use it firsthand in the last couple of weeks, and I was impressed with how it works and how clean it was to interact with. Thanks for sharing the knowledge about this thing, and I am hoping that a lot of our listeners will go check out CycloneDX and put it into use. You'll find it at the place where you get all your good OWASP stuff.  

Patrick Dwyer  28:07

Thanks, Chris.  

Chris Romeo  28:09

Thanks for listening to the application security podcast. You'll find the show on Twitter @AppSecPodcast and on the web at You can also find Chris on Twitter @edgeroute and Robert @RobertHurlbut. Remember, with application security; there are many paths but only one destination.

Need more information about Security Journey? Get in touch.

Ready to start your journey?

Book a Demo