Проверяем приложения, API, мобильные клиенты, конвейер сборки и ИИ-контур по методологиям OWASP — открытым, признанным индустрией и достаточно подробным, чтобы результат можно было проверить. Каждая находка воспроизводится. Каждое требование закрывается доказательством.
Заявка почти никогда не звучит как «нужен аудит по ASVS уровня L2». Она звучит так.
«Клиент прислал опросник по безопасности на восемьдесят пунктов. Половину вопросов мы не понимаем.»
Крупный заказчик проводит вас через свою процедуру проверки поставщика.
Разбираем опросник, отвечаем на то, что уже выполнено, и превращаем остальное в короткий план. Экспресс-диагностика.
«Выходим в банк. Требуют анализ уязвимостей по ОУД4, а мы не понимаем, что нам делать.»
Требование Банка России к прикладному ПО, которое банк отдаёт клиентам.
Приводим приложение в состояние, в котором проверка проходится, и собираем доказательную базу. Заключение делает лицензиат — мы готовим к нему. Аудит приложения по ASVS.
«Кода стало втрое больше, его пишет модель, и построчно его никто не читает.»
Скорость выросла, ревью — нет. Дефекты уезжают в прод быстрее, чем их успевают заметить.
Смотрим не только код, но и петлю: где стоят проверки, что они ловят, что проходит мимо. Цепочка поставки и конвейер.
«Был инцидент. Нужно понять, что ещё такого же осталось.»
Одна найденная дыра почти никогда не бывает единственной в своём классе.
Ищем однотипные места по всей кодовой базе, а не только чиним найденное. Аудит приложения по ASVS.
«Запустили ассистента на своих документах. Безопасники спрашивают, что будет, если в документ вписать инструкцию.»
Внедрение в промпт и доступ к чужим документам через общий индекс.
Проверяем ИИ-контур по отдельному списку: границы агента, обработка вывода, изоляция данных в поиске. Аудит ИИ-контура.
«Нас покупают. Технический аудит будет смотреть в том числе безопасность.»
Находки на этой стадии двигают цену сделки.
Проходим по тому же списку, что и покупатель, но до него — чтобы разговор шёл о плане, а не о сюрпризе. Экспресс-диагностика.
«Прошлый аудит дал двести находок. Через полгода набралось столько же новых.»
Чинили результат, а не причину. Процесс, который производит дефекты, не менялся.
Оцениваем зрелость разработки и строим дорожную карту, а не очередной список находок. Оценка зрелости разработки.
«Нужен пентест. Для галочки, отчёт положить в папку.»
Честный запрос, который мы честно не берём.
Такую работу мы не делаем — и говорим об этом сразу, а не после подписания.
Некоммерческий фонд, который с 2001 года выпускает открытые методологии безопасной разработки. Его документы — не закон и не стандарт в юридическом смысле; их сила в том, что на них ссылаются все стороны разговора.
Разные документы отвечают на разные вопросы. Ошибка — тащить Top 10 в приёмку или ASVS в разговор с генеральным. Каждая карта открывается целиком: структура, все категории по-русски, что мы по ней проверяем.
Десять классов риска, с которых начинают все
Стандарт верификации: то, что можно записать в договор
Как именно тестировать: процедура, а не список рисков
Отдельный список, потому что у API ломается другое
Риски приложений на языковых моделях
Мобильное приложение: требования, тесты и каталог слабостей
Из чего собрано ваше приложение и кто это может подменить
Конвейер как поверхность атаки
Зрелость процесса: не «что сломано», а «почему ломается снова»
Объём считается от вашей архитектуры, поэтому сроки здесь типовые, а цены не публикуются: назвать их до разговора — значит либо завысить, либо потом переторговывать.
Первый заход. Нет понимания, насколько всё плохо, и нужно решение — что делать дальше.
Диагностика не заменяет аудит. Её работа — дать основание для решения, а не полноту.
Требование заказчика или регулятора, подготовка к сделке, выход в новый сегмент.
Запущен или готовится к запуску продукт с моделью внутри — и непонятно, как его проверять.
Это то направление, где документы фонда меняются быстрее всего: список рисков пересобирали дважды за полтора года. Работаем по действующей редакции и говорим, что именно в ней изменилось.
Заказчик просит опись состава ПО. Или конвейер имеет доступ в прод, а его никто не проверял.
Прошлый аудит не помог: находки починили, новые набежали. Или нужен ответ на ГОСТ Р 56939-2024.
Быстрый релизный цикл. Разовый аудит устаревает через месяц после сдачи.
Одни и те же классы дефектов повторяются от спринта к спринту.
Самая большая часть работы — четвёртый этап, и именно он не поддаётся автоматизации. Всё остальное существует, чтобы он состоялся и чтобы его результат можно было использовать.
Договариваемся, что в объёме, что трогать нельзя, в каком окне работаем и кому звонить, если что-то упало.
Вам: Письменное разрешение на работы и контакт дежурного. Без этого не начинаем.
Собираем поверхность: домены, эндпоинты, панели, забытые окружения, старые версии API. Почти всегда находится то, о чём в компании уже забыли.
Вам: Карта поверхности атаки — часто первый полезный артефакт сам по себе.
Прогоняем инструменты: состав зависимостей, секреты, конфигурация, статический анализ. Это дёшево и находит нижний слой.
Вам: Ничего. Сырой вывод сканера — не результат, и мы его не сдаём.
Основная часть. Контроль доступа, бизнес-логика, сценарии, которые нельзя выразить сигнатурой. Здесь находится то, ради чего всё затевалось.
Вам: Промежуточный статус: если находим критичное, сообщаем сразу, не дожидаясь отчёта.
Каждую находку воспроизводим. Не воспроизвели — не пишем. Оцениваем влияние на ваш бизнес, а не по формуле из карточки уязвимости.
Вам: Отсутствие ложных срабатываний в отчёте. Это то, за что обычно платят разработчики своим временем.
Собираем реестр находок, матрицу требований и план устранения волнами. Отдельно — одна страница для того, кто отчёт читать не будет.
Вам: Документ, по которому можно работать, а не пугать им совет директоров.
Два часа с командой: проходим находки, отвечаем на вопросы, спорим о приоритетах. Часть находок после разговора меняет оценку — это нормально.
Вам: Согласованный план, а не спущенный сверху.
После ваших правок проверяем исправленное. Отдельно смотрим, не появилось ли нового рядом.
Вам: Отчёт о ретесте — тот документ, который обычно и просят показать заказчик или проверяющий.
Отчёт, который прочитали один раз и положили в папку, — плохой результат. Хороший — набор документов, которыми пользуются в работе и показывают заказчику.
Всё, что доступно снаружи, с указанием, кто это поддерживает. Регулярно оказывается, что часть — никто.
Каждая находка: где, как воспроизвести, что будет, если не чинить, что делать. Без воспроизведения запись в реестр не попадает.
Требование ASVS, целевой уровень, вердикт, доказательство. Тот артефакт, который показывают заказчику и проверяющему.
Волнами, а не списком из двухсот строк: что в этот спринт, что в квартал, что принимаем как риск сознательно.
Проверки, поставленные в ваш конвейер и настроенные так, чтобы их не отключили на второй неделе из-за шума.
Одна страница: что нашли, чем это грозит, сколько стоит починить. Без слова «хакер».
Что закрыто, что осталось, что появилось нового. Документ, который переживает проект.
Четыре числа, на которые мы опираемся в разговоре. У каждого — ссылка на первоисточник и дата сверки: цифра без источника на странице не стоит.
Средняя доля задач, в которых сгенерированный код прошёл проверку безопасности. Годом раньше было 55 процентов — показатель стоит на месте, а объём такого кода растёт.
Veracode, 2026 GenAI Code Security Report · сверено 09.09.2026Хуже всего сгенерированный код держит межсайтовое выполнение сценариев и внедрение в журналы: 15 и 12 процентов прохождения соответственно. Для сравнения, внедрение SQL — 83 процента.
Veracode, 2026 GenAI Code Security Report · сверено 09.09.2026Редакция 2025 года построена на ~175 000 записей CVE и 643 уникальных типах дефектов, сопоставленных с ними, по данным с 2,8 млн приложений. В редакции 2021 года было 125 000 записей и 241 тип.
OWASP Top 10:2025, введение · сверено 09.09.2026С 30 мая 2025 года при повторном нарушении — от 1 до 3 процентов годовой выручки, но не менее 20 и не более 500 млн рублей. Утечки происходят через первые строки списка рисков, а не через экзотику.
ст. 13.11 КоАП РФ в редакции 420-ФЗ от 30.11.2024 · сверено 09.09.2026OWASP не является нормативным документом в России: ни ФСТЭК, ни Банк России не ссылаются на него в текстах приказов и положений, официального признанного перевода не существует. Но требования регуляторов сформулированы как «проведите анализ уязвимостей», «смоделируйте угрозы», «выстройте процесс разработки» — без указания, как именно. OWASP закрывает это «как»: даёт методологию, по которой работу можно выполнить и показать результат.
Утверждён приказом Росстандарта от 24.10.2024 № 1504-ст, заменил редакцию 2016 года. Главное изменение — не список мер, а процессная модель из 25 процессов, включая моделирование угроз и описание поверхности атаки, статический и динамический анализ, фаззинг, тестирование на проникновение, управление уязвимостями на всём жизненном цикле.
Кого касается: Обязателен разработчикам средств защиты информации при сертификации ФСТЭК (через приказ ФСТЭК № 240 от 01.12.2023 в редакции приказа № 230 от 30.06.2025) и разработчикам ПО для значимых объектов КИИ. Остальным формально добровольный — но всё чаще появляется в тендерах и договорах.
SAMM закрывает процессную часть: пятнадцать практик модели ложатся на процессы стандарта почти один в один. ASVS даёт проверяемые требования к самому продукту, WSTG — процедуру тестирования.
Для объектов первой категории — обязательный динамический анализ кода. Для всех значимых объектов — анализ уязвимостей с подтверждением отсутствия хотя бы тех уязвимостей, что уже занесены в банк данных угроз ФСТЭК.
Кого касается: Субъекты КИИ по 187-ФЗ: энергетика, транспорт, связь, финансы, здравоохранение, промышленность.
ASVS работает как чек-лист требований, WSTG — как процедура, по которой проверка проводится и описывается. Карточки уязвимостей банка данных ФСТЭК содержат перекрёстные ссылки на CVE и CWE, поэтому находки, описанные в терминах OWASP, сопоставляются с реестром регулятора.
Положение 851-П (в силе с 29.03.2025) заменило 683-П, положение 821-П (в силе с 01.04.2024) заменило 719-П. Прикладное ПО, которое банк отдаёт клиентам — интернет-банк, мобильный банк, — проходит либо сертификацию, либо анализ уязвимостей по требованиям ОУД4 (оценочный уровень доверия по ГОСТ Р ИСО/МЭК 15408-3). По ГОСТ Р 57580.1 переходный период: с 01.10.2025 уровень защиты не ниже третьего, с 01.01.2027 — не ниже четвёртого.
Кого касается: Кредитные организации, операторы по переводу денежных средств, платёжные агенты, некредитные финансовые организации.
ОУД4 требует методического проектирования, функционального тестирования и независимого анализа уязвимостей. ASVS даёт структуру требований для веба и API, MASVS — для мобильного приложения, WSTG — методику тестирования. Важно: сам вывод об ОУД4 делает лицензиат ФСТЭК или аккредитованная лаборатория, а не мы. Наша работа — привести приложение в состояние, в котором эта проверка проходится.
С 30.05.2025 действуют оборотные штрафы: до 15 млн рублей за первое нарушение, при повторном — от 1 до 3 процентов годовой выручки, но не менее 20 млн и не более 500 млн рублей. С декабря 2024 года действует статья 272.1 Уголовного кодекса — незаконный оборот персональных данных.
Кого касается: Любая компания, у которой на сайте есть форма. Форма обратной связи делает вас оператором персональных данных.
Утечки происходят не через экзотику: нарушенный контроль доступа, инъекции, небезопасная конфигурация — первая, вторая и пятая строки Top 10:2025. Это ровно тот объём, который закрывает базовая диагностика.
Заменил приказ № 17, действовавший тринадцать лет. Расширил область с государственных информационных систем на все информационные системы госорганов, предприятий и учреждений; групп технических мер стало 17 вместо 13. Впервые вводит требования при использовании технологий искусственного интеллекта: контроль доступа к моделям, фильтрация входных запросов и выходных ответов, квотирование, мониторинг функциональности.
Кого касается: Государственные органы, предприятия и учреждения.
Требования приказа — контроль доступа к модели, фильтрация входа и выхода, квоты — по смыслу совпадают с пунктами LLM Top 10: внедрение в промпт, небезопасная обработка вывода, неограниченное потребление.
Первый российский документ, системно описывающий риски применения ИИ: отравленные и устаревшие данные, нарушение конфиденциальности, сбои модели включая галлюцинации и дрейф, недостаточная объяснимость, риски поставщиков и открытого кода. Предложено более двадцати мер, в том числе подтверждение человеком критичных операций, выполняемых с участием ИИ.
Кого касается: Финансовый рынок. Статус рекомендательный, но проверяющий будет смотреть на него.
Мера «подтверждение человеком критичной операции» — это ровно то, что в LLM Top 10 2026 стоит на третьем месте под названием «Избыточные полномочия».
Прямых требований к безопасной разработке для включения в реестр нет — акцент на правах на продукт и совместимости с отечественными операционными системами. Отдельный трек «доверенного ПО» с проверкой на уязвимости находится в стадии формирования, и утверждать его состав сейчас нельзя.
Кого касается: Вендоры, продающие в госсектор.
Практическая часть, которую спрашивают уже сейчас, — опись состава ПО. Формат CycloneDX, выросший из OWASP, принят Ecma International как ECMA-424.
Границы стоят на этой же странице специально. Они снимают часть заявок до разговора — и делают достовернее всё остальное.
Если мы не смогли повторить, в отчёт это не попадает. Сырой вывод сканера не является результатом работы.
Одна и та же техническая уязвимость в витрине и в биллинге — это разные приоритеты. Оценка из карточки уязвимости — вход, а не ответ.
Отчёт нужен, чтобы починить, а не чтобы продать следующий этап. Если что-то не критично — так и написано.
Отчёт, отправленный письмом, не работает. Работает разговор, на котором разработчики спорят с нашими приоритетами.
Документы фонда обновляются: список веб-рисков пересобран в 2025 году, стандарт верификации — в 2025-м, список рисков ИИ — в 2026-м. Мы называем редакцию, по которой работали, и дату сверки.
Мы не лицензиат ФСТЭК и не испытательная лаборатория. Заключение по ОУД4 и аттестат выдаём не мы. Наша работа — привести систему в состояние, в котором эта проверка проходится, и собрать доказательную базу.
Если задача — получить документ и положить в папку, мы не подходим. Это честный запрос, у него есть исполнители, просто не мы.
Нагрузочные и разрушающие проверки — только на стенде или в согласованное окно, письменно.
Пока не увидели архитектуру, сроки не называем. Оценка «примерно как в прошлый раз» на аудите не работает.
Пентест отвечает на вопрос «можно ли сюда попасть» и останавливается, когда попал. Аудит по стандарту отвечает на вопрос «что из требований выполнено», и проходит весь список, включая места, где всё в порядке. Первое даёт остроту, второе — полноту и доказательства. Чаще всего нужно второе, а просят первое.
Это обычная ситуация, и она не мешает. Отчёт пишется для разработчиков и для руководителя, а не для отсутствующего у вас отдела. Начать разумно с экспресс-диагностики: она даёт основание для решения, а не сразу двести задач в бэклог.
Для базового уровня — нет, он проверяется снаружи. Начиная со стандартного уровня — да, и это принципиально: без кода часть требований проверить нельзя, и честнее сказать «не проверено», чем «выполнено».
Меняет объём, а не природу дефектов. Опубликованное в 2026 году исследование безопасности сгенерированного кода даёт средний показатель прохождения проверок безопасности 56 процентов — почти без изменений за год, при том что объёма такого кода стало кратно больше. Отдельно проседают межсайтовое выполнение сценариев и внедрение в журналы. Практический вывод простой: проверка должна стоять в конвейере, а не в конце квартала.
Реестр находок с воспроизведением, матрицу требований с доказательствами, план устранения волнами, одну страницу для руководства и отчёт о ретесте. Плюс настроенные в вашей сборке проверки, если формат это включает.
Диагностика — около недели. Аудит приложения — три–пять недель. Оценка зрелости процесса — три недели. Точные сроки называем после того, как посмотрели архитектуру и договорились об объёме.
Заключение по ОУД4 выдаёт лицензиат ФСТЭК или аккредитованная лаборатория — не мы. Мы делаем подготовку: приводим приложение в соответствие требованиям, собираем доказательную базу и устраняем то, на чём проверка обычно спотыкается. Так проверка проходится с первого раза, а не с третьего.
Так не бывает, но бывает, что не находится ничего критичного. Тогда результат работы — матрица требований с закрытыми пунктами и доказательствами. Это ровно тот документ, который просит показать заказчик, и он стоит своих денег независимо от количества находок.
Этого достаточно для первого разговора. По итогам скажем, какой формат подходит, что реально нужно проверить, а что можно не трогать — и подходим ли мы вам вообще. Если нет, скажем сразу.