Software Supply Chain Security Testing
Software supply chain security testing across Europe: dependency, build and vendor risk mapped by OSCP engineers. SBOM, SCA and a fixed quote.
Supply chain security testing looks at the code and vendors you did not write but still ship and depend on: open-source packages, their transitive dependencies, build tooling, container base images and the third parties plugged into your systems. Most breaches now arrive through something you trusted, and this is where we find it before an attacker does.
Log4Shell, the xz backdoor and the SolarWinds build compromise all landed the same way: through a component an organisation trusted implicitly. Your own code can be clean while a single dependency five levels down the tree, or a vendor with access to your data, quietly opens the door. Testing the supply chain means treating everything you pull in or connect to as a potential entry point.
What supply chain security testing actually covers
We build a complete picture of what your software is made of and who it trusts, then probe each layer for the ways it could be poisoned, hijacked or misused. The output is not a generic list of CVEs; it is the specific set of components and relationships that put your organisation at real risk, ranked by what an attacker could actually do with them.
How we test your supply chain
The engagement runs in two connected tracks. The technical track pulls apart the software you build and ship; the vendor track evaluates the third parties you rely on. Both feed one risk picture, because an attacker does not care whether the weak link is a npm package or a SaaS vendor with an API key to your database.
Building the inventory
We generate a software bill of materials for the components in scope using formats your tooling can consume, then reconcile it against what is actually deployed. Teams are routinely surprised by what turns up: abandoned packages, duplicate versions, and dependencies nobody remembers adding.
Software composition analysis
We run software composition analysis with tools such as Syft for SBOM generation, Grype and Trivy for known-vulnerability matching, and OWASP Dependency-Check across the ecosystems you use. Findings are then triaged by hand so you get the vulnerabilities that are reachable in your code, not every CVE that exists in a library you barely call.
Testing for poisoning paths
We check whether your internal package names can be hijacked through dependency confusion, whether typosquatted lookalikes could slip into a build, and whether your registries and mirrors enforce integrity. Where you allow it, we demonstrate the path end to end so the risk is undeniable rather than theoretical.
Build and release integrity
We look at how artifacts are built, signed and promoted to production, and measure the maturity against the SLSA framework. A build nobody can verify is a build an attacker can quietly replace, and that is exactly how the largest supply-chain incidents happened.
Vendor and third-party risk
For the vendor track we run a structured vendor security assessment: what data each third party can touch, how they authenticate to you, what their own posture looks like, and what happens to your data if they are breached. We can drive this from an industry questionnaire such as the SIG or CAIQ so the output slots into your existing third party security risk management process.
Risks we find in the supply chain
The failure modes cluster into a handful of patterns. Recognising them is half the work; proving which ones apply to you is the other half.
Vulnerable and unmaintained dependencies
The obvious one, and still the most common. A known-vulnerable library reachable from an internet-facing endpoint, or a package that has not shipped a security update in years and never will. We prioritise by reachability and exposure, not by CVSS in a vacuum.
Dependency confusion and namespace hijacking
When your build can be tricked into pulling a public package that impersonates a private internal one. This turned into a mass-exploitation technique against major companies, and many private registries are still configured in a way that allows it.
Compromised build and distribution
Unsigned artifacts, mutable tags, and registries without access control, so a tampered image or package deploys as if it were legitimate. This is the SolarWinds class of problem, and the fix is integrity you can verify.
Over-trusted third parties
A marketing tool with a live API key to your customer database. A vendor whose breach becomes your breach because they held standing access they never needed. A vendor security assessment catches these before the incident, not after.
Tools and standards we work to
The technical work uses Syft, Grype, Trivy, OWASP Dependency-Check and Snyk for composition analysis, with cosign and Sigstore concepts applied to build integrity. We measure maturity against SLSA and the NIST Secure Software Development Framework, and align vendor findings to ISO 27001 supplier controls. Tools generate the raw picture; our engineers decide what is exploitable and what genuinely threatens you, because an unreachable vulnerability in a dev-only dependency is not the same risk as one on your login path.
Want this tested on your own systems?
Free 20-minute scoping call, a fixed price with no hourly surprises, and a free retest once you fix what we find.
What you get
The deliverables are built for both your engineers and your risk and procurement owners.
- A software bill of materials for the components in scope, in a format your tooling can ingest.
- A technical report scoring each finding by CVSS and, more usefully, by reachability and business exposure, with a concrete fix or version target.
- A vendor risk register from the security assessment, showing what each third party can access and where the gaps are.
- A prioritised remediation plan, a call with the reviewing engineer, and a free retest after you fix.
- An attestation letter mapped to your compliance obligation where you need one.
Compliance and standards
Supply chain testing supports a growing set of obligations. ISO 27001:2022 controls A.5.19 to A.5.23 cover supplier relationships and cloud services. DORA requires financial entities to manage ICT third-party risk with real oversight, and NIS2 extends supply-chain security duties across many essential and important entities in the EU. SOC 2 vendor-management criteria expect evidence of due diligence. We map the report and attestation to whichever of these you answer to.
How a supply-chain compromise actually unfolds
The pattern behind the headline incidents is consistent, and seeing it explains why testing the whole chain matters. An attacker does not go after your hardened application. They find a component you trust and slip their code in upstream, so it arrives inside a legitimate update you install without a second thought.
The trust that gets abused
It might be a popular open-source package whose maintainer account was phished, a build server compromised so every artifact it produces carries a backdoor, or a small dependency five levels down your tree that nobody reviews. Your pipeline pulls it, signs it as your own, and ships it to customers. The malicious code inherits every permission your legitimate software has.
What testing changes
We map the components and relationships that carry this risk for you specifically, then show which ones an attacker could realistically reach and what they would gain. That turns a vague fear into a ranked list of concrete actions: pin and verify these dependencies, lock down that registry, require signing on those artifacts, reduce that vendor’s access.
Open source is not the enemy
None of this is an argument against open source, which underpins nearly all modern software and is often better maintained than the closed alternatives. The point is to use it deliberately: know what you depend on, verify it, and have a plan for when one of those dependencies has a bad day. Most teams can cut their exposure sharply with a handful of process changes rather than by rewriting anything.
Keeping the picture current
A software bill of materials is only useful if it stays accurate, so we deliver it in a machine-readable format and show your team how to regenerate it as part of the build. New vulnerabilities appear in components that were clean when we tested them, which is why the SBOM plus a monitoring process matters more than a one-off report. We also flag the dependencies most likely to become a problem: unmaintained packages, single-maintainer projects, and anything with a track record of security issues. Where a component is both risky and hard to replace, we say so plainly and suggest how to reduce your reliance on it over time, rather than pretending a version bump makes the risk disappear.
Pricing
The supply chain security testing cost depends on how many applications and components are in scope, how deep the dependency tree runs, and how many third-party vendors you want assessed alongside the software.
| Engagement | What’s included | Timeline | Price |
|---|---|---|---|
| Application SBOM & SCA | One application, full dependency tree, SBOM generation, reachability triage, dependency-confusion check, report and free retest | 3–5 working days | from €3,000 |
| Software + build integrity | Multiple applications, container images, build and release integrity against SLSA, registry configuration, exec + technical report | 5–9 working days | €4,500–€10,000 |
| Software + vendor programme | Technical track plus a structured vendor security assessment of your key third parties with a risk register and questionnaire | 9–15 working days | €10,000–€22,000 |
| Compliance add-on | Mapping and attestation letter for ISO 27001, SOC 2, DORA or NIS2 | with any tier | from €800 |
| Custom / large estate | A full product portfolio and a wide vendor base, scoped to your needs | on scoping | custom |
Every engagement is fixed-price, quoted after a free 20-minute scoping call — no hourly surprises, and a retest is included. Get a fixed quote
FAQ
How much does supply chain security testing cost?
Do you generate a software bill of materials?
What is dependency confusion and do you test for it?
Do you assess our third-party vendors as well as our code?
How do you avoid drowning us in irrelevant CVEs?
What will you actually deliver?
Does this help with DORA, NIS2 or ISO 27001?
Will testing disrupt our systems or vendors?
Related services
Product teams shipping software built on open-source and container images, security and procurement teams responsible for third-party risk, and organisations facing DORA, NIS2 or ISO 27001 supplier obligations. We are a European offensive-security team working with clients EU-wide and remotely.
Security you can prove
The same standard on every engagement, big or small.
Evidence, not opinions
Every finding ships with a reproduction and proof of concept — no vague "maybe vulnerable".
Humans over scanners
Certified engineers find the logic flaws and chained attacks automated tools walk straight past.
Fixed price, free retest
You know the cost up front, and verifying the fix is part of the deal — not a second invoice.
Ready to lock this down?
Free scoping call, fixed price, free retest. Tell us what you're running and we'll take it from there — usually within one business day.
Tell us what you're running
Scoping is free. We reply within one business day, and under 30 minutes for active incidents.