SBOM and open-source dependency review

Why SBOM and open-source dependency review is now a buyer requirement

A software bill of materials (SBOM) is a machine-readable inventory of the components inside an application, and buyers now ask for one when a framework, a customer security questionnaire, a product launch, an insurer or a due diligence team wants evidence of dependency control. Producing an SBOM alone does not answer that request. The buyer usually wants to know that the inventory is accurate, that known vulnerabilities in it are triaged, that license obligations are understood and that the inventory is refreshed as the software changes. Confirm early which of these your requester actually means, because the answer determines whether you need an inventory, a review of its contents or a process to maintain it.

The risks behind these requests are concrete. Vulnerable and abandoned components stay in production because nobody owns them. License exposure appears when a copyleft or restrictively licensed package enters a commercial product without review. Unknown transitive dependencies, the libraries pulled in by other libraries, are where most surprises sit, because teams rarely declare them. Tampered packages are the hardest to see, since a poisoned dependency can look identical to the legitimate one until its integrity is checked. OWASP lists these concerns under A03 Software Supply Chain Failures in the OWASP Top 10:2025, the current edition of the OWASP Top 10, which is why security reviewers now treat dependency control as a core application control rather than an optional extra.

Three public references give buyers and assessors a common language. NIST SP 800-218, the Secure Software Development Framework (SSDF) Version 1.1 published in February 2022, groups practices into Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities, and dependency management sits within that set of practices. The NTIA's *Minimum Elements for a Software Bill of Materials*, published on 12 July 2021 under Executive Order 14028, defines data fields, automation support and practices and processes that an SBOM should cover. Ask your requester which of these references their questionnaire cites, and confirm that the SBOM format you deliver, CycloneDX or SPDX, is one they accept.

What can be in scope for an SBOM and dependency review

Most of the cost and value in an SBOM and dependency review comes from a few early decisions: which artifacts are covered, whether the work builds a new inventory or checks an existing one, and how deep the dependency tree goes. Agree these in writing before work starts, because each one changes what evidence exists at the end.

Products, repositories and build outputs

Start by naming the products, repositories, release branches, build outputs and container images that the SBOM must describe. A single application often produces several artifacts, such as a service image, a client package and a set of libraries, and each one needs its own inventory. Confirm which versions are in scope, including older releases still in customer use, and which environments the deployed images come from.

New SBOM or review of an existing one

Decide whether the work generates an SBOM from source and build metadata or checks one the team already produces. Checking an existing file means verifying that it lists components accurately, that versions match what runs in production, and that it meets the NTIA minimum data fields. Generating one means choosing CycloneDX or SPDX, agreeing which tools produce it, and deciding who maintains it afterward.

Dependency depth: direct, transitive and vendored

Define how deep the review goes. Direct dependencies are declared in the project manifest, transitive dependencies arrive through them, and vendored code is copied into the repository without a package record. Many incidents start in transitive or vendored code that no manifest lists. Ask whether the review must cover the full tree, and how vendored or copied code will be identified.

Lockfiles, manifests and CI metadata

A reliable inventory depends on access to lockfiles, build manifests and CI metadata, not only the source tree. Lockfiles pin the versions that were actually resolved, build manifests show how artifacts were assembled, and CI logs record the tools and base images used. Confirm read access to these files and the pipeline records before the review starts, since a list built from manifest ranges alone can describe versions that were never shipped.

Proprietary and third-party components

Set rules for components that are not open source, such as commercial libraries, licensed SDKs and components supplied by a vendor. Decide whether they appear in the SBOM, who supplies their version data, and how the team will handle components whose contents cannot be inspected. Agree in advance how confidential component names and license terms are stored and shared, since the SBOM may reach customers, auditors or regulators.

How the review runs, phase by phase

The sequence moves from agreed scope to a verified inventory, then to vulnerability, license and maintenance findings, and finally to a retest that confirms the inventory stays current. Each phase produces an artifact the client can keep and check against its own process.

