GitHub Artifact Attestations now in Public Beta

[chrispat]

Hey, Y'all!
I’m excited to announce that GitHub Artifact Attestations are in public beta🎉

❓ What does this mean❓

Artifact Attestations allow project maintainers to effortlessly create a tamper-proof, unforgeable paper trail linking their software to the process which created it. Downstream consumers of that metadata can then use it as a foundation for new security and validity checks through policy evaluation via tools like Rego and Cue. We’re starting with verification support based on GitHub CLI, but will expand to bring these same controls to the Kubernetes ecosystem as well later this year.

📑 Want to learn more? Here are some resources:

• Where does your software really come from about software attestations
• Our blog post with an overview of the new capabilities
• The docs give you all of the details about how repository rules work.

❔ Still have queries❔

• Feel free to post here for feedback.

[teo-tsirpanis]

That's really nice, thanks!

How would this interact with Release artifacts, given that Actions artifacts are not permanent?

[chrispat]

While actions is required for creating attestations you can use those actions to attest any artifact regardless of where you are storing it. So you could have your workflow attest all of the binaries you are publishing to a release.

[teo-tsirpanis]

Oh I see, you attest arbitrary files, the word artifact confused me for a bit. Very cool, thanks!

[oreillymj]

Can you explain the process of adding attestation to source only tarballs. If I don't distribute binaries/have a GA doing a build, is attestation added to the process GH performs to create a source tarball when a new release is created?

[prabhu]

Another feature to lock down the users to a single platform?

[phillmv]

Hopefully, not!, for two reasons:

1. All attestations generated on our platform can be downloaded and stored elsewhere.
2. Attestations generated for public repos use the Sigstore public good instance. These "open source" attestations can then be verified without any infrastructure that GitHub owns or controls.

[finnigja]

Is there any reason why I wouldn't be able to create an assertion in one GHA workflow, then verify that assertion in another GHA workflow? Both workflows live in the same repo.

I'm experimenting with this over at https://github.com/finnigja/stunning-broccoli. It builds & attests a release successfully in this workflow.

If I download the attested artifact locally I can verify it:

$ gh attestation verify ~/Downloads/stunning-broccoli-v0.0.2.tar.gz -o finnigja
Loaded digest sha256:699a957d21b31bf2513d8d6a191745fd846b0c6602489bd4aa2707afbcef8822 for file:///Users/jsf/Downloads/stunning-broccoli-v0.0.2.tar.gz
Loaded 1 attestation from GitHub API
✓ Verification succeeded!

sha256:699a957d21b31bf2513d8d6a191745fd846b0c6602489bd4aa2707afbcef8822 was attested by:
REPO                        PREDICATE_TYPE                  WORKFLOW
finnigja/stunning-broccoli  https://slsa.dev/provenance/v1  .github/workflows/build-attested-release.yml@refs/tags/v0.0.2

But if I try to download it & verify inside a GHA (using this workflow), the workflow run fails:

gh attestation verify stunning-broccoli-v0.0.2.tar.gz -o finnigja
Failed to verify the artifact: failed to fetch attestations for subject: sha256:699a957d21b31bf2513d8d6a191745fd846b0c6602489bd4aa2707afbcef8822

It has the correct SHA for the artifact, which I think suggests the artifact is downloaded correctly but there's maybe a problem with retrieving the assertion to verify against?

It's definitely there... https://github.com/finnigja/stunning-broccoli/attestations/789050.

I've tried swapping the tokens that the gh step is using so it's the same PAT I'm using locally instead of the default workflow token, but get the same error.

[phillmv]

Hello!

Is there any reason why I wouldn't be able to create an assertion in one GHA workflow, then verify that assertion in another GHA workflow? Both workflows live in the same repo.

No, there is no reason why! Thanks for this very tidy report with a convenient public repo for me to poke at.

I forked your repo and tried it on on my end and the unsatisfying answer is…………

the version of gh that ships in Actions does not support the current version of provenance attestations our tool generates 🤦‍♀️.

I'm going to follow up with the Actions team to see if we can refresh the ubuntu-latest image accordingly.

Thanks!

$ ./bin/gh version
gh version 2.48.0 (2024-05-07)
https://github.com/cli/cli/releases/tag/v2.48.0
$ ./bin/gh at verify ~/Downloads/stunning-broccoli-fork-v0.0.3.tar.gz -o phillmv
Verifying attestations for the artifact found at file:///Users/phillmv/Downloads/stunning-broccoli-fork-v0.0.3.tar.gz
Failed to verify the artifact: failed to fetch attestations for subject: sha256:2c1108441c85e2dbeff3251145f3bce33f0e9e7550b0201a4e21a3a116085049
$ gh version
gh version 2.49.0 (2024-04-30)
https://github.com/cli/cli/releases/tag/v2.49.0
$ gh at verify ~/Downloads/stunning-broccoli-fork-v0.0.3.tar.gz -o phillmv
Loaded digest sha256:2c1108441c85e2dbeff3251145f3bce33f0e9e7550b0201a4e21a3a116085049 for file:///Users/phillmv/Downloads/stunning-broccoli-fork-v0.0.3.tar.gz
Loaded 1 attestation from GitHub API
✓ Verification succeeded!

sha256:2c1108441c85e2dbeff3251145f3bce33f0e9e7550b0201a4e21a3a116085049 was attested by:
REPO                            PREDICATE_TYPE                  WORKFLOW
phillmv/stunning-broccoli-fork  https://slsa.dev/provenance/v1  .github/workflows/build-attested-release.yml@refs/tags/v0.0.3

[finnigja]

Ahh, that explains it.. if I do an update of gh in a test workflow, the attestation works as expected. 🎉

Thanks! Looking forward to playing with this some more..

[trungnt2910]

Would be nice if in the (far?) future this could be used for signing executables (such as PE binaries) or packages (such as .msix files).

[hfhbd]

Do you have any sample how to use this with Maven Central? Maven Central already requires a signing certificate, uploaded to a public key server. Can I use the short-lived X.509 key to do the signing by myself (using maven/Gradle) without the GitHub Action? If so, how do I get the short-lived X.509 key?

[phillmv]

🤔 skimming over the maven requirements, i fear the answer is "sort of but not really".

You could in theory configure our signing setup to use a long lived key – or upload the ephemeral key to Maven – but then why bother? Once you set up your actions workflow to have access to a specific key that Maven recognizes you'd done all the hard work of signing; one of the points/goals/advantages of Sigstore and our Artifact Attestations feature is that it reduces the burden of distributing public keys down to the security of your GitHub account.

For Maven in particular, Artifact Attestations are a complement, an additional feature to be used alongside their GPG signing.

[hfhbd]

But wouldn't it possible to create the short live key, convert it to GPP format (?) and upload it to a public key server in a setup action, exposing it as an output/environment variable to use it with maven? 🤔

Then I don't need to maintain my personal GPG key that also expires. And shouldn't it also simplify the validation of the signed artifacts by only trusting GitHub certificate, and not each personal certificate?

[phillmv]

But wouldn't it possible to create the short live key, convert it to GPP format (?) and upload it to a public key server in a setup action, exposing it as an output/environment variable to use it with maven? 🤔

I think it is possible! You could create the key, use it to sign with gpg, upload the key to maven, then use the same key to sign the attestation, and then throw it away. I just don't think that in this case it buys you anything 🤔 to have the same key used for both the gpg maven signing and for signing the attestation.

The time-saving trick you're performing here is storing your Maven credentials as a secret on your repo, and having the workflow generate and upload the key for you. You can make this work today and save yourself from managing the long lived key without making that key be the same key used for the attestation 🙂.

And shouldn't it also simplify the validation of the signed artifacts by only trusting GitHub certificate, and not each personal certificate?

In Sigstore, the trust we're verifying lies in the certificate authority's key that generates the certificate. It's the cert authority (aka Fulcio) that verifies the authenticity of the signing request. When we verify artifacts signed with Sigstore, we check for the validity of the Fulcio certificate and the values embedded inside that certificate. (Did this artifact originate from the your-name/your-repo? yes or no?)

The way forward to simplify our lives would be for Maven to support verifying that attestations coming from your-name/your-repo have been signed using Sigstore 😄, i.e. what we did with npm, in addition to GPG keys.

[ji-677]

Do you have any sample how to use this with Maven Central? Maven Central already requires a signing certificate, uploaded to a public key server. Can I use the short-lived X.509 key to do the signing by myself (using maven/Gradle) without the GitHub Action? If so, how do I get thlived X.509 key?

[Forrin]

Support for multiple subjects within an Attestation would be useful and something I'd like to see. The current solution will create an attestation for each subject, however many of the predicates expect that multiple subjects will exist.

Furthermore, I'd like to be able to add subjects without having to reference a file. A good example is the git commit as a subject.

I think supporting other signing tools could be useful, though allowing a privately run Fulcio would be a good first step.

I think much of this can be done with the libraries that exist.. or forking them and making some adjustments. I'm sure I'll see more as I work with this tooling.

Something else I'm interested in is creating attestations for each supply chain step (collecting data on the step... the action/command, state of work dir before and after, etc). This is possible if you create a composite for each action of interest... but it's a lot of work. Ideally we could switch in-toto attestations on and get them, mostly, for all workflows.

Thanks

[phillmv]

Support for multiple subjects within an Attestation would be useful and something I'd like to see.

We'll likely introduce support for this later this year.

To help us design the feature, could you give us some examples of attestations/predicates you want to create?

[Forrin]

Vulnerability scans, test results, etc. In many cases we probably want the git commit sha in the subject. For test results, we may want the tested files to be in the subjects (or a dir hash?), especially for a mono repo.

[ji-677]

Support for multiple subjects within an Attestation would be useful and something I'd like to see. The current solution will create an attestation for each subject, however many of the predicates expect that multiple subjects will exist.

Furthermore, I'd like to be able to add subjects without having to reference a file. A good example is the git commit as a subject.

I think supporting other signing tools could be useful, though allowing a privately run Fulcio would be a good first step.

I think much of this can be done with the libraries that exist.. or forking them and making some adjustments. I'm sure I'll see more as I work with this tooling.

Something else I'm interested in is creating attestations for each supply chain step (collecting data on the step... the command, state of workbefore and after, etc). This is possib if you create a composite for each action of intere. but it's a lot of work. Ideally we could switch in-toto attestations on and get them, mostly, for all workflows.

T

[dalcinl]

Is it possible to remove/delete attestation entries from org/repo/attestations list? I got a couple entries there after testing the new feature. However, I would like to remove them because I would like to have there just final release artifacts once I publish my next release.
https://github.com/mpi4py/mpi4py/attestations

[phillmv]

We have planned to add this ability, but unfortunately we didn't get to it in time for our public beta. If you happened to attest something that absolutely needs to be deleted (i.e. for legal reasons), please reach out through support and we'll do it manually.

For right now, for what its worth, from your users' perspective you should be directing them to use the gh attestation verify -o mpi4py <filehere> command – and there they won't see any of the extra attestations 😄.

[dalcinl]

We have planned to add this ability, but unfortunately we didn't get to it in time for our public beta.

Great. I just wanted to provide feedback on feature that would be nice to have.

use the gh attestation verify -o mpi4py command

To clarify: This would still work even if the artifact filename (and attestation name) is the same for different attestations? As you can see in the attestation list of my project, all entries are named mpi4py-4.0.0.dev0.tar.gz.

[phillmv]

This would still work even if the artifact filename (and attestation name) is the same for different attestations?

Yep! We take the artifact digest and ignore the filename. As long as the contents of the file are the same, then it should work.

[dfunkt]

