Bree Benesh
|
May 20, 2026
|8 min read
Search Topic

Put plainly by our Head of Product, Lauren Morris, in our recent webinar on Dependency-Track: “I eat Fritos all the time and purposely do not read the label. But sometimes you do want to know what you're putting in your body.”
Modern software works in a similar way. Every application is built on layers of dependencies, base images, and transitive components that evolve faster than most teams can track manually. A Software Bill of Materials (SBOM) provides a practical way to understand what is actually inside that stack. The comparison to nutrition labels fits neatly: you may not check every label every day, but when you need to know, that information becomes essential.
The core argument is simple: periodic scans are no longer enough. When a supply chain exploit emerges, organizations need visibility into their exposure in minutes, not days later. This guide explains how continuous SBOM monitoring works and why many teams choose a managed approach rather than operating the platform themselves.
Dependency-Track is an open source, API-first Software Composition Analysis platform that ingests SBOMs, catalogs components, and continuously matches that inventory against vulnerability intelligence. The important framing is that it is a portfolio tool, not a 1:1 project tool.
That portfolio orientation matters because most organizations do not have one application. They have fleets. Dependency-Track is designed to answer questions across that fleet without turning every incident into a manual inventory exercise.
Dependency-Track is an OWASP project, which positions it as an open source standard and part of a security community that values transparency and shared practices. This aligns naturally with amazee.io’s “open source at the core” ethos.
SBOMs are inventories of the contents of your software artifact. They can describe application dependencies, OS packages, and deeper layers of container images.
SBOMs become far more valuable when they’re generated automatically and ingested continuously, because security depends on both what you run and what the world discovers about what you run.
In practice, SBOMs help you answer:
The National Vulnerability Database (NVD) is the primary source of standardized vulnerability data, enriching CVEs with severity scores, affected products, and remediation guidance. But the NVD is not always fast. Processing and enrichment delays can leave security teams without critical context during the first hours of an incident, when exploit tooling spreads quickly and leadership wants immediate answers.
The goal is not to replace the NVD. It is to reduce the gap between knowing what software you have and understanding whether it is vulnerable.
To close that gap, organizations aggregate intelligence from multiple sources, including GitHub Advisory Database, OSV, and Snyk.
The value is speed and context. Alternative feeds often publish affected ranges, remediation guidance, and exploit discussions before the NVD completes enrichment. Combining those sources gives teams faster answers and better data during active incidents.
Aggregation matters most during fast-moving zero-day events. In our aforementioned webinar, amazee.io’s Principal Architect, Sean Hamlin, highlighted the recent Next.js RCE issue, in which bots began scanning the internet within hours of the disclosure.
The 2024 XZ Utils backdoor incident showed a different risk: a trusted low-level dependency becoming the target itself. In both cases, version-level visibility is essential for understanding real exposure.
But visibility only matters if inventory stays current, which is where automated ingestion becomes critical.
Dependency-Track is only as useful as the SBOM pipeline feeding it. Manual uploads don’t scale and often fail under stress. The goal is to generate SBOMs automatically and continuously ingest them, keeping the inventory current without heroics.
At a high level, the pipeline needs two things: SBOMs generated automatically, and continuous ingestion into a central inventory. With Lagoon, this can be integrated into the deployment flow so teams don’t rely on manual uploads.
SBOM quality also matters. In the webinar, Sean referenced moving from Trivy to Syft because Syft can produce more complete labels. In the Lagoon context, SBOM generation typically adds 20-60 seconds to a deployment during the “Insights gathering” step, a manageable cost for continuous visibility.
Finally, closed-loop notifications using tools like Slack and Teams help you avoid living in the UI. The best practice is simple. The system should only notify you when a new CVE matches your existing inventory.
Alert fatigue kills programs. Dependency-Track’s risk score is useful, but it should guide research and not trigger panic by itself. The goal of triage is to quickly separate “interesting” from “urgent,” and to document decisions so teams don’t re-litigate the same findings every time a scanner refreshes.
Two concepts help teams focus on what matters:
VEX lets you document non-exploitability when a vulnerable library exists, but the vulnerable code path is not reachable in your context. It’s how you turn “this shows up in the SBOM” into a defensible decision: present, but not exploitable here.
EPSS helps prioritize vulnerabilities that are more likely to be exploited in the wild, which is often more operationally useful than severity alone, especially when teams are staring at a long backlog.
Dependency-Track becomes essential as soon as you have enough services that spreadsheets become useless. In the webinar, Sean describes the calm workflow: search for a CVE, see affected projects immediately, and hand developers a targeted list instead of asking them to inventory everything during a crisis.
High-value fleet questions that Dependency-Track can answer:
In practice, teams usually consider one of three options:
DIY (open source): gives maximum transparency, but you operate the platform long-term.
Commercial SaaS: reduces operations but can introduce “black box” tradeoffs and data-residency constraints.
Managed Dependency-Track (amazee.io): keeps open source transparency while removing the day-two operational burden, with strong control over where data lives.
| Feature | DIY (Standard Open Source) | Commercial SaaS (Snyk, Black Duck, etc.) | Managed Dependency-Track (amazee.io) |
|---|---|---|---|
| Direct Cost | $0 (Licensing) | High (Per-seat/Per-repo) | Predictable (Tiered Pricing) |
| Infrastructure | You manage Java/PostgreSQL | Proprietary "Black Box" | Open Source (on optimized PaaS) |
| Data Sovereignty | Your Cloud | Their Cloud | Your Cloud (In isolation) |
| Transparency | Full (Source available) | None (Proprietary) | Full (Open source code/logic) |
| Threat Feeds | Manual Configuration | Proprietary & Bundled | Pre-configured (Multi-source) |
| Compliance | Your responsibility | SOC 2 / ISO (on their end) | SOC 2 / ISO / DORA Ready |
Here’s the key point: the hidden cost of DIY isn’t the first deployment. It’s the day-two work, such as upgrades, database tuning, feed health, monitoring, backups, and keeping the platform itself secure. If your goal is to reduce supply chain risk, the more time you spend operating the tool, the less time you spend reducing actual risk.
SBOMs and vulnerability posture can be sensitive. During Q&A, Lauren succinctly summarized the expectation: “Your data is your data.” For many teams, the requirement is that vulnerability and SBOM data stay within existing security boundaries in AWS, GCP, or another controlled environment, rather than living in a shared public cloud SaaS footprint.
Data sovereignty is also intertwined with compliance. If you need to prove control over where data lives and how it is accessed, the hosting model becomes part of your security story.
Managed Dependency-Track focuses on removing the day-one configuration headache and the day-two operations burden. It also supports the deployment flexibility described by Sean, where instances can be provisioned in the location and cloud environment required by the customer.
The “inception” joke from the webinar illustrates how deep the integration can go. Sean described deploying Dependency-Track with Lagoon and using Dependency-Track to create SBOMs for Dependency-Track itself. It is funny, but it also demonstrates a platform mindset where continuous security is baked into how systems are delivered.
Managed hosting also ties into platform security. The goal is to meet SOC 2, ISO 27001, and DORA-oriented expectations through a managed approach that pre-configures feeds, reduces manual twiddling, and standardizes operations in a way that stands up to audits.
Teams tend to fall into the DIY trap because the software is free, only to realize the operational burden is high. Dependency-Track needs care, and vulnerability intelligence needs to stay healthy. Managed Dependency-Track keeps the transparency and cost-efficiency of open source while removing the operational overhead, so the organization can focus on remediation.
In a BYOC model, security and uptime are not owned by one party. They are shared across a stack, with each layer managed by the party best equipped to handle it. Getting clarity here early helps procurement because it turns the question of who is accountable into an actionable map of duties and escalation paths.
Stop fighting fires when the next CVE drops. With Managed Dependency-Track from amazee.io, you get a dedicated instance (within your cloud boundaries) that continuously matches your SBOM inventory to vulnerability intelligence and alerts you only when action is required.
Reach out to your amazee.io Client Engagement Manager or contact the amazee.io sales team to get started.
👓 [Article] DDoS Attack Mitigation for Enterprises
👓 [Product Page] Managed Dependency-Track
👓 [Article] Fault-Tolerant Enterprise Hosting