Продолжаем серию постов про инструментарий AppSec-инженера. А то последний пост про MAST…

Продолжаем серию постов про инструментарий AppSec-инженера. А то последний пост про MAST был аж 3 ноября. Сегодня поговорим про SCA 🤌

Что такое SCA?

SCA — это Software Composition Analysis, анализ состава программного обеспечения. Но так как эти посты нужны для более простого объяснения всего вот этого, я бы сказал так: это проверка всего чужого кода, который вы притащили к себе в проект. А в современном приложении чужого кода обычно 80–90%. Иногда больше

Любая библиотека, npm-пакет, Maven-зависимость, pip-модуль и тд — все вот это должно быть проанализировано SCA. Инструмент смотрит, из чего реально состоит приложение, и проверяет не уязвима ли версия библиотеки, которую вы используете 🤓

Для чего используется SCA?

SCA нужен, чтобы не проснуться однажды с новостью формата «уязвимость в Log4j / OpenSSL / left-pad / insert_random_library_name_here ломает половину интернета — и да, вы тоже пострадали». Он решает сразу несколько задач. Во-первых, поиск известных уязвимостей в зависимостях (CVE, GHSA, NVD и вся эта радость). Во-вторых, контроль лицензий: MIT — окей, Apache — окей, GPL в проде — привет юристам. В-третьих, инвентаризация: вы хотя бы знаете, какие версии библиотек реально у вас используются?

Как это работает?

SCA-инструмент берет manifests и lock-файлы (package.json, package-lock.json, pom.xml, requirements.txt, go.mod и тд), иногда — бинарники и контейнеры, и строит полное дерево зависимостей 🌳

Причём не только прямых, но и транзитивных. Тех, которые тянутся хвостом, хотя вы их не добавляли (и вообще не были в курсе об их существовании). И дальше происходит корреляция версий библиотек с базами уязвимостей и лицензий. По каждой найденной уязвимости прилетает finding. Нашлась лицензия, несовместимая с моделью распространения — туда же

Отдельно стоит здесь упомянуть SBOM (Software Bill of Materials). По факту это подробный список всех компонентов, зависимостей (включая библиотеки с открытым исходным кодом) и метаданных (лицензии, версии, уязвимости), которые входят в состав софта

Как использовать SCA?

Чаще всего SCA живет в CI/CD. Каждый коммит или merge request запускает автоматическую проверку. Это самый адекватный вариант, потому что уязвимости в библиотеках появляются быстрее, чем вы успеваете писать код 👨‍💻

В более зрелых процессах SCA еще и ломает пайплайн. Если прилетела критическая уязвимость без фикса или запрещенная лицензия — релиза не будет. Больно, но эффективно. Такой подход называется Quality Gate, кстати говоря

Инструменты для реализации SCA

Опенсорс здесь чувствует себя уверенно. Из самых популярных вариантов я могу выделить OWASP Dependency-Check и Trivy

Из коммерческих решений есть Snyk. В отечественном сегменте — Solar appScreener, CodeScoring и связка SCA+SBOM в экосистемах крупных вендоров 🤑

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