The Code You Didn't Write

As developers, your job is hard, so the last thing you want is to spend time managing someone else’s code. Yet one of the most common findings in penetration test reports is a deceptively simple item: out-of-date third-party libraries. It’s not even your code, but how do you stop this from becoming your problem?

What is Dependency Track?

When you’re generating your code, a Software Bill Of Materials (SBOM) gives you a complete inventory of every third-party component your application relies on. Dependency Track takes that SBOM and does the heavy lifting, continuously monitoring across all your projects, so you don’t have to. It focuses on three things specifically: security, compliance, and control.

Security: The Log4Shell Story

In 2021, Log4Shell hit on a Friday morning. For those of us in the United Kingdom, it landed around 9 AM — a perfect start to the weekend. We had no idea whether we were exposed. We sent messages. We asked around. People looked at each other and shrugged. We had no single place to go, no way to instantly know which projects were affected or who to talk to.

By Tuesday, customer emails were already arriving: Are you impacted? What’s your stance? What are you doing about this?

With Dependency Track already in place, we could have walked into that Friday knowing exactly which projects carry the vulnerable library, and we could have been proactive in sending notifications to our customers, rather than reactive. You’re not going to prevent the vulnerability, but you will have the awareness, and in security, awareness is everything.

Compliance: Licensing Changes

Licensing is something people rarely think about until it’s too late, since open source libraries can change hands. A vendor acquisition can turn a free tool into a paid one overnight, or introduce licensing terms your organisation can’t accept, particularly in regulated or enterprise environments ( Dependency Track flags that too).

Increasingly, third-party license tracking is also showing up as a contractual requirement from external partners, which isn’t just good practice; for some organisations, it’s becoming an obligation.

Control: What’s in Your Code

There’s a control angle worth mentioning that goes beyond vulnerabilities and licensing. We’ve seen bloated containers carrying libraries that aren’t being used. Loading one into Dependency Track immediately surfaced dependencies that served no purpose; the fix wasn’t to patch, it was simply removing them.

This is about knowing exactly what’s in your codebase, what versions are running, and which other projects are consuming the same components.

What This Means For You

From a security perspective:

• Instant visibility into which projects are affected when a new CVE is published
• Reduced latency from “unknown exposure” to “actionable response” — measured in days, not weeks
• A single portal for targeted, informed conversations instead of company-wide panic messages

From a client perspective:

• Faster, more confident responses when customers ask about your exposure to emerging threats
• Demonstrable security posture for audits, contracts, and compliance requirements
• Proactive communication that builds trust before incidents escalate

The Goal

Security work should be asynchronous, running in the background, not blocking your process, so when it comes to Dependency Tracking, it fits into your CI/CD pipeline quietly. You build, the SBOM is generated and uploaded, then the monitoring happens without you having to think about it. Until something needs your attention, and when it does, you’ll already know.