В современных условиях разработка программного обеспечения всё чаще осуществляется в сжатые сроки и в рамках распределённых команд. При этом требования к безопасности программных продуктов постоянно возрастают, особенно в организациях, где программное обеспечение применяется в корпоративной или промышленной инфраструктуре. Ошибки в исходном коде, небезопасная обработка пользовательского ввода, некорректная работа с памятью, недостаточная проверка прав доступа и использование небезопасных функций могут привести к возникновению уязвимостей, влияющих на конфиденциальность, целостность и доступность информационных систем.
Одним из распространённых инструментов контроля безопасности программного обеспечения является статический анализ кода, или SAST. Данный подход предполагает исследование исходного кода, байт-кода или иных статических представлений программы без её непосредственного выполнения. SAST-инструменты позволяют выявлять потенциальные дефекты безопасности на ранних этапах жизненного цикла разработки, до передачи программного обеспечения в промышленную эксплуатацию. Это делает статический анализ важным элементом процессов безопасной разработки и DevSecOps.
Однако внедрение SAST в крупных организациях сопровождается рядом практических проблем. Во-первых, результаты анализа часто содержат большое количество срабатываний, часть из которых не является реальными уязвимостями. Во-вторых, разработчикам и специалистам по информационной безопасности требуется значительное время для интерпретации отчётов, проверки контекста и определения приоритета устранения. В-третьих, разные инструменты могут использовать различные форматы отчётов, классификации и уровни критичности, что затрудняет их объединение в единый процесс управления уязвимостями.
В связи с этим возрастает интерес к применению интеллектуальных методов обработки результатов анализа кода. Одним из перспективных направлений является использование больших языковых моделей, способных обрабатывать текстовые описания, фрагменты кода, сообщения анализаторов и формировать пояснения на естественном языке. При этом в корпоративной разработке особое значение имеет не только функциональность модели, но и способ её размещения. Использование внешних облачных сервисов может быть ограничено требованиями по защите исходного кода, коммерческой тайны, персональных данных и иной чувствительной информации. Поэтому для организаций с повышенными требованиями к безопасности более предпочтительным является применение локальных LLM-моделей, развёрнутых во внутреннем контуре.
Локальная LLM-модель в данном случае рассматривается как вспомогательный инструмент, который не заменяет SAST и не отменяет экспертную проверку. Её задача состоит в предварительной обработке результатов анализа: объяснении сути срабатывания, выделении потенциально опасных случаев, группировке однотипных замечаний, формировании рекомендаций по устранению и подготовке информации для специалиста. Такой подход позволяет снизить рутинную нагрузку и повысить удобство работы с результатами SAST, сохранив контроль со стороны человека.
Основными задачами локальной LLM-модели при анализе SAST-результатов могут быть:
– пояснение сути срабатывания простым языком для разработчика;
– определение возможного влияния обнаруженного дефекта на безопасность приложения;
– сопоставление срабатывания с типовыми классами ошибок, например, CWE;
– предварительная оценка вероятности ложноположительного результата;
– группировка повторяющихся срабатываний по файлам, модулям, типам ошибок и причинам возникновения;
– формирование рекомендации по устранению уязвимости;
– подготовка краткого резюме для специалиста по информационной безопасности;
– выделение срабатываний, требующих ручной проверки в первую очередь.
На практике процесс применения локальной LLM-модели может быть организован следующим образом. Сначала SAST-инструмент выполняет анализ исходного кода и формирует отчёт. Далее результаты приводятся к единому структурированному формату, например, JSON или SARIF. После этого из отчёта выделяются необходимые поля: идентификатор правила, уровень критичности, путь к файлу, строка кода, описание проблемы, фрагмент исходного кода и дополнительные сведения анализатора. На следующем этапе данные передаются в локальную LLM-модель, которая формирует предварительное заключение.
Важным требованием является ограничение объёма и состава данных, передаваемых модели. Даже при локальном размещении нецелесообразно передавать весь исходный код проекта, если для анализа конкретного срабатывания достаточно небольшого фрагмента. Перед отправкой данных в модель желательно выполнять предварительную фильтрацию: удаление секретов, токенов, паролей, внутренних адресов, персональных данных и иной информации, не требующейся для анализа. Такой подход снижает риски случайного раскрытия чувствительных сведений и упрощает контроль работы системы.
Типовая схема обработки одного SAST-срабатывания может включать несколько этапов. На первом этапе система получает техническое описание проблемы от анализатора. На втором этапе формируется запрос к LLM-модели по заранее заданному шаблону. В запросе указываются роль модели, формат ответа и ограничения. Например, модели можно запретить делать окончательный вывод об отсутствии уязвимости и обязать указывать уровень уверенности. На третьем этапе модель формирует ответ в структурированном виде. На четвёртом этапе результат сохраняется в системе управления уязвимостями или передаётся специалисту для проверки.
Пример полей, которые может формировать локальная LLM-модель:
– краткое описание проблемы;
– возможный класс уязвимости;
– предполагаемая причина возникновения;
– потенциальное влияние на безопасность;
– оценка необходимости ручной проверки;
– рекомендация по исправлению;
– уровень уверенности модели;
– признаки возможного ложноположительного срабатывания.
Особое значение имеет формат ответа модели. Если результат формируется в свободной текстовой форме, его сложнее автоматически обрабатывать и сравнивать с другими данными. Поэтому для корпоративного применения целесообразно использовать структурированный формат: JSON, таблицу или заранее определённую карточку с фиксированными полями. Это позволяет интегрировать модель в существующие процессы DevSecOps, системы отслеживания задач, средства управления уязвимостями и отчётности.
При этом важно понимать, что LLM-модель не является источником истины. Она может ошибаться, неправильно интерпретировать код, переоценивать или недооценивать критичность проблемы, а также формировать убедительные, но некорректные объяснения. Поэтому результаты работы модели должны использоваться только как предварительная аналитическая информация. Окончательное решение о наличии уязвимости, её критичности и способе устранения должно приниматься специалистом по информационной безопасности или ответственным разработчиком.
Преимущества применения локальных LLM-моделей в процессе анализа SAST-результатов можно рассматривать по нескольким направлениям. Во-первых, повышается читаемость отчётов. Стандартные сообщения анализаторов часто бывают краткими и технически сложными, особенно для разработчиков, не имеющих глубокого опыта в информационной безопасности. LLM-модель может преобразовать такое сообщение в понятное объяснение с указанием причины и возможного способа исправления.
Во-вторых, снижается нагрузка на специалистов. В крупных проектах количество SAST-срабатываний может быть значительным, и ручная первичная сортировка занимает много времени. Модель может помочь отобрать наиболее подозрительные случаи, сгруппировать похожие проблемы и подготовить краткую сводку. Это не отменяет проверки, но позволяет специалисту быстрее перейти к наиболее важным вопросам.
В-третьих, повышается единообразие обработки результатов. Разные специалисты могут по-разному описывать одни и те же проблемы. Использование единого шаблона анализа позволяет формировать более стандартизированные заключения, что особенно важно для отчётности, аудита и накопления базы знаний.
В-четвёртых, появляется возможность формирования обучающих материалов для разработчиков. На основе типовых SAST-срабатываний и пояснений модели можно создавать внутренние рекомендации по безопасному программированию. Это позволяет использовать результаты анализа не только для устранения конкретных дефектов, но и для повышения зрелости процесса разработки.
Вместе с тем применение LLM-моделей в корпоративной разработке связано с рядом рисков и ограничений. Одним из основных рисков является недостоверность ответа модели. Даже при корректном запросе модель может сформировать ошибочный вывод. Например, она может посчитать реальную уязвимость ложноположительным срабатыванием либо предложить исправление, которое нарушит бизнес-логику приложения. Поэтому автоматическое закрытие SAST-срабатываний на основании ответа LLM недопустимо без дополнительной проверки.
Другим важным риском является возможность утечки чувствительной информации. Если модель развёрнута локально, риск передачи данных во внешние сервисы снижается, однако сохраняются риски, связанные с логированием запросов, хранением истории, резервным копированием и доступом администраторов к данным. Поэтому при внедрении необходимо определить правила хранения запросов и ответов, настроить разграничение доступа и исключить попадание секретов в контекст модели.
Отдельного внимания заслуживает риск prompt injection. В исходном коде или комментариях могут содержаться фрагменты текста, которые при передаче в LLM-модель будут интерпретированы как инструкции. Например, комментарий в коде может содержать указание проигнорировать предыдущие правила или скрыть проблему. Чтобы снизить этот риск, необходимо явно отделять анализируемые данные от управляющих инструкций, использовать жёсткие шаблоны запросов и проверять ответы модели на соответствие ожидаемому формату.
Для безопасного внедрения локальной LLM-модели в процесс анализа SAST можно выделить несколько организационных и технических мер:
– размещение модели во внутреннем контуре организации;
– запрет передачи исходного кода и SAST-отчётов во внешние сервисы без отдельного разрешения;
– предварительная очистка данных от секретов и чувствительной информации;
– ограничение объёма передаваемого фрагмента кода;
– использование фиксированных шаблонов запросов;
– формирование ответа в структурированном формате;
– обязательная ручная проверка выводов модели;
– ведение журнала решений и обратной связи;
– регулярная оценка качества ответов модели;
– запрет автоматического закрытия срабатываний без подтверждения специалиста.
Для оценки эффективности такого подхода необходимо использовать измеримые показатели. В качестве метрик могут применяться среднее время первичного разбора одного SAST-срабатывания, доля срабатываний, для которых модель сформировала полезное пояснение, точность предварительной классификации, доля ошибочных рекомендаций, количество случаев неверного определения ложноположительного результата, а также уровень удовлетворённости разработчиков и специалистов по безопасности. Дополнительно можно оценивать, насколько часто рекомендации модели принимаются после экспертной проверки.
Оценку качества целесообразно проводить на заранее подготовленной выборке SAST-срабатываний, по которым уже есть экспертная разметка. Такая выборка может включать реальные уязвимости, ложноположительные результаты, низкоприоритетные замечания и сложные спорные случаи. Ответы модели сравниваются с экспертными решениями. При этом важно оценивать не только итоговую классификацию, но и качество объяснения, корректность рекомендаций и полноту указания рисков.
Внедрение локальной LLM-модели может быть особенно полезно в организациях, где уже существует процесс безопасной разработки, но специалисты сталкиваются с большим количеством результатов SAST. В таких условиях модель выступает как дополнительный аналитический слой между инструментом статического анализа и человеком. Она не заменяет правила SAST, не выполняет самостоятельное сканирование и не принимает окончательные решения, а помогает быстрее понять смысл результата и подготовить его к дальнейшей обработке.
С архитектурной точки зрения система может состоять из нескольких компонентов. Первый компонент — SAST-инструмент, выполняющий анализ кода. Второй компонент — модуль нормализации отчётов, приводящий результаты к единому формату. Третий компонент — модуль фильтрации данных, исключающий из запроса лишние или чувствительные сведения. Четвёртый компонент — локальный сервер LLM-инференса. Пятый компонент — модуль постобработки, который проверяет формат ответа и передаёт результат в систему управления задачами или уязвимостями. Шестой компонент — интерфейс эксперта, в котором специалист может подтвердить, отклонить или скорректировать вывод модели.
Такой подход позволяет постепенно внедрять LLM в существующий процесс без резкого изменения всей инфраструктуры разработки. На начальном этапе модель может использоваться только для формирования пояснений. Затем можно добавить группировку срабатываний, подготовку рекомендаций и предварительную оценку приоритета. После накопления статистики и экспертной обратной связи возможно уточнение шаблонов запросов и правил обработки результатов.
Особенно важно обеспечить воспроизводимость работы модели. Для этого необходимо фиксировать версию модели, параметры генерации, шаблон запроса и версию входных данных. Без этого будет сложно объяснить, почему по одному и тому же срабатыванию в разные моменты времени были получены разные выводы. В корпоративной среде воспроизводимость важна не только для технического анализа, но и для внутреннего контроля, аудита и расследования спорных случаев.
Следует также учитывать, что локальная LLM-модель может не обладать актуальными знаниями о новых уязвимостях, библиотеках и практиках эксплуатации. Поэтому её ответы желательно дополнять внутренней базой знаний, нормативными требованиями, правилами безопасной разработки и данными из систем управления уязвимостями. Для этого может применяться подход retrieval-augmented generation, при котором модель получает не только SAST-срабатывание, но и релевантные фрагменты внутренней базы знаний. Такой подход позволяет повысить прикладную ценность ответа, не дообучая модель на чувствительных данных.
Важным направлением развития является связь между SAST, SCA, SBOM и системами управления уязвимостями. SAST показывает потенциальные дефекты в коде, SCA позволяет анализировать сторонние зависимости, а SBOM описывает состав программного продукта. Локальная LLM-модель может использоваться как средство объяснения и связывания этих данных, например, для подготовки краткой карточки риска: какой компонент затронут, где расположен проблемный код, какие зависимости используются, есть ли связь с известными классами уязвимостей и какие действия рекомендуется выполнить.
Таким образом, применение локальных LLM-моделей для предварительного анализа результатов SAST является перспективным направлением развития процессов безопасной разработки. Наибольшую ценность такой подход имеет не в автоматической замене эксперта, а в снижении рутинной нагрузки, повышении читаемости отчётов, ускорении первичной сортировки и улучшении коммуникации между разработчиками и специалистами по информационной безопасности. При этом ключевыми условиями успешного внедрения являются локальное размещение модели, защита исходного кода, контроль качества ответов, структурированный формат вывода и обязательная экспертная проверка.
Внедрение LLM в контур анализа безопасности должно рассматриваться как постепенный и контролируемый процесс. На первом этапе целесообразно использовать модель только для пояснения SAST-срабатываний и формирования черновых рекомендаций. На следующих этапах возможно расширение функций за счёт группировки результатов, приоритизации и интеграции с внутренней базой знаний. Такой подход позволяет повысить эффективность DevSecOps-процессов и одновременно сохранить требуемый уровень контроля над решениями, связанными с безопасностью программного обеспечения.
Литература:
- OWASP. Source Code Analysis Tools. — Текст: электронный // OWASP Foundation: [сайт]. — URL: https://owasp.org/www-community/Source_Code_Analysis_Tools (дата обращения: 28.06.2026).
- OWASP. Static Code Analysis. — Текст: электронный // OWASP Foundation: [сайт]. — URL: https://owasp.org/www-community/controls/Static_Code_Analysis (дата обращения: 28.06.2026).
- 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).
- ГОСТ Р 56939–2024. Защита информации. Разработка безопасного программного обеспечения. Общие требования. — М.: Российский институт стандартизации, 2024.
- NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). — 2023. — URL: https://www.nist.gov/itl/ai-risk-management-framework (дата обращения: 28.06.2026).
- OWASP. Top 10 for Large Language Model Applications. — Текст: электронный // OWASP Foundation: [сайт]. — URL: https://owasp.org/www-project-top-10-for-large-language-model-applications/ (дата обращения: 28.06.2026).
- ФСТЭК России. Информационное сообщение от 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).
- Банк данных угроз безопасности информации ФСТЭК России. — Текст: электронный // БДУ ФСТЭК России: [сайт]. — URL: https://bdu.fstec.ru/ (дата обращения: 28.06.2026).
- MITRE. Common Weakness Enumeration. — Текст: электронный // MITRE: [сайт]. — URL: https://cwe.mitre.org/ (дата обращения: 28.06.2026).
- FIRST. Common Vulnerability Scoring System Version 4.0: Specification Document. — Текст: электронный // FIRST: [сайт]. — URL: https://www.first.org/cvss/specification-document (дата обращения: 28.06.2026).
