APP / APP-04
Dependency and software supply-chain security — SCA/SBOM
Know a software product’s components and govern provenance, vulnerabilities and updates. An SBOM describes components; it must be used and maintained to support security.
WHEN IT HELPS
A focused response
to a defined need.
Many open-source dependencies, customer demand for a software bill of materials, supplier incident or inability to identify products using a vulnerable component.
SCOPE & OUTCOMES
What the engagement covers.
Scope
- Component inventory
- direct/transitive dependencies
- SBOM
- vulnerability analysis
- artefact provenance
- signatures where needed
- updates
- exception handling
Deliverables
- Version-linked SBOM
- dependency register
- contextual prioritisation
- provenance policy
- update process
- verification evidence and coverage limitations
Acceptance evidence
The target version’s SBOM is reproducible; critical components are identified; a test alert maps to affected products; update and exception processes work.
DELIVERY
How the work is structured.
Approach
Understand architecture; select risks and requirements; integrate or verify controls; test; hand over to teams and plan regression checks.
Prerequisites & responsibilities
Customer: code, architecture, developers, test environment and pipeline access. Provider: expertise and checks; code remediation only when included.
Scope factors
Applications, languages, repositories, dependencies, roles, pipelines, volume and depth. Separate tooling licenses, remediation development and maintenance.
Questions to clarify
Can the components of each version be reconstructed? Who tracks vulnerabilities after release? Are dependencies inside images and binaries visible?
IMPORTANT BOUNDARIES
A vulnerable component’s presence does not always prove exploitability, and absence from an incomplete SBOM does not prove actual absence. Software licensing requires separate analysis.
Controls apply to agreed versions and scope. No scanner, SBOM or framework alone guarantees the security of delivered software.
IN PRACTICE
Illustrative situations.
These examples describe possible engagements and target outcomes. They are not customer references or achieved results.
Scenario 01
A vendor receives an alert about a common library. Project: map SBOMs to shipped versions and assess exposure. Target outcome: a justified list of products to fix rather than a uniform reaction across the catalogue.
Scenario 02
A customer requests SBOMs from suppliers. Project: define format, versioning and use of results. Target outcome: actionable information; incomplete or outdated SBOMs are flagged rather than treated as guarantees.
Technology and reference context
Examples: SCA/SBOM and provenance-verification tools; NIST SSDF practices, with formats and integrations defined during scoping.
The final technology set is agreed during scoping, based on interoperability, licensing, access rights and operating requirements.
CONNECTED SERVICES
Build the next step.
These services can complement the engagement. They are not automatically included.
START A CONVERSATION
Make the scope clear.
We will clarify the objective, dependencies and responsibilities of this service before proposing delivery.