«Говорят, что технический анализ не должен содержать оценок. На практике оценка — это фундамент, на котором стоят все выводы о безопасности. Разбираемся, как она работает и почему её игнорируют.»
Откуда берутся «хорошие» и «плохие» патчи
Оценка безопасности начинается до анализа кода. Если рассматривать типичный отчёт исследователя, первым идёт технический разбор уязвимости: расположение в коде, вектор атаки, условия эксплуатации. Следом — оценка критичности: CVSS-балл, возможность RCE, масштаб потенциального ущерба. Казалось бы, всё объективно.
Но уже на этом этапе появляются неочевидные критерии. Например, эксплойт для утечки хешей сессий в веб-приложении. Технически он не даёт прямого контроля, но открывает дорогу для атак. Оценка его критичности зависит от контекста: на публичном SaaS-сервисе это катастрофа, во внутреннем инструменте для пяти сотрудников — низкий приоритет. Вывод исследователя формируется не только по коду, но и по предполагаемому окружению.
С исправлениями ситуация сложнее. Патч, закрывающий уязвимость, не всегда признают хорошим. Иногда он вводит побочные эффекты, ломает обратную совместимость или требует полного обновления инфраструктуры. Оценка «качество исправления» строится на компромиссе между безопасностью и практичностью, что уже выходит за рамки чистой техники.
[ИЗОБРАЖЕНИЕ: Схема — на входе технические факты (код, логика), на выходе рекомендация (критичность, приоритет). Между ними «фильтры»: контекст окружения, требования регуляторов, бизнес-логика, опыт команды.]
Как нормативные требования становятся точкой отсчёта
В российском сегменте требования ФСТЭК и 152-ФЗ задают жёсткий каркас для оценки. Исследователь, проверяющий систему, смотрит на неё через две линзы одновременно: техническую (есть ли дыра) и нормативную (нарушает ли это положение закона).
Допустим, в системе управления базами данных нашли уязвимость, позволяющую получить доступ к журналам аудита. С технической стороны это проблема контроля доступа. С точки зрения 152-ФЗ — прямое нарушение требований к неизменяемости и защищённости журналов учёта. Нормативный контекст резко повышает приоритет такой находки, даже если эксплойт сложен.
Требования регуляторов меняют и подход к исправлениям. Технически достаточно закрыть дыру патчем. Но если система должна соответствовать, например, требованиям по криптографической защите, исследователь обязан оценить, не нарушает ли исправление эти требования. Иногда «правильное» с точки зрения закона решение технически менее оптимально, но его всё равно придётся рекомендовать.
Кто решает, что важно, а что — шум
Фильтрация сигналов от шума — самая субъективная часть работы. Два исследователя на одном проекте могут дать разные списки приоритетов. Разница возникает не из-за квалификации, а из-за внутренних рамок оценки.
На решение влияют факторы, которые редко декларируют явно:
- Опыт инцидентов в похожих системах. Если исследователь видел, как через схожую уязвимость слили данные, он будет настаивать на срочном исправлении.
- Знакомство с кодом и архитектурой. Неочевидная связь между модулями может превратить мелкую уязвимость в критическую.
- Ожидания заказчика или продукт-менеджера. Иногда бизнес готов мириться с определёнными рисками ради скорости разработки, и это приходится учитывать.
Именно здесь оценка становится ключевым инструментом. Без неё отчёт превращается в перечень проблем без контекста, бесполезный для принятия решений.
Роль в расследовании инцидентов
Когда инцидент уже произошёл, работа идёт в обратном порядке. Сначала есть факт: утечка данных, остановка сервиса, несанкционированный доступ. Задача — восстановить цепочку и понять, какая уязвимость стала причиной.
На этом этапе нормативная оценка определяет фокус расследования. Если скомпрометированы персональные данные, основное внимание уделяют журналам доступа, системам аутентификации, местам хранения — тем зонам, где требования 152-ФЗ наиболее жёсткие. Расследование инцидента с промышленной системой будет сконцентрировано на соблюдении профильных стандартов и регламентов.
Итоговый отчёт об инциденте всегда содержит раздел «Рекомендации». Это уже не технический анализ, а чистая оценка: какие меры принять, чтобы подобное не повторилось, и какие из них являются обязательными по закону.
Кому и зачем это знать
Понимание роли нормативных суждений полезно не только исследователям.
Разработчики, получающие отчёты, видят не просто список багов, а расставленные приоритеты. Зная, что стоит за оценкой «критичный», проще аргументировать сроки на исправление перед менеджментом.
Руководители проектов и заказчики начинают различать технический риск и нормативный. Уязвимость может быть технически незначительной, но создавать серьёзные проблемы с compliance. Без этого понимания решения о распределении ресурсов принимаются вслепую.
Для самих исследователей осознанный подход к оценкам — это способ повысить ценность своей работы. Отчёт, в котором каждая находка объяснена с точки зрения и техники, и регуляторики, становится документом для принятия решений, а не просто техническим заданием на исправление.
Что дальше
Субъективная оценка не исчезнет из security research. Законы и стандарты усложняются, появляются новые требования. Искусственный интеллект и автоматизированные сканеры могут находить потенциальные уязвимости, но интерпретировать их в контексте конкретной системы и её нормативных рамок пока способен только человек.
Вместо того чтобы пытаться исключить оценочные суждения, эффективнее сделать их процесс прозрачным. Чётко отделять в отчёте технические факты от их интерпретации, указывать, какие нормативные требования влияют на приоритет, документировать допущения о контексте системы.
Итог — не «объективный» отчёт, а честный. В котором видно, где заканчиваются данные и начинается профессиональное суждение, основанное на опыте, знании закона и понимании рисков.