ZDNet AI→ оригинал

Почему традиционная безопасность приложений уже не работает

Модель find-and-fix больше не работает. AI помощники ускоряют разработку, CI/CD развёртывает код постоянно, а очередь патчей растёт экспоненциально. Старая AppS

Почему традиционная безопасность приложений уже не работает
Источник: ZDNet AI. Коллаж: Hamidun News.
◐ Слушать статью

Модель "найди-и-исправь" для безопасности приложений перестаёт работать. Когда разработчики дописывают код за AI, развёртывают обновления каждый день, а список известных уязвимостей растёт в геометрической прогрессии, старый подход просто захлёбывается.

Почему поломалась старая

AppSec Традиционная безопасность полагалась на то, что найденные баги можно исправить до следующего релиза. Но мир изменился. AI-ассистенты вроде GitHub Copilot ускоряют написание кода, разработчики за день выпускают несколько версий (спасибо CI/CD-пайплайнам), а количество известных уязвимостей (CVE) выросло в несколько раз за пару лет. Скорость разработки теперь обгоняет скорость поиска и исправления проблем. Проблема обостряется экспоненциально: каждой CVE нужно время на анализ, assessment, разработку патча, тестирование, откат версии. А новых уязвимостей находится каждую неделю. Очередь растёт быстрее, чем её успевают обрабатывать.

Точка перегрева * **Экспоненциальный рост CVE**: каждый год новых

уязвимостей больше, чем в предыдущий. Только за 2023 год зарегистрировано более 28 тысяч CVE. Отстающие патчи: очередь на исправления длиннее, чем человечество может обработать. Средняя задержка между открытием уязвимости и выпуском патча — месяцы. AI быстрее, чем QA: генеративные модели пишут код быстрее, чем его можно проверить вручную или даже автоматизированными инструментами. * Бесконечная цепь зависимостей: одна уязвимость в популярной библиотеке заражает сотни и тысячи приложений, от мобилок до критичных инфраструктур.

Сдвиг влево

Компании начинают переходить на "shift-left" — встраивать проверки безопасности на ранние стадии разработки, прямо в IDE разработчика, а не ловить проблемы после развёртывания в production. Это значит: статический анализ (SAST) блокирует ненадёжный код до merge'а, проверки зависимостей отлавливают CVE в версиях библиотек, динамический анализ (DAST) имитирует атаки на тестовом окружении. Но даже этого часто недостаточно. Некоторые компании переходят на автоматизированный ответ на инциденты: если найдена уязвимость в production, алерт тут же откатывает или изолирует проблемный код без человека. Это снижает окно уязвимости с часов до минут.

«Безопасность больше не может быть финальным шагом в разработке.

Это должно быть встроено в код с первой строки.»

Новый контракт между

Dev и Sec Старая модель была антагонистична: разработчики писали быстро, security-инженеры позже критиковали. Новая модель требует сотрудничества. Разработчик привыкает думать о безопасности при написании кода, security инженер встраивается в team и пишет автоматизацию вместо ручных проверок.

Что это значит Эра, когда AppSec-команда сидела с чек-листом и ловила баги на pentest'е, уходит.

Новая реальность — безопасность встроена в разработку, а не наклеена сверху. DevSecOps, а не отдельные AppSec-отделы. Компании, которые не переориентируются, будут отставать и в скорости, и в надёжности.

ЖХ
Hamidun News
AI‑новости без шума. Ежедневный редакторский отбор из 400+ источников. Продукт Жемала Хамидуна, Head of AI в Alpina Digital.
Что вы думаете?
Загружаем комментарии…