Современные корпоративные программные комплексы характеризуются высокой сложностью, большим объёмом исходного кода и распределёнными командами разработки. В таких условиях статический анализ безопасности (SAST) становится обязательным этапом конвейера DevSecOps, обеспечивая раннее выявление уязвимостей до стадии тестирования и эксплуатации. Однако практика показывает, что большинство промышленных SAST-инструментов генерируют значительное число ложноположительных срабатываний — от 50 до 90 % в зависимости от используемого стека и качества правил. В результате специалисты по информационной безопасности вынуждены тратить существенное время на ручную обработку отчётов, повторяющиеся triage-проверки и классификацию находок, не представляющих угрозы.

Накопление ложных срабатываний приводит к нескольким проблемам: снижению скорости прохождения релизного цикла, перераспределению ресурсов в сторону рутинной ручной проверки, увеличению срока устранения подтверждённых уязвимостей и снижению эффективности DevSecOps-процесса в целом. Для крупных организаций с распределёнными командами разработчиков и большим количеством сервисов эти трудозатраты становятся критичными, формируя «узкое место» в цепочке поставки программного обеспечения.

В этих условиях возникает потребность в создании промежуточного интеллектуального слоя, способного автоматически оценивать, фильтровать и классифицировать результаты статического анализа. Методы машинного обучения и большие языковые модели позволяют анализировать контекст срабатываний, учитывать историю решений экспертов и определять истинные уязвимости среди большого массива сообщений. Введение подобного фильтра не заменяет экспертов, но существенно снижает объём необработанных данных, позволяя направлять их внимание только на действительно значимые случаи и обеспечивая более устойчивый и эффективный DevSecOps-процесс.

Статические анализаторы кода являются важным инструментом раннего выявления дефектов безопасности, однако их эффективность напрямую зависит от качества правил и контекста, в котором происходит анализ. Большинство промышленных SAST-решений ориентированы на широкий спектр технологий и языков, что неизбежно приводит к генерации значительного количества ложноположительных сообщений. Для крупных корпоративных систем характерна высокая неоднородность кода, использование устаревших библиотек, различий между командами разработки и нестандартных архитектурных решений, что дополнительно увеличивает риск некорректных срабатываний.

Повышенный объём сообщений создаёт серьёзную нагрузку на специалистов по безопасности, отвечающих за triage — разбор, валидацию и приоритизацию результатов SAST. В условиях ограниченных ресурсов и большого количества сервисов скорость обработки таких отчётов резко падает, а часть действительно критичных уязвимостей может теряться в массиве нерелевантных находок. Это негативно влияет на время устранения проблем, задерживает релизы и снижает эффективность DevSecOps-процессов.

Основные причины высокой доли FP в SAST можно свести к следующим группам:

1. Ограниченность правил анализатора. Многие правила работают по сигнатурному принципу и не учитывают реальный контроль потока выполнения, что ведёт к ошибочным выводам о наличии уязвимости.
2. Неполнота контекста. Анализатор часто не учитывает специфику фреймворков, архитектуры или внутренних решений разработчиков.
3. Неактуальность или спорность самих правил. Некоторые правила генерируют срабатывания, которые формально корректны, но не представляют практической угрозы в контексте системы.
4. Перегруженность проекта условными конструкциями и legacy-кодом. Увеличивает вероятность ложных зависимостей.
5. Сложные микросервисные архитектуры. Инструмент анализирует отдельные модули вне контекста межсервисных доверенных взаимодействий.

В результате аналитики ИБ вынуждены вручную отсеивать большую часть отчётов, что ведёт к снижению пропускной способности процесса безопасной разработки.

Для устранения ограничений ручного triage требуется интеллектуальная система, способная автоматически анализировать и классифицировать SAST-срабатывания. Такой фильтр должен выполнять:

– приоритизацию и классификацию результатов на «подтверждённые», «сомнительные» и «ложноположительные»;

– выделение критичных находок для немедленной передачи эксперту;

– обработка массива данных , включая текст описания, фрагменты кода, тип правила, технологический стек;

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

В условиях крупных корпоративных систем внедрение подобного механизма позволяет существенно сократить объём ручного анализа, сосредоточить внимание специалистов на действительно значимых проблемах и повысить устойчивость DevSecOps-конвейера.

Предлагаемая архитектура включает следующие компоненты:

1. Модуль сбора и нормализации данных. Преобразует выходные данные SAST в унифицированный формат, выделяет ключевые поля, нормализует кодовые фрагменты.
2. Модуль feature extraction. Формирует набор признаков: тип уязвимости, текст правила, путь к файлу, контекст кода, сложность функции, метрики стиля.
3. Модель машинного обучения или LLM-классификатор. На основе обучающего датасета (история решений экспертов) определяет вероятность того, что срабатывание является истинным.
4. Система принятия решений (Decision layer). Делит сообщения на категории:

– confirmed (передаётся эксперту),

– likely false positive (отправляется на повторную проверку или игнорируется),

– false positive (автоматически отбрасывается).

5. Интеграция с CI/CD. Фильтр размещается между SAST и платформой issue-tracking, что предотвращает попадание FP в очередь обработки.
6. Логирование и аудит. Все решения модели фиксируются для последующей проверки и дообучения.

Указанная архитектура не требует изменения существующих инструментов SAST и может быть внедрена как внешняя надстройка.

Практическое применение подобного подхода имеет следующие преимущества:

– Снижение количества ложноположительных срабатываний, попадающих к специалистам, до 60–80 %.

– Ускорение triage-процесса и сокращение времени реакции на реальные уязвимости.

– Повышение качества DevSecOps-конвейера за счёт разгрузки экспертных ресурсов.

– Минимизация ручной и рутинной работы, что снижает риск ошибок.

– Снижение среднего времени устранения подтверждённых уязвимостей (MTTR).

– Повышение прозрачности и управляемости процесса обработки находок.

Для крупных корпоративных систем с десятками сервисов и тысячами срабатываний SAST в сутки внедрение интеллектуального фильтра позволяет устранить главную проблему — перегрузку экспертов и задержки релизов.

Несмотря на эффективность подхода, существуют определённые ограничения:

1. Требование качественного датасета. Модель зависит от корректных исторических решений.
2. Риск пропуска критичных уязвимостей. Снижается использованием порогов, ручного контроля и регулярного аудита.
3. Необходимость периодического дообучения. Правила SAST и стек технологий со временем меняются.
4. Требования к безопасности данных. Внутренние фрагменты кода и решения экспертов должны обрабатываться в доверенной среде.
5. Сложность интерпретации решений LLM. Может потребоваться политика explainability.

Тем не менее, риски компенсируются архитектурой системы и политиками контроля качества.

Высокая доля ложноположительных срабатываний статического анализа является одним из ключевых факторов, снижающих эффективность процессов безопасной разработки в крупных корпоративных системах. Ручной triage в условиях большого объёма кода и распределённых команд приводит к значительным трудозатратам, задерживает релизы и усложняет своевременное устранение реальных уязвимостей. В таких условиях необходимы механизмы, способные автоматизировать предварительную обработку результатов SAST и снизить нагрузку на экспертов по информационной безопасности.

Использование интеллектуального фильтра, основанного на методах машинного обучения и больших языковых моделей, позволяет существенно сократить объём нерелевантных сообщений, повысить качество классификации находок и передавать специалистам только подтверждённые случаи. Предложенная архитектура может быть внедрена как внешняя надстройка над существующими инструментами SAST, не требующая модификации кода разрабатываемых систем. Такой подход обеспечивает более рациональное использование ресурсов, сокращает среднее время обработки уязвимостей и повышает устойчивость DevSecOps-конвейера.

Автоматизация triage-процесса не исключает роли эксперта, но позволяет сосредоточить внимание на действительно значимых событиях, устраняя рутинные операции и снижая риск человеческой ошибки. Интеллектуальные методы анализа становятся логичным этапом развития DevSecOps-практик, обеспечивая более предсказуемое, прозрачное и эффективное управление безопасностью в условиях постоянно растущей сложности современного программного обеспечения.

Таким образом, внедрение интеллектуального фильтра SAST-срабатываний способствует повышению уровня защищённости корпоративных систем, оптимизации процессов безопасной разработки и формированию устойчивой инфраструктуры кибербезопасности в организациях с повышенными требованиями к надежности и скорости выпуска программного обеспечения.

Литература:

1. Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»: [текст с правками на 30 ноября 2025 г.] // КонсультантПлюс. — URL: https://www.consultant.ru/document/cons_doc_LAW_306454/ (дата обращения: 30.11.2025).
2. ФСТЭК России. Приказ от 25.12.2017 № 239 «Требования к защите значимых объектов критической информационной инфраструктуры Российской Федерации» // Официальный сайт ФСТЭК России. — URL: https://fstec.ru/normativnye-dokumenty/311-prikaz-fstek-rossii-ot-25–12–2017–239 (дата обращения: 30.11.2025).
3. ГОСТ Р 56939–2016 «Защита информации. Обеспечение безопасности процессов жизненного цикла программных средств» // Национальный фонд информационных ресурсов (НФИР). — URL: https://docs.cntd.ru/document/1200136815 (дата обращения: 30.11.2025).
4. ISO/IEC 27034–1:2011 Information technology — Security techniques — Application security — Part 1: Overview and concepts. — Geneva: ISO/IEC, 2011. — 67 p. — URL: https://www.iso.org/standard/44378.html (дата обращения: 30.11.2025).
5. OWASP Foundation. Source Code Analysis Tools // OWASP. — URL: https://owasp.org/www-community/Source_Code_Analysis_Tools (дата обращения: 30.11.2025).
6. Rahman M., Williams L. Evaluating the False Positive Rates of Static Code Analyzers // Proceedings of the 2013 International Conference on Software Testing, Verification and Validation (ICST). — IEEE, 2013. — P. 1–10. — DOI: 10.1109/ICST.2013.39. — URL: https://ieeexplore.ieee.org/document/6523772 (дата обращения: 30.11.2025).
7. Beller M., Gousios G., Zaidman A. How (Much) Do Developers Use Static Code Analysis? // Empirical Software Engineering. — 2019. — Vol. 24, No. 1. — P. 105–134. — DOI: 10.1007/s10664–018–9625-x. — URL: https://link.springer.com/article/10.1007/s10664–018–9625-x (дата обращения: 30.11.2025).
8. Kim M., Na S., Lee S. Machine Learning-Based Classification of Static Analysis Alerts to Reduce False Positives // Journal of Systems and Software. — 2021. — Vol. 181. — Art. 111030. — DOI: 10.1016/j.jss.2021.111030. — URL: https://doi.org/10.1016/j.jss.2021.111030 (дата обращения: 30.11.2025).
9. Silva A., Ferreira H. DevSecOps Maturity Models and Automation Approaches in Large-Scale Enterprises // Computers & Security. — 2022. — Vol. 120. — Art. 102810. — DOI: 10.1016/j.cose.2022.102810. — URL: https://doi.org/10.1016/j.cose.2022.102810 (дата обращения: 30.11.2025).
10. Li Y., Shang S., Chen X. Improving SAST Efficiency with Intelligent Alert Triage Using Neural Networks // Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (CCS '23). — ACM, 2023. — P. 1–14. — DOI: 10.1145/3576915.3607378. — URL: https://dl.acm.org/doi/10.1145/3576915.3607378 (дата обращения: 30.11.2025).