Рекомендации по обеспечению безопасности для цепочки поставок программного обеспечения

Открытый код можно встретить повсюду. Его можно найти во многих проприетарных базах кода и проектах сообщества. Для организаций и отдельных лиц вопрос уже не в том, используют ли они открытый код, а в том, какой именно открытый код и в каком объеме.

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

Зависимости

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

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

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

Уязвимости

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

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

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

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

Компрометация цепочки поставок

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

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

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

Состояние Octoverse 2020 — жизненный цикл уязвимостей

Программное обеспечение, к которому не были применены исправления

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

• Знайте, что находится в вашей среде. Для этого необходимо определить все зависимости и все промежуточные зависимости вашего проекта и оценить риски этих зависимостей, например уязвимости или ограничения лицензирования.
• Управляйте зависимостями. При обнаружении новой уязвимости системы безопасности необходимо определить, затрагивает ли вас эта уязвимость, и если да, то установить последнюю версию программного обеспечения и доступные исправления для системы безопасности. Особенно важно отслеживать изменения, которые включают появление новых зависимостей, и регулярно выполнять аудит старых зависимостей.
• Отслеживайте цепочку поставок. Для этого выполняйте аудит средств контроля, используемых для управления зависимостями. Это поможет обеспечить соблюдение более строгих условий для ваших зависимостей.

&Состояние Octoverse 2020 — Рекомендации

Мы расскажем о различных средствах и методах, предоставляемых NuGet и GitHub, которые можно использовать для устранения потенциальных рисков вашего проекта.

Ознакомление с тем, что находится в вашей среде

Пакеты с известными уязвимостями

Пользователь пакета | Автор пакета

.NET 8 и Visual Studio 17.8 добавили NuGetAudit, который будет предупреждать о прямых пакетах с известными уязвимостями при восстановлении. .NET 9 и Visual Studio 17.12 изменили настройки по умолчанию, чтобы также предупреждать о транзитивных пакетах.

NuGetAudit требует источника для предоставления известной базы данных уязвимостей, поэтому если вы не используете nuget.org в качестве источника пакета, его следует добавить в качестве источника аудита.

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

Схема зависимостей NuGet

📦 Пользователь пакета

Просмотреть зависимости NuGet для проекта можно непосредственно в соответствующем файле проекта.

Обычно это находится в одном из двух мест.

• packages.config – расположен в корневом каталоге проекта.
• <PackageReference> — расположен в файле проекта.

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

Для сред CLI можно использовать dotnet list package команду для вывода списка зависимостей проекта или решения. Вы также можете использовать команду dotnet nuget why, чтобы понять, почему транзитивные пакеты (те, на которые ваш проект не ссылается напрямую) включаются в пакетный граф проекта.

Дополнительные сведения об управлении зависимостями NuGet см. в следующей документации.

Диаграмма зависимостей GitHub

📦 Пользователь пакета | 📦🖊 Автор пакета

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

Для получения дополнительной информации о зависимостях репозитория GitHub см. следующую документацию.

Версии зависимостей

Пользователь пакета | Автор пакета

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

• Visual Studio
• .NET SDK и Runtime
• NuGet
• Пакеты NuGet

Управление зависимостями

Устаревшие и содержащие уязвимости зависимости NuGet

📦 Пользователь пакета | 📦🖊 Автор пакета

С помощью dotnet CLI вы можете получить список всех известных нерекомендуемых или содержащих уязвимости зависимостей, которые могут содержаться в вашем проекте или решении. Вы можете использовать команду dotnet list package --deprecated или dotnet list package --vulnerable для получения списка любых известных устареваний или уязвимостей. NuGetAudit может предупреждать вас об известных уязвимых зависимостях и включён по умолчанию, если источник предоставляет базу данных уязвимостей.

Уязвимые зависимости GitHub

Пользователь пакета | Автор пакета

Если ваш проект размещен на GitHub, вы можете использовать GitHub Security для поиска уязвимостей безопасности и ошибок в вашем проекте, и Dependabot исправит их, открыв pull request против вашего кода.

Одна из целей подхода «Сдвиг влево» — это перехват зависимостей, содержащих уязвимости, до их появления. Возможность получить сведения о зависимостях, таких как лицензия, промежуточные зависимости и возраст зависимостей, поможет вам сделать именно это.

Дополнительные сведения об оповещениях и обновлениях для системы безопасности Dependabot см. в следующей документации.

Конфигурация NuGet

📦 Пользователь пакета

nuget.config Добавьте файл в корневой каталог репозитория проекта. Это рекомендуется, так как оно способствует повторяемости и гарантирует, что разные пользователи имеют одну и ту же конфигурацию NuGet. Рекомендуется добавлять clear элемент(ы), чтобы исключить применение специфичной для пользователя или машины конфигурации. Дополнительные сведения о применении параметров.

