Skip to content
ISO 27001, SOC 2, the DPDP Act and manual VAPT.
Standalone ServiceIts own practice area, with no sub-services beneath it

Supply-Chain Security

Software Composition Analysis (SCA) Services

We analyse the open-source and third-party dependencies in your applications for known vulnerabilities, license risk and supply-chain integrity, and generate an SBOM you can trust. Then we help you fix what matters and keep it fixed in CI.

Request an AssessmentBook a Scoping Call

See the engagement path, 6 phases

Overview

The components you depend on carry their own bugs, their own licenses and their own supply chains. When one of them is compromised or a new CVE lands, your application inherits the problem. Software Composition Analysis makes that surface visible. We build a complete dependency inventory including transitive packages, generate a standards-based SBOM, and map every component to known vulnerabilities in CVE, NVD and OSV. We then triage by reachability so you fix what is genuinely exposed first, review licenses against your policy, and wire continuous checks into your pipeline so the picture stays current.

Methodology

How the Engagement Runs

Every phase has a named output, so you always know what is being worked on and what lands on your side of the table.

The Engagement, End to End

6 Phases, 6 Named Handovers

Flow

Flow chart of the Software Composition Analysis (SCA) engagement, 6 phases in order, each one selectable. Phase 1, Dependency Inventory and SBOM. We enumerate every direct and transitive dependency across your projects and generate a standards-based SBOM in CycloneDX or SPDX format. Activities: Enumerate direct and transitive dependencies per repository; Generate an SBOM in CycloneDX format; Record component versions, origins and build tooling; Reconcile the inventory with what you actually ship. Hands over CycloneDX SBOM. Phase 2, Vulnerability Mapping. We match each component and version against CVE, NVD and OSV data to surface known vulnerabilities, with severity and affected version ranges. Activities: Match dependencies against CVE and OSV data; Confirm affected version ranges against your pinned versions; Flag abandoned and unmaintained components; Record severity and available fix versions. Hands over Mapped Vulnerability Inventory. Phase 3, Reachability and Exploitability Triage. We assess whether vulnerable code is actually called and reachable in your application, so you prioritise real exposure over theoretical alerts. Activities: Check whether vulnerable code is actually reachable; Trace call paths from your code into the affected function; Separate runtime dependencies from build and test only; Rank exposure by reachability, severity and fix effort. Hands over Reachability-Ranked Exposure List. Phase 4, License and Policy Review. We check every dependency license against your policy and flag copyleft, incompatible or unknown licenses before they become a legal problem. Activities: Resolve the licence of every component including transitives; Flag licence conflicts against your policy; Highlight copyleft obligations in distributed code; List components with missing or ambiguous licences. Hands over Licence Risk Register. Phase 5, Remediation and Pinning. We recommend safe upgrade paths, pin versions, and guide replacements for abandoned or high-risk components so fixes do not break your build. Activities: Plan upgrade paths that avoid breaking changes; Pin versions and add a lockfile discipline; Recommend replacements for abandoned packages; Group fixes into batches your team can ship. Hands over Prioritised Remediation Plan. Phase 6, Continuous Monitoring in CI. We wire SCA checks into your pipeline so new vulnerabilities and license changes are caught on every build, not months later. Activities: Wire the scan into the CI pipeline; Set the policy for what blocks a build and what warns; Automate SBOM generation on every release; Route new alerts to the team that owns the service. Hands over CI Policy Gate. Each phase begins from the artefact the phase before it produced.

Phase 01 Dependency Inventory and SBOM

We enumerate every direct and transitive dependency across your projects and generate a standards-based SBOM in CycloneDX or SPDX format.

What Happens In This Phase

  • Enumerate direct and transitive dependencies per repository
  • Generate an SBOM in CycloneDX format
  • Record component versions, origins and build tooling
  • Reconcile the inventory with what you actually ship

The Handover

CycloneDX SBOM

The next phase starts from this.

