{"meta":{"title":"Аттестации артефактов","intro":"Ознакомьтесь с преимуществами использования и безопасности аттестаций артефактов.","product":"GitHub Actions","breadcrumbs":[{"href":"/ru/actions","title":"GitHub Actions"},{"href":"/ru/actions/concepts","title":"Основные понятия"},{"href":"/ru/actions/concepts/security","title":"Безопасность"},{"href":"/ru/actions/concepts/security/artifact-attestations","title":"Аттестации артефактов"}],"documentType":"article"},"body":"# Аттестации артефактов\n\nОзнакомьтесь с преимуществами использования и безопасности аттестаций артефактов.\n\n## Обзор\n\nАттестации артефактов позволяют создавать нефиксируемые проверки подлинности и гарантии целостности создаваемого программного обеспечения. В свою очередь, пользователи, использующие программное обеспечение, могут проверить, где и как было создано ваше программное обеспечение.\n\nПри создании аттестаций артефактов с помощью программного обеспечения вы создадите криптографически подписанные утверждения, которые устанавливают происхождение сборки и содержат следующие сведения:\n\n* Ссылка на рабочий процесс, связанный с артефактом\n* Репозиторий, организация, среда, фиксация SHA и триггер события для артефакта\n* Другие сведения из токена OIDC, используемого для установления происхождения. Дополнительные сведения см. в разделе [OpenID Connect](/ru/actions/concepts/security/openid-connect).\n\nВы также можете создать аттестации артефактов, которые включают связанный счет за программное обеспечение материалов (SBOM). Связывание сборок со списком зависимостей открытый код, используемых в них, обеспечивает прозрачность и позволяет потребителям соответствовать стандартам защиты данных.\n\n## Уровни SLSA для аттестаций артефактов\n\nПлатформа SLSA является отраслевым стандартом, используемым для оценки безопасности цепочки поставок. Он упорядочен на уровни. Каждый уровень представляет большую степень безопасности и надежности для цепочки поставок программного обеспечения. Аттестации артефактов сами по себе предоставляют SLSA версии 1.0 сборки 2.\n\nЭто обеспечивает связь между артефактом и его инструкциями по сборке, но вы можете выполнить этот шаг дальше, требуя, чтобы сборки использовали известные, проверенные инструкции сборки. Отличный способ сделать это заключается в том, чтобы создать сборку в многократно используемый рабочий процесс, который многие репозитории в вашей организации совместно используются. Повторно используемые рабочие процессы могут обеспечить изоляцию между процессом сборки и вызывающим рабочим процессом, чтобы соответствовать уровню сборки SLSA версии 1.0. Дополнительные сведения см. в разделе [Использование аттестаций артефактов и повторно используемых рабочих процессов для достижения уровня сборки SLSA версии 3](/ru/actions/how-tos/secure-your-work/use-artifact-attestations/increase-security-rating).\n\nДополнительные сведения об уровнях SLSA см. в разделе [уровней](https://slsa.dev/spec/v1.0/levels) безопасности SLSA.\n\n## Создание GitHub аттестаций артефактов\n\nДля создания аттестаций артефактов GitHub использует Sigstore, который является проектом открытый код, который предлагает комплексное решение для подписывания и проверки артефактов программного обеспечения с помощью аттестаций.\n\n**Общедоступные репозитории** , которые создают аттестации артефактов, используют общедоступный [экземпляр Sigstore Public Good Instance](https://openssf.org/blog/2023/10/03/running-sigstore-as-a-managed-service-a-tour-of-sigstores-public-good-instance/). Копия сгенерированного пакета Sigstore хранится на GitHub и также записывается в неизменяемый лог прозрачности, который доступен для общедоступного чтения в интернете.\n\n**Приватные репозитории** генерирующие аттестации артефактов используют экземпляр Sigstore GitHub. экземпляр Sigstore GitHub использует ту же базу кода, что и общедоступный экземпляр Sigstore Public Good, но он не содержит журнал прозрачности и только федеративныеGitHub Actions.\n\n## Когда следует создавать аттестации\n\nСоздание аттестаций только не обеспечивает никаких преимуществ безопасности, аттестации должны быть проверены для того, чтобы преимущество было реализовано. Ниже приведены некоторые рекомендации по поводу того, как думать о том, что подписывать и как часто:\n\nВы должны подписать:\n\n* Программное обеспечение, которое вы освобождаете, что вы ожидаете, что люди будут работать `gh attestation verify ...` .\n* Двоичные файлы будут запускаться, пакеты будут загружаться или манифесты, содержащие хэши подробного содержимого.\n\nНе следует \\*\\*\\*\\* подписывать:\n\n* Частые сборки, которые предназначены только для автоматического тестирования.\n* Отдельные файлы, такие как исходный код, файлы документации или внедренные образы.\n\n## Проверка аттестаций артефактов\n\nПри использовании программного обеспечения, публикующего аттестации артефактов, можно использовать GitHub CLI для проверки этих аттестаций. Так как аттестации предоставляют сведения о том, где и как было создано программное обеспечение, можно использовать эти сведения для создания и применения политик безопасности, повышающих безопасность цепочки поставок.\n\n> \\[!WARNING] Важно помнить, что аттестации артефактов *не* являются гарантией защиты артефакта. Вместо этого артефакты связывают вас с исходным кодом и инструкциями по сборке, созданными ими. Это зависит от того, чтобы определить критерии политики, оценить эту политику, оценивая содержимое, и принимать информированное решение о рисках при использовании программного обеспечения.\n\n## Следующие шаги\n\nЧтобы приступить к созданию и проверке аттестаций артефактов для сборок, см. раздел [Использование аттестаций артефактов для установления происхождения сборок](/ru/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations)."}