Финальная версия SSDF (NIST 800-218) – отличия от проекта и их последствия для вас

22 марта NIST выпустил финальную версию SSDF 1.1 (среды разработки безопасного программного обеспечения). 

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

Что такое структура NIST SP 800-218? SSDF объединяет давние рекомендации по передовой практике безопасной разработки программного обеспечения. Его настраиваемый, независимый от отрасли подход создан для облегчения межведомственной коммуникации (и производителя/покупателя), помогающей определить стратегические цели и оценить текущие пробелы. 

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

Отличия финальной версии от черновой: 

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

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

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

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

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

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

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

Резюме

В целом, NIST считает, что «практика, задачи и примеры реализации SSDF представляют собой отправную точку для рассмотрения. Они предназначены для изменения и настройки, а также для развития с течением времени».

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

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

Чтобы узнать больше о новых правилах и SSDF, посетите наш вебинар на «Демистификация новых правил кибербезопасности в 2022 году».