В апреле 2023 года CISA выпустило новое совместное руководство по безопасности программного обеспечения под названием Изменение баланса рисков кибербезопасности: принципы безопасности по замыслу и принципы по умолчанию. Руководство было составлено в сотрудничестве с 9 различными агентствами, включая АНБ, Австралийский центр кибербезопасности (ACSC) и Федеральное управление информационной безопасности Германии (BSI) и других. Тот факт, что множество агентств со всего мира сотрудничали в подготовке руководства по кибербезопасности, должен стать убедительным свидетельством важности, которую тема кибербезопасности имеет во всем мире на данный момент.
Джен Истерли, директор CISA, поделилась своими мыслями по теме кибербезопасности в недавней речи, которую она произнесла перед студентами и преподавателями Университета Карнеги-Меллон в Питтсбурге. По словам директора CISA, эти руководящие принципы должны помочь глобальной индустрии программного обеспечения в ближайшие годы:
- Бремя обеспечения безопасности никогда не должно ложиться исключительно на клиента. Производители программного обеспечения должны нести ответственность за свои продукты и код.
- Производители технологий должны принять радикальную прозрачность как обязательство нести ответственность за свою продукцию.
- Производителям технологий следует сосредоточиться на создании безопасных продуктов, разрабатывая такие, которые безопасны по своей конструкции и безопасны по умолчанию.
Руководство CISA учитывает эти основные принципы и расширяет их, включая полный список практических предложений, которые производители программного обеспечения могут использовать, чтобы вывести на рынок более безопасные продукты.
Интересно отметить, что многие явные предложения основаны на Структура SSDF NIST но сформулировано более практично, менее добровольно.
Одно из предложений руководства, которое напрямую связано с радикальной прозрачностью, заключается в том, чтобы производители программного обеспечения включили создание СБОМ в своем SDLC, чтобы обеспечить видимость компонентов своего программного обеспечения.
Но достаточно ли создать SBOM и даже опубликовать его? Что на самом деле может сделать производитель или потребитель программного обеспечения с файлом SBOM JSON или XML?
В этой статье мы рассмотрим возможности использования SBOM сегодня для производителя программного обеспечения, информацию, которую можно добавить в SBOM для ее обогащения, а также бизнес-аналитику, которую можно получить в результате изучения таких расширенных документов. Мы кратко рассмотрим сторону соблюдения требований при использовании SBOM и то, где лежит ваша ответственность как производителя программного обеспечения, агрегатора программного обеспечения или сопровождающего открытого исходного кода. В заключение мы поговорим об управлении рисками и о том, как принципы CISA, касающиеся безопасности по замыслу и безопасности по умолчанию, сочетаются с соблюдением нормативных требований в области кибербезопасности и продуманным управлением рисками.
Не все SBOM были созданы равными
Сегодня существует множество инструментов для создания SBOM, от решений с открытым исходным кодом до проприетарных решений, и человек или компания, желающие включить создание SBOM в свою СОП, могут легко это сделать. Можно было выбирать между разными стандартов тот, который наиболее соответствует их потребностям, но даже в этом случае вы можете столкнуться со слишком большим количеством инструментов, чтобы принять обоснованное решение. Итак, на что еще вы можете обратить внимание, выбирая именно то, что вам нужно? Генерация СБОМ инструмент для тебя?
Сначала проверьте, какая информация включена или пропущена при создании SBOM. Спецификация, включающая инструменты и код, которые были частью процесса разработки, но не являлись частью реального продукта, вероятно, будет содержать много избыточной информации, которую очень сложно «вычистить» из результирующего файла, чтобы вы могли оставить только самая актуальная информация. Аналогично, инструменты или код, которые не включены или намеренно опущены, будут явно отсутствовать, например, когда вы хотите сканировать уязвимости.
Список компонентов и зависимостей программного обеспечения сам по себе по большей части бессмысленен. Он служит очень малой цели, кроме того, что вы можете с ним делать. Сегодня наиболее распространенным использованием SBOM является сканирование компонентов программного обеспечения для получения списка уязвимостей, которые могут повлиять на ваш продукт.
Важно помнить, что около 95% обнаруженных вами уязвимостей не могут быть использованы в вашем продукте. Хитрость заключается в том, чтобы найти эти неуловимые 5%, составить план работы и начать бороться с этими уязвимостями, которые можно использовать. Как определить, что можно использовать, а что нет? Это большой вопрос, который не дает спать по ночам людям из службы безопасности и технических специалистов. Одним из текущих предложений является использование решения под названием VEX – Обмен эксплуатацией уязвимостей, форма рекомендаций по безопасности, целью которой является информирование о возможности использования компонентов с известными уязвимостями в контексте продукта, в котором они используются. Большая часть работы по просеиванию стога сена информации об уязвимостях и поиску уязвимостей, которые можно использовать, по-прежнему остается на усмотрение команды инженеров. В конце концов, кто будет знать свой продукт лучше, чем люди, которые его кодировали?
Однако вы можете сделать и другие вещи, особенно когда речь идет об унаследованных уязвимостях, которые происходят из родительских образов вашего образа Docker или из зависимостей, находящихся далеко в вашей цепочке зависимостей. Использование инструментов с открытым исходным кодом, таких как родительское изображение вы можете выяснить, какие уязвимости появились в родительском образе, а какие были прямым результатом вашего кода. Это должно устранить потенциально большой пул уязвимостей и облегчить работу по их анализу. Использование различных рекомендаций о различных уязвимостях также является хорошей идеей, поскольку, как только вы определили, что уязвимость не может быть использована, имеет смысл сообщить об этом другим членам вашей команды или вашим пользователям, чтобы вы не продолжали проверять одну и ту же уязвимость в каждой версии. вашего продукта, в котором вы даже не изменили модуль, в котором он был найден. Также желательно следить за зависимостями с открытым исходным кодом и сторонними поставщиками, чтобы, как только они найдут и исправят уязвимости, которые можно использовать, вы могли обновить этот код в своем продукте, чтобы сделать уверен, что вы также защищены от этой конкретной потенциальной проблемы.
Что еще вы можете добавить к SBOM?
Как указано выше, сегодня одним из наиболее распространенных применений SBOM является контрольный список для сканирования уязвимостей. Используя различные свободно доступные базы данных, такие как NVD (Национальная база данных уязвимостей), вы можете просмотреть список компонентов, аналогичный тому, который предоставляется SBOM, и увидеть, какие уязвимости он содержит. Получив список уязвимостей, вы можете упорядочить его по степени серьезности, проверить, есть ли у них существующие исправления и так далее.
Еще один уровень информации о ваших компонентах, который полезно иметь, — это их лицензия. Многие компоненты с открытым исходным кодом поставляются с лицензией, несовместимой с коммерческим использованием. Важно убедиться, что все ваши компоненты с открытым исходным кодом, даже те, которые вы не включили сами, но были включены каким-либо другим компонентом, совместимы со всем, что вы пытаетесь создать, с точки зрения их лицензии.
И последнее предложение — следить за показателями «здоровья» безопасности с открытым исходным кодом для ваших зависимостей, таких как Система показателей OpenSSF. Наличие объективного, относительно простого показателя кибербезопасности библиотек с открытым исходным кодом может оказаться большим подспорьем при принятии решения о том, какие библиотеки включить в ваш продукт или исключить из него. Эти оценки в сочетании с серьезностью уязвимостей — хороший способ упорядочить уязвимости, над которыми вы хотите работать в первую очередь.
Управление рисками как упражнение по бизнес-аналитике
Существует несколько риски безопасности любому производителю программного обеспечения приходится сталкиваться в наши дни. Удивительно, что производители чувствуют себя в безопасности, выводя что-либо на рынок, несмотря на вредоносное ПО, криптомайнеры, похитители паролей и программы-вымогатели. Никто не может справиться со всем сразу, поэтому компании создают модели угроз и пытаются управлять своими рисками в соответствии с тем, что они считают своими самыми слабыми звеньями. Самый простой первый шаг — убедиться, что ваш код и процесс разработки соответствуют всем применимым нормам и передовым практикам. SSDF Ниста и OpenSSF SLSA являются хорошей отправной точкой, а также требования США к таким вещам, как SBOM. Следование правилам и передовому опыту может, по крайней мере, обещать относительную безопасность от судебных разбирательств в соответствии с Safe Harbor программа. Но это только начало.
Руководство CISA призывает производителей подходить к созданию своей продукции в первую очередь с учетом безопасности. Некоторая «прикручиваемая» безопасность после завершения работы над продуктом не может устранить некоторые фундаментальные недостатки, являющиеся частью архитектуры продукта. Согласно руководству, продукты, защищенные дизайном, — это продукты, в которых безопасность клиентов является основной бизнес-целью, а не просто технической функцией. Производителям также рекомендуется принять радикальная прозрачность и подотчетность. Это означает, среди прочего, обеспечение того, что рекомендации по уязвимостям и связанные с ними общие уязвимости и воздействия (CVE) записи являются полными и точными. Это также означает, что рекомендуется делиться компонентами кода, его зависимостями и уязвимостями, чтобы показать пользователям и клиентам, что производитель, по крайней мере, осведомлен о потенциальных проблемах в продукте.
Согласно Википедии, Бизнес-аналитика (BI) включает в себя стратегии и технологии, используемые предприятиями для анализ данных и управление деловой информацией. Как вы можете себе представить, сбор SBOM для каждой сборки, а также отчета об уязвимостях, информации о лицензии и рекомендаций, которые определяют, какие уязвимости можно использовать, а какие нет, — это большой объем информации. Количество информационных точек увеличивается, если учесть срок службы типичного программного продукта и тот факт, что вы хотите иметь эту информацию для любого стороннего кода или инструмента, который вы используете, а также для пакетов с открытым исходным кодом, которые вы включаете. прямо или временно. Чтобы разобраться во всем этом таким образом, чтобы его могли использовать представители службы безопасности организации (вероятно, директор по информационной безопасности и подчиненные им люди), вам нужна система, единая платформа «панельного стекла». это позволяет вам систематизировать всю эту информацию, эффективно ее искать и при необходимости представлять ее в полезных отчетах. Чтобы привести лишь один пример того, насколько важной может быть платформа BI для платформы кибербезопасности, представьте себе Лог4Дж драма прошлого года. Разве не было бы здорово с помощью нескольких нажатий клавиш найти эту «новую» угрозу во всех ваших продуктах, включая зависимости и сторонние инструменты? А как насчет проверки наличия другой новой угрожающей CVE, которая только что вышла? Или подготовить отчет о том, как общее количество уязвимостей в вашей компании со временем постепенно уменьшается (или, по крайней мере, не увеличивается). Такую полезную информацию о «общей картине» может предложить только система BI на базе платформы сбора данных, обогащенной SBOM, обеспечивающей кибербезопасность.
Только получив всю необходимую информацию, вы сможете по-настоящему оценить свой риск, как в текущем коде, так и в зависимостях, а также при выборе включения или исключения какого-либо стороннего инструмента или кода из вашего продукта. При непрерывном запуске вы также можете использовать эту оценку риска для контроля сборок и остановки их производства или доставки в случае обнаружения какой-либо подозрительной активности.
Глядя в будущее
Технологии постоянно развиваются. Если когда-то монолитные проекты кода, расположенные на серверах, расположенных в офисе организации, были нормой, то сегодня это мультиоблачная микросервисная архитектура и LLM-программы. SBOM необходимо продолжать развиваться, чтобы иметь возможность поддерживать любую сложную архитектуру или инфраструктурное программное обеспечение, чтобы сохранять свою актуальность и полезность. Например, CycloneDX компании OWASP уже работает над включением Прозрачность машинного обучения в их формате SBOM. В тот же формат также обязательно включаются возможности VEX и API-интерфейс совместного использования SBOM при планировании на будущее. Я предсказываю, что все больше и больше платформ, подобных той, которую создал Писец будет создан для накопления и обмена информацией, связанной с безопасностью, включая SBOM, как по нормативным причинам, так и ради пользы и ценности, которую такая обогащенная информация представляет для организаций, использующих ее должным образом.
Платформа Scribe собирается выпустить новый инструмент BI как часть существующей платформы безопасности со всеми предложенными мной возможностями и многим другим. Я призываю вас попробуй, увидите полезность такой информации, накопленной с течением времени, и посмотрите, для чего вы можете использовать эту информацию. Независимо от того, решили ли вы включить платформу Scribe в свой SDLC или нет, гонка за более безопасную экосистему и более всеобъемлющий и полезный SBOM еще далека от завершения. Лучше уже сейчас сесть в вагон прозрачности, чем допустить, чтобы радикальная прозрачность была навязана вам регулированием или давлением рынка.
Этот контент предоставлен вам Scribe Security, ведущим поставщиком комплексных решений для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающим современную безопасность артефактов кода, а также процессов разработки и доставки кода по всей цепочке поставок программного обеспечения. Подробнее.
Статьи по теме
