Podcast
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Links
Follow Me
Follow Me
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Navigating SBOMs at Scale: Inside DependencyTrack with Niklas Düster
Play On
15 JUL • 2025
41 mins
Share:
Niklas Düster got involved with Dependency Track the way many great open source stories begin: by trying to solve a problem at work. As a security engineer, he was drowning in vulnerability scan reports that didn’t scale. When he discovered Dependency Track and CycloneDX, he not only adopted them but began contributing, eventually becoming the project’s co-lead alongside Steve Springett.
In this conversation, Niklas walks us through how Dependency Track helps teams stay on top of their software bill of materials (SBOMs), enabling continuous visibility across thousands of components. We dig into real-world workflows, from uploading SBOMs in CI/CD pipelines to responding quickly during incidents like Log4Shell and how version 5 of the platform is evolving to support horizontal scaling, smarter suppression logic, and role-based access control.
He also breaks down how teams use VEX files to add context to vulnerabilities, why gating deployments can backfire, and how CEL-based policy conditions offer a more flexible way to manage findings. The goal isn’t just to scan for issues, but to track them intelligently across the full software lifecycle.
Underlying it all is a clear philosophy: prioritize usability, support real engineering workflows, and keep the system lean enough that newcomers can adopt it without needing a Kafka cluster. Niklas’s focus is on making open source tooling that actually works in production, not just in theory.
Transcript
Show/Hide Transcript
So DependencyTrack was the reason why we adopted SBOMs in the first place.
We didn't use it before.
Yeah.
But for us we basically used I think a Maven plugin back in the day or a PHP plugin.
So you were a Java shop?
Mostly, yeah, but also PHP, JavaScript, a little bit of everything.
Luckily there were plugins available for build managers or package managers at that time, so integrating that was quite easy to do for us.
So we ended up generating SBOMs for every single build, upload them to DependencyTrack and then went from there.
Basically it was quite straightforward.
Welcome back to another episode of Nerding Out with Viktor.
Today I'm joined by Niklas Düster.
Welcome to the show, Niklas.
Thank you.
Thank you so much for having me.
Very much.
So this is kind of like almost a part two to my episode with Steve Springett where we talked about all things cyclondx and all things SBOMs, really?
So this is kind of like almost a part two to my episode with Steve Springett where we talked about all things cyclondx and all things SBOMs, really?
And you are the maintainer of dependencytrack.
And let's maybe for those not familiar with yourself and DependencyTrack, let's start off with who's Niklas?
What should we know?
Okay, so hi, I'm Niklas.
I live in Germany.
I am German, of course.
I'm the co leader of the OWASP DependencyTrack project.
As Victor already teased at, I co lead this project together with Steve Springett, who is also the original creator of the project.
I'm also involved in the Cyclone DX project, which is a closely related effort in the OWASP Foundation.
I maintain the Go Library and the Go SBOM generator for that project.
In my day job I'm a contractor for a financial institution.
I mostly work with DependencyTrack there as well.
Before that I was a security engineer for a European payment service provider.
Did everything from AppSec to incident response, developer education, and so on and so forth.
When it comes to DependencyTrack itself.
Sorry, did I.
No, no, go ahead.
No, I was going to say.
Yeah, perfect.
Yeah.
So DependencyTrack itself, it's mainly an SBOM platform or a BOM platform, if you will.
You can upload sboms or any kinds of bills of materials.
DependencyTrack will analyze them for various types of risks, which of course includes vulnerabilities, but also license compliance, component age, whatever have you.
We can also generate sboms in certain cases or other artifacts like VEX files, VDR reports, whatever have you.
Yeah, but dependencytrack as a core is a BOM ingestion and analysis platform.
Very cool.
So we met in person.
It's About a month or so ago in Barcelona for the.
As part of the AppSec conference, where we had a T conference, the Transparency Exchange API.
And you were part of that, helping out, kind of shaping that out.
So it was really good to meet you in person there.
And that's kind of why I wanted to invite you on the show and do a deep dive on DependencyTrack, because I think there's a lot to uncover there.
But how did you get involved with DependencyTrack in the first place?
What led you down that path?
Oh, that's fun because I think it's the typical way that you get involved with open source projects.
Right.
I mentioned I was security engineer before the payment service company and were of course tasked with finding vulnerabilities in components that the company uses.
At the time we used dependency check.
So every single pipeline of our products ran this tool, it generated an HTML report and then we as the security team had to go to every single pipeline, look at that report, and then check for false positives, etc.
And at some point we just thought, this doesn't scale anymore.
And this was, I think, 2018.
So we did some research and then found the efforts of Steve Springett, who was just in the process of releasing or evolving DependencyTrack Publishing Cyclone DX as an alternative.
So we ended up adopting that.
And while were playing with the tool, implementing it in our pipelines, we noticed some things were missing.
We would like to have OpenID Connect, for example, so we didn't have to manage our own users all the time.
I end up implementing that, contributing it, I contributed more and more, and at some point Steve just said, hey, why don't you just join the project and help me out here?
Good stuff.
So obviously, having worn the security hats in companies before, you're no stranger to SBOMs.
Or were you actually using SBOMs at that point?
I mean, what did that security journey look like?
You said 2018.
That's kind of early days of SBOMs were there, like how that looked like back then.
So DependencyTrack was the reason why we adopted SBOMs in the first place.
We didn't use it before.
Yeah, but for us we basically used I think a Maven plugin back in the day or a PHP plugin.
So you were a Java shop?
Mostly, yeah, but also PHP, JavaScript, a little bit of everything.
Luckily there were plugins available for build managers or package managers at that time, so integrating that was quite easy to do for us.
So we ended up generating SBOMs for every single build, upload them to DependencyTrack and then went from there.
Basically it was quite straightforward.
And if I may add, that as well.
So one of the biggest successes that we had was during the time of log 4J where everyone was just scrambling around.
So one of my colleagues ended up finding the announcement of log 4J of the vulnerability essentially on Twitter before there was a CVE for it.
And while everyone else was kind of scrambling, hey, where do we use log4j?
We were just able to go to DependencyTrack, search for that library name, and at least for the projects that generated SBoMS at the time, were able to immediately find where it was used, fix it.
I mean, that's a success story, right?
That's exactly like, I think post Log4j and the likes off.
Right.
That was when a lot of companies realized like, holy shit, we have no idea what goes into our software stack.
Right?
Yeah.
And it goes back to like the use case for how people want SBoM.
That is usually one of the things where people like there is a sense of urgency because this is not the last time this will happen.
This was the wake up call.
But it will certainly happen again.
Maybe not in that same domain, but somewhere in your stack.
Right?
For sure, yes.
So DependencyTrack, great tool for analyzing an SBoM, essentially.
Talk me through kind of how people use DependencyTrack.
You mentioned in your example you used in a CI CD pipeline.
Is that the normal case where people basically upload SBOMs from their CI CD pipeline straight into DependencyTrack.
Is that the workflow usually you usually see?
Yeah, that's the most prominent workflow, I would say.
It's also the most straightforward to set up given you already have a CI CD infrastructure.
Right.
We also have seen shops that have or security teams that run separate pipelines where they basically pull in all the repositories their company has or iterate over their GitLab instance, whatever else, and then run a generic SBoM generation tool.
Right.
Like CDX Gen, for example, is one.
Other people might use Sift or Trivi and then upload those SBOMs in bulk, let's say every.
Every day, every week, whatever.
So that is another workflow we know of.
People who manually are upload sboms, for example, for mergers and acquisitions, if you buy a company, you may ask them, hey, like, what is your maturity?
Like, can you provide an S BOM for us?
We can analyze what you have.
So people end uploading SBOMs manually there?
Yeah, more like a one off operation than yes.
Most of the time, yes and yeah.
Interesting so let's walk me through, let's take a step further.
Further in that step.
Right.
So I've heard of companies in the financial sector, for instance, that heavily rely on DependencyTrack for vulnerability management.
They even integrate it in their deployment pipelines.
So not only do their CICD pipeline kind of send S pumps to DependencyTrack, but also they gate deployments based on the output of DependencyTrack.
Right.
And that opens up an interesting conversation because I'm curious about what your view on that is because there are.
Just because the predator track found the vulnerability today doesn't mean it wasn't there yesterday on the last deploy.
But all of a sudden now you're gating deployments.
How do you see kind of like, I guess the output being used and how to best leverage that to kind of gate against.
I mean, just because.
Halting the deployment process just because you found the vulnerability necessarily not the best approach.
So I'm curious but like what you see in terms of best practices, how to use these tools.
Okay, so first off, I would really not recommend to block like a deployment process just because a tool found something.
You can use that as a warning signal and you can probably have someone being notified about that to look into it.
But really as security team, if you block hotfix deployments, for example, people are going to hate you.
Like that is just straight up the reality.
So just please do not do it.
And of course, even tools or tools like DependencyTrack, they can have false positives, they can have bugs, sometimes it is again, I would not rely on those tools to block deployments.
Block CI builds, sure, do it if you want, but don't fail.
Yeah, yeah.
As soon as you can, like fail things.
Entering master, of course, or main.
The main branch.
Right.
But don't block deployments.
That, that would be my first recommendation.
I think the biggest value of DependencyTrack is really also in the name track.
You upload the SBoM you deploy and then while the application runs in your environment, DependencyTrack keeps reanalyzing that bom.
And if it finds something, you are being notified and then you can act on it.
That's really the main use case I would say for dependencytrack and that's also what I would recommend to do.
Right, okay, very good point.
Let's dive deeper into the pedestri track because I think I'm not the only one who.
When I first started using the pedest track, I was a bit confused by.
There's a lot of terminology.
It's a complex product.
Right.
There's no doubt to that it is.
Right.
It has a lot of terminology that may mean different to different people.
Right.
Like maybe I don't put you on spot, but like can you go over the building blocks of DependencyTrack.
How to best use it and set it up from zero, how you track projects, what are the best practices really?
Okay, so let's start with the building blocks.
The first major building block is your portfolio.
And the portfolio is just a collection of all your projects.
A project then is basically what you would describe in let's say an SBoM.
Right?
It's your application.
It could be a hardware piece, whatever have you, and then within that project you have components and this could be like your third party libraries, your first party libraries.
Again, whatever else.
Sorry, are components the same as components in an SBOM?
Or components are your top level component, so to speak in CycloneDX terminology.
And then.
Or like how does that matter?
Because that's the problem that we've had the same conversation in the TEA project.
Right?
Like what's the component?
Because there are.
So definition of what a component is, Right?
It is a very generic term to be fair.
Yes.
So how you map it to Cyclone DX is in Cyclone DX you have this metadata section, every bom and that metadata dot Component.
Top level component.
Yes, top level component.
That is basically what you would map to a project DependencyTrackDependencyTrack.
And then everything in the components array of a Cyclone DX bill of materials would then be your list of components.
Okay, now I'm with you.
Okay, A bit confusing, but yeah.
It kind of DependencyTrack evolved side by side with SiteGroundX.
So it's not like the standard already existed and we could implement it one to one.
DependencyTrack, right, yeah.
There's also this little wrinkle here where if you upload a bom to DependencyTrack, the name of your top level component is not automatically set as your project name.
Right.
Because you can create a project ahead of time and then upload a BOM to it.
Right.
And again people might want like human readable names in their projects.
Whereas in the SBOM it says Company X stats component.
Yeah, yeah.
So there's this part.
Yeah, but yeah, you have portfolio, list of projects and then within the project you have components.
Now every single component can have vulnerabilities.
They can have what we call internally policy violations.
So you can set up DependencyTrack, certain conditions for which we will then flag the component.
One example of a policy would be users copy left license or Uses non copyleft license.
If we detect that, we will flag something that is visible in the UI and that you can then take action on.
Yeah, I mentioned findings.
The vulnerability findings are there.
We track.
So we mirror vulnerability databases, we mirror the NVD, we mirror optionally GitHub advisories and OSV.
You can view all of these things in the UI and you can also backtrack.
So if you search for a CVE, you can look up, hey, which project or which component is affected by that CVE.
For most things there are multiple ways to arrive at the same conclusion, if you will.
Yeah, let's double down a little bit on licensing because that's a hot topic and B a complicated topic.
Right?
Because obviously you have the simple example of like this is Apache license.
Cool, that's easy.
But then we have far more complicated examples of license expressions, right, where you have multiple things how you built an engine around that.
Because what does copyleft mean when you have these really complicated expressions which might have custom licenses and whatnot as well?
How does that engine actually work behind the scenes?
Good question.
So the core engine really is quite simplistic.
So in SiteGroundX you can have an array of licenses and you can have, of course, license expressions.
The core engine of DependencyTrack mainly focuses on the license objects where the ID is known.
So the SPDX ID is known and we can flag based on that.
We do support expressions, but the expressions are then evaluated at runtime, basically.
So every time you check for a policy, we have to step through that expression and then check if your policy would be violated by the concluded license of that expression.
Okay, yeah.
Okay, yeah.
So because that's hard to know ahead of time, like do that calculation.
Right.
So you have to essentially do it on the.
At a calculator at runtime.
Interesting.
But it is definitely something that we want to improve on.
Right?
Because ideally you can click on every single license in that expression or even the conclude license would be displayed in the UI for you.
So you can make your.
Or no, sorry.
So the expression, sometimes you get the choice between multiple licenses, right?
Because it.
Or mit.
And really to make an informed decision about whether this is a problem for you, someone needs to step up and say, I want choosing Apache 2 or I'm choosing MIT or whatever.
Right.
Someone needs to make this decision.
This is something we want to.
Or matching your criteria that you're looking up for, like is it compatible with my expression?
Or my, my criteria.
Right, correct.
One of those two.
Right.
But yeah, it Gets a lot more complicated.
Right.
I think people are new to the SBOM world or are up for a world of pain when you start to realize how complicated this can get, right?
Oh yes.
Can get, yes.
And so you have this.
And I guess one obvious thing is, at least to me, is when you run this in production, you start chucking S boms.
Imagine you're a mid sized shop and you might deploy every day.
Like maybe you deploy multiple times a day for every single microservice.
You have a new SBOM every time you deploy.
Right.
That directory of SBOMs becomes very large very quickly.
How, if you're going to run queries against that and vulnerability checks against that, how have you solved a the scalability side of that?
Because that's the sheer data.
Like we could talk like gigabytes or terabytes of SBOMs.
Right.
And sifting through that is very expensive.
Talk me through the architectural decisions of how you scale DependencyTrack, really for the real world.
So there are two parts.
There's currently the major version 4 of DependencyTrack that most people use.
We are currently working on a version 5 that addresses some of these scalability issues that we identified.
But you mentioned microservices and deploy multiple times a day potentially.
One thing to Note first about DependencyTrack is DependencyTrack does not store the raw SBoM.
Dependency Check is a processing platform, which means it takes information out of the SBOM and then ingests or stores just this information in its database.
Even if you have like, let's say 1 gigabyte sbom file.
Right.
I hope you don't.
But if you have Depends guys, they do.
Oh my God.
Yeah.
Poor souls.
So even if you have a large SBOM like that, not all of this information might be relevant to DT or to DependencyTrack.
So we might end up just storing subsection or sub some of this information.
So you don't really acquire a huge amount of data even if you upload many sboms.
Yeah, because I guess you could deduplicate most of the data.
Right?
Yeah, that's also another point.
Like the quality of some SBOMs is really all over the place.
Some are just broken.
If you just insert them into your database and make them searchable like this, people will have a very bad experience finding stuff.
But yeah, it's mostly just a database, a relational database.
Behind the scenes components have their own table, projects have their own table, obviously vulnerabilities, etc.
And this really works quite well.
The biggest bottleneck that we had in version 4 is mostly around processing of things.
So if you upload a large SBoM that needs to be validated, it needs to be parsed and converted to internal model and analysis needs to happen in various forms.
Right.
Could be vulnerability analysis, license, whatever else.
These are all asynchronous, quite IO heavy tasks in some way.
And the version 4 architecture was basically an in memory event system.
So you could hammer the instance with lots of events, it would pile up in memory until it would be processed.
And that just has a limit.
Right.
If you deploy hundreds of thousands of times per day, you know, you end up with a huge queue.
Your memory usage goes all over the place.
So that is a problem that we are going to be addressing in version 5.
Sorry.
We investigated or we first tried to use an external message broker.
In this case it was Kafka.
We separated out a few services.
For example, vulnerability analysis doesn't have to happen in the main instance of DependencyTrack.
So it was a separate service that could survive mostly without database access.
So it will also not hammer the database.
We then later on decided we need to scale this back just because the message broker itself is such a huge operational burden, especially for newcomers.
It's not a lean thing anymore.
Yeah, correct.
So now we will be dialing back to only requiring a Postgres database in version 5.
And we will like all the messaging asynchronous stuff will happen on a separate database if you so wish.
Like you can run the main application one database, scale that up to whatever data requirements you have and then for like all the messaging stuff, you can deploy a separate smaller instance that just doesn't interfere with the main operations of the application anymore.
And this is optional.
Yeah.
Does it scale horizontally though?
Because right now it's one big monolith.
Right?
Correct.
Yes, it will scale horizontally and it already does.
Like the version 5 that we have on GitHub right now already can scale horizontally and it does.
Like we have a pretty huge user of that version already and it runs with three instances in production at the moment.
Yeah, okay, fantastic.
No, it's a really cool project.
All right.
And you said postgres is where you store all the data sound choice.
Right.
So that makes it very battle tested.
All right, so we talked about SBOMs in decent track, but I think when we're speaking about DependencyTrack, one obvious thing we also need to talk about like what happens when a vulnerability is discovered.
Right.
Maybe we start the conversation but about talk about vex files and the likes of.
Right.
Like maybe for those unfamiliar, can you brief the audience on what are Vex files, how do they fit into the DependencyTrack ecosystem.
Okay, so VEX files are.
Or VEX just means Vulnerability Exploitability Exchange.
It's an.
I would say it's an attempt of going.
Making lights go off.
So whenever a vulnerability is found, a red light turns on in your UI.
Basically speaking, a Vex file can then describe if a vulnerability is found.
Is this actually exploitable?
Is this something you have to worry about?
And ideally, these VEX files would come from the vendor of the software.
Because.
Because only they can know is this actually affecting that given piece of software?
Right.
They can give various types of analyses, I think they're called.
Or states.
They can state this is not applicable because the code is not present at runtime or because I have certain guidelines in place, certain guardrails.
Sorry.
So they can make all these different assessments, provide you the Vex file and you as a consumer of the Vex file, can then turn the lights in your scanner off.
Figuratively speaking.
Yeah, go ahead.
Yeah.
DependencyTrack supports VEX files, so whenever DependencyCheck identifies a vulnerability, it creates a record in the database.
There is a table that you as a user can look at that provides all the information about the vulnerability.
And we provide you the option to upload a VEX file to apply analysis, which could then lead to a suppression of the.
Of the finding.
So you can generate Excel from DependencyTrack and then you can federate out to however you see fit, which then, if you are shipping SBoMS to your customers, you would then in your SBoM point to that VEX file and say, here's an addendum essentially to the SBOM saying that yes, you will find this, but even if you do find this vulnerability when you scan this sbom, I ignore it because it's not impacted.
Right.
You could, but Dependency Check currently does not automatically fetch VEX files that are mentioned in the.
In the BOM that you upload.
So this is currently a missing piece of automation, I would say.
Yeah.
Okay.
Does DependencyTrack pull in any external references?
Because obviously that's a.
It doesn't.
Because that's a big concept in Cyclone.
Right.
Particular as you go in larger scale.
I know Cyclone takes a very different approach than SPDX when it comes to what's considered an SBOM cycle.
DX is heavily lenient on external references.
So is that something that's coming in five or what's the roadmap for allowing lookup for external references?
I wouldn't say this currently on the roadmap but it is definitely planned.
So we know we have a gap there.
Especially if you talk about linking BOMs, right.
You can have a super bom, if you will, that then describes your entire system that links down to SBoMS of the services you deploy.
So, so we know this is a heavily asked for use case and we definitely want to implement that.
It is currently not on the roadmap per se, but yeah, we have plans.
I think a big part of complexity here is can you really trust the URLs that are being linked there in the SBoM?
So there's a lot of trust being.
You need to provide a SHA, right, as part of the SBOM or some kind of algorithm that says you can fetch this file, but here's the hash for that file that you can validate against.
Right?
Sure.
But even from the application security side of things, even if the SHA is valid, is even the like the artifact that is being described there, is that even trustworthy?
Right.
I can give you an SBoM and the SHA might match, but the artifact being described by the SHA might still be malicious.
Now we come back to trust, right?
Like ideally you need to have some, you need to do kind of some signing off the initial SBOMs and then you can trust.
Yeah, correct.
Yes.
So if we, I mean I think if you're actually going to use SBOMs in the real world and actually rely it.
I think attestation is kind of table sticks and honestly with GitHub these days it's so easy to do attestation.
But yeah, that's.
Yeah, if you do attestation and then, yeah, then you can trust the SHA and then you can trust the link, right?
Correct.
Assuming there's no collision.
But yes, generally speaking you can trust it.
Right?
Yeah, hopefully people are not using MD5 anymore.
All right, cool.
So we covered a bit of that.
What I'm really interesting is understanding more the roadmap in general.
So you mentioned five focus a lot on scalability.
What else can we see in the fiber release?
So what we've built is that kind of ties into the whole VEX conversation.
What we have noticed is if you as a secure team, or even as a team lead whatever, you have many projects to.
Or many services to administer.
Right.
You might see the same vulnerabilities pop up over and over again.
Or you might just have false positives that will never be exploited by your services.
But.
But the scanners still find it, including DependencyTrack at some time.
And sometimes you cannot just like false positives are One thing, but also stuff not being exploitable.
And the problem with stuff not being exploitable is it is highly contextual.
You cannot at the system level, say always silence this specific vulnerability and call it a day.
Because then you might suppress true positives.
Right, True.
And this is where VEX kind of falls short.
Either you have to generate VEX files for all your internal services and someone has to constantly check is this still applicable?
Or you have one giant VEX file or one main VEX file that you upload to all your services to reduce the noise.
Right.
What this means is it's kind of, it's contextual.
You need more information to make this decision.
Can I suppress this?
So what we've built in version 5 is it kind of mixes into the policy engine stuff.
It is a way to attach a condition to essentially what is a VEX file.
So we will give you the option to provide a cell expression.
So cell is a common expression language.
It's from Google, I think it's used in Kubernetes as well for admission, webhooks, I think.
Oh yeah.
So we allow you to use this expression language to attach a condition to your Vex statement and you can then say if this specific component is introduced through another component and it is only present in, or let's say it's present in a project tagged with a specific tag or that has specific property only, then apply the suppression so you get a lot more flexibility.
So like if you have a shared component across multiple projects, for instance, you can say, well, I ignore this because we know what it's being used as part of.
Yeah, correct.
Just one example.
Right.
But you can get very creative with the expressions that you create and we think this can alleviate a lot of pain points that people currently have with like suppressing stuff that just doesn't matter.
But scanners still bring up including DependencyTrack.
Right.
So this is one thing we are also heavily interested or planning to evolve DependencyTrack for more use cases beyond just software and hardware.
There is this concept of a cryptography bill of materials that we really want to support.
So which cryptographic algorithms do you use potentially?
Which certificates?
This is all risk.
Right.
And we like to look, or we want to look at DependencyTrack as a supply chain risk management platform.
Eventually it should not just be software and formats like SiteGroundX provide its information.
It would be nice to act on it.
Right.
So this is on the longer term roadmap as well.
We are currently also heavily implementing user management improvements so if you are a large organization, you cannot just give everyone access to every single project and that is something where DependencyTrack version 4 currently falls a little bit short.
There's a limited amount of access control mechanisms that you can use to prevent people from looking at projects, modifying projects.
So this is something we are heavily currently working on and I hope we can demo something very soon.
On that note, we have a community meeting every single month, which you are welcome to join.
Everyone watching this.
Yeah, maybe if you're interested, join us there.
Absolutely.
That's super cool.
Let's talk about use cases and what are the craziest and I mean actually let me rephrase that question.
Give us an order of magnitude of scale of how DependencyTrack being used both in terms of.
I know it's an open source project so you might not have exact data, but how popular is DependencyTrack and amongst those people who are using it, like what's the scale of this?
Like how large are the dependent track organizations or like use cases?
That is a very good question.
I would love to give you an accurate answer.
The problem is of course we are an open source project.
Up until recently we didn't have any telemetry at all.
Like we didn't know how many users actually use or deploy DependencyTrack.
But that being said, we, in the last major version, the last minor version, sorry we introduced just very basic telemetry that tells us which version you are using, right?
It's people can turn it off, they can see in the settings what is being sent, etc.
It's quite transparent.
And we released that version I think one or two months ago.
Since then, I think this week is the first week where we had on two consecutive days 3000 instances reporting back to us on the latest like minor version, right.
And people are sometimes reluctant to update to newer versions.
Subjectively I think those are quite good numbers like for adoption on its own.
Of course we hope this will increase over time as we roll up new releases.
Right.
And people really want to upgrade to that as per scale of individual instances.
I know like the majority of instances are probably mid sized, small to mid sized shops.
They might have hundreds to a few thousands of projects.
I am working for a, I can't call it customer, but a big user of DependencyTrack who's looking at over 100 thousands of projects who are like deployed in production that are constantly being scanned.
Right.
And we are like this is one example.
But large companies do have lots of services that they run production.
We know a Few I can't name drop, of course, but we know larger companies are running DependencyTrack.
They do not disclose to us how many projects they run on DependencyTrack, but we can guesstimate it will be in the same ballpark as that one big user.
I know Monzo is a big shop of DependencyTrack, if I'm not wrong.
Right, yes, sorry, yeah, go ahead.
They also present at one of our community meetings about their experience with DependencyTrack.
They even mentioned like the cost of running it in their environment.
Yep.
Right.
And I think there are quite a few other banks.
I think JP is one of the customers or users of as well.
I believe I've heard.
Yeah, you can't, you may or may not know, I don't know.
But for those larger instances, like you say hundred thousand of components, what does it translate to?
Like, let's go back to like scalability.
What have you seen?
Because obviously the big ones will.
I mean this is how it tends to work even in open source.
Right.
Like if the real big guys, they will find their way to you if they want to have your support as they scale up.
Right.
So talk to me about some scalability scenarios where you've seen like what, I mean, 100,000 components.
Yeah, maybe it's only one S.1 per component, but like give me some data on like scalability problems you've encountered so far.
Okay, so first off, what I meant was not components but like projects.
Right.
And every single project can have thousands of components.
So it is not unusual to end up with like millions of records in your components table, if you will.
Right.
As per, like how people deal with it.
I think most people just end up like scaling the database until it doesn't work anymore.
Right.
You can, you can crank up hardware pretty far if you want.
There have been some performance issues in the past that we addressed if people point them out to us.
But really my experience is that people tend to not reach out to us directly when they have performance issues.
What ends up happening is they think this is an open source project, we can just take the code, make adjustments to it as we need, as we please.
And this of course also includes the database schema.
If they end up finding something, a missing index or whatever, they just apply to their production database.
They may tell us about it, may contribute it back, but many simply don't.
That's my, that's my experience.
That's fair enough.
So the next thing I want to talk a bit about is, I mean a lot of it is still around SBOMs.
So the next thing I want to talk a bit about is, I mean a lot of it is still around SBOMs.
Right.
So I.
We have some pretty fast movements in the SBOMs world.
We have Cyclone DX2 coming out shortly.
I mean, obviously that must be something that you guys got your eyes on pretty carefully with Steve behind the roadmap.
So talk to me about that.
Talk to me about SPDX as well.
Are you aiming for feature parity?
What's the status today?
Talk to me about how you see the landscape of formats or the format war, if you will.
Yeah, format war, that's interesting.
So SPDX is currently not supported by DependencyTrack.
There is a history around that.
SPDX was at one point supported.
It was removed.
I will not go into that specifically because it's kind of political, but there is currently an open issue in DependencyTrack to add SPDX version 3 support back and really I don't think we should be.
We should be bound to a specific format.
I would like everything to be agnostic.
That's the whole purpose of ingesting data from the BOMs into our own format.
Right.
So we don't have to rely on any specific format anymore.
So it is on the roadmap, if you will.
No one is actively working on it.
I think the SPDX folks themselves would be.
Are interested in contributing that to DependencyTrack.
It might just be a matter of having a good conversation between the two of us and figuring out how.
Yeah, I mean, I had Alan Friedman on the show last year and I think to paraphrase what he said, like, if we're still talking about formats in five years, we've lost the battle of S BOMs.
Yeah, right, for sure.
And I, I kind of agree with that.
Right.
Like it's just a way to express data slightly differently like that.
It should just be an implementation detail, hopefully soon enough.
Right.
But even on Cyclone you were pretty late to add support for Cyclone 1.6.
Even that took a while.
Walk to me like, what are the complexities?
Like what?
Because I mean, you would expect, given that it's a OS project tightly coupled with Cyclone, what are the internals of like keeping up with the development there?
You mean on the DependencyTrack side of things or.
Yes, yes, yes.
Okay, so whenever a new major version of CycloneDX comes out, generators adopt it very quickly.
So it doesn't take long for people to upload the BOM DependencyTrack and then discover it's breaking.
I think CDX gen was probably the first one to generate it.
So it doesn't take long for people to upload the Bomb 3 Pensi track and then discover it's breaking.
Yeah, that's what I did.
Yeah, it's kind of so there are multiple parts to it.
The main thing why uploads might be failing is because we do schema validation.
Right?
We try to keep everything kind of enfor that it follows the spec.
And of course, if you do JSON schema validation, you need the schema to be present in order to validate against it.
Yes.
And that schema is currently embedded into a CycloneDX library.
So before we can adopt new CycloneDX versions, the library needs to update.
It needs to update the embedded schema.
Only then can schema validation succeed and we can accept new SBOM files or files in that format.
So that's the bottleneck.
That is one part of the story.
There might be some changes in the format itself that we need to adopt to.
So if there are new fields that users are interested in, we need to lay this out.
What do we need to support?
Additionally, was some field renamed, did some format change of a field or did the type change?
All of this needs to be prepared.
Obviously we cannot just allow people to upload documents and then present broken data.
Yeah, of course, yeah.
But otherwise that's pretty straightforward.
I'm probably going to have Steve talk about Cyclone 2.0 on some future episode.
Do you want to give some kind of hints on where you see things are heading with Cyclone 2.0 or how that's going to fit into or make the life easier for the likes of the bandage strike?
I have to admit, I'm not too deep into the CycloneDX 2.0 work at the moment.
I know there's a very big aspect or a very big priority on discoverability this time.
I think Steve is very keen on making the data not really format bound, but more like, yeah, discoverable in a sense.
I would love DependencyTrack to really leverage that to maybe offload some of the stuff that DependencyTrack currently does to something that is more standardized, centralized.
That's coming from SiteGround DX.
Yeah, right.
And for uploading SBOMs, is it purely JSON or do you support XML as well?
We also support XML.
Yep.
Okay.
Okay, good.
All right, so for people who wants to get involved with DependencyTrack, where can they kind of, where should they, who should they talk to, where should they get started, and so on.
So the first would obviously be dependencytrack.org, which is our main website.
The second would be the GitHub organization.
It's just called DependencyTrack.
On GitHub we have a community repository which includes the links to our previous community meetings.
There's a calendar invite if you want to join the community meetings in the future.
I guess there are lots of open issues in the DependencyTrack repository.
If you find something that you would like to work on, we have help wanted labels for all those issues.
You're more than welcome to contribute.
Otherwise we have a Slack channel in the owasp.
Slack.
It's hashtag dependency.
No project DependencyTrack.
Yeah.
So we are very open to anyone who's interested in the project to come.
In and say hello and the stack you're working in Java and any other skills people should be like when you look for contributors.
Yeah.
So one very big aspect that we really need more help on is user experience.
Front end work.
I have to admit I'm very much a backend guy.
I'm terrible at ui.
Steve was a lot better than me on this aspect.
Steve is very visionary when it comes to designing UX and I don't have that skill, to be honest.
So if Anyone looks at DependencyTrack thinks oh my God, what is this?
And knows how to improve the user experience, we would be very happy to have you.
But of course, if you know front end Vue JS JavaScript we have that stack as well for the backend work.
It's mostly Java as you mentioned.
It's Maven Docker.
Yeah, that's pretty much it.
Thankful for every contribution.
Perfect.
Nicholas, this has been super helpful.
I think it has helped people navigate the pentacy track.
I think it gives a quick intro to it, help avoid common pitfalls, hopefully when they are starting to use DependencyTrack.
So again, thank you for coming on the show and really appreciate it.
Thank you so much.
Thank you for having me.
It was a big honor.
Thank you.
Thank you.
Cheers.
Found an error or typo? File PR against this file or the transcript.