Рекомендации по защите кода в цепочке поставок

Об этом руководстве

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

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

Приведем некоторые ключевые риски в процессе развертывания.

• Использование зависимостей с уязвимостями системы безопасности, которыми может воспользоваться злоумышленник.
• Утечка учетных данных или маркера проверки подлинности, которыми может воспользоваться злоумышленник для доступа к ресурсам.
• Внесение уязвимости в собственный код, который злоумышленник может использовать.

Эти риски открывают возможности для атаки на ваши ресурсы и проекты. Кроме того, эти риски напрямую передаются всем, кто использует созданный вами пакет. В следующих разделах объясняется, как защитить себя и пользователей от этих рисков.

Создание программы управление уязвимостями для зависимостей

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

1. создали инвентаризацию зависимостей;

2. знаете, когда в зависимости присутствует уязвимость системы безопасности;

3. Принудительное применение проверок зависимостей для запросов на вытягивание.

4. оценили влияние этой уязвимости на код и приняли решение, какие действия следует предпринять.

Автоматическое создание инвентаризации

В качестве первого шага необходимо выполнить полную инвентаризацию зависимостей. Граф зависимостей для репозитория показывает зависимости для поддерживаемых экосистем. Если вы синхронизируете свои зависимости или используете другие экосистемы, вам нужно будет дополнить его данными из сторонних инструментов или перечислить зависимости вручную. Если у вас есть по крайней мере доступ на чтение к репозиторию, вы можете экспортировать граф зависимостей для репозитория в качестве совместимого с SPDX программного обеспечения, счета за материалы (SBOM) с помощью пользовательского интерфейса GitHub или GitHub REST API. Дополнительные сведения см. в разделе Экспорт программного счета за материалы для репозитория.

Автоматическое обнаружение уязвимостей в зависимостях

          Dependabot может помочь вам, отслеживая ваши зависимости и уведомляя вас о наличии известной уязвимости. Вы даже можете включить Dependabot автоматический вызов pull request, которые обновляют зависимость до защищённой версии. Дополнительные сведения см. в разделе [AUTOTITLE и [AUTOTITLE](/code-security/dependabot/dependabot-alerts/about-dependabot-alerts)](/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates).

Автоматическое обнаружение уязвимостей в запросах на вытягивание

Это Действие проверки зависимостей требует проверки зависимостей для ваших pull-запросов, что облегчает вам возможность увидеть, не внесёт ли он уязвимую версию зависимости в ваш репозиторий. Когда обнаружена уязвимость, они Действие проверки зависимостей могут заблокировать слияние pull request. Дополнительные сведения см. в разделе Сведения о проверке зависимостей.

Оценка подверженности риску от уязвимой зависимости

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

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

Защита маркеров взаимодействия

Код часто должен взаимодействовать с другими системами по сети, поэтому необходимо использовать секреты (такие как пароль или ключ API) для проверки подлинности. Чтобы ваша система могла работать, ей нужен доступ к этим секретам, но рекомендуется не включать их в исходный код. Это особенно важно для репозиториев, к которым многие люди могут иметь доступ и критически важные для общедоступных репозиториев.

Автоматическое обнаружение секретов, зафиксированных в репозитории

          GitHub Сотрудничайте со многими провайдерами, чтобы автоматически определять, когда секреты закреплены или хранятся в ваших публичных репозиториях и публичных NPM-пакетах, от которых вы зависите, и уведомляет провайдера, чтобы тот мог принять необходимые меры для обеспечения безопасности вашего аккаунта. Дополнительные сведения см. в разделе [AUTOTITLE](/code-security/secret-scanning/managing-alerts-from-secret-scanning/about-alerts##about-partner-alerts).

Вы можете включить и настроить дополнительное сканирование, которое будет предупреждать вас о случайно утеченных секретах, если GitHub вы владеете:

• Общедоступные репозитории.
• Организация, использующая GitHub Team или GitHub Enterprise Cloud имеющая лицензию на GitHub Secret Protection or GitHub Advanced Security. Secret scanning Также проанализирую ваши личные репозитории.

Безопасное хранение секретов, на которых вы используете GitHub

Помимо кода, вам, вероятно, придётся использовать секреты и в других местах. Например, чтобы рабочие GitHub Actions процессы Dependabotили ваша GitHub Codespaces среда разработки могли взаимодействовать с другими системами. Дополнительные сведения о безопасном хранении и использовании секретов см. в разделе AUTOTITLE, [AUTOTITLE[ и Использование секретов в GitHub Actions](/code-security/dependabot/working-with-dependabot/configuring-access-to-private-registries-for-dependabot#storing-credentials-for-dependabot-to-use).](/codespaces/managing-your-codespaces/managing-encrypted-secrets-for-your-codespaces)

Хранение уязвимых шаблонов кода вне вашего репозитория

Создание процесса проверки запроса на вытягивание

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

Сканирование кода на наличие уязвимых шаблонов

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

Дальнейшие шаги

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview)
  

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-accounts)
  

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds)