Pipeline & supply-chain security
Your build system can reach production. In most estates it does that with a static access key pasted into a settings field years ago, readable by everyone who has ever had repository access, and valid until somebody remembers to revoke it. We replace it with credentials that live for minutes.
Where this sits
How the work is shaped
A bounded engagement with a stated end. It is small enough to buy without a committee and specific enough that you can tell afterwards whether it worked.
Every credential the pipeline holds, what each one can reach, and when it was last rotated. Read-only, and no change to the build.
Short-lived federation in place of the static keys, third-party actions pinned to a digest, and the build role scoped to what it actually uses.
The old keys revoked, the build green, and a written record of what changed. You own every line of it in your own repository.
What we change
None of this is a product you buy from us. Every change lands as configuration your team reviews, owns and can revert without calling anyone.
Delete every static cloud credential from CI. Short-lived federation issues a token when the build runs and it dies when the job ends, so a leaked log line stops being an incident.
Third-party actions and base images pinned to a digest rather than a tag. A tag is a label its owner can repoint; a digest is the artefact itself.
Dependency and image scanning moved from a report nobody opens to a gate the build has to pass. Findings arrive at the pull request, not in a monthly export.
Most build roles carry the permissions of the first thing they ever deployed. We scope the role to what the pipeline actually calls, and nothing else.
Application secrets out of repositories and environment files and into a managed store, with rotation that happens on a schedule rather than after an incident.
Builds emit a software bill of materials with provenance attached. It is inventory and evidence, the fastest honest answer to what shipped and where it came from.
What we do not do
This is a narrow engagement on purpose. Three things sit outside it, and we would rather you read that here than discover it in week two.
There are good products in this category and we will tell you which one fits. We do not resell them, we take no margin on them, and most of what we change needs no product at all.
This engagement is about how the build runs and what it can reach. Static analysis of your own source is a separate discipline with separate tooling, and we will say so rather than pad the scope.
We leave you controls that fail loudly and a record of what changed. We do not staff a console. If you want the pipeline monitored around the clock, that is an MDR conversation and we will help you specify it.
Why this team
How engagement works
This is deliberately the smallest engagement we sell. It is bounded to a single week against a stated scope, it produces a change you can point at, and it does not roll into anything else unless you ask it to. Most estates need it once.
// start the conversation · [email protected]
Frequently asked
A secrets manager protects the credential at rest. It does not change the fact that the credential itself never expires, so anything that reads it once holds cloud access indefinitely. Federation removes the credential rather than storing it more carefully.
The exposure is rarely an attacker reaching the pipeline directly. It is a key printed into a build log, copied into a local environment file, or inherited by a contractor’s fork. A credential that expires in minutes survives all three.
Nor can we. The mapping phase is read-only and changes nothing. Federation runs alongside the existing key until the build is green on both, and only then is the old credential revoked. Rollback is one pull request.
Most teams do, and most of those scans produce a report rather than a decision. The change here is that the scan gates the build at an agreed severity, suppressions carry a named owner, and the findings arrive at the pull request.
It does not. Federation, digest pinning and role scoping are configuration in your own repositories, using what your cloud and CI platform already provide. Where a product genuinely helps we will name it, and we take no margin on it.
You do, because it never left. Every change is a reviewed pull request in your repository, written in the same infrastructure-as-code your platform already uses, with the reasoning recorded. There is no Calvrix component to keep paying for.