Последнее время я здесь много писал про атаки на цепочку поставок (https://t.me/maxienerg…

Последнее время я здесь много писал про атаки на цепочку поставок (https://t.me/maxienergy_channel/386). И чем больше я разбираю такие кейсы, тем сильнее ощущение, что одной только проверки состава зависимостей нам уже начинает не хватать (и у вас такая мысль должна была родиться сама после моих последних трех постов)

Потому что знать, из чего состоит приложение, это, конечно, важно. Но сейчас этого уже недостаточно 🤌

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

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

Поэтому поговорим CBOM (Capability Bill of Materials). Это совсем новая концепция, которой реально занялись только осенью прошлого года. Насколько мне известно, она впервые упоминается в работе (https://dl.acm.org/doi/10.1145/3719027.3765136) двух исследователей из Швеции. По сути это попытка описать не только состав приложения, но и допустимые возможности его компонентов. То есть и сам список зависимостей, и то, что им вообще можно делать

Значительная часть современных атак на цепочку поставок происходит не через CVE в выводе Trivy, а через фактическое поведение зависимости. Вредоносный postinstall, неожиданный сетевой вызов, чтение секретов из окружения, попытка сходить в файловую систему и тд

А концепция CBOM предлагает смотреть на зависимости не как на обычные кубики в конструкторе, из которого ПО состоит, а как на сущности с конкретными привилегиями. Грубо говоря, если библиотека нужна только чтобы отправлять HTTP-запросы, то не должна она читать ключи, лазить по энвам или делать еще что-то, о чем ее никто не просил 🙂

Это хорошо стыкуется и с тем, о чем я уже писал в последних постах. Вспомните кейс с axios (https://t.me/maxienergy_channel/387), где проблема прилетела транзитивно через лишнюю зависимость и вредоносный скрипт на этапе установки. А кейс с Trivy (https://t.me/maxienergy_channel/388), где удар пришелся уже по инфраструктуре сборки и доставки?

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

Поэтому сегодня я и выступаю на Merge Conf (https://tatarstan2026.mergeconf.ru/speakers/development/cyber-security/knyazev) в Иннополисе именно с темой CBOM. Хочу донести до большого количества людей, что это за концепция, почему SBOM уже недостаточно, как важно думать про контроль зависимостей и почему вся эта концепция закономерно станет следующим шагом для AppSec и DevSecOps 💯

Если будете сегодня на Merge — залетайте в аудиторию 106. Обсудим то, как перестать смотреть на зависимости только как на список с уязвимостями и начать воспринимать их более объективно

#информационная_безопасность