1.Are there any plans for supporting multiple SBOM files? Using "BUILDKIT_SBOM_SCAN_STAGE=true" in a multi-stage Dockerfile creates additional files (https://docs.docker.com/build/attestations/sbom/#scan-stages) which should be included in the attestation process.

2. Are there any plans for some sort of auto sourcing the SBOM files from a Docker container that has been built with "sbom: true"? (talking about those built with bake-action/build-push-action prior to the SBOM attestation step of the workflow)

[phillmv]

Is there any reason why I wouldn't be able to create an assertion in one GHA workflow, then verify that assertion in another GHA workflow? Both workflows live in the same repo.

Interesting! Do you have any samples for us to look at? I think the short answer is… if you have multiple SBOM files for a single specific image manifest digest, then feel free to create multiple SBOM attestations for that one digest.

• But if we're talking about "one manifest, but each layer has its own SBOM" then we'll have to gather some feedback on how users interact with the layers (vs the top level manifest)

Are there any plans for some sort of auto sourcing the SBOM files from a Docker container that has been built with "sbom: true"?

We're still figuring out how the community wants to interact with SBOMs. Due to the nature of a software bill of material, it's very hard to provide a generic solution / snap to any particular solution. Our inclination at the moment is to say "you tell us where your sbom is and we will make sure it's associated with your container image" – but we're very much open to feedback.

[martincostello]

I just discovered that there's a 64-file limit to the number of items that can be attested, which is preventing me from using attestation on a handful of repositories where we produce ~100 binaries/packages. Can this limit be raised?

[chrispat]

@martincostello In your case do you want an individual attestation per artifact or would you prefer to have 1 attestation with many subjects?

[martincostello]

I assumed that we should be doing an attestation per artifact (our users don't necessarily use all of them, they might just use one). If there's a different scenario we should be doing that's the other way around that's effectively the same for the end-user to do "this file came from this build" that would be fine.

[bdehamer]

@martincostello In the latest build, the subject limit has been bumped from 64 to 2500

[yanivpaz]

1. Can the attestation replace the signing process in all aspects ( authenticity, digest validation etc)?

• Signing -powerfull tool for ensuring the integrity of their software artifacts
• Artifact Attestation -same as Signing but more simple and flexible

2. how does the artifact attestation related to
   https://github.com/in-toto/attestation/tree/main/spec/predicates

[phillmv]

Hi! Artifact attestations use signing and a special metadata format - the attestation predicates you linked - to handle authenticity and digest validation. The attestations are signed, which provides authenticity, and the digests are stored within the dsse envelope & attestation predicates.

Hope that helps,

[C0D3-M4513R]

I love what I'm seeing, but unfortunately after testing it a bit (C0D3-M4513R/time#3) I ran into one show stopper:

• Action has stopped working, fails to download syft anchore/sbom-action#472 which seems to be caused by Curl returns 000 http status codes on successful download actions/runner-images#10009

Effectively I cannot generate a sbom from my cargo.toml under windows, which of course stops me from doing attestation with an sbom there (but with the current setup of one matrix build it would mean no sbom for any attestation effectively).

[phillmv]

Thanks for reporting this! Fwiw, in our opinion, if you distribute builds of your software in general it is very useful to attest their provenance – above and beyond whether you include a bill of materials 😄.

[C0D3-M4513R]

Sure, but when including an sbom is almost as easy as just doing provenance I'll gladly go the next step.
I believe that just including provenance is not enough for most cases, especially when considering what happened to xz and log4j.

In the case of log4j the damage could/can be assessed for almost all publications, since in maven and gradle dependency information is published alongside the release artifact.

When looking at Attestations with sbom's I see a way to do the same thing with arbitrary files.

e.g.:
Let's assume we have a repo, where artifacts mostly have attestations with sboms.
This could then allow for automatic flagging of potentially vulnerable attachments of releases and tags on a repo.
Whenever you detect a dependency with a security issue you could scan all the attestations and look for the vulnerable dependency. Then you can flag all tag/release attachments on the repo with that hash.
Vulnerability information could then be shown for all individual release/tag attachments as additional information.

(Yes I'm aware, that scanning all attestations requires a significant amount of computational power when dealing with large numbers of attestations.)

[djahandarie]

For those of us who want to verify artifacts within an application as opposed to an environment where we can run executables (e.g., within a V8 sandbox), is there any library that we could call that serves the same function as gh attestation verify?

[phillmv]

Hello,

Yep! We use the sigstore-go library to do this. That said, my recommendation is to use our cli utility where possible, because setting it up correctly requires a lot of work: you will at the very least have to care about distributing key material from our tuf repository.

For more information, you can see how we've implemented it in our cli utility here: https://github.com/cli/cli/blob/trunk/pkg/cmd/attestation/verify/verify.go

In addition, I believe there is a Python implementation, and there may be one in progress in Rust.

[stdedos]

My build process generates a lot of artifacts: https://github.com/stdedos/junit2html/actions/runs/10125546240

1. As someone might want to download the file and start using the product, they are all packaged with the same name junit2html, and with the version name appended (to avoid duplicates e.g. if someone wants to keep different versions around).
   However, that leads to not being able to find "the correct" attestation, unless someone starts "reverse": sha256 the result, find the correct link, and download the correct attestation. Is there a way to improve this, apart from fully-appending the filenames?
2. It seems to be a bit "excessive" that each artifact generates a separate json. Can they be somehow consolidated into one file? Or am I using the action wrong?

I may not be understanding attestations at all, so be nice 🙏

[chrispat]

https://github.com/orgs/community/discussions/122028#discussioncomment-11126236

[bdehamer]

@stdedos the latest release introduces support for multi-subject attestations: https://github.com/actions/attest-build-provenance/releases/tag/v2.0.0

[pmartu12]

is it possible set a rule in order to create attestation only from protected branch?

[v1v]

Is it possible to list all the attestations for a given GitHub repository or GitHub Org using the Rest API?

[AptiviCEO]

The GitHub documentation states that you can list attestations for a given user, a repository, or an organization, but you'll need to provide a subject digest in the format of sha256:HEX_DIGEST as it's required.

• Organization: https://docs.github.com/en/rest/orgs/orgs?apiVersion=2022-11-28#list-attestations
• Users: https://docs.github.com/en/rest/users/attestations?apiVersion=2022-11-28#list-attestations
• Repositories: https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#list-attestations

Do you mean listing all attestations with just a repo or organization name without specifying the hex digest?

[v1v]

Thanks @AptiviCEO,I saw those entrypoints but I'm interested to visualise all those details without specifying the hex digest. I can see the UI supports those details at the repo level: https://github.com/ORG/REPO/attestations.

OTOH, the name list-attestations is misleading, I see some other list-<entity> endpoints that don't need any further details, such as list-members, list-packages, list-pull-requests to 'list' a few

[hfhbd]

We generate about 100 attestations per release. The attestation view https://github.com/ORG/REPO/attestations lists all attestations. Are there any plans to group the attestations per tag or similar?

[bdehamer]

We're working on a feature which which will allow you to associate multiple subjects with a single attestation. This should help to clean-up the attestations list as anything which is attested as part of the same release will be represented by a single attestation.

[bdehamer]

The latest release introduces support for multi-subject attestations: https://github.com/actions/attest-build-provenance/releases/tag/v2.0.0

[j-m]

Are there any plans to make this available to user-owed private repos? Otherwise please add some sort of notice to the Attestations page.

Twas rather annoying to go through the trial and error of setting it all up only to finally be met with

Error: Failed to persist attestation: Feature not available for user-owned private repositories. To enable this feature, please make this repository public.

[bdehamer]

At this point, there are no plans to support this feature on private repos unless you are on the GitHub Enterprise Cloud plan.

This is described in the docs and we've updated the READMEs for the attestation actions to include this information as well.

[Andy-commits-lgtm]

Гей, ви всі! Я радий повідомити, що атестації артефактів GitHub знаходяться в публічній бета-версії🎉

❓ Що це означає❓

Атестації артефактів дозволяють супроводжувачам проекту без особливих зусиль створювати захищений від підробки паперовий слід, що пов’язує їх програмне забезпечення з процесом, який його створив. Далі споживачі цих метаданих можуть використовувати їх як основу для нових перевірок безпеки та дійсності за допомогою оцінки політики за допомогою таких інструментів, як Rego та Cue . Ми починаємо з підтримки перевірки на основі GitHub CLI , але пізніше цього року розширимо, щоб перенести ті самі елементи керування в екосистему Kubernetes.

📑 Хочете дізнатися більше? Ось деякі ресурси:

• Звідки насправді походить ваше програмне забезпечення щодо атестації програмного забезпечення
• Наша публікація в блозі блозі з оглядом нових можливостей
• У документах ви знайдете всі подробиці про те, як працюють правила репозиторію.

❔ Ще є запитання❔

• Не соромтеся опублікувати тут, щоб отримати відгук.