Agree scope against the NTIA minimum elements
Before any tooling runs, the reviewer and the client agree which products, repositories, build outputs and deployed images are in scope, and which SBOM practices are being assessed. The NTIA minimum elements, published on 12 July 2021 under Executive Order 14028, group expectations into data fields, automation support, and practices and processes, so the scope document maps each category to a named owner and a defined artifact. The step closes when the client signs off on that written scope, which is the baseline for every later phase.
Collect the build-time component data
The reviewer gathers the manifests, lockfiles, container base image references and build metadata that describe what the software actually contains, and confirms with the development team which build process produced each release. Generating the inventory from the build, rather than from a manual list, reduces the gap between what is documented and what is shipped. The output is a list of input sources per product, with gaps and unknowns recorded rather than guessed.
Generate or validate the SBOM in CycloneDX or SPDX
The client either supplies an existing SBOM or the reviewer generates one, in CycloneDX (published as ECMA-424) or SPDX (ISO/IEC 5962:2021), depending on what the client's tooling and customers expect. Validation checks the document against its format's schema, confirms that each component carries a version, supplier and unique identifier, and compares the result against the collected inputs. The step closes when the SBOM validates and every discrepancy with the build data has been resolved or logged as an open item.
Analyze known vulnerabilities and licenses
The reviewer matches each component and version against vulnerability sources the client accepts, and checks declared and detected licenses against the client's license policy, flagging incompatible or unknown terms. Findings are triaged for reachability and exploitability in the product's actual use, so a vulnerable library that is never loaded is recorded differently from one on a live path. The output is a findings register with severity, affected component, license category and a recommended action for each item.
Assess maintenance health of key dependencies
For components that carry weight in the product, the reviewer checks signals of maintenance health such as release cadence, unresolved security issues, maintainer activity and whether the project has a published security policy. Where the source repository is hosted on GitHub, OpenSSF Scorecard results give automated checks such as Branch-Protection, Dangerous-Workflow, Pinned-Dependencies and Token-Permissions, each scored 0 to 10 and combined into a weighted aggregate. The output is a short risk note per critical dependency, with a replacement, pinning or monitoring decision recorded.
Map findings to NIST SSDF practices and report
The reviewer links the findings and process gaps to the relevant NIST SP 800-218 practices, such as PS.3 for archiving and protecting releases, PW.4 for reusing vetted components, and RV.1 for identifying vulnerabilities, so the client can show how each gap relates to a recognized framework. The report separates confirmed findings from observations, gives the evidence behind each, and states what was not tested. It is complete when the client has reviewed a draft and the findings have been accepted or disputed in writing.
Set the inventory update process and retest
The client and reviewer agree how the SBOM is regenerated, which pipeline events trigger it, who owns the license and vulnerability queue, and how new components are approved. Remediated findings are retested against the same inventory to confirm the fix and to check that the SBOM now reflects the change. Retest closes when each agreed finding is marked resolved, accepted with a documented risk decision, or still open with an owner. Ongoing monitoring can be scoped separately as a retainer if the client wants continuous coverage.

What the review finds in a typical dependency inventory

This table compares six weakness categories that show up in SBOMs and open-source dependency inventories, describing what each looks like in the inventory and why it matters to a customer or auditor. Read each row as a question to ask of your own inventory: if the answer is unclear, the category is likely present and worth scoping into the review.

