Build attestation framework should be used

build_attestation_framework

Severity

high

Remediation Complexity

medium

Remediation Risk

low

Remediation Effort

medium

Family

CI/ CD Security

Description

A build attestation framework should be used.

This check tries to determine if the project uses a build attestation framework to establish trust and provide assurance about the integrity and security of software builds or artifacts.

You can configure tools or run commands to check for workflows using tools to verify this. The parameters are tools and commands.

Security

The primary purpose of a build attestation framework is to address the following goals:

Supply Chain Security: With the increasing complexity of software supply chains, a build attestation framework helps verify the source and integrity of the software components used during the build process. It provides transparency and visibility into the entire build pipeline, allowing organizations to identify and mitigate any potential security risks or compromised dependencies.
Trustworthy Software Delivery: By attesting to the build process and its associated artifacts, a build attestation framework enables recipients to verify the authenticity and integrity of the delivered software. It assures them that the build was performed correctly and without unauthorized modifications or tampering, reducing the risk of deploying compromised or malicious software.
Compliance and Regulatory Requirements: Many industries and regulatory frameworks require organizations to demonstrate control and visibility over their software supply chains. A build attestation framework helps meet these compliance requirements by providing a documented trail of the build process, ensuring adherence to specific security and quality standards.
Vulnerability Management: A build attestation framework can integrate with vulnerability scanning and management tools to track and validate the versions of dependencies used in the build process. This helps identify any known vulnerabilities or weaknesses in the software components, allowing organizations to apply necessary patches or upgrades.

In summary, a build attestation framework provides an additional layer of trust and accountability for software builds. It ensures the security, authenticity, and integrity of software artifacts, enabling organizations to confidently deploy and manage their software supply chains.

Mitigation / Fix

Add a step to every pipeline that produces a signed attestation of what the build consumed and what it produced. The check looks for a known attestation tool in the pipeline definitions and build scripts of the project.

This check reads pipeline definitions and build scripts only. An attestation produced anywhere else — a build run by hand, a release job living in another repository — is not visible to it, so the finding stays open until the attesting step belongs to a pipeline this project owns.

Xygeni Salt

Salt attests a build incrementally: declare the materials the build consumes, wrap each build step so its command and products are recorded, then commit the signed attestation to the ledger.

# Wrap a build step: the sources are materials, the JAR is the product
salt -q -p $PIPE -s $STEP -d . \
     -t material -f src/main -t product -f target/my_thing.jar \
     -- mvn package

# Complete the attestation and sign it without managing keys
salt attestation commit -p build-image --keyless

For an artifact that is already built, provenance emits signed SLSA v1 provenance in a single step. The git repository, branch and commit recorded in it are read from --basedir, so run it in the checkout the artifact was built from.

salt attestation provenance -f target/my_thing.jar

Attesting is only half of it: verify the attestation where the artifact is consumed — at deployment, or before promoting a build between environments. An attestation nobody checks proves nothing.