Доброго времени суток! Одно из направлений кибербезопасности, которое меня давно интересует, — DevSecOps. Идея «безопасность как часть процесса разработки, а не финальный аудит перед релизом» кажется мне правильной: уязвимость дешевле найти до того, как код ушёл в прод. Но на практике всё упирается в инструменты. Композиционный анализ (SCA) — проверка сторонних компонентов на известные уязвимости — в коммерческих решениях стоит сотни тысяч рублей, требует подписки и, что важнее, отправляет ваш SBOM на чужой сервер. Для проектов, где код нельзя выносить за периметр, это стоп-фактор. Я написал свою замену. Она сократила время анализа примерно на 90% по сравнению с ручной сверкой, которую я делал раньше. Что она делает На первом этапе инструмент синхронизирует локальные копии баз: · БДУ ФСТЭК — российская база, основная для заказчика; · NVD — национальная база уязвимостей США; · CPE — словарь продуктов NIST для сопоставления версий; · CVSS — метрики критичности; · японская база (JVN); · база OSV/GHSA. Дальше — всё конфиденциально, без интернета. Загружаете тестируемое ПО, идёт сверка с локальными базами, результат обрабатывает локальная модель ИИ и готовит протокол: найденные уязвимости, полное описание, рекомендации по исправлению. Почему это интересно · Без подписки. Базы открытые, обновление — по расписанию. · Без выноса данных. Всё считается на вашей машине или в вашем контуре. · Протокол, а не сырой JSON. На выходе — документ, который можно отдать разработчику или приложить к отчёту. Что дальше Сейчас в разработке: · статический анализатор кода; · анализатор поверхности атак; · доработка инструмента фаззинг-тестирования. В следующих постах разберу, как устроена синхронизация баз, как локальная модель помогает с классификацией и почему иногда «свой велосипед» оказывается быстрее и дешевле готового. Если тема близка — расскажите в комментариях, чем пользуетесь для SCA и что в этом процессе раздражает больше всего.