Рассмотрим пример.

<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
  <packageSourceMapping>
    <clear />
  </packageSourceMapping>
</configuration>

Каналы NuGet

📦 Пользователь пакета

Используйте источники пакетов, которыми вы доверяете. При использовании нескольких общедоступных и частных источников пакетов NuGet пакет может быть загружен из любого из источников. Чтобы гарантировать, что ваша сборка является предсказуемой и защищенной от известных атак, таких как Путаница зависимостей, необходимо знать, из каких конкретных источников поступают ваши пакетные зависимости. Для защиты можно использовать один веб-канал или частный веб-канал с возможностями восходящего потока.

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

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

Политики доверия клиентов

📦 Пользователь пакета

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

Для настройки политик доверия клиентов см. следующую документацию.

Файлы блокировки

📦 Пользователь пакета

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

Чтобы включить блокировку файлов, см. следующую документацию.

Сопоставление источников пакетов

📦 Пользователь пакета

Сопоставление источников пакетов позволяет централизованно объявлять, из какого источника будет восстанавливаться каждый пакет в решении в файле nuget.config.

Сведения о том, как включить сопоставление источников пакетов, см. в следующей документации.

Безопасные компьютеры

Права доступа к каталогу

📦 Пользователь пакета

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

Если вы используете пакеты, которые не находятся в nuget.org, то если любая другая учетная запись на компьютере может считывать глобальные пакеты NuGet или каталоги кэша HTTP или выходной каталог сборки проекта, эти пакеты могут быть раскрыты пользователям, которые не должны иметь доступа к этим пакетам.

На Linux dotnet nuget update source изменит разрешения файла nuget.config, чтобы сделать его доступным только для чтения владельцем файла. Тем не менее, если измените файл nuget.config любым другим способом, и он находится в расположении, где другие учетные записи могут считывать файл, может произойти утечка информации об URL-адресе источника пакета или учетных данных источника пакета. Необходимо убедиться, что любой файл конфигурации nuget.config не может быть прочитан другими пользователями того же компьютера.

Решения в каталоге загрузок

📦 Пользователь пакета

Следует проявлять особую осторожность при работе с решениями или проектами в каталоге загрузок. NuGet накапливает параметры из нескольких файлов конфигурации, и MSBuild обычно импортирует Directory.Build.props, Directory.NuGet.props, Directory.Build.targets и потенциально другие файлы из любого родительского каталога прямо до корневого каталога файловой системы.

Папка загрузок представляет дополнительный риск, так как обычно это расположение по умолчанию, куда веб-браузеры загружают файлы из Интернета.

Агенты сборки

📦 Пользователь пакета

Агенты сборки (агенты CI), которые не сбрасываются в исходное состояние после каждой сборки, имеют несколько рисков, которые необходимо учитывать.

Сведения о безопасных способах управления учетными данными см. в документации по потреблению пакетов из аутентифицированных каналов.

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

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

Отслеживание цепочки поставок

Сканирование секретов GitHub

📦🖊 Автор пакета

GitHub проверяет репозитории на наличие ключей API NuGet, чтобы предотвратить неправомерное использование секретов, которые были зафиксированы случайно.

Чтобы узнать больше о проверке секретов, см. Проверка секретов.

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

📦🖊 Автор пакета

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

Чтобы подписать пакет, см. раздел Подписывание пакета.

Воспроизводимые сборки

📦🖊 Автор пакета

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

Дополнительные сведения о воспроизводимых сборках см. в Созданиe пакетов с исходной ссылкой и Воспроизводимая проверка сборки.

Двухфакторная проверка подлинности (2FA)

📦🖊 Автор пакета

Для каждой учетной записи на nuget.org включена двухфакторная аутентификация. Это добавляет дополнительный уровень безопасности при входе в вашу учетную запись GitHub или учетную запись NuGet.org.

Резервирование префикса идентификатора пакета

📦🖊 Автор пакета

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

Дополнительные сведения о резервировании префиксов идентификаторов см. в разделе Резервирование префикса идентификатора пакета.

Объявление нерекомендуемым и удаление из списка пакета, содержащего уязвимости

📦🖊 Автор пакета

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

Сведения о том, как объявить пакет нерекомендуемым и снять его с публикации, см. в следующей документации по объявлению пакета устаревшим и снятию с публикации пакетов.

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

Итоги

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

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

Дополнительные сведения о защите программного обеспечения во всем мире см. в «Отчете о безопасности The State of the Octoverse 2020».