Программное обеспечение с открытым исходным кодом всегда уязвимо для злоумышленников, но спецификации программного обеспечения могут помочь смягчить угрозу. Рекомендации АНБ закладывают прочную основу для управления экосистемой.
Безопасность цепочки поставок программного обеспечения по-прежнему остается важной темой для кибербезопасности и индустрии программного обеспечения, и на это есть веская причина — от продолжающихся атак на крупных поставщиков программного обеспечения до злонамеренного сосредоточения злоумышленников на экосистеме программного обеспечения с открытым исходным кодом. В связи с этим, продолжается разработка надежных рекомендаций, помогающих практикам снизить риски в цепочке поставок программного обеспечения. Последняя публикация «Защита цепочки поставок программного обеспечения: рекомендуемые методы управления программным обеспечением с открытым исходным кодом и спецификациями программного обеспечения» выпущена Агентством национальной безопасности США (АНБ).
Данная публикация основана на предыдущих, таких как Исполнительный указ Белого дома по кибербезопасности (EO), а также меморандумы и предстоящие требования для федеральных агентств, такие как меморандумы Управления управления и бюджета (OMB) 22-18 и 23-16 , которые требуют от поставщиков программного обеспечения федеральному правительству США подтверждения соответствия таким публикациям, как Secure Software Development Framework (SSDF) Национального института стандартов и технологий (NIST), а в некоторых случаях даже предоставление SBOM.
Хотя руководство АНБ ссылается на предыдущие публикации Белого дома, NIST и OMB, эта публикация актуальна для всех организаций, производящих и потребляющих программное обеспечение, использующих открытое ПО (OSS) и желающих использовать такие артефакты, как SBOM (Software Bill of Materials — это список всех open source и других сторонних компонент, использующихся в кодовой базе программного продукта.). Вот некоторые из ключевых областей руководства, включая рекомендации и выводы из документа.
Оглавление
Структура руководства АНБ по SBOM
Руководство АНБ сосредоточено на четырех ключевых областях, как указано в таблице ниже, и согласовано с SSDF (Secure Software Development Framework). (Область 1 опущена, поскольку это просто введение):
Управление программным обеспечением с открытым исходным кодом
В этом разделе руководства АНБ определяются, среди прочего, ключевые роли и обязанности разработчиков и поставщиков. В нем отмечается, что у разработчиков есть такие обязанности, как выявление потенциальных решений OSS для использования и интеграция решений OSS в программное обеспечение продукта, а также отслеживание обновлений этих компонентов. Поставщики — это те, кто производит продукт или услугу и выполняет такие действия, как мониторинг изменений лицензий или уязвимостей компонентов OSS, включенных в продукты, из-за рисков, которые они могут передать последующим потребителям.
АНБ излагает основные соображения по использованию OSS, такие как оценка компонентов OSS на наличие уязвимостей в таких источниках, как NVD (National Vulnerability Database) и другие базы данных уязвимостей, а также обеспечение того, чтобы уязвимые компоненты не были включены в продукты. Оно также рекомендует организациям помнить о вопросах лицензирования, таких как соблюдение лицензий, а также экспортный контроль, например, развивающиеся правила ЕС, которые могут повлиять на включение OSS в продукты.
В руководстве рекомендуется использовать SBOM как средство управления наборами компонентов OSS, а также как средство обеспечения прозрачности для последующих потребителей и прозрачности уязвимости компонентов, включаемых в продукты при разработке. SBOM представляют собой вложенный перечень программных компонентов, и преобладающими форматами являются Linux Foundation SPDX и OWASP CycloneDX. АНБ рекомендует, чтобы создаваемые SBOM соответствовали минимальным требованиям к элементам, указанным в документе NTIA (National Telecommunications and Information Administration) «Минимальные элементы для SBOM».
Создание и поддержание внутрикорпоративного безопасного репозитория с открытым исходным кодом
Учитывая, насколько широко организации используют OSS (в некоторых исследованиях приводятся цифры о том, что 70-90% современных кодовых баз являются OSS и около 90% кодовых баз содержат некоторые компоненты OSS), еще одной рекомендацией руководства АНБ является создание и поддержание внутреннего безопасного репозитория OSS. Этот репозиторий помогает проверять компоненты OSS, чтобы убедиться, что они соответствуют организационным рискам и требованиям соответствия, прежде чем они будут доступны группам разработчиков и продуктов.
АНБ рекомендует использовать такие инструменты, как анализ состава программного обеспечения, для выявления уязвимостей, а также проблем с лицензированием, прежде чем предоставлять компоненты OSS разработчикам через безопасный репозиторий, как показано на изображении ниже:
Это означает, что организации необходимо определить процессы добавления пакетов ПО для использования, а также анализ безопасности и документацию, необходимую для добавления пакетов в защищенный репозиторий. В нем также отмечается, что для таких сред, как разработка, могут существовать разные политики по сравнению с продуктивными релизами, и рекомендуется согласовывать их с отраслевыми структурами, такими как Secure Supply Chain Consumption (S2C2F), которые направлены на предоставление разработчикам возможности безопасного использования OSS.
Процесс внедрения OSS должен включать в себя такие действия, как анализ состава программного обеспечения, сканирование на вирусы и фазинг-тестирование, происходящие в изолированных безопасных средах. Разработчикам также рекомендуется принимать во внимание другие факторы, такие как лицензирование, историю уязвимостей и преимущества внедрения компонентов с точки зрения времени и снижения внутренних затрат на разработку. АНБ также рекомендует использовать такие инструменты, как система показателей OpenSSF для анализа компонента. Система показателей OpenSSF выходит за рамки запаздывающих индикаторов риска, таких как известные уязвимости, и рассматривает такие аспекты, как обзоры кода проекта, плотность участников, техническое обслуживание и многое другое.
Отмечается, что небольшие организации могут иметь единый безопасный репозиторий и иметь разработчиков, реализующих управление, тогда как более крупные организации могут использовать комиссии по проверке открытого исходного кода для рассмотрения запросов на внедрение и привлечения ряда заинтересованных сторон, таких как разработка, управление и безопасность. Рекомендации включают в себя мониторинг репозиториев авторизованных компонентов на предмет новых уязвимостей и сохранение информации о том, какие группы разработчиков и продуктовые команды внедрили компонент, чтобы они могли участвовать в любых необходимых действиях по реагированию на инциденты, если компонент впоследствии станет уязвимым или скомпрометированным.
В целях обеспечения контекста и определения приоритетов для последующих потребителей программного обеспечения руководство рекомендует поставщикам и разработчикам принять документы Vulnerability Exploitability eXchange (VEX), чтобы помочь потребителям и клиентам узнать, какие компоненты действительно подвержены уязвимости, какие из них были устранены, и что потенциально следует нейтрализовать с помощью компенсирующих мер контроля.
АНБ также рекомендует поставщикам и поставщикам применять процессы аттестации, чтобы продемонстрировать безопасную разработку продукта на всех этапах создания, сканирования и комплектования, разработки и распространения продукта. Конечно, это происходит благодаря отраслевым усилиям, таким как in-toto (открытый стандарт метаданных для цепочки поставок ПО) и SSDF (Secure Software Development Framework), а также самоаттестации, когда машиночитаемые артефакты не генерируются и не используются. Это помогает обеспечить гарантию безопасности не только компонентов конечного продукта, но и процесса разработки.
Для устранения уязвимостей АНБ рекомендует использовать не только CVE и NVD, но и другие базы данных уязвимостей, такие как OSV, а также источники информации об уязвимостях, такие как каталог известных эксплуатируемых уязвимостей CISA (KEV) и систему оценки эксплойтов (EPSS), дающих представление не только о критичности уязвимостей, но также об известных или вероятных способах их эксплуатации.
Обслуживание, поддержка и антикризисное управление ПО с открытым исходным кодом
Еще одним ключевым видом деятельности, которому уделяется особое внимание, являются требования к безопасной подписи кода, такие как выполнение подписи кода, использование проверенной криптографии и защита самой инфраструктуры подписи кода. АНБ также рекомендует иметь план кризисного управления, основанный на таких руководствах, как «Руководство по реагированию на инциденты» NIST. Он включает в себя такие действия, как определение кризиса, структурирование того, как ваша организация будет реагировать и кто будет в этом участвовать. Это крайне важно иметь на случай активной эксплуатации уязвимостей компонента OSS. Это также включает в себя создание и развитие Группы кризисного управления (CMT), а также ее ролей и обязанностей. Эта группа будет расследовать потенциальные инциденты, связанные с активной эксплуатацией, определять, затронута ли система или приложение, если компонент находится в пути выполнения, и определять, можно ли исправить уязвимость и необходимы ли компенсирующие меры.
Создание, проверка и артефакты SBOM
В этом разделе руководства основное внимание уделяется инструментам, процессам и соображениям по созданию и использованию SBOM. Чтобы эффективно использовать SBOM, поставщикам необходимо понимать, как создаются продукты и какие компоненты они содержат. Руководство АНБ, учитывая, что SBOM могут создаваться на различных этапах жизненного цикла разработки программного обеспечения (SDLC), разбивает инструменты SBOM на четыре категории экстракторов: исходного кода, двоичных файлов, пакетов и среды выполнения.
АНБ рекомендует организации проверить точность содержимого SBOM перед подписанием. В нем также повторяется, что SBOM могут сопровождаться такими документами, как VEX, чтобы внести ясность в отношении уязвимых компонентов, действий, предпринятых поставщиками для устранения уязвимостей, и компонентов, которые потенциально остаются уязвимыми или пригодными для использования. Поскольку SBOM — новая и развивающаяся тема, АНБ указывает на различные ресурсы SPDX , CycloneDX и Linux Foundation, где организации могут узнать больше о SBOM, их роли и о том, как их можно использовать для снижения организационных рисков.
В руководстве подчеркивается скорость появления вредоносных эксплойтов, выпускаемых в среднем через 5,5 дней после обнаружения и раскрытия уязвимости, и рекомендуется использовать SBOM в конвейерах автоматизации, таких как CI/CD, для автоматизации создания SBOM. Оно также советует просмотреть ресурсы CISA (Cybersecurity & Infrastructure Security Agency) по SBOM и VEX. Подробную визуализацию того, как документы VEX и SBOM работают вместе, см. на изображении ниже:
Это демонстрирует, как SBOM может обеспечить прозрачность компонентов программного обеспечения, а VEX может сопровождать это от поставщиков программного обеспечения, чтобы сообщить, какие компоненты затронуты уязвимостями, и может потребовать определенных действий со стороны потребителей. SBOM и сопроводительные документы VEX могут быть предоставлены потребителям, чтобы сообщить, какие компоненты OSS входят в продукт или приложение, а VEX может помочь максимально использовать ресурсы, чтобы сосредоточиться на том, какие аспекты продукта уязвимы.
Это решает давнюю проблему отсутствия прозрачности, которая существует между поставщиками и потребителями программного обеспечения, и дает возможность повысить безопасность цепочки поставок программного обеспечения во всей экосистеме. Для получения более подробной информации о процессах SBOM для поставщиков ПО, руководство АНБ рекомендует использовать руководство NTIA (National Telecommunications and Information Administration) «Пособие для поставщиков программного обеспечения: производство и предоставление SBOM».