DevSecOps and Software Supply Chain

Build and Release Integrity

We enable you to prove with signatures and records that every package you release comes from the approved source and an untampered build. Any change during the build is detected before deployment.

Schedule a Meeting All services in this area

What it is

A process reviewing source code cannot see code inserted in the build environment. Such tampering can reach all customers in an update that is signed and appears legitimate. Build integrity relies on a provenance record documenting which source, environment, and steps produced each package. The SLSA framework organizes these controls into levels, making it easier to set targets.

Scope

Isolation of the build environment and separation from developer access
Signed provenance record for each package
Signing of packages and images, and protection of signing keys
Verification of signature and provenance before deployment
Current state and target according to SLSA levels
Retention of release records for audit

The need

When organizations need it

As a bank, when you need to demonstrate code integrity controls during transfers between environments for audit.
When you distribute updates to customers as a software vendor and must prove the update originated from you.
When multiple teams share your build servers and it is unclear who can change what.

Method

How we work

Flow

We identify every step from source code to released package, and who can intervene at each step.
Target level

We determine your current state against SLSA levels and set a realistic target for your products.
Signing and provenance

We design package signing, provenance generation, and key protection.
Verification

We add a control to the deployment step that rejects any package whose signature or provenance cannot be verified.

Outcome

What you have at the end

For every package you release, signed records show its source and build. Any package that cannot be verified is blocked at deployment.

Frequently asked questions

We have a code signing certificate. Is that sufficient?

A signature shows the package was signed with your key. Code added during the build can also be signed with the same key. Provenance and an isolated build environment close this gap.

Are reproducible builds required?

They are not required and are not easy in every language. For critical components, they provide extra assurance by showing that an independent build produces the same output.

Is SLSA a certification?

No. SLSA is an open framework that structures software supply chain controls in levels. You can demonstrate with records which level you meet.

DevSecOps and Software Supply Chain