Посты
Продолжаем серию постов про инструментарий AppSec-инженера. А то последний пост про MAST…
23 декабря 2025 г. в 20:08•Max Knyazev is typing…Зеркало Telegram
Продолжаем серию постов про инструментарий 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
Открыть исходный пост в TelegramЧто такое 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