Weakness category	What it looks like in the inventory	Why it matters to a customer or auditor
Incomplete or inaccurate component data	Components listed without versions, supplier names or unique identifiers, or transitive packages missing entirely because the SBOM was generated from a lockfile that does not match the shipped build	Without accurate component data, a new advisory cannot be matched to the product, and an assessor cannot confirm the inventory reflects what is deployed
Unpinned or unverified dependencies	Version ranges that resolve to different code on each build, no recorded hashes, and packages pulled from public registries without a checked origin	Builds are not reproducible and the component that was reviewed may not be the one that ships, which weakens any claim of artifact integrity
Known vulnerabilities in direct and transitive packages	Advisories matched to components in the inventory, often deep in the dependency tree, with no record of whether the affected code path is reachable or how the finding was triaged	Customers and auditors expect a documented triage decision for each finding, including fixes, mitigations and accepted risk with an owner and review date
Abandoned or unmaintained projects	Components with no releases or commits for a long period, archived repositories, or packages whose maintainers no longer respond to security reports	No upstream fix is likely to arrive, so the owner must plan a replacement, a fork or a documented compensating control
License conflicts with distribution terms	Copyleft or source-available licenses in components that are embedded in a product being distributed, or license fields missing or inconsistent across the inventory	Distribution terms may require source disclosure or restrict commercial use, and procurement and legal reviews usually ask for license evidence alongside security evidence
Gaps in update governance	No named owner for each component, no defined cadence for reviewing advisories, and an SBOM generated once at release and never refreshed	Assessors look for a repeatable process that keeps the inventory current, and a stale SBOM can misstate exposure to a vulnerability disclosed after the last release

CycloneDX or SPDX: which format fits your environment

Security teams usually want an SBOM that feeds vulnerability management quickly and accurately. CycloneDX 1.7, released on 21 October 2025 and published as ECMA-424 by Ecma Technical Committee TC54, was designed with security use cases in mind, and its component and vulnerability data fit well with scanners and tracking tools that match components to advisories.

Component identity: Confirm each component carries a usable name, version and package identifier, since matching against advisories fails when these are missing or inconsistent.
Dependency relationships: Check that direct and transitive dependencies are represented, so a flaw in a nested library can be traced to the application that ships it.
Vulnerability data: Ask whether the tooling in use can ingest and emit the vulnerability fields the team relies on, and confirm that version support with the tool vendor.
Hashes and provenance pointers: Verify that artifact hashes are present where the team needs integrity checks, which connects the SBOM to build verification.
Ownership of the file: Confirm who regenerates the SBOM after each build, because a stale file is the most common reason vulnerability matching goes wrong.

Before accepting a CycloneDX file, ask the reviewer to confirm it validates against the schema for the version you chose and maps the NTIA data fields.

What drives the cost and duration of an SBOM review

This table compares the cost components of an SBOM and open-source dependency review, who is paid for each, whether the work is one-time or recurring, and what pushes effort up or down. Use it to see which parts of your estate will move the quote and which questions to put into a written scope before work starts.

Cost component	What drives effort	One-time or recurring	What to request in the quote
Products and repositories in scope	Each product adds its own build, manifests and release history to review; shared libraries reduce repeated work	One-time for the initial inventory, recurring when new repositories join	A list of products, repositories and versions covered, with exclusions stated
Language ecosystems and build systems	Each package manager and lock file format needs its own resolution method; mixed monorepos take longer to reconcile	One-time, with recurring effort when toolchains change	Ecosystems named explicitly, plus how lock files and build outputs are read
Container images and firmware layers	Base images, OS packages and embedded firmware components are often missing from manifests and need extraction and identification	One-time for baseline images, recurring at each rebuild	Image list, base image policy and whether firmware or vendor binaries are included
Generation versus validation of existing SBOMs	Generating a new CycloneDX or SPDX document is usually less work than validating an SBOM produced by another tool against the NTIA data fields	One-time per product, then recurring on regeneration	Whether the output is new, checked or corrected, and which NTIA data fields must be present
Depth of transitive analysis	Resolving transitive dependencies, vendored code and copied snippets takes more time than listing direct dependencies	One-time, with a recurring cost to re-resolve as trees change	Stated depth (direct, transitive, or vendored code) and how unknown components are handled
License review scope	Licenses must be identified, reconciled and checked against the organization's policy; ambiguous or custom licenses need legal input	One-time review, recurring for new or changed components	Whether license compliance is in scope, which policy applies and who signs off on findings
Vulnerability and maintenance analysis	Matching components to known vulnerability records and assessing project health adds triage effort, especially for large trees	Recurring as new advisories are published	Sources used for vulnerability matching and whether maintenance health is assessed
Interviews and access needs	Build engineers and product owners must confirm how artifacts are built and which dependencies are actually shipped; source and lock file access speeds the work	One-time during scoping and review	Named contacts, repository and build access, and the number of working sessions
Ongoing update process	A process to regenerate the inventory on each release, and to triage new advisories, is what keeps the SBOM accurate over time	Recurring, usually the largest long-term cost if left unplanned	Whether the quote includes setting up automation, a review cadence, or a retainer for updates

