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

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

SAST-инструменты применяются для поиска небезопасных функций, ошибок обработки пользовательского ввода, потенциальных SQL-инъекций, межсайтового скриптинга, ошибок управления памятью, некорректной работы с правами доступа, небезопасной криптографии, утечек чувствительной информации и иных дефектов. В рамках процессов безопасной разработки SAST часто встраивается в конвейер CI/CD, систему контроля версий или процесс проверки изменений перед включением кода в основную ветку проекта.

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

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

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

Причины возникновения ложноположительных срабатываний можно разделить на несколько групп:

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

– отсутствие информации о внутренней архитектуре приложения;

– некорректная настройка правил анализа;

– использование универсальных правил без адаптации под проект;

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

– нестандартные механизмы валидации и фильтрации пользовательского ввода;

– использование внутренних библиотек и фреймворков, неизвестных анализатору;

– неполная поддержка языка программирования или используемых технологий;

– сложная структура проекта и большое количество зависимостей;

– отсутствие регулярной актуализации профилей анализа.

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

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

Методику снижения ложноположительных срабатываний SAST в промышленных программных системах можно представить в виде последовательности этапов:

– инвентаризация анализируемых проектов и используемых технологий;

– первичная настройка профиля SAST;

– классификация выявленных срабатываний;

– экспертная верификация результатов;

– формирование базы ложноположительных срабатываний;

– настройка исключений и уточнение правил;

– повторный анализ и оценка эффективности;

– регулярная актуализация правил и профилей анализа.

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

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

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

Профиль анализа должен формироваться с учётом следующих факторов:

– используемый язык программирования;

– тип программной системы;

– критичность обрабатываемых данных;

– наличие сетевых интерфейсов;

– особенности взаимодействия с базами данных;

– применение криптографических механизмов;

– требования внутренних стандартов безопасной разработки;

– результаты предыдущих проверок;

– накопленная статистика ложноположительных срабатываний.

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

– подтверждённая уязвимость;

– ложноположительное срабатывание;

– требует дополнительной проверки;

– принято как технический риск;

– дублирующее срабатывание;

– нерелевантно для данного проекта;

– устранено;

– исключено по утверждённому правилу.

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

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

При экспертной проверке целесообразно учитывать следующие вопросы:

– поступают ли данные из недоверенного источника;

– выполняется ли проверка или фильтрация входных данных;

– возможно ли достижение уязвимого участка кода в реальном сценарии;

– есть ли внешние интерфейсы, через которые может быть передан опасный ввод;

– существуют ли дополнительные защитные механизмы;

– затрагивает ли срабатывание критичный компонент системы;

– может ли эксплуатация дефекта повлиять на доступность, целостность или конфиденциальность данных;

– является ли проблема повторяющейся для нескольких модулей.

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

База ложноположительных срабатываний может включать следующие поля:

– идентификатор срабатывания;

– идентификатор правила SAST;

– проект или модуль;

– файл и строка кода;

– краткое описание проблемы;

– статус проверки;

– причина признания ложноположительным;

– дата принятия решения;

– ответственный специалист;

– ссылка на задачу или обсуждение;

– срок пересмотра исключения.

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

На шестом этапе выполняется настройка исключений и уточнение правил анализа. Исключения могут задаваться на разных уровнях: для конкретной строки кода, файла, директории, правила, проекта или типа срабатывания. Наиболее безопасным считается точечное исключение с обязательным указанием причины. Массовое отключение правил следует применять осторожно, поскольку оно может привести к пропуску реальных уязвимостей.

Существуют следующие подходы к настройке исключений:

– исключение конкретного подтверждённого ложноположительного срабатывания;

– исключение автоматически сгенерированного кода;

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

– исключение устаревших модулей при наличии отдельного плана переработки;

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

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

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

– отключение нерелевантных правил для конкретного типа проекта.

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

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

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

Для оценки эффективности методики можно использовать следующие показатели:

– общее количество SAST-срабатываний до и после настройки;

– доля ложноположительных срабатываний;

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

– среднее время экспертной проверки одного срабатывания;

– количество повторяющихся ложных сообщений;

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

– количество отключённых правил;

– количество точечных исключений;

– число случаев повторного появления ранее исключённых проблем;

– уровень доверия разработчиков к результатам анализа.

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

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

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

Отдельно следует выделить работу с дублирующими срабатываниями. В крупных проектах один и тот же дефект может проявляться в нескольких местах или порождать несколько сообщений от анализатора. Например, одна небезопасная функция может использоваться в разных модулях, а один поток данных может быть отмечен несколькими правилами. Для снижения нагрузки необходимо группировать такие срабатывания по общей причине, а не рассматривать каждое сообщение изолированно. Это позволяет устранять первопричину проблемы, а не отдельные её проявления.

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

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

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

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

Практическое внедрение методики целесообразно выполнять поэтапно. На первом этапе проводится пилотный анализ одного или нескольких проектов. Цель пилота — определить типовые источники ложноположительных срабатываний и оценить исходное качество отчётов. На втором этапе формируется базовый профиль анализа и правила классификации. На третьем этапе создаётся реестр ложноположительных срабатываний и настраиваются точечные исключения. На четвёртом этапе методика масштабируется на другие проекты. На пятом этапе вводится регулярный контроль метрик и пересмотр правил.

Примерный порядок внедрения может выглядеть следующим образом:

– выбрать пилотный проект;

– выполнить первичный SAST-анализ без дополнительных исключений;

– выделить наиболее часто повторяющиеся типы срабатываний;

– провести экспертную проверку выборки результатов;

– определить долю ложноположительных срабатываний;

– настроить профиль анализа;

– сформировать базу исключений;

– повторить анализ;

– сравнить показатели до и после настройки;

– закрепить методику во внутреннем регламенте.

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

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

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

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

Литература:

1. OWASP. Source Code Analysis Tools. — Текст: электронный // OWASP Foundation: [сайт]. — URL: https://owasp.org/www-community/Source_Code_Analysis_Tools (дата обращения: 28.06.2026).
2. OWASP. Static Code Analysis. — Текст: электронный // OWASP Foundation: [сайт]. — URL: https://owasp.org/www-community/controls/Static_Code_Analysis (дата обращения: 28.06.2026).
3. Souppaya M., Scarfone K., Dodson D. Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST Special Publication 800–218. — 2022. — URL: https://csrc.nist.gov/pubs/sp/800/218/final (дата обращения: 28.06.2026).
4. ГОСТ Р 56939–2024. Защита информации. Разработка безопасного программного обеспечения. Общие требования. — М.: Российский институт стандартизации, 2024.
5. ФСТЭК России. Информационное сообщение от 28 мая 2026 г. № 240/24/3693 о методике выявления уязвимостей и недекларированных возможностей в программном обеспечении. — Текст: электронный // ФСТЭК России: [сайт]. — URL: https://fstec.ru/dokumenty/vse-dokumenty/informatsionnye-i-analiticheskie-materialy/informatsionnoe-soobshchenie-fstek-rossii-ot-28-maya-2026-g-n-240–24–3693 (дата обращения: 28.06.2026).
6. MITRE. Common Weakness Enumeration. — Текст: электронный // MITRE: [сайт]. — URL: https://cwe.mitre.org/ (дата обращения: 28.06.2026).
7. FIRST. Common Vulnerability Scoring System Version 4.0: Specification Document. — Текст: электронный // FIRST: [сайт]. — URL: https://www.first.org/cvss/specification-document (дата обращения: 28.06.2026).
8. Chess B., McGraw G. Static Analysis for Security // IEEE Security & Privacy. — 2004. — Vol. 2, № 6. — P. 76–79.
9. Johnson B., Song Y., Murphy-Hill E., Bowdidge R. Why Don’t Software Developers Use Static Analysis Tools to Find Bugs? // Proceedings of the 35th International Conference on Software Engineering. — 2013. — P. 672–681.
10. Bessey A., Block K., Chelf B., Chou A., Fulton B., Hallem S., Henri-Gros C., Kamsky A., McPeak S., Engler D. A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World // Communications of the ACM. — 2010. — Vol. 53, № 2. — P. 66–75.