Рекомендации по обеспечению безопасности системы сборки

Руководство по защите конечного этапа цепочки поставок — систем, используемых для создания и распространения артефактов.

В этой статье

Информация о руководстве

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

В чем заключаются риски?

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

Защита системы сборки

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

  1. Шаги сборки должны быть понятными и воспроизводимыми.

  2. Вы должны точно знать, что выполнялось во время процесса сборки.

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

GitHub Actions помогает реализовать эти возможности. Инструкции по сборке хранятся в репозитории вместе с кодом. Вы выбираете среду, в которой выполняется сборка, включая Windows, Mac, Linux или средства выполнения, размещенные вами. Каждая сборка начинается с нового образа средства выполнения тестов, что затрудняет сохранение атаки в вашей среде сборки.

Помимо преимуществ безопасности, GitHub Actions позволяет запускать сборки вручную, периодически или в ответ на события Git в репозитории для частых и быстрых сборок.

GitHub Actions — это большая тема, но хорошим местом для начала является[ AUTOTITLE, а такжеСинтаксис рабочего процесса для GitHub Actions иОбщие сведения о GitHub Actions](/actions/using-workflows/triggering-a-workflow).

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

Note

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

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

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

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

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

Аттестации артефактов включают подпись по встроенному артефакту, а также ссылки на исходный код и инструкции по сборке. Если вы подписываете сборку с помощью аттестаций артефактов, вам не нужно управлять собственным материалом ключа подписывания. GitHub обрабатывает это для вас с помощью центра подписывания, который мы работаем.

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

Подписывание сборок

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

Как именно вы подписываете сборку, зависит от того, какой код вы пишете, и от того, кто ваши пользователи. Часто сложно понять, как безопасно хранить закрытый ключ. Одним из основных вариантов здесь является использование зашифрованных секретов GitHub Actions, хотя необходимо соблюдать осторожность и внимательно ограничивать доступ к этим рабочим процессам GitHub Actions. Если закрытый ключ хранится в другой системе, доступной через Интернет (такой как Microsoft Azure или HashiCorp Vault), можно использовать более сложный вариант — проверку подлинности с помощью OpenID Connect, чтобы не передавать секреты в системах. Если закрытый ключ доступен только из частной сети, можно также использовать локальные средства выполнения для GitHub Actions.

Дополнительные сведения см. в разделе "[AUTOTITLE", "Использование секретов в GitHub Actions", иСведения об усилении защиты с помощью OpenID Connect](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners).

Усиление защиты для GitHub Actions

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

Дополнительные сведения см. в разделе "[AUTOTITLE" и "Защита системы безопасности для GitHub Actions](/actions/security-guides/using-githubs-security-features-to-secure-your-use-of-github-actions)".

Следующие шаги