Frameworks that expect SBOM and dependency evidence

Several frameworks ask for the same underlying evidence: a current inventory of components, a record of how those components were checked, and a process for acting on what the checks find. The cards below show what each framework expects in this area and what a reviewer will look for. DeployOpen prepares the evidence, while independent auditors and certification bodies draw the conclusions.

NIST SSDF practice groups

NIST SP 800-218 groups its practices into Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). For SBOM work, PO covers the roles and policies that own the inventory, PW covers how components are selected and reviewed, and RV covers how newly disclosed vulnerabilities in dependencies reach the people who fix them. Check that each practice has a named owner and a recorded output, such as a policy, a review log or a triage record.

ISO/IEC 27001 development controls

Annex A control A.8.28 covers secure coding and A.8.29 covers security testing in development and acceptance. Together they ask whether testing of dependencies and custom code is defined and carried out during the life cycle, not only before release. For an SBOM programme, expect the assessor to ask who runs the component checks, how often they run, and where results are recorded. The control wording is in ISO/IEC 27002, which the assessor will use as guidance.

DORA open source analyses

DORA Article 25(1) lists source code reviews where feasible, vulnerability assessments, open source analyses and penetration testing among the appropriate tests in a digital operational resilience testing programme. For financial entities, open source analysis is the item that maps most directly to dependency review. Confirm with your compliance team which of your systems fall within scope and whether the regulator or your internal policy sets a testing frequency, since the regulation does not supply one in this context.

CMMC Level 2 vulnerability scanning

The CMMC Assessment Guide for Level 2 ties requirement 3.11.2, vulnerability scanning, to a note that custom-developed software may need penetration testing or source code scanning. For a contractor, this means dependency scanning of the application's packages may not be enough on its own where the organization builds its own software. Ask your assessor how they expect custom code and third-party components to be covered, and keep the scan scope and results tied to the systems in your assessment boundary.

OWASP ASVS 5.0.0 access needs

OWASP ASVS 5.0.0 notes that verifying many Level 2 and Level 3 requirements needs access to documentation, source code, configuration and the development team, not only black box testing. For dependency review, this means the tester needs the lockfiles, build manifests and SBOM generation settings, not just the running application. Agree that access in writing before testing starts, and confirm which build artifacts and repository branches are in scope.

Software supply chain failures in OWASP Top 10 2025

Software Supply Chain Failures is A03 in the OWASP Top 10 2025. Auditors and customers who read the list will expect to see that your organization knows which third-party components it runs, where they came from and how they are updated. An SBOM gives the evidence trail, but only if it is generated from the build and refreshed when dependencies change. Ask whether your inventory covers transitive dependencies and container base images.

How to keep the SBOM current after the review

An SBOM produced once during a review describes one build at one point in time. Every new commit, dependency update, base image change and release alters the inventory, so a document that was accurate in the review report can be wrong within weeks. The practical goal is to make the SBOM a build output that is regenerated with each release, so the inventory your customers, auditors and incident responders read always matches the artifact in production. Ask the team which tool generates the SBOM today, which format it emits (CycloneDX or SPDX), and whether that output is stored with the release or only exists on a developer laptop.

Tie the SBOM to the release artifact itself. Generate it in the pipeline after the build, store it next to the artifact in the same registry or release record, and sign or hash it so later readers can confirm it was not altered. Pin dependencies to exact versions or digests and verify them at install time, using lock files and checksums, so that the components listed are the components actually built. Regeneration alone does not prevent drift if a build can pull an unpinned or substituted package, which is why the review should map each pipeline step against the OWASP CI/CD risks CICD-SEC-3 Dependency Chain Abuse and CICD-SEC-9 Improper Artifact Integrity Validation. Those controls belong to the wider pipeline review, and the CI/CD pipeline security review page covers how that assessment is run.

