Использование аттестаций артефактов для установления происхождения сборок

Аттестации артефактов позволяют повысить безопасность цепочки поставок ваших сборок, установив, где и как было создано программное обеспечение.

Кто может использовать эту функцию?

Аттестации артефактов доступны в общедоступных репозиториях для всех текущих планов GitHub. Они недоступны в устаревших планах, таких как Бронза, Silver или Gold. Если вы используете план GitHub Free, GitHub Proили GitHub Team план, аттестации артефактов доступны только для общедоступных репозиториев. Чтобы использовать аттестации артефактов в частных или внутренних репозиториях, необходимо использовать план GitHub Enterprise Cloud.

В этой статье

Необходимые компоненты

Прежде чем приступить к созданию аттестаций артефактов, необходимо понять, что такое и когда их следует использовать. См . раздел AUTOTITLE.

Создание аттестаций артефактов для сборок

Вы можете использовать GitHub Actions для создания аттестаций артефактов, которые устанавливают подтверждения сборки для артефактов, таких как двоичные файлы и образы контейнеров.

Чтобы создать аттестацию артефактов, необходимо:

  • Убедитесь, что в рабочем процессе настроены соответствующие разрешения.
  • Включите шаг в рабочий процесс, использующий attest-build-provenance действие.

При запуске обновленных рабочих процессов они будут создавать артефакты и создавать аттестацию артефактов, которая устанавливает проверку сборки. Аттестации можно просмотреть на вкладке "Действия** репозитория**". Дополнительные сведения см. в репозиторииattest-build-provenance.

Создание прованса сборки для двоичных файлов

  1. В рабочем процессе, который создает двоичный файл, который вы хотите подтвердить, добавьте следующие разрешения.

    permissions:
  id-token: write
  contents: read
  attestations: write

  2. После шага, в котором был построен двоичный файл, добавьте следующий шаг.

    - name: Generate artifact attestation
  uses: actions/attest-build-provenance@v2
  with:
    subject-path: 'PATH/TO/ARTIFACT'

    Значение subject-path параметра должно быть задано в путь к двоичному файлу, который требуется подтвердить.

Создание провенанса сборки для образов контейнеров

  1. В рабочем процессе, который создает образ контейнера, который вы хотите подтвердить, добавьте следующие разрешения.

    permissions:
  id-token: write
  contents: read
  attestations: write
  packages: write

  2. После создания образа добавьте следующий шаг.

    - 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

    Значение subject-name параметра должно указывать полное имя образа. Например, ghcr.io/user/app или acme.azurecr.io/user/app. Не включайте тег в имя изображения.

    Значение subject-digest параметра должно иметь дайджест SHA256 для аттестации в форме sha256:HEX_DIGEST. Если рабочий процесс используется docker/build-push-action, вы можете использовать digest выходные данные этого шага для предоставления значения. Дополнительные сведения об использовании выходных данных см. в разделе Синтаксис рабочего процесса для GitHub Actions.

Создание аттестации для счета за программное обеспечение материалов (SBOM)

Вы можете создать подписанные аттестации SBOM для артефактов рабочего процесса.

Чтобы создать аттестацию для SBOM, необходимо:

  • Убедитесь, что в рабочем процессе настроены соответствующие разрешения.
  • Создайте SBOM для артефакта. Дополнительные сведения см anchore-sbom-action . в разделе GitHub Marketplace.
  • Включите шаг в рабочий процесс, использующий attest-sbom действие.

При запуске обновленных рабочих процессов они будут создавать артефакты и создавать аттестацию SBOM. Аттестации можно просмотреть на вкладке "Действия** репозитория**". Дополнительные сведения см. в репозитории attest-sbom действий.

Создание аттестации SBOM для двоичных файлов

  1. В рабочем процессе, который создает двоичный файл, который вы хотите подтвердить, добавьте следующие разрешения.

    permissions:
  id-token: write
  contents: read
  attestations: write

  2. После шага, в котором был построен двоичный файл, добавьте следующий шаг.

    - name: Generate SBOM attestation
  uses: actions/attest-sbom@v2
  with:
    subject-path: 'PATH/TO/ARTIFACT'
    sbom-path: 'PATH/TO/SBOM'

    Значение subject-path параметра должно иметь путь к двоичному файлу, описываемого SBOM. Значение sbom-path параметра должно быть задано в пути созданного файла SBOM.

Создание аттестации SBOM для образов контейнеров

  1. В рабочем процессе, который создает образ контейнера, который вы хотите подтвердить, добавьте следующие разрешения.

    permissions:
  id-token: write
  contents: read
  attestations: write
  packages: write

  2. После создания образа добавьте следующий шаг.

    - 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

    Значение subject-name параметра должно указывать полное имя образа. Например, ghcr.io/user/app или acme.azurecr.io/user/app. Не включайте тег в имя изображения.

    Значение subject-digest параметра должно иметь дайджест SHA256 для аттестации в форме sha256:HEX_DIGEST. Если рабочий процесс используется docker/build-push-action, вы можете использовать digest выходные данные этого шага для предоставления значения. Дополнительные сведения об использовании выходных данных см. в разделе Синтаксис рабочего процесса для GitHub Actions.

    Значение sbom-path параметра должно быть задано в путь к файлу SBOM в формате JSON, который требуется подтвердить.

Проверка аттестаций артефактов с помощью GitHub CLI

Можно проверить аттестацию артефактов для двоичных файлов и образов контейнеров и проверить аттестации SBOM с помощью GitHub CLI. Дополнительные сведения см. в attestation разделе руководства GitHub CLI.

Примечание.

Эти команды предполагают, что вы находитесь в интерактивной среде. Если вы находитесь в автономной или воздушной среде, см . раздел AUTOTITLE.

Проверка аттестации артефакта для двоичных файлов

Чтобы проверить аттестацию артефактов для двоичных файлов, используйте следующую команду GitHub CLI.

Bash
gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R ORGANIZATION_NAME/REPOSITORY_NAME

Проверка аттестации артефакта для образов контейнеров

Чтобы проверить аттестацию артефактов для образов контейнеров, необходимо указать префикс oci:// полного доменного имени образа вместо пути к двоичному файлу. Следующую команду GitHub CLI можно использовать.

Bash
docker login ghcr.io

gh attestation verify oci://ghcr.io/ORGANIZATION_NAME/IMAGE_NAME:test -R ORGANIZATION_NAME/REPOSITORY_NAME

Проверка аттестации для SBOM

Чтобы проверить аттестации SBOM, необходимо указать --predicate-type флаг для ссылки на предикат, отличный от по умолчанию. Дополнительные сведения см . в предикаты Vetted в репозитории in-toto/attestation .

Например, действие attest-sbom в настоящее время поддерживает предикаты SPDX или ЦиклонеDX SBOM. Чтобы проверить аттестацию SBOM в формате SPDX, можно использовать следующую команду GitHub CLI.

Bash
gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY \
  -R ORGANIZATION_NAME/REPOSITORY_NAME \
  --predicate-type https://spdx.dev/Document/v2.3

Чтобы просмотреть дополнительные сведения об аттестации, см --format json . флаг. Это может быть особенно полезно при проверке аттестаций SBOM.

Bash
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'

Следующие шаги

Чтобы сохранить аттестацию релевантными и управляемыми, следует удалить аттестации, которые больше не нужны. См . раздел AUTOTITLE.