Read the handover cards on their own and you have the paper trail. Select a phase to see what happens inside it.
  1. 01

    Dependency Inventory and SBOM

    We enumerate every direct and transitive dependency across your projects and generate a standards-based SBOM in CycloneDX or SPDX format.

    OutputCycloneDX SBOM

    Activities

    • Enumerate direct and transitive dependencies per repository
    • Generate an SBOM in CycloneDX format
    • Record component versions, origins and build tooling
    • Reconcile the inventory with what you actually ship
  2. 02

    Vulnerability Mapping

    We match each component and version against CVE, NVD and OSV data to surface known vulnerabilities, with severity and affected version ranges.

    OutputMapped Vulnerability Inventory

    Activities

    • Match dependencies against CVE and OSV data
    • Confirm affected version ranges against your pinned versions
    • Flag abandoned and unmaintained components
    • Record severity and available fix versions
  3. 03

    Reachability and Exploitability Triage

    We assess whether vulnerable code is actually called and reachable in your application, so you prioritise real exposure over theoretical alerts.

    OutputReachability-Ranked Exposure List

    Activities

    • Check whether vulnerable code is actually reachable
    • Trace call paths from your code into the affected function
    • Separate runtime dependencies from build and test only
    • Rank exposure by reachability, severity and fix effort
  4. 04

    License and Policy Review

    We check every dependency license against your policy and flag copyleft, incompatible or unknown licenses before they become a legal problem.

    OutputLicence Risk Register

    Activities

    • Resolve the licence of every component including transitives
    • Flag licence conflicts against your policy
    • Highlight copyleft obligations in distributed code
    • List components with missing or ambiguous licences
  5. 05

    Remediation and Pinning

    We recommend safe upgrade paths, pin versions, and guide replacements for abandoned or high-risk components so fixes do not break your build.

    OutputPrioritised Remediation Plan

    Activities

    • Plan upgrade paths that avoid breaking changes
    • Pin versions and add a lockfile discipline
    • Recommend replacements for abandoned packages
    • Group fixes into batches your team can ship
  6. 06

    Continuous Monitoring in CI

    We wire SCA checks into your pipeline so new vulnerabilities and license changes are caught on every build, not months later.

    OutputCI Policy Gate

    Activities

    • Wire the scan into the CI pipeline
    • Set the policy for what blocks a build and what warns
    • Automate SBOM generation on every release
    • Route new alerts to the team that owns the service

Specification

What We Run, and What We Measure You Against

The tooling our engineers use on this work, and the published standards the findings and evidence are mapped to.

Scope

What Is Examined, and What it Is Measured Against

Map

Map of the Software Composition Analysis (SCA) scope, running left to right in three stages. Stage one, what we run, 9 tools and techniques: Snyk, OWASP Dependency-Check, Trivy, Grype, Syft, Dependabot, Renovate, OSV-Scanner, Black Duck. Stage two, findings from all of it are proven by hand and written up once. Stage three, measured against 8 published standards: OWASP Dependency-Check standards, CycloneDX, SPDX, NIST SSDF (SP 800-218), SLSA, CISA SBOM guidance, CVE/NVD, OSV.

What We Run

9 tools

  • Snyk
  • OWASP Dependency-Check
  • Trivy
  • Grype
  • Syft
  • Dependabot
  • Renovate
  • OSV-Scanner
  • Black Duck

Converges On

One Set of Proven Findings

Every issue is reproduced by hand before it is written down, and it is written down once.

Measured Against

8 standards

  • OWASPDependency-Check
  • OWASPCycloneDX
  • SPDXLinux Foundation
  • NIST SSDF (SP 800-218)
  • SLSAOpenSSF
  • CISASBOM Guidance
  • CVE/NVDMITRE, NIST
  • OSVOpenSSF
One pass of testing and analysis, one set of findings, then that single set is graded against every standard on the right. You are not paying for the same work once per framework.

Deliverables

What You Receive

  • Standards-based SBOM in CycloneDX or SPDX format
  • Ranked vulnerability report mapped to CVE, NVD and OSV with reachability context
  • License and policy risk summary with flagged components
  • Remediation and pinning plan with safe upgrade paths
  • CI integration guidance for continuous monitoring

Scope This Engagement

Tell us about your environment, your timelines and any audit dates you are working to. We come back with scope, effort and a start date.

Request an AssessmentBook a Scoping Call

Questions

What Clients Ask Us

Something here not covered? Ask Us Directly.

What is an SBOM and why do I need one?

An SBOM, or software bill of materials, is a complete list of the components your application is built from. It lets you answer 'are we affected?' in minutes when a new vulnerability lands, and it is increasingly expected by customers and regulators. We generate yours in CycloneDX or SPDX so it works with your tooling.

How do you decide which vulnerabilities to fix first?

We rank by real exposure, not raw counts. Reachability triage tells us whether the vulnerable code is actually called in your application, and we combine that with severity and how easy the fix is. That keeps your team working on genuine risk instead of chasing every alert.

Can this run automatically on every build?

Yes. We wire SCA into your CI pipeline so each build is checked against the latest vulnerability and license data. New issues surface as they appear, and you set the policy for what blocks a build versus what raises a warning.

Elsewhere

Other Practice Areas

All Services