Vulnerability data also goes stale even when the inventory is correct, because newly published advisories affect components that were clean at release. Schedule recurring re-checks of the stored SBOMs against current vulnerability and license data, and agree in advance who receives the results and what response times apply to critical findings. Name one accountable owner for the SBOM process and one for exceptions, meaning any component kept despite a finding, unmaintained project or incompatible license. Each exception should record the reason, the compensating control and an expiry date for review. Confirm with the client's security and legal teams which deadlines and approvals their own policies require, since those, not generic guidance, set the cadence.

How the review differs by delivery model

For a SaaS product, the provider controls the running system, so the most reliable inventory is generated from the build. The review starts with the repositories, lockfiles, container images and deployment manifests that produce the production service. Because customers never receive the binaries, the SBOM serves mainly internal vulnerability management and customer security questionnaires, and it must match what is actually deployed rather than what was intended.

Build-time generation: The SBOM is produced in the pipeline from lockfiles and built images, so each release carries its own inventory.
Runtime drift: Reviewers compare the SBOM with running containers to find packages added by base images or manual patches.
Hosted dependencies: Managed services such as databases and queues appear as third-party components that need their own review.
Customer requests: Many buyers ask for an SBOM on request, so confirm the format (CycloneDX or SPDX) and update cadence in advance.
Upstream health: Scorecard results for key open-source repositories show whether maintainers enforce branch protection and pin their own dependencies.

Before sign-off, confirm that the SBOM is regenerated on every production release and that the team can name the owner of each critical dependency.

What your team prepares before the review starts

Start by assembling the inputs that let the reviewer work from evidence rather than inference. The most useful item is read access to the repositories and build system, including the lockfiles and manifests that declare dependencies, such as package-lock.json, go.sum, Cargo.lock or pom.xml, depending on your stack. Without the lockfile, a reviewer can only infer which versions ship, and transitive dependencies (the libraries your libraries pull in) are often where the findings sit. Also supply any existing SBOM in CycloneDX or SPDX form, even if you believe it is out of date, so the reviewer can see where it diverges from what the build actually produces.

Next, provide pipeline logs or build metadata for a recent release, and a list of the products and versions you distribute to customers or deploy into regulated environments. The distributed-product list defines the boundary of the inventory. A dependency that exists only in a test harness is a different risk from one bundled into a shipped artifact, and the report will state which is which only if you tell the reviewer what leaves your control. Confirm with your engineering lead which build outputs are signed or attested, since this determines whether the reviewer can trace an artifact back to its build inputs. Record anything you cannot provide, because an explicit gap in the report is more useful to an auditor than an unstated assumption.

Finally, settle three decisions before work begins. Document your licensing position on proprietary components and any copyleft obligations your legal team has already assessed, so license findings are judged against your policy rather than a generic one. Name one owner who receives findings, decides on remediation and can accept or reject risk, because unowned findings stall. Agree change-freeze or release windows with the reviewer so that dependency upgrades and fixes do not land mid-assessment and invalidate the inventory. Teams that settle these points early usually see fewer open questions in the draft report, though the time saved depends on the size and state of your codebase, which should be confirmed during scoping.

What to check before choosing an SBOM review provider

An SBOM and dependency review is only as useful as the inventory and judgment behind it. The cards below cover the skills, boundaries and deliverables that separate a usable review from a tool export, and they apply whichever provider you shortlist.

Fluency in CycloneDX and SPDX

Ask the provider which format they will produce and why. CycloneDX and SPDX cover overlapping but different ground, and your customers or tools may require one over the other. Check that the provider can explain how each format records components, versions, hashes, licenses and relationships, and that they can validate output against the schema the format defines. Ask how they handle the NTIA minimum data fields, since a file that omits them may fail a customer review even when it parses correctly.

