Непрерывное обеспечение: неотъемлемая практика обеспечения безопасности цепочки поставок программного обеспечения

Эти является второй в серии статей, посвященных новым рекомендациям NIST SP 800-218. Первую статью можно найти здесь.

Непрерывная гарантия:
Комплексная практика обеспечения безопасности цепочки поставок программного обеспечения

Как мы обсуждали в нашей предыдущей статье, руководящие принципы, установленные Национальным институтом стандартов и технологий США (NIST), радикально изменят способ предоставления программных продуктов и услуг правительству Соединенных Штатов. 

В частности, НИСТ СП 800-218 устанавливает набор высокоуровневых безопасных методов разработки программного обеспечения, которые должны быть интегрированы в каждый жизненный цикл разработки программного обеспечения (SDLC). Ожидается, что внедрение этих практик во всю цепочку поставок программного обеспечения будет способствовать созданию более безопасных продуктов и услуг для доставки не только правительству США, но, в конечном итоге, во все отрасли и по всему миру. 

В этой статье мы рассмотрим решающую роль Continuous Assurance (CA) в удовлетворении этих новых требований. 

Обзор: что такое непрерывное обеспечение и как оно работает? 

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

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

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

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

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

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

Почему непрерывный?

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

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

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

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

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

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

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

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

Сбор доказательств: примеры и рекомендации

Вот несколько примеров доказательств, которые можно собрать в рамках SDLC:

Вот типы политик, которые можно использовать, используя эти доказательства:

Будущее непрерывного контроля кода

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

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

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