Информация о руководстве
В этом руководстве описываются самые важные изменения, которые можно внести для улучшения защиты вашей системы сборки. В каждом разделе описаны изменения, которые можно внести в процессы для повышения безопасности. Сначала указаны изменения с самым высоким влиянием.
В чем заключаются риски?
Некоторые атаки на цепочки поставок программного обеспечения направлены непосредственно на систему сборки. Если злоумышленник сможет изменить процесс сборки, то сможет использовать систему, не прилагая никаких усилий для взлома личных учетных записей или кода. Важно, чтобы вы не забывали защитить систему сборки, как и личные учетные записи и код.
Защита системы сборки
Существует несколько возможностей обеспечения безопасности, которые должна иметь система сборки.
-
Шаги сборки должны быть понятными и воспроизводимыми.
-
Вы должны точно знать, что выполнялось во время процесса сборки.
-
Каждая сборка должна начинаться в новой среде, чтобы взломанная сборка не сохранялась и не могла повлиять на будущие сборки.
GitHub Actions помогает реализовать эти возможности. Инструкции по сборке хранятся в репозитории вместе с кодом. Вы выбираете среду, в которой выполняется сборка, включая Windows, Mac, Linux или средства выполнения, размещенные вами. Каждая сборка начинается с нового образа средства выполнения тестов, что затрудняет сохранение атаки в вашей среде сборки.
Помимо преимуществ безопасности, GitHub Actions позволяет запускать сборки вручную, периодически или в ответ на события Git в репозитории для частых и быстрых сборок.
GitHub Actions — это большая тема, но хорошим местом для начала [является AUTOTITLE, а также Синтаксис рабочего процесса для GitHub Actions и Общие сведения о GitHub Actions](/actions/using-workflows/triggering-a-workflow).
Подписывание сборок
После того как процесс сборки будет защищен, вам следует предотвратить незаконное изменение конечного результата процесса сборки. Подписывание ваших сборок — отличный способ сделать это. При публичном распространении программного обеспечения это часто делается с помощью пары открытого и закрытого криптографических ключей. Вы используете закрытый ключ для подписи сборки и публикуете открытый ключ, чтобы пользователи программного обеспечения могли проверить подпись в сборке до его использования. Если байты сборки изменятся, подпись не пройдет проверку.
Как именно вы подписываете сборку, зависит от того, какой код вы пишете, и от того, кто ваши пользователи. Часто сложно понять, как безопасно хранить закрытый ключ. Одним из основных вариантов здесь является использование зашифрованных секретов GitHub Actions, хотя необходимо соблюдать осторожность и внимательно ограничивать доступ к этим рабочим процессам GitHub Actions. Если закрытый ключ доступен только из частной сети, можно также использовать локальные средства выполнения для GitHub Actions.
Дополнительные сведения см. в разделе AUTOTITLE[ и О самостоятельно размещенных средствах выполнения](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect).](/actions/security-guides/encrypted-secrets)
Усиление защиты для GitHub Actions
Существует много дополнительных действий, которые можно предпринять для дополнительной защиты GitHub Actions. В частности, будьте осторожны при оценке сторонних рабочих процессов и рассмотрите возможность использования CODEOWNERS, чтобы ограничить пользователей, которые могут вносить изменения в рабочие процессы.
Дополнительные сведения см. в разделе [AUTOTITLE и Защита системы безопасности для GitHub Actions](/actions/security-guides/using-githubs-security-features-to-secure-your-use-of-github-actions).