Что такое безопасность цепочки поставок программного обеспечения?

Цепочка поставок программного обеспечения включает в себя все, что влияет или играет роль в продукте или приложении на протяжении всего жизненного цикла разработки программного обеспечения (SDLC).

В последние годы атаки на цепочку поставок программного обеспечения становятся все более распространенными и изощренными. В своем отчете за 2022 год Gartner гласит: «Ожидайте постоянного расширения зоны корпоративных атак и увеличивайте инвестиции в процессы и инструменты для обнаружения и устранения угроз идентификации, а также обеспечения целостности цифровых цепочек поставок».

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

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

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

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

 

 

Атаки на цепочки поставок программного обеспечения: почему они так распространены?

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

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

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

SSDF (NIST 800-218) завершен и вступил в силу.

Структура SSDF (NIST 800-218) требует от поставщиков внедрения методов обеспечения безопасности, охватывающих жизненный цикл разработки программного обеспечения (SDLC). Он способствует обеспечению прозрачности и мерам защиты от несанкционированного доступа, стремясь уменьшить уязвимости безопасности и злонамеренное вмешательство.

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

SSDF состоит из четырех основных частей:

01 /
Подготовьте организацию (PO):

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

02 /
Защитите программное обеспечение (PS):

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

03 /
Создание хорошо защищенного программного обеспечения (PW):

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

04 /
Реагирование на уязвимости (RV):

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

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

SLSA — это структура, которую вы должны соблюдать

Разработанная в Google структура под названием SLSA (Уровни цепочки поставок для артефактов программного обеспечения) предоставляет рекомендации по достижению четырех уровней защиты цепочки поставок программного обеспечения. Платформа фокусируется на целостности сборки артефактов с целью предотвращения взлома и защиты артефактов.

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

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

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

Вам следует рассматривать SLSA как отраслевой стандарт, узнаваемый и согласованный уровень защиты и соответствия, которого вы должны придерживаться.

Как защитить цепочку поставок программного обеспечения?

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

Однако мы хотели бы подчеркнуть три основных класса мер безопасности:

1. Обеспечьте безопасность конфигурации жизненного цикла разработки программного обеспечения.

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

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

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

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

3. Проверка целостности и безопасности сборки программных артефактов.

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

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

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

Полное решение для цепочки поставок программного обеспечения должно включать в себя:

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

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

Механизм политики, который сравнивает эти аттестации с политикой, определенной организацией, или с политикой, основанной на стандартах, для проверки и демонстрации соответствия.

Центр обмена информацией, связанной с доверием, между производителями и потребителями программного обеспечения; это может быть внутри или внутри предприятия).

Читать

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

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

Добавьте к этому тот факт, что компании не хотят передавать друг другу свой проприетарный код.

Гарантия кода на протяжении всего SDLC

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

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

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

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

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

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

Подробнее

Объяснение безопасности цепочки поставок программного обеспечения

Что скрывается в вашем коде?

Как повысить доверие к цепочке поставок программного обеспечения?

Каковы последствия окончательной версии SSDF (NIST 800-218)?

Что насчет Continuous Assurance и безопасности цепочки поставок программного обеспечения?

Почему непрерывное обеспечение является неотъемлемой практикой обеспечения безопасности цепочки поставок программного обеспечения?

Как реализовать автоматическую оценку соответствия SLSA?

Как SBOM может повысить безопасность цепочки поставок программного обеспечения?

Как защитить свое программное обеспечение с помощью SBOM?

Автоматизация оценки соответствия SLSA

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

Оценку соответствия SLSA можно автоматизировать в соответствии с их требованиями. Но как организации следует его приобрести? Есть ли конкретные рекомендации, которым вам следует следовать?

Посмотрите это видео, где мы делимся лучшими практиками реализации автоматизации с использованием инструментов с открытым исходным кодом, таких как Sigstore и OPA, в реальных сценариях. Как концептуальные, так и технические передовые практики проливают свет на реальные детали и проблемы оценки и автоматизации соответствия SLSA.

Перед использованием Scribe После использования Scribe
Trust Hub – обмен информацией

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

  • Совместное использование и управление SBOM как внутри организации с другими заинтересованными сторонами, так и снаружи с клиентами или пользователями.
  • Интеллектуальный SBOM с действенной информацией
  • Данные SBOM можно использовать в качестве «ворот» для конвейера или продукта, используемых для определения того, соответствует ли полученное изображение ожидаемому.
  • Теперь возможна синхронизация между разными командами и организациями.
Безопасный SDLC: политика и соответствие требованиям

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

  • Надежный, основанный на фактических данных способ, гарантирующий соблюдение безопасных политик SDLC в соответствии с новейшими правилами и рамками безопасности цепочки поставок программного обеспечения (SLSA 3, SSDF).
Обнаружение целостности и взлома

  • Только то, что вы можете почерпнуть из журналов и API.
  • Не подписан до самого конца процесса – прямо перед доставкой (относится только к «финальному лагу» MITM)

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

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

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

  • Проверка неправильной конфигурации инструментов CI/CD
  • Ищем утекшие секреты
  • Проверка известных уязвимостей (CVE)

  • Проверка пробелов SDLC в вашей цепочке инструментов CI/CD.
  • Проверка известных уязвимостей (CVE) и репутации репозиториев OSS.
  • Регистрация защищенных от несанкционированного доступа подтверждений того, что необходимые меры безопасности были приняты вовремя на каждом этапе процесса в соответствии с политикой SDLC организации.

Scribe Security — новый стандарт безопасности цепочки поставок программного обеспечения

Непрерывное обеспечение кода состоит из процессов и инструментов, которые:

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

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

Проверьте целостность инструментов CI/CD, используемых для создания кода.

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

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

Читать далее

Чем мы можем помочь?

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

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

Свяжитесь с нами

Оставайтесь в курсе

Непрерывное обеспечение и безопасность цепочки поставок программного обеспечения | Писец безопасности
Непрерывное обеспечение: неотъемлемая практика обеспечения безопасности цепочки поставок программного обеспечения
Читать далее
ОКОНЧАТЕЛЬНАЯ ВЕРСИЯ SSDF
Финальная версия SSDF (NIST 800-218) – отличия от проекта и их последствия для вас
Читать далее
Изображение статьи IconBurst
IconBust, новая атака NPM
Читать далее

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

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

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

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

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

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

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

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

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

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

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

Финальная версия НИСТ SSDF 1.1 (Secure Software Development Framework) была выпущена 22 марта. В сентябре 2021 года был опубликован черновой вариант структуры. Многие различия сосредоточены вокруг различных приведенных примеров, а не вокруг практик и задач высокого уровня.

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

Укрепление доверия к вашему программному обеспечению — важная задача, особенно с учетом новых стандартов и лучших практик, таких как SSDF и SLSA. Вскоре продавцы, которые не смогут доказать это доверие, не смогут продавать свою продукцию федеральному правительству США.

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

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

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

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