Сведения о аттестациях артефактов
Аттестации артефактов позволяют создавать нефиксируемые проверки подлинности и гарантии целостности создаваемого программного обеспечения. В свою очередь, пользователи, использующие программное обеспечение, могут проверить, где и как было создано ваше программное обеспечение.
При создании аттестаций артефактов с помощью программного обеспечения вы создадите криптографически подписанные утверждения, которые устанавливают происхождение сборки и содержат следующие сведения:
- Ссылка на рабочий процесс, связанный с артефактом.
- Репозиторий, организация, среда, фиксация 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
.
Создание прованса сборки для двоичных файлов
-
В рабочем процессе, который создает двоичный файл, который вы хотите подтвердить, добавьте следующие разрешения.
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
Note
Эти команды предполагают, что вы находитесь в интерактивной среде. Если вы находитесь в автономной или воздушной среде, см. раздел "Проверка аттестаций в автономном режиме".
Дополнительные сведения см. в attestation
разделе руководства GitHub CLI.