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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете настроить secret scanning для проверки секретов, выданных многими поставщиками услуг, и уведомления вас об обнаружении. Вы также можете определить пользовательские шаблоны для обнаружения дополнительных секретов на уровне репозитория, организации или предприятия. Дополнительные сведения см. в разделе [AUTOTITLE и Сведения о проверке секретов](/code-security/secret-scanning/introduction/supported-secret-scanning-patterns).

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

Кроме кода, вероятно, необходимо использовать секреты в других местах. Например, чтобы разрешить рабочим процессам GitHub Actions или Dependabot взаимодействовать с другими системами. Дополнительные сведения о безопасном хранении и использовании секретов см. в разделе [AUTOTITLE и Настройка доступа к частным реестрам для Dependabot](/actions/security-guides/encrypted-secrets).{ % else %}".

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

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

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

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

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

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

• Защита сквозной цепочки поставок

• Рекомендации по защите учетных записей

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