What’s happening
GitHub is incorporating Artifact Attestations as part of its workflows in GitHub Actions, allowing you to verify the origin and integrity of artifacts generated in a pipeline.
This means you can now demonstrate, in a verifiable way, that a build was generated by a specific workflow, on a concrete commit, and hasn’t been tampered with.
Why it matters
Most recent software attacks don’t happen in the source code, but in the supply chain.
The problem:
- someone compromises a pipeline
- or introduces malicious code in the build process
- and the final artifact looks legitimate
Artifact Attestations attack that problem directly.
What is an attestation (without the fluff)
An attestation is basically a signed record that says:
- what was built
- how it was built
- where it was built
- with what source code
And it does so in a cryptographically verifiable way.
How it works in practice
GitHub automatically generates build metadata and signs it.
Then you can:
- verify the artifact before deployment
- confirm that it comes from your workflow
- detect tampering
Basic example in GitHub Actions
name: Build and attest
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build
run: npm install && npm run build
- name: Generate artifact attestation
uses: actions/attest-build-provenance@v1
with:
subject-path: 'dist/**'
This step generates an attestation for the built artifacts.
How to verify an artifact
You can use tools like cosign:
cosign verify-attestation \
--type slsaprovenance \
<image-or-artifact>
This allows you to validate that the artifact matches the expected build process.
Real-world use cases
1. Secure deployment
Before deploying:
- you verify the attestation
- confirm the origin
- reduce the risk of compromised artifacts
2. Open source
Allows users to verify that published binaries match the repo code.
3. Audit
You can demonstrate how an artifact was generated in a regulated environment.
Advantages
- You don’t need additional infrastructure
- Integrated in GitHub Actions
- Based on standards (SLSA)
- Low adoption effort
Limitations
- Only covers what happens inside the pipeline
- Doesn’t replace code review
- Requires discipline in verification
What you should do now
- Add attestations to your critical pipelines
- Verify artifacts before deployment
- Review workflow permissions
Why it matters in LATAM
Many teams don’t have resources for complex supply chain security solutions.
This allows you to improve security with what you’re already using.
Conclusion
Artifact Attestations aren’t an incremental improvement.
They’re a shift in how you validate trust in your software.
And for the first time, it’s something you can adopt today without changing your stack.