Лучшие практики обеспечения безопасности цепочки поставок программного обеспечения

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

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

Безопасность цепочки поставок программного обеспечения — это набор стандартизированных методов, применяемых для защиты вашего программного обеспечения от потенциальных уязвимостей на протяжении всего жизненного цикла разработки программного обеспечения, начиная с момента разработки приложения и заканчивая непрерывной интеграцией и развертыванием (конвейер CI/CD).

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

Лучшие практики для защиты вашей цепочки поставок программного обеспечения

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

Приобретайте хорошо защищенные компоненты

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

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

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

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

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

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

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

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

• Создание проектной и архитектурной документации для каждого артефакта.
• Создание моделей угроз для программных продуктов
• Определение и реализация тестов безопасности
• Установка конкретных критериев выпуска для оценки продукта
• Установление политик обработки уязвимостей для каждого продукта
• Документирование и публикация процедур безопасности для каждой версии программного обеспечения.

 Используйте безопасные сторонние программные наборы инструментов и библиотеки совместимости.

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

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

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

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

Предотвращение модификации или использования исходного кода инсайдерами.

По данным Агентства кибербезопасности и безопасности инфраструктуры (CISA), инсайдером является любое лицо, имеющее авторизованный доступ или знание ресурсов организации. Лица, которые имеют или имели доступ к вашим объектам, сети, оборудованию и системам, могут потенциально поставить под угрозу целостность вашего программного продукта, намеренно или неосознанно.

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

• Сбалансированный и аутентифицированный процесс регистрации исходного кода
• Автоматическое сканирование безопасности на наличие уязвимостей
• Обучение безопасной разработке программного обеспечения
• Укрепление среды разработки
• Приоритизация проверок кода

Сохраняйте код или исполняемые файлы и проверяйте все изменения перед утверждением.

Управление версиями — это одна из стандартных практик, которая помогает поддерживать целостность вашего программного обеспечения. В рамках процесса непрерывной интеграции и развертывания (конвейер CI/CD) вам потребуется поддерживать репозиторий для хранения вашего кода и исполняемых файлов. Это обеспечивает рабочую историю вашего кода, поэтому вы можете легко отслеживать, что было в стеке разработки до этого момента.

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

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

Создайте и поддерживайте SBOM для каждого созданного пакета программного обеспечения.

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

Спецификация программного обеспечения может быть подготовлена ​​на основе спецификаций, определенных в стандартных форматах, таких как теги обмена данными пакета программного обеспечения (SPDX), CycloneDX и идентификации программного обеспечения (SWID), определенные Linux, OWASP и NIST соответственно.

Для каждого создаваемого вами программного продукта поставщики или владельцы сторонних компонентов, которые вы используете, должны предоставить полную спецификацию программного обеспечения. Результаты вашего проекта и SBOM, предоставленные поставщиком, также могут быть проверены с помощью инструмента анализа состава (SCA).

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

Укрепите среду сборки

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

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

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

Системы блокировки

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

Ограничьте активность внешней сети и сети вне локальной сети.

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

Мониторинг систем на предмет утечек данных

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

Настройте конвейер контроля версий

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

Многофакторная аутентификация

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

Разделите инженерную сеть

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

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

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

Поставщики программного обеспечения должны иметь процесс принятия обновлений или отчетов о потенциальных уязвимостях или дефектах в своих продуктах от сторонних исследователей или клиентов. Вам также необходима автоматизированная система, которая уведомляет вас об обновлениях уязвимостей, объявленных доверенными организациями, такими как Агентство кибербезопасности и безопасности инфраструктуры (CISA).

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

Обслуживание компонентов

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

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

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