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

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

В этой статье

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

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

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

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

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

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

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

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

Дополнительные сведения об уровнях SLSA см. в разделе уровней безопасности SLSA.

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

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

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

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

Что затверять

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

Вы должны подписать:

  • Программное обеспечение, которое вы освобождаете, что вы ожидаете, что люди будут работать gh attestation verify ... .
  • Двоичные файлы будут запускаться, пакеты будут загружаться или манифесты, содержащие хэши подробного содержимого.

Не следует **** подписывать:

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

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

При использовании программного обеспечения, публикующего аттестации артефактов, можно использовать 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.