One of the most common arguments in support of Open Source in nearly any software development project, is that everyone uses it. I’d go so far as to argue that 100% of the software that I’ve developed has only been possible due to open source components; whether that’s development tooling, shared libraries, or open standards and frameworks.
Over the last 12 months we’ve seen a significant uptick in what is known as ‘Supply Chain’ attacks. Given the above arguments, it’s very clear that anyone working directly or indirectly with Open Source software needs to understand these attack vectors, and work out how they can be mitigated.
For several years, I’ve had the pleasure of working on some Open Source projects and making small and simple contributions. Most of the blog posts you’ll find written are predominantly from the perspective of securing a single project or a version-controlled monorepo. As the software we manage on behalf of organisations balloons, then so does this complexity.
Nerding out over Christmas, my partner and I decided to look into what software already exists out there to solve this issue, and whether there would be mileage for us to develop our own product in this space; with her also focused on how this problem should be presented back to non-technical stakeholders.
OWASP
One of the organisations I turn to in this space is OWASP (Open Worldwide Application Security Project) that is a global non-profit providing guidance, research, products and a community. Whilst there are lots of professionals worrying about some of the new threats and vectors facing the industry, their popular ‘Top 10‘ gives us a grounding in reality of how few organisations get the basics right.
Back in 2021 Joe Biden’s Administration issued an Executive Order 10460 to try and encourage a step change in how technology companies should be expected to operate securely. Whilst I’d encourage you to read the full text yourself, one of the key things was that all technology should include a Software Bill of Materials so that the purchaser was aware of not just what they were directly purchasing, but to understand the supply chain risk.
Whilst still in their relative infancy, SBOM’s have really taken off, with organisations like Anchore really learning-in to the open source community to produce tooling to translate the ‘package management manifests’ already common within most language-ecosystems, into SBOM manifests.
Opportunity or Threat
Whilst I believe this is a great improvement, one of the drawbacks is consistent with vulnerability management’s favourite paradigm “Security through Obscurity.” In making your SBOM’s transparent and open, if you have poor internal practices and you use outdated dependencies, then you’re going to be found out. It speaks to America’s dominance of global technology, that the impact the Executive Order had in this space was to get companies to sit up and listen.
Not just libraries
Atlassian (an Australian company) kicked off a 4 year ‘Continuous PaaS Recover’ (CPR) programme to try and address its dependency hell. Whilst this was initially aimed at it’s ‘Service layer’, the reality was that it exposed an architectural paradigm at the top of many organisations. Developer ‘freedom to’ innovate without considering the supply chain of both libraries and services, and ‘freedom from’ being restricted by a management (or security) layer that primarily seems to be just saying ‘no.‘
To resolve the dependency issues cited by Atlassian, they needed to address the service design and services layers to help decouple their critical services.
What’s a CVE / CWE?
I’d recommend a sidetrack to read up ‘What is a CWE?’ from mitre, and ‘What is a CVE?’ from Snyk. These are both incredibly important for running both your risk management and vulnerability management processes; but can often be overlooked.
One of the other things of note is that historically much security and vulnerability management has been exercised by American institutions such as NIST and the National Vulnerability Database. The challenges facing the global technology world now need to include how do we appropriately fund the ecosystems necessary to do the research into both identifying and fixing these vulnerabilities, rather than relying on other institutions to do the work for us.
Building blocks; let’s start at the bottom
The tool I’d been looking to evaluate was Dependency Track. It’s a self-hosted container solution that allows for your to either manually ingest, or setup Continous Integration services to post their up-to-date SBOMs. In the OWASP Top 10 this year it’s been promoted to A03:2025 Software Supply Chain Failures, with several CWEs being cited.
I setup Dependency Track and used an ‘organisation secret’ in my Github Org to act as the ingestion secret for allowing my Continous Integration workflows on github to post their version data back into DependencyTrack. I was only evaluating, so rotating this secret and storing at a more granular level may suit your risk level better. I only gave the token permissions to post data back into Dependency Track, but even that has the risk of an exposed token being used to inject bad data into my systems.
Overall I was quite impressed with the solution, and especially the ‘Exploitability Predictions’ screen:
Again, there’s a shipload of implied knowledge here, but along the X axis is the relative CVSS (Common Vulnerability Scoring System) score – provides a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity, against a Y axis of EPSS score – a data-driven effort for estimating the likelihood (probability) that a software vulnerability will be exploited in the wild.
This is all great information, but in the hierarchy of the DIKW pyramid, we’re still playing in the bottom half.
As a brief evaluation, I’ve been quite impressed with Dependency Track and will be looking to write up a blog-post on how to set it up securely within your organisation, and good patterns to use to reduce the threat of it being a honeypot for attackers to use against you.