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

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

В этой статье

Note

Аттестации артефактов находятся в общедоступной бета-версии и подлежат изменению.

Сведения о аттестациях артефактов

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

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

  • Ссылка на рабочий процесс, связанный с артефактом.
  • Репозиторий, организация, среда, фиксация SHA и триггер события для артефакта.
  • Другие сведения из токена OIDC, используемого для установления происхождения. Дополнительные сведения см. в разделе Сведения об усилении защиты с помощью OpenID Connect.

Вы также можете создать аттестации артефактов, которые включают связанный счет за программное обеспечение материалов (SBOM). Связывание сборок со списком зависимостей открытый код, используемых в них, обеспечивает прозрачность и позволяет потребителям соответствовать стандартам защиты данных.

Сведения о уровнях SLSA для аттестаций артефактов

Платформа SLSA является отраслевым стандартом, используемым для оценки безопасности цепочки поставок. Он упорядочен на уровни. Каждый уровень представляет большую степень безопасности и надежности для цепочки поставок программного обеспечения. Аттестации артефактов предоставляют SLSA версии 1.0 уровня сборки 2.

Вы можете использовать аттестации артефактов для достижения уровня сборки SLSA версии 1.0; однако мы настоятельно рекомендуем сначала сосредоточиться на широком внедрении уровня сборки 2 в организации. Гораздо лучше согласованно соответствовать уровню 2 в сборках, чем иметь небольшую часть сборок, которые достигают уровня 3. Чтобы достичь уровня сборки 3, рекомендуется стандартизированию процесса сборки с помощью повторно используемых рабочих процессов, аудита повторно используемых рабочих процессов, чтобы обеспечить соответствие требованиям уровня 3, а затем обновить политику проверки, чтобы требовать эти проверенные повторно используемые рабочие процессы.

Дополнительные сведения см. в разделе " Провананс " документации ПО SLSA.

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

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

Общедоступные репозитории , которые создают аттестации артефактов, используют общедоступный экземпляр Sigstore Public Good Instance. Копия созданного пакета Sigstore хранится с помощью GitHub и также записывается в неизменяемый журнал прозрачности, который является общедоступным для чтения в Интернете.

Частные репозитории , создающие аттестации артефактов, используют экземпляр Sigstore GitHub. Экземпляр Sigstore GitHub использует ту же базу кода, что и общедоступный экземпляр Sigstore Public Good, но у него нет журнала прозрачности и только федеративные данные GitHub Actions.

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

При использовании программного обеспечения, публикующего аттестации артефактов, можно использовать GitHub CLI для проверки этих аттестаций. Так как аттестации предоставляют сведения о том, где и как было создано программное обеспечение, можно использовать эти сведения для создания и применения политик безопасности, повышающих безопасность цепочки поставок. Дополнительные сведения см. в статье "Проверка аттестаций артефактов с помощью GitHub CLI".

Warning

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

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

Вы можете использовать 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@v1
  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@v1
  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@v1
  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@v1
  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

Чтобы проверить аттестацию артефактов для двоичных файлов, используйте следующую команду 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

Дополнительные сведения см. в attestation разделе руководства GitHub CLI.