Prerequisites
Before you start generating artifact attestations, you need to understand what they are and when you should use them. See アーティファクト構成証明.
Generating artifact attestations for your builds
You can use GitHub Actions to generate artifact attestations that establish build provenance for artifacts such as binaries and container images.
To generate an artifact attestation, you must:
- Ensure you have the appropriate permissions configured in your workflow.
- Include a step in your workflow that uses the
attest-build-provenance
action.
When you run your updated workflows, they will build your artifacts and generate an artifact attestation that establishes build provenance. You can view attestations in your repository's Actions tab. For more information, see the attest-build-provenance
repository.
Generating build provenance for binaries
-
In the workflow that builds the binary you would like to attest, add the following permissions.
permissions: id-token: write contents: read attestations: write
-
After the step where the binary has been built, add the following step.
- name: Generate artifact attestation uses: actions/attest-build-provenance@v2 with: subject-path: 'PATH/TO/ARTIFACT'
The value of the
subject-path
parameter should be set to the path to the binary you want to attest.
Generating build provenance for container images
-
In the workflow that builds the container image you would like to attest, add the following permissions.
permissions: id-token: write contents: read attestations: write packages: write
-
After the step where the image has been built, add the following step.
- name: Generate artifact attestation uses: actions/attest-build-provenance@v2 with: subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} subject-digest: 'sha256:fedcba0...' push-to-registry: true
The value of the
subject-name
parameter should specify the fully-qualified image name. For example,ghcr.io/user/app
oracme.azurecr.io/user/app
. Do not include a tag as part of the image name.The value of the
subject-digest
parameter should be set to the SHA256 digest of the subject for the attestation, in the formsha256:HEX_DIGEST
. If your workflow usesdocker/build-push-action
, you can use thedigest
output from that step to supply the value. For more information on using outputs, see GitHub Actions のワークフロー構文.
Generating an attestation for a software bill of materials (SBOM)
You can generate signed SBOM attestations for workflow artifacts.
To generate an attestation for an SBOM, you must:
- Ensure you have the appropriate permissions configured in your workflow.
- Create an SBOM for your artifact. For more information, see
anchore-sbom-action
in the GitHub Marketplace. - Include a step in your workflow that uses the
attest-sbom
action.
When you run your updated workflows, they will build your artifacts and generate an SBOM attestation. You can view attestations in your repository's Actions tab. For more information, see the attest-sbom
action repository.
Generating an SBOM attestation for binaries
-
In the workflow that builds the binary you would like to attest, add the following permissions.
permissions: id-token: write contents: read attestations: write
-
After the step where the binary has been built, add the following step.
- name: Generate SBOM attestation uses: actions/attest-sbom@v2 with: subject-path: 'PATH/TO/ARTIFACT' sbom-path: 'PATH/TO/SBOM'
The value of the
subject-path
parameter should be set to the path of the binary the SBOM describes. The value of thesbom-path
parameter should be set to the path of the SBOM file you generated.
Generating an SBOM attestation for container images
-
In the workflow that builds the container image you would like to attest, add the following permissions.
permissions: id-token: write contents: read attestations: write packages: write
-
After the step where the image has been built, add the following step.
- name: Generate SBOM attestation uses: actions/attest-sbom@v2 with: subject-name: ${{ env.REGISTRY }}/PATH/TO/IMAGE subject-digest: 'sha256:fedcba0...' sbom-path: 'sbom.json' push-to-registry: true
The value of the
subject-name
parameter should specify the fully-qualified image name. For example,ghcr.io/user/app
oracme.azurecr.io/user/app
. Do not include a tag as part of the image name.The value of the
subject-digest
parameter should be set to the SHA256 digest of the subject for the attestation, in the formsha256:HEX_DIGEST
. If your workflow usesdocker/build-push-action
, you can use thedigest
output from that step to supply the value. For more information on using outputs, see GitHub Actions のワークフロー構文.The value of the
sbom-path
parameter should be set to the path to the JSON-formatted SBOM file you want to attest.
Verifying artifact attestations with the GitHub CLI
You can validate artifact attestations for binaries and container images and validate SBOM attestations using the GitHub CLI. For more information, see the attestation
section of the GitHub CLI manual.
メモ
These commands assume you are in an online environment. If you are in an offline or air-gapped environment, see Verifying attestations offline.
Verifying an artifact attestation for binaries
To verify artifact attestations for binaries, use the following GitHub CLI command.
gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R ORGANIZATION_NAME/REPOSITORY_NAME
gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R ORGANIZATION_NAME/REPOSITORY_NAME
Verifying an artifact attestation for container images
To verify artifact attestations for container images, you must provide the image's FQDN prefixed with oci://
instead of the path to a binary. You can use the following GitHub CLI command.
docker login ghcr.io gh attestation verify oci://ghcr.io/ORGANIZATION_NAME/IMAGE_NAME:test -R ORGANIZATION_NAME/REPOSITORY_NAME
docker login ghcr.io
gh attestation verify oci://ghcr.io/ORGANIZATION_NAME/IMAGE_NAME:test -R ORGANIZATION_NAME/REPOSITORY_NAME
Verifying an attestation for SBOMs
To verify SBOM attestations, you have to provide the --predicate-type
flag to reference a non-default predicate. For more information, see Vetted predicates in the in-toto/attestation
repository.
For example, the attest-sbom
action currently supports either SPDX or CycloneDX SBOM predicates. To verify an SBOM attestation in the SPDX format, you can use the following GitHub CLI command.
gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY \ -R ORGANIZATION_NAME/REPOSITORY_NAME \ --predicate-type https://spdx.dev/Document/v2.3
gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY \
-R ORGANIZATION_NAME/REPOSITORY_NAME \
--predicate-type https://spdx.dev/Document/v2.3
To view more information on the attestation, reference the --format json
flag. This can be especially helpful when reviewing SBOM attestations.
gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY \ -R ORGANIZATION_NAME/REPOSITORY_NAME \ --predicate-type https://spdx.dev/Document/v2.3 \ --format json \ --jq '.[].verificationResult.statement.predicate'
gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY \
-R ORGANIZATION_NAME/REPOSITORY_NAME \
--predicate-type https://spdx.dev/Document/v2.3 \
--format json \
--jq '.[].verificationResult.statement.predicate'
Next steps
To keep your attestations relevant and manageable, you should delete attestations that are no longer needed. See 成果物構成証明のライフサイクルの管理.