Experience with your language ecosystems

Dependency resolution differs across npm, Maven, PyPI, Go modules, NuGet and container base images. Ask for examples of SBOM generation in the ecosystems you use, including how lockfiles, transitive dependencies, vendored code and build-time-only packages are handled. A provider who has only scanned one language will tend to miss inventory gaps in the others. Request a short description of how they would confirm the inventory is complete for your largest build target.

A written scope and deliverables list

Before work starts, the scope should name the repositories, build targets, container images, products and time window covered, plus the exact outputs: SBOM files, vulnerability findings, license findings, a prioritized remediation list and a retest. Ask what is excluded, such as runtime-only components or vendor binaries without source. Fixed-scope agreements make cost and effort comparable between bids, so ask each provider to quote against the same written list.

Bounded license advice

License findings usually identify the license expression, flag copyleft or unknown terms, and note conflicts with your distribution model. They do not settle legal questions. Confirm in writing that license analysis is technical and is not legal advice, and that your counsel makes the final decision on obligations and exceptions. Ask how the provider records unknown or missing license data, since those gaps are often the largest source of uncertainty.

Handling of confidential source code

Reviewing dependencies often means reading manifests, lockfiles and sometimes source. Ask where analysis runs, which tools transmit data outside your environment, who on the provider's team can access the code, how access is revoked at the end, and whether the work can run inside your own build infrastructure or an air-gapped network. Request the data handling terms in writing before any repository access is granted.

Retest terms and keeping the inventory current

A one-off SBOM is out of date after the next dependency update. Ask whether the quote includes a retest after remediation, how many retest rounds are covered, and whether the provider will help set up regeneration on each build or release. Clarify which steps recur, such as scheduled scans or dependency alerts, and which are one-time, such as the initial inventory. Ask what a retest will verify and what happens to findings that are accepted as risk.

Explaining findings to customers and auditors

Your customer, assessor or regulator will ask how the inventory was produced and why certain findings were accepted. Ask for a sample report and check whether it states the tools, versions, data sources, scan dates and limitations in plain language. Confirm the provider can walk your product security team and an external assessor through the method. Keep in mind that an independent auditor or certification body issues any assessment opinion, so the provider's report should support that work rather than replace it.

How much effort does an SBOM review take and can we do it ourselves?

Can our own engineers generate an SBOM without outside help?

Yes, in most build environments your team can generate an SBOM with tooling already in the pipeline, and that is usually the right starting point. The output is only as good as the build it describes, so the first job is making sure the generator sees the real dependency tree, including transitive packages, container base images and vendored code. The NTIA's *Minimum Elements for a Software Bill of Materials* defines the data fields, automation support and practices an SBOM should meet, which gives your team a checklist to test its own output against. Confirm with any provider which of those elements they will verify and whether they will check the SBOM against your actual build artifacts.

What does an outside reviewer add to an SBOM we generated ourselves?

An outside reviewer checks whether the inventory is complete and accurate, not just whether a file exists. They compare the SBOM against the build, look for missing components and misidentified versions, assess which findings are reachable in your application, and review the license and maintenance data behind each dependency. They also test the process around the SBOM: who updates it, how it is triggered on every release, and how it links to vulnerability triage. Internal teams often miss gaps they have built themselves, so an independent check is most valuable before the SBOM goes to a customer or auditor.

Should we choose CycloneDX or SPDX for our SBOM?

Both formats are recognized standards, so the choice usually depends on the tools your ecosystem supports and what your customers or regulators ask for. CycloneDX is published as the Ecma standard ECMA-424 and its current specification version is 1.7, released on 21 October 2025. SPDX is recognized as the international open standard ISO/IEC 5962:2021, and SPDX 3.0.0 was released in April 2024 under Linux Foundation governance. Confirm which version your scanners, procurement teams and customers accept, and agree the format in the written scope so that the deliverable matches what the recipient can read.

How long does an SBOM review take and what makes it longer?

The duration depends mainly on the number of applications and services in scope, how many languages and package managers they use, whether build pipelines are reproducible, and how much vendored or container-based software sits inside the products. Reviews of a single application with a clean build usually move faster than a portfolio with legacy components and no pipeline automation. Access to developers who can explain build steps and to the people who own each product also shapes the schedule. No fixed duration applies to every estate, so ask any provider to state the assumptions behind its timeline in the written scope.

Is a dependency vulnerability scanner enough on its own?

A scanner is necessary but not sufficient. Scanners match component names and versions against vulnerability databases, which produces both false positives and false negatives: a flagged library may not be reachable in your code, and a repackaged or unlisted component may not be flagged at all. A review adds judgment about exploitability, checks maintenance health and license terms that scanners often report poorly, and examines whether the pipeline pins dependencies and verifies their integrity. OpenSSF Scorecard offers automated checks on open-source repositories, which can inform this review, but it does not replace it for your own build.

How does retesting work after we fix findings from an SBOM review?

Retesting usually re-runs SBOM generation on the updated build, confirms that the flagged components were removed, upgraded or documented as accepted risks, and checks that the vulnerability data has been refreshed. It is normally scoped as a smaller follow-up than the original review, but the exact coverage should be written into the agreement. Ask the provider whether retesting covers only the findings listed in the original report or also a fresh inventory comparison, and whether it includes a check of the process changes you made to keep the SBOM current.

Will an SBOM review satisfy our auditor or customer?

An SBOM and its review are evidence that supports an assessment, but they do not certify your software or your compliance. ISO/IEC 27001:2022 Annex A control A.8.28 Secure coding and A.8.29 Security testing in development and acceptance are the controls where this evidence is typically referenced. DORA Article 25(1) lists source code reviews where feasible and open source analyses among appropriate tests. Independent auditors and certification bodies decide whether the evidence is sufficient. Confirm with your auditor or customer which format, scope and report contents they expect before the work starts.

What should we prepare before asking for an SBOM review quote?

A quote follows from a written scope, so the more precise your input, the more accurate the estimate. Prepare a list of products and services in scope, their languages and package managers, how builds and releases run, whether SBOMs are already generated, and which formats your customers require. Also name the internal owners who can answer build questions. Expect ongoing costs as well as the initial review: keeping the inventory current across releases is usually a recurring activity, and ask whether the quote includes handover of the process or a retainer for updates.

How DeployOpen scopes, reviews and retests SBOMs

DeployOpen is a Chainscore Labs company that runs security testing and prepares systems and evidence for compliance assessments. We do not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, and an SBOM review from us is an input to their work, not a substitute for it. Most SBOM and dependency engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts. The written scope should name the products or repositories covered, the SBOM format (CycloneDX or SPDX), the build outputs that must match the SBOM, the tools and access provided, and the people who will answer questions about build and release processes.

We do not publish a price list. A quote follows from the written scope, so the inputs that move it are the number of products and versions, how many build pipelines produce artifacts, whether the SBOM must be generated or only checked, whether vendor and third-party components need separate handling, and whether the client wants a license review in addition to vulnerability and maintenance checks. Ask for the quote to separate one-time work (initial inventory, baseline findings, and the process design) from recurring work (regeneration, triage and retesting). The review itself compares the SBOM against the build, checks that component identifiers and versions are accurate, triages known vulnerabilities by reachability and exposure, flags unmaintained or license-conflicting components, and records what the client should accept, fix or track.

Findings are reported with the affected component, the evidence, the recommended action and an owner. Retest is written into the scope: after the client fixes or formally accepts a finding, we verify the change in the SBOM and the build output and update the report. For clients who need the inventory kept current across releases, a retainer can cover regeneration on each build, periodic dependency and advisory triage, and an agreed cadence of re-reviews. Confirm with us, before signing, exactly which of these recur, who receives the output, and how the SBOM will be stored and versioned so that your auditor or customer can trace each release to its inventory.