How SALT works

There are techniques that help to keep the integrity and authentication of each element in a modern software pipeline. At the Source Control Management system, signing commits / tags is a well-known technique.

Regarding the build / deploy pipelines, the build infrastructure should have the same level of security configuration as its generated artifacts' target runtime environment. Jobs (or steps) are the atomic build tasks that run in a single worker/runner (often a provisioned container or VM, but there are other options: serverless, sandboxes, secure enclaves…​). To keep the integrity of the build process:

• each step should have clearly defined inputs -materials- and outputs -artifacts-,

• step logic should be immutable, typically by pinning versions in build tools including plugins, extensions and reusable tasks,

• generation of attestations should be done, for out-of-band verification of the build process. This last practice is the goal of SALT.

SALT (acronym for Software Attestation Layer for Trust) is the feature in the Xygeni platform for build security. SALT is the infrastructure for creating and verifying software attestations, aiming at different use-cases.

A command-line interface (salt command) is provided for generating attestations in CI/CD pipelines, or for verification of the integrity of the attestations with regard to the software artifacts the attestation refers to. Additional integrations, like plugins, are provided for the most popular CI/CD systems. See command-line reference for further details.

Xygeni provides an attestation registry based on the combination of the in-toto Archivista as storage and sigstore Rekor as transparency log. The public server for the Xygeni-provided attestation registry is at https://salt.xygeni.io.

Result upload: The results for the attestation generation are uploaded to Xygeni, so any error or integrity failure is reported and could be notified to DevOps engineers and security management teams.