SALT Architecture
Last updated
Last updated
The SALT data model contains most of the in-toto specification types for software attestations, including:
The in-toto , common format for signed attestations.
The in-toto , typically as payload of an in-toto Envelope.
, plus the older and versions.
All predicates in the in-toto , including:
(SCAI),
,
(VSA),
predicates for holding SBOM formats like and ,
predicate for vulnerability scanning results, and
predicate to express results of any type of tests.
The legacy in-toto and the new .
Xygeni specific predicates:
Collection, a collection of predicates. A better alternative to the in-toto for holding multiple predicates on the subjects.
CommandRun, a predicate with information for the execution of a command in a pipeline.Generated by the attestation run command.
Environment, a predicate with the system environment where the build/deploy is running.Generated by the environment attestor.
Git, a predicate with git data: information about last commit (sha1 hash, author and committer, message, commit signature if any), the commit parents, the git treeHash, and git refs pointing at it.Generated by the git attestor.
Materials, a predicate with materials (input resources) that were registered as relevant for the pipeline, by the attestation init and attestation add commands.
Products, a predicate with products (typically, by-products) that were generated at a certain step in a pipeline.
Xygeni Build Security includes the following elements:
Build provenance: metadata representing details on the pipeline, when and where the build were performed, inputs (materials) and outputs (artifacts produced) at each step,
Attestation agent, an actor that runs the checks, creates attestations (signing notes based on a policy associated with the build pipeline) and publishes them in the Attestations Registry.
Attestations Registry, a store for attestations providing an api for storing, fetching and searching for attestations.This could include a transparency, append-only ledger, that acts as a tamper-evident log.
Verifier, that ensures the integrity of an artifact according to the build security policy.The verifier is a consumer of attestations required by the policy, which grabs the attestations for the Attestations Registry and ensures the validity of the attestations.The verifier can be used at enforcement points like in admission controllers.
Build Security Policy, a definition of the checks to be performed at the build & deploy pipeline, on collected attestations to produce a final verification status, conformant or not with the policy. Attestations include evidence that cannot be tampered with, and which policies may refer to.
A “deny” result can be enforced (the artifact is not allowed to run at all) or alerted (the artifact is allowed to run, but a warning notification is emitted).
Please note that the Xygeni platform helps with hardening the build & deploy infrastructure by providing other tools, like build security checks, which detect if the build system satisfies certain security requirements, or otherwise have weaknesses that might be exploited by adversaries.
There are different elements in the support infrastructure for build security:
An Attestation Storage/Search Service (the “ledger” that holds the generated attestations and provides security services like timestamping, integrity, transparency, non-repudiation, source authentication, search by subject or by other criteria, etc.),
a Signature Infrastructure (“PKI”) including key management like an external KMS and certificate authority (CA), sign/verify, transparency ledger),
An optional Timestamping Authority (TSA), that certifies the occurrence of certain events (like the creation/registration of a software attestation) at a given time.
Attestor, a logic for gathering context information about the environment or the context for the build & deploy system. There are predefined attestors for getting information from git or the build system environment.
The following image depicts the main parts of SALT.
Verification is the point where the policy based on attestations is applied. Must follow the , which stands that to be safe, the system should be designed to fail closed rather than open. If an attacker can delete or hide any attestation, the verifier must return “deny” with “required attestation not found”. So the policy must list the required attestations, and the omission of a single attestation cannot move the system to “allow”.
