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
.
Создание прованса сборки для двоичных файлов
-
В рабочем процессе, который создает двоичный файл, который вы хотите подтвердить, добавьте следующие разрешения.
permissions: id-token: write contents: read attestations: write
-
После шага, в котором был построен двоичный файл, добавьте следующий шаг.
- name: Generate artifact attestation uses: actions/attest-build-provenance@v1 with: subject-path: 'PATH/TO/ARTIFACT'
Значение
subject-path
параметра должно быть задано в путь к двоичному файлу, который требуется подтвердить.
Создание провенанса сборки для образов контейнеров
-
В рабочем процессе, который создает образ контейнера, который вы хотите подтвердить, добавьте следующие разрешения.
permissions: id-token: write contents: read attestations: write packages: write
-
После создания образа добавьте следующий шаг.
- 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 для двоичных файлов
-
В рабочем процессе, который создает двоичный файл, который вы хотите подтвердить, добавьте следующие разрешения.
permissions: id-token: write contents: read attestations: write
-
После шага, в котором был построен двоичный файл, добавьте следующий шаг.
- 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 для образов контейнеров
-
В рабочем процессе, который создает образ контейнера, который вы хотите подтвердить, добавьте следующие разрешения.
permissions: id-token: write contents: read attestations: write packages: write
-
После создания образа добавьте следующий шаг.
- 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.
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
Чтобы проверить аттестацию артефактов для образов контейнеров, необходимо указать префикс oci://
полного доменного имени образа вместо пути к двоичному файлу. Следующую команду GitHub CLI можно использовать.
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
Дополнительные сведения см. в attestation
разделе руководства GitHub CLI.