Безопасность приложений: SCA, SAST, DAST и MAST. Что дальше?

Я видел столько панелей мониторинга сканеров, что уже могу распознать этот шаблон. SAST выявляет теоретические уязвимости, которые никогда не будут задействованы. DAST пожимает плечами, потому что путь к уязвимой функции заблокирован. SCA наводняет систему CVE, которые никогда не затрагивают активные пути. MAST отчитывает мое мобильное приложение за секреты, которые я удалил еще в прошлом квартале. Эти инструменты по-прежнему незаменимы, но теперь они служат лишь отправной точкой, а не конечной станцией. Следующий этап — не очередной продукт-«серебряная пуля», а переход к управлению состоянием (posture), происхождением (provenance) и доказательством (proof).

За последний год сообщество признало очевидное: поле битвы — это цепочка поставок программного обеспечения и работающая система, а не только сканирование до релиза. Обновление OWASP 2025 года подняло сбои в цепочке поставок ПО до позиции A03, переосмыслив уязвимые и устаревшие компоненты как системный экосистемный риск, охватывающий зависимости, системы сборки и инфраструктуру дистрибуции (обзор Endor Labs здесь). Параллельно CISA продвинула руководство по SBOM, выпустив черновик 2025 года, который требует более богатых, машиночитаемых метаданных и подчеркивает автоматизацию для масштабирования.

Состояние, происхождение и доказательство: новая триада

Управление состоянием безопасности приложений (Application Security Posture Management, ASPM) — это плоскость управления, которая вновь делает старый квартет полезным. Отчет Gartner за 2025 год об инновациях (Innovation Insight) описал, как ASPM связывает разрозненные сигналы по всему SDLC, обеспечивает соблюдение политик и приоритизацию на основе контекста, такого как достижимость и фактическая экспозиция. Это означает сведение результатов SAST, DAST, SCA, IaC и времени выполнения в единое представление, а затем фильтрацию для выделения того небольшого подмножества, которое действительно имеет значение.

Мне нравится рассматривать ASPM через призму «от кода до облака», поскольку это отражает, как на самом деле работают наши системы. Руководство Wiz Academy описывает основные возможности ASPM: унифицированная видимость, приоритизация рисков, принудительное соблюдение политик и постоянное обнаружение на этапах разработки, сборки и развертывания. Цель состоит в том, чтобы уменьшить усталость от оповещений, одновременно связывая проблемы кода с влиянием на время выполнения (ASPM ASPM). Это соответствует предпосылке Gartner, но добавляет практические детали о корреляции сигналов репозитория, политик конвейера и облачной реальности.

Состояние (Posture) — это «что». Происхождение (Provenance) — это «как». Фреймворк SLSA предоставляет нам общий словарь и проверяемые элементы управления, чтобы доказать, что артефакты были собраны с помощью закаленных, защищенных от вмешательства конвейеров с подписанными подтверждениями, которым могут доверять потребители ниже по потоку (обзор OpenSSF здесь). Когда я настаиваю на Уровне 2 SLSA для большинства сервисов и Уровне 3 для критических путей, я не гонюсь за формальным соответствием; я покупаю целостность, которая выдерживает аудит и инциденты.

Доказательство (Proof) — это то, где SBOM наконец взрослеют. Привязка генерации SBOM к сборке, которая выдает развертываемые биты, их подписание и валидация во время развертывания превращают SBOM из «списков ингредиентов» в принудительные элементы управления. Практическое руководство (best practices v2 paper) TAG-Security CNCF является моей практической картой: роли, VEX для эксплуатируемости, криптографическая проверка, чтобы убедиться, что тесты действительно выполнялись, и предписывающие указания для облачных фабрик.

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

От панелей мониторинга к решениям: ASPM на практике

Программа управления состоянием — это набор привычек, а не просто платформа. Я начинаю с объединения результатов сканирования в единый реестр рисков, но отказываюсь от триажа в вакууме. Результаты должны содержать доказательства достижимости, теги конфиденциальности данных и контекст экспозиции. Вот где ASPM доказывает свою ценность. Материалы Wiz Academy подчеркивают эту связь «от кода до облака» и показывают, как уменьшить шум, чтобы разработчики видели те немногие проблемы, которые блокируют бизнес, а не стену теоретического риска. Подход Gartner обосновывает внедрение в регулируемых средах, где разрозненные сигналы подрывают скорость устранения уязвимостей.

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

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

Строгость цепочки поставок без показухи

Работа с цепочкой поставок может выродиться в бумажную волокиту, если мы забудем о главном. Суть в целостности. Я придерживаюсь простого подхода к SLSA: Уровень 2 быстро, Уровень 3 для критических путей. Это означает закаленную службу сборки, изолированные сборки, подписанное происхождение и проверенную цепочку от исходного кода до артефакта.  SBOM становятся операционными, как только они становятся машиночитаемыми, подписанными и проверенными при развертывании. Черновик CISA 2025 года ужесточил требования к полям, форматам и автоматизации, что я приветствую, поскольку это ускоряет и упрощает закупки и реагирование на инциденты (CISA).

Документ CNCF заполняет пробелы. Он объясняет, как связать SBOM с VEX, добавить криптографические проверки для этапов конвейера и рассматривать инфраструктуру разработчика как часть цепочки поставок. Последний пункт важен, поскольку злоумышленники все чаще нацеливаются на репозитории, настройки CI и реестры артефактов, а не только на зависимости кода. Рекомендации для государственного сектора от CNCF отражают те же приоритеты для государственных рабочих нагрузок, с конкретными уроками, извлеченными из SolarWinds, Log4Shell и xz.

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

Реальность времени выполнения: инструменты, а не иллюзии

Тестирование до релиза необходимо, но недостаточно. Инструментарий IAST дает мне истинные данные о времени выполнения во время QA, наблюдая за фактическими путями выполнения для уменьшения ложных срабатываний и сохранения контекста разработчика. В продакшене модель смещается в сторону RASP, который блокирует эксплуатацию внутри приложения в тот самый момент, когда происходят рискованные операции: построение SQL, выполнение команд ОС, сериализация — то, чего WAF не видят. Это не критика WAF; это признание того, что инспекция сетевого уровня и интроспекция уровня приложения решают разные задачи.

Если вы думаете, что периметровых средств контроля достаточно, две недели ноября 2025 года должны развеять это заблуждение. CISA выпустила экстренные рекомендации по уязвимостям Cisco ASA и FTD (CVE‑2025‑20333, CVE‑2025‑20362), поскольку агентства сообщали об устройствах как о «исправленных», которые все еще работали на уязвимых версиях. Директива предписывала минимальные версии, криминалистические проверки и сроки, и напомнила всем, что все устройства должны быть обновлены, а не только те, что обращены в Интернет (пресс-релиз CISA здесь).

Урок переносимый: относитесь к статусу «исправлено» как к состоянию, требующему доказательств. Проверяйте минимальные версии релизов, подтверждайте состояние всего парка устройств и выводите из эксплуатации устаревшее оборудование. Сочетайте периметровые средства контроля с датчиками уровня приложений и защитой времени выполнения контейнеров, поскольку ваши рабочие нагрузки все чаще находятся в Kubernetes и управляемых платформах. Рыночные анализы подтверждают сдвиг в сторону оркестрированных, облачно-нативных сред, где возможна последовательная политика времени выполнения (пост о трендах CNCF здесь).

Предупреждение: связывайте телеметрию времени выполнения с вашей практикой TDIR (Threat Detection and Incident Response). Когда RASP блокирует внедрение в продакшене, это событие должно приводить к исправлениям кода, а не просто к закрытому оповещению.

Защита экосистем ИИ и цепочки поставок

Среди предстоящих изменений ИИ является самым неуловимым. Финальные рекомендации NIST 2025 года по состязательному ML разделили угрозы на PredAI и GenAI и назвали внедрение промптов (prompt injection) в прямой и косвенной форме доминирующим типом эксплуатации в агентных системах, где доверенные инструкции смешиваются с недоверенными данными (Обзор Meritak; объяснение IBM). Институт безопасности ИИ США опубликовал работу по оценке угона агентов (agent hijacking evaluations), которую я считаю обязательным чтением для «красных команд» при делегировании действий инструментам (блог NIST AISI).

Для разработчиков профиль сообщества NIST SP 800‑218A от июля 2024 года расширяет SSDF на генеративный ИИ и модели общего назначения (foundation models). Он охватывает моделирование угроз промптов, защиту конвейеров данных обучения, изоляцию операций моделей и привязку документации к моделям к практикам безопасной разработки.

На уровне языков немодная ранее рекомендация стала мейнстримом. В июне 2025 года АНБ и CISA настоятельно рекомендовали внедрять языки с безопасной работой с памятью, предоставив прагматичные указания по миграции устаревших систем: начинать с самого важного, постепенно интегрировать и защищать старые модули с помощью усиленного FFI (CSI АНБ/CISA).

Выбор языков, который устраняет целые классы ошибок

Если вы хотите избавиться от классов уязвимостей, перестаньте их писать. В июне 2025 года АНБ и CISA опубликовали совместное CSI с призывом внедрять языки с безопасной работой с памятью, предоставив прагматичные указания по миграции устаревших систем. Начинайте с самого важного, интегрируйте постепенно и защищайте старые модули с помощью усиленного FFI. Это не академическое позерство. Переполнения буфера, использование после освобождения и гонки данных подрывают устойчивость и стоят реальных денег. Языки с безопасной работой с памятью снижают эти риски по своей сути.

Предупреждение: требуйте использования языков с безопасной работой с памятью для нового кода, планируйте миграцию для модулей с высоким риском и опубликуйте график с датами и метриками. Объясните причины, используя руководство АНБ и CISA, а затем измерьте результаты.

Какое место занимают SCA, SAST, DAST и MAST теперь

Они остаются основополагающими, будучи интегрированными в программу с ориентацией на состояние (posture-centric).

• SAST по-прежнему выявляет проектные и имплементационные недостатки, но я настаиваю на анализе достижимости и исправлении силами разработчика прямо в IDE; передавайте результаты SAST в ASPM для контекста, чтобы теоретические проблемы не затмевали реальные.
• DAST незаменим для оценки экспозиции до релиза, однако я сочетаю его с IAST для наблюдения за путями выполнения кода вживую и снижения ложных срабатываний.
• SCA выходит за рамки списков CVE, когда генерация SBOM привязывается к сборкам, а VEX сокращает шум; лучшие практики CNCF и черновик CISA по SBOM за 2025 год описывают, как это делать правильно.
• MAST контролирует усиление защиты мобильных приложений, но я интегрирую проверки гигиены секретов и безопасного хранения в те же элементы управления жизненным циклом, что используются для серверных приложений.

Совет руководству: что я внедряю дальше

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

1. ASPM как плоскость управления. Объединяйте сигналы, дедуплицируйте и ранжируйте по эксплуатируемости — достижимость, экспозиция, конфиденциальность данных. Автоматически назначайте владельцев и используйте шлюзы политик для рискованных сборок.
2. Строгость цепочки поставок. Внедряйте уровни SLSA, требуйте подписанные SBOM и подтверждения, и проводите валидацию при развертывании. Нет артефакта без происхождения, нет развертывания без верификации.
3. Защита времени выполнения. Встраивайте RASP в стеки приложений, обеспечивайте контроль времени выполнения контейнеров и сохраняйте WAF на периметре. Связывайте события с конвейером TDIR, чтобы блокировка в продакшене инициировала исправления в коде.
4. Жизненный цикл секретов и машинные идентификаторы. Централизованное хранение, автоматизированная ротация, принцип наименьших привилегий везде, взаимный TLS для аутентификации между сервисами.
5. Программа безопасности ИИ. Принимайте NIST SP 800‑218A, проводите тестирование агентов на угон (red-team), обеспечивайте разделение привилегий и отслеживайте результаты.
6. Политика в отношении языков. Требуйте использования языков с безопасной работой с памятью для нового кода, планируйте миграции для модулей с высоким риском и используйте руководство АНБ/CISA для информирования заинтересованных сторон.

Заключение

SCA, SAST, DAST и MAST остаются фундаментом, но они наиболее эффективны, когда оркестрируются ASPM, подтверждаются SLSA и SBOM, и защищаются средствами контроля времени выполнения. Добавьте специфические для ИИ меры защиты и языки с безопасной работой с памятью, и вы перейдете от погони за результатами к принятию решений с уверенностью. Это мой план «что дальше».

Эта статья публикуется в рамках Сети экспертных авторов Foundry.
Хотите присоединиться?