Control over what your software is built from — and proof that the package at the client came out of your process.
Your client checks where the package came from without asking you for a statement.
This is the starting point in many companies that ship fast and are regulated.
Most of your product is someone else's code. No one has to attack you directly — a library or a tool you use is enough. One compromised element reaches everyone who downloads it, along with the update.
We define the scope after an assessment — starting with the element that lowers your risk fastest.
You know what your product is built from.
We generate the bill of materials automatically with every release, not by hand once a year — so the question "do you use this library" stops being a week-long project. We sign artifacts so the client can independently verify they received what came out of your process. New dependencies pass a check before they enter the project, because the cheapest moment to reject a risky library is before it is added. We arrange the whole thing to close the technical layer of the CRA requirements.
Each stage leaves you with a concrete result, not meeting notes.
An SBOM generated automatically with every release, not once a year by hand.
ResultAn SBOM generated automatically with every release
The client can verify they received what came out of your process.
ResultSigned artifacts your client can verify on their own
A new library passes a check before it enters the project.
ResultRules for accepting new dependencies, built into code review
Technical documentation and the ability to respond to a vulnerability report.
ResultTechnical documentation and a vulnerability reporting procedure for the CRA
Implementation ends with working configuration and evidence, not a report full of recommendations. Here is an example.
# signing without long-lived keys
cosign sign registry.example.com/api@sha256:4f3c…
# verification on the client side
cosign verify \
--certificate-identity-regexp '^https://github.com/acme/' \
--certificate-oidc-issuer \
https://token.actions.githubusercontent.com \
registry.example.com/api@sha256:4f3c…Your client knows they received exactly what left your process.
| Component | Version | License |
|---|---|---|
| openssl | 3.0.15 | Apache-2.0 |
| zlib | 1.3.1 | Zlib |
| log4j-core | 2.24.1 | Apache-2.0 |
“Do you use this library?” becomes a single search.
Templates and roles are agreed before the first report is due.
Illustration. We choose scope and tools after the assessment. We cover the technical layer; full CRA compliance also requires organisational and legal measures.
We define the scope after a call and an assessment. Smaller engagements close in a few weeks; larger ones we split into stages, so the result is visible after the first.
Usually not to all of it. In most cases access to the build pipeline configuration and organization settings is enough. We define the scope in writing before we start.
Yes, but not full time. We need contact with someone who knows the system, and a review of our changes. The rest is on us.
We plug into what already works for you. Replacing a tool is the most expensive and least often necessary way to improve security.
No. We work with standards and tools your team knows or will quickly learn — not a proprietary method only we understand. Everything is documented and handed over.
We wire controls so they run in the background. If one starts blocking work, we tune it or move it to a different point in the process.