SBOM and software supply chain vulnerability management

Each release should carry its own SBOM, generated from the build that produced the shipped artifact. Trivy can produce a software bill of materials for a target and can also scan an existing SBOM, and its report formats include SBOM output. The usual approach is to generate the SBOM in CI, store it with the release artifact and tag it with the version number, so a buyer or assessor can match a file to a specific build. The SBOM format is typically CycloneDX, which Dependency-Track consumes directly. Confirm with your engineering team that the SBOM lists components from the container image, the application dependencies and the operating system packages, because missing layers are the most common gap during review. DeployOpen can plan and implement this pipeline step in your environment, but the SBOM itself is a record your build produces.

A Dependency-Track project holds the component inventory for each product and keeps its history as new SBOMs are uploaded, so you can see which versions of a library each release contained and when a vulnerable component first appeared. Dependency-Track correlates components against sources including the NVD, GitHub Advisories, OSV and Trivy, which lets the inventory update as new CVEs are published, without rescanning the artifact. Ask the people reviewing your evidence which history they need: a per-release view, a per-component search across all products, or both. Confirm that your retention settings keep older project versions long enough to answer those questions.

Triage decisions are recorded against the component and vulnerability inside the Dependency-Track project, and Dependency-Track consumes and produces CycloneDX VEX documents. A VEX statement records whether a known vulnerability is exploitable in your product, for example because the vulnerable code path is not reachable. The record should state the analyst, the date, the justification and the release it applies to. Confirm with your security team how analysis states are reviewed before a finding is marked not affected, because an unreviewed suppression is a common finding in assessments. Publish the VEX document with each release so customers receive the same decisions you hold internally.

Dependency-Track identifies license risk, tracks license use by component using SPDX license IDs, and applies global and per-project policies for security, license and operational compliance. A policy violation is a recorded event, and the decision to accept, replace or remove the component should be written next to it. Confirm which licenses your organization prohibits or requires legal review for, such as copyleft terms in distributed products, and who signs off the exceptions. Keep the policy definitions under version control so an assessor can see what rules applied on the date a release shipped.

Dependency-Track sends configurable notifications to Jira, and it has native support for DefectDojo, so a finding can become a tracked remediation item with an owner and a due date. The evidence an assessor usually samples is the chain from finding to ticket to fix to the next SBOM showing the component removed or upgraded. Confirm that ticket identifiers are stored with the finding and that closed tickets link back to the release where the fix shipped. DeployOpen can configure these integrations within the agreed scope, and the ticketing tool remains your system of record.

An exception approval should name the component or vulnerability, the affected product and release, the risk owner, the compensating control, the approval date and an expiry date after which the exception is reviewed again. Dependency-Track policies and VEX justifications can hold part of this record, while the approval itself usually lives in your governance tool or ticketing system and is referenced from the finding. Ask your auditors whether they expect a named individual with authority to accept risk and whether expired exceptions must trigger a new decision. Without an expiry, an exception tends to become a permanent gap.

Retention should cover every release that remains in support, plus the period your contracts, customers or regulators require after end of support. Confirm the retention period with your legal and compliance teams, because no single standard supplied here sets it for every sector. Store the SBOM and VEX files in an immutable or access-controlled location, record the checksum of each file, and keep the Dependency-Track project versions that match them. Retention cost is usually modest storage, while the larger cost is the time spent reconstructing records that were not kept at the time of release.

The main cost drivers are the number of products and build pipelines that produce SBOMs, the number of correlation sources you need, how much of the environment is air-gapped, the volume of VEX statements your teams must write and review, and how many systems the findings must reach. Each product line adds pipeline changes, component mapping and triage. Air-gapped operation adds manual transfer of Dependency-Track and Trivy database updates. Ask any quote to break effort down by these drivers so you can see which ones your portfolio triggers and which ones you can reduce by starting with a smaller scope.

One-time costs cover designing the SBOM generation step for each build pipeline, deploying Dependency-Track, setting up notifications and policies, and the initial inventory of components across existing products. Recurring costs cover keeping pipelines current as build tooling changes, mirroring vulnerability databases on a schedule, triaging new CVEs and writing VEX statements, reviewing license policy exceptions, and upgrading the platform. Trivy's documentation warns that database mirrors must be kept updated, so that recurring step should be named explicitly in any quote, along with whether upgrades and support are covered by a retainer.

Expect to provide named engineering owners for each product and pipeline, access to build systems and artifact repositories, and a decision-maker for policy such as which severities block a release. A named legal reviewer should own license policy, because license risk tracked by SPDX license IDs requires an interpretation of obligations that technical staff should not decide alone. Security or compliance staff should confirm how VEX statements will be reviewed and retained. Ask the implementation partner to list these inputs in writing so that delays from missing access or unclear ownership are visible before work starts.

A single product with one pipeline is a reasonable first project for an internal team, particularly if engineers already operate CI systems and Dependency-Track is deployed in their environment. The difficulty increases across a portfolio. Each product has different languages, build systems and ownership, the correlation sources must be configured consistently, and VEX decisions need a review process that stays consistent across teams. Many organizations keep ownership of the program and bring in a partner for the initial pipeline design, the policy model and the integration with ticketing and reporting, then run the recurring work internally.

No duration applies to every organization, because the timeline depends on the number of products, how many pipelines already generate SBOMs, the state of build systems, and whether the environment is air-gapped. A narrow pilot covering one product with an existing build pipeline is usually shorter than a rollout across a portfolio with mixed languages and separate owners. Ask for a timeline in the written scope that is tied to named phases such as pilot pipeline, policy agreement, portfolio onboarding and handover, and confirm which dependencies on your teams and change windows it assumes.

A fixed-scope quote should list the products and pipelines in scope, the SBOM formats and generation tools used, the correlation sources enabled in Dependency-Track, the notification and ticketing integrations, the policies for security, license and operational compliance, and how air-gapped database updates will be handled. It should also state the deliverables, such as pipeline configuration, runbooks and handover sessions, the client inputs and owners, the acceptance criteria, and whether a recurring retainer for upgrades and continuous support is separate. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and prices follow from that written scope.