Software Supply Chain & SBOM Assurance
Most modern applications are 80% other people's code. We map what's actually inside your software — dependencies, build pipeline, artifact flow — produce accurate SBOMs, and harden the path from commit to production against the tampering attacks hitting real supply chains.
Verified Solvex Specialist
Verified by SolvexDirect specialist contact for Solvex engagements
What this means. An authorized Solvex administrator registered and approved this exact public identity. What it does not. Solvex has not inspected the account on the platform, and this is not the platform's own verification.
Solvex specialists never ask for your passwords, recovery phrases, one-time codes, or payments to a personal account. Work, scope and invoices are agreed in writing through the official channels on this site.
Signed authorization required. This engagement is performed only against systems you own or are contractually authorized to have tested, under an agreed scope. See the responsible testing policy.
What's covered
- Full dependency inventory: direct, transitive, vendored and container base layers
- SBOM generation (CycloneDX/SPDX) and validation of any existing SBOMs
- Build-pipeline integrity review: source, build, artifact signing, deployment path
- Dependency risk analysis: known vulnerabilities, maintenance health, typosquatting exposure
- Artifact provenance and signing posture (SLSA-aligned review)
- Third-party and vendor component intake process review
What you receive
- Machine-readable SBOMs (CycloneDX and/or SPDX) for the systems in scope
- Supply-chain risk report: vulnerable, abandoned and high-risk dependencies prioritised
- Build-pipeline hardening plan mapped to SLSA levels
- A repeatable SBOM generation process wired into your CI
- Customer- and regulator-ready SBOM documentation guidance
Evidence and reporting
How the work is kept honest- Evidence, frozen at issuanceFindings tie to something observed. When the report is issued, the evidence behind it is frozen in the same transaction and cannot be edited afterwards.
- A signed reportAn Ed25519 signature covers both the report content and the delivered file. Alter a byte of either and verification fails.
- Signed scope firstTesting starts only after written scope and signed authorization for systems you own or are entitled to have tested.
Anyone holding a Solvex report can verify it publicly without seeing its contents.
Our boundaries
What this engagement does not do, stated before it starts.
- SBOMs reflect what analysis can see — we state coverage and blind spots explicitly
- We don't certify third-party components as vulnerability-free
- Fixing or upgrading dependencies is your engineering work unless separately engaged
- Access is read-only to repositories and pipelines; we never modify your build
How this engagement runs
- 01
Intake
Tell us the system, the goal and the constraints. If the work is not a good fit, we say so before anyone is invoiced.
- 02
Scope and authorization
Written scope and signed authorization before anything is touched. Security testing runs only against systems you own or are contractually entitled to have tested.
- 03
Investigation or build
Specialists matched to the work. Findings are proven by hand — scanner output is a lead, never a finding.
- 04
Evidence
Every finding ties to something observed. When a report is issued, its evidence is frozen in the same transaction, so what backed the report cannot change afterwards.
- 05
Delivery
A signed report: an Ed25519 signature over both the content and the file, with a short verification reference you can read down a phone.
- 06
Verification and retest
Anyone holding the report can verify it publicly without seeing its contents. Fixes are retested as part of the engagement — “fixed” means we confirmed it.
Questions we are asked
- Why do we need an SBOM?
- Two reasons: response speed and obligation. When the next Log4j lands, an accurate SBOM answers 'are we affected?' in minutes instead of weeks. And SBOMs are increasingly required — US federal procurement, the EU Cyber Resilience Act and enterprise customers all now ask for them.
- Our scanner already lists our dependencies. Isn't that enough?
- Scanner output is a starting point, but it routinely misses vendored code, dynamically-loaded components and container base layers, and it says nothing about your build pipeline's integrity. This engagement validates what the tools see, fills the gaps, and hardens the path your code travels from commit to production.
- What is SLSA and do we need the highest level?
- SLSA is a maturity framework for build integrity — from basic provenance to fully hardened, verifiable builds. Most organisations shouldn't jump to the top level; we map where you are, where your risk and customer requirements say you need to be, and the pragmatic path between.
Related services
Cloud / DevSecOps
DevSecOps CI/CD Pipeline Audit
Your build pipeline is a high-value target and a chance to catch flaws early. We audit your CI/CD for security gaps, embedded secrets and supply-chain risk, and help you shift security left without slowing delivery.
Governance / Compliance
Supply Chain Risk Management
Your security is only as strong as your vendors'. We assess and help you manage third-party and supply-chain risk, so a supplier's weakness doesn't become your breach — as headline incidents keep proving.
Offensive / Testing
Secure Source Code Review
Some flaws only reveal themselves in the code. Our experts read your source — by hand, guided by tooling — to find vulnerabilities, insecure patterns and design weaknesses that black-box testing can miss.