Completeness
Does the SBOM include transitive dependencies and build-added components?
Dependency analysis focus
Indicative view, not a measurement: 3 primary focus, 2 usual component, 1 context or scope-dependent, 0 outside normal scope.
| Area | Level |
|---|---|
| Design and trust boundaries | limited focus |
| Authentication and authorisation | out of scope |
| Inputs and data processing | limited focus |
| Business logic | out of scope |
| Secrets and cryptography | limited focus |
| Dependencies and builds | primary focus |
Third-party code is part of your product
Applications rely on open-source libraries, frameworks and container images. Their defects and licences become part of your product even when you did not write them.
Dependency analysis asks what the software contains, which components have known vulnerabilities or other risks, and which are relevant to you.
- Direct and transitive application dependencies.
- Container images and base system packages within scope.
- Component age, maintenance and origin.
- Known vulnerabilities and their relevance to your use.
- A licence inventory to support your legal assessment.
Tool results verified in context
SCA tools compare components against public vulnerability databases such as OSV. Results can be long and include findings without practical impact. For significant items, we verify reachability, configuration and availability of a fixed version.
Where included, we also assess the path from source to release: dependency sources, pinned versions, build permissions and CI secrets. We draw on OWASP SCVS and NIST SSDF secure development guidance. This is not certification or a formal compliance assessment.
SBOM preparation or validation
A Software Bill of Materials is a machine-readable component inventory. Some buyers require it as part of delivery. We help create one or verify it against the built version.
We use open CycloneDX (ECMA-424) and SPDX (ISO/IEC 5962:2021) formats, adapting detail to customer requirements or internal processes.
Accuracy
Do versions and identifiers match the actual release?
Maintainability
Is the SBOM generated automatically for every build or only once?
Typical findings
Vulnerable versions
Components with known vulnerabilities and available fixed versions.
Unmaintained components
Libraries without active maintenance or clear ownership.
Unpinned versions
Dependencies downloaded without pinned versions or integrity checks.
Weak build security
Excessive CI permissions, unprotected secrets or unverified package sources.
Deliverables and required inputs
We need access to a specific code revision or built artefacts, dependency files and build instructions. Analysis captures the state at the time. New vulnerabilities emerge continually, so we recommend ongoing dependency checks in development. Retesting and follow-up consultation are agreed in the proposal.
- A component inventory and prioritised, relevance-verified risks.
- Recommended updates, replacements or temporary mitigations.
- A prepared or validated SBOM within agreed scope.
- Recommendations for ongoing dependency management in development.
