The challenge behind the engagement.
Software supply chain security keeps a compromised package or build step out of production and backs the assurances your customers ask for. We review how outside code enters your builds, from public and private sources, and whether versions are pinned and screened. We rate how strongly each pipeline protects what it builds, and check the software bill of materials you produce against current expectations. We look for the weaknesses behind recent supply-chain attacks: unvetted build steps, long-lived credentials in the pipeline, and maintainers without strong sign-in. We design a way to sign what you ship and to refuse anything unsigned before it reaches production. You receive a rating for each pipeline, a review of your bill of materials, a signing design, and a remediation plan. Build-integrity ratings are claims you make and customers verify; no one certifies them.
For platform and engineering leaders whose customers or federal primes ask for a software bill of materials or evidence of how you build and secure your software. Also for teams that just rotated every pipeline credential after a dependency or build-tool compromise and want the next one to fail at the gate.
What we do.
What you can use.
Map registry to runtime
You grant read access to your source control settings, build configuration, the registries that hold your packages and images, your package and version files, and any existing bill of materials or signing setup. We agree the pipelines and ecosystems in scope, list the outside software that enters your builds, and trace the path from download to running workload. No production data is touched.
Rate build integrity and your bill of materials
Each pipeline gets a build-integrity rating covering how it is built and how its source is controlled, and we check how outside code is brought in. Your bill of materials is compared to current expectations, including the newer details on component identity, licensing, and how the list was produced. We score every repository in scope and check for the weaknesses behind recent supply-chain attacks.
Design signing, then prove it blocks
We design a way to sign what you ship and prove where it came from, using tools you already use, plus a deployment check that refuses anything not signed. When you want us to implement it, the changes go in as proposed changes your team reviews. The evidence is a signed release, a verifiable build record, and a blocked attempt to deploy something unsigned.
Who it’s for.
When you need it.
- Software producers whose customers or federal primes request a software bill of materials or build-integrity evidence
- Platform teams pulling open-source packages from public registries into production builds
- Organizations recovering from a compromised dependency or a poisoned build tool
- Product teams that must show where an artifact came from and how it was built
- A customer contract now requires an SBOM or provenance you cannot yet produce
- A dependency or build-action compromise has forced a mass credential rotation
- A federal prime or agency asks for evidence of secure-development and supply-chain practices
- You are standardizing build platforms after a merger or a tooling migration
What the scope can include.
- 01
How outside code enters your builds, from public and private sources: a controlled gateway, pinned versions, and how advisories are handled
- 02
The build-integrity level each pipeline reaches, with the gap to the level your customers ask for
- 03
Your software bill of materials checked against current expectations and regenerated with every release
- 04
Signing and provenance: how releases are signed and recorded, and whether anything downstream verifies them before deploy
- 05
Exposure to the weaknesses behind recent supply-chain attacks: unvetted build steps, long-lived credentials in the pipeline, and maintainers without strong sign-in
- 06
How you vet vendor software before you buy it, and how you answer "are we affected?" when a new advisory lands
What it typically costs.
One rate: $150/hour.
Every engagement is priced by the hours it takes at one flat rate, with scoping, the work, and the final deliverables included. Find the size closest to yours.
A handful of code repositories and one build pipeline
About 32–56 hours10 to 30 repositories, a few pipelines, a parts list for customers
About 72–120 hours50+ repositories and several build systems, with signing and verification designed in
About 140–240 hours- Number of repositories, package sources, and build pipelines
- Whether signing and verification before deploy must be designed
- Customer or contract requirements for a software parts list
- How many third-party build steps and outside packages are used
1–2 weeks for a small shop; 4–8 weeks for many repositories and build systems
Get a fixed quote for your scopeRanges are planning estimates at $150/hour, not a quote. Your price is confirmed in writing after a scoping call, before any work begins.
What you take forward.
- Assessment report rating each pipeline and mapped to recognized secure-supply-chain and secure-development practices
- A build-integrity level per pipeline, a review of your bill of materials against current expectations, and a repository health baseline
- Signing and verification design naming who signs, how it is recorded, and the point that refuses unsigned releases
- Remediation plan naming an owner for each build-integrity gap, missing bill-of-materials detail, and exposed pipeline credential, sequenced so quick wins land first
Final coverage, deliverables, timing, and any retesting or implementation work are confirmed before the engagement begins.
Before we get started.
A customer asked for a bill of materials and proof of how we build our software; what do we produce?
Two things. A software bill of materials, produced automatically at build time for each release, listing the components you ship and the newer details customers now expect. And evidence of build integrity, which is a statement about how your software is built, backed by a record the customer can verify. A middle level means signed evidence from a hosted build service; a higher level means isolated builds using keys the build itself cannot reach. No body certifies these levels. We help you meet the requirements and produce the evidence; your customer verifies it.
Did the 2026 federal policy change mean agencies no longer ask us for this?
Not quite. A 2026 policy change removed the single government-wide requirement to submit a standard secure-development attestation form. Agencies now set their own risk-based assurance policies, and many still ask for the same evidence: a current bill of materials on request, and assurances about how you build and secure your software. Primes often pass those terms down to subcontractors. In practice, expect some agencies and primes to keep asking. Building this evidence and a release-time bill of materials once lets you answer any of them without a scramble.
- Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities
- Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines
- SLSA specification
- 2026 Minimum Elements for a Software Bill of Materials (SBOM)
- OWASP Top 10 CI/CD Security Risks
- Threat Modeling - OWASP Cheat Sheet Series
- 2025 CWE Top 25 Most Dangerous Software Weaknesses