Программное обеспечение всегда создавалось на основе противоречия между скоростью и безопасностью. Команды разработчиков настаивают на ускорении циклов выпуска, а группы безопасности — на тщательном тестировании и проверке. На протяжении десятилетий отрасль рассматривала это как компромисс с нулевой суммой. Если вам нужна скорость, вы соглашаетесь на риск. Если вы хотели безопасности, вы жертвовали скоростью.
Это напряжение уже обострялось под давлением гибкой разработки и непрерывной доставки. Теперь, когда ИИ переписывает правила создания программного обеспечения, баланс полностью рушится.
Помощники по программированию на базе искусственного интеллекта и большие языковые модели позволяют разработчикам генерировать код с беспрецедентной скоростью. То, что раньше занимало недели, теперь можно сделать за часы. Прирост производительности неоспорим. Последствия для безопасности столь же неоспоримы.
Код, созданный ИИ, по своей сути не более безопасен, чем код, написанный человеком. Во многих случаях это менее безопасно. Модели воспроизводят небезопасные шаблоны из своих обучающих данных, молча импортируют зависимости и создают рабочие процессы, обходящие критические проверки. Чем быстрее поступает код, тем быстрее с ним появляются уязвимости. Если в отрасли и дальше будут рассматривать скорость и безопасность как взаимоисключающие понятия, результатом станет лавина небезопасных приложений, предоставляемых с рекордной скоростью.
Будущее развития зависит от преодоления этого компромисса. Нам нужна модель, в которой программное обеспечение можно будет создавать быстрее и безопаснее.
Почему традиционная безопасность не может идти в ногу со временем
Первая волна попыток решить эту проблему была сосредоточена на внедрении безопасности на ранних этапах жизненного цикла. Такие движения, как «сдвиг влево» и DevSecOps, обещали, что за счет сканирования конвейеров CI и включения безопасности в рабочие процессы разработчиков уязвимости будут обнаруживаться раньше и устраняться с меньшими затратами. Принцип был разумным. Практики не было.
Традиционные инструменты безопасности не были созданы для современной скорости. Статический анализ замедлял сборку. Динамическое тестирование требовало специализированной среды и длительного времени выполнения. Анализ композиции выявил тысячи зависимостей, многие из которых были нерелевантными. Результатом стало слишком много выводов, слишком мало контекста и слишком большая задержка. Разработчики проигнорировали этот шум, количество незавершенных работ росло, а обещания о более ранней безопасности не оправдались.
Если эти инструменты не могут идти в ногу с разработкой, управляемой человеком, они еще менее подходят для разработки, управляемой искусственным интеллектом. Когда код создается со скоростью машины, сканеры, которые работают часами или генерируют тысячи предупреждений, просто нежизнеспособны. Будущее безопасного развития требует новой основы.
Катализатор ИИ
ИИ не просто ускорил развитие. Это создало новые категории риска. Оперативное внедрение, манипулирование моделями и небезопасная конструкция плагинов — это направления для атак, которых раньше никогда не существовало. Ошибки бизнес-логики встречаются чаще, поскольку модели не обладают знаниями в предметной области и создают рабочие процессы в обход организационных правил. Даже недетерминированный характер результатов ИИ создает проблемы, поскольку одно и то же приглашение может изо дня в день давать разный код.
Масштабы этих рисков означают, что старый компромисс — выбирать скорость или выбирать безопасность — больше недопустим. Организации не могут замедлять разработку, чтобы обеспечить безопасность, поскольку бизнес зависит от скорости. Но они также не могут игнорировать безопасность, потому что риски экзистенциальны. Утечки данных, нарушения нормативных требований и сбои в работе влекут за собой слишком большие затраты, чтобы их можно было принять.
Вот почему будущее должно быть за достижением обоих. Революция искусственного интеллекта требует не только более быстрого кода. Это требует более быстрого и безопасного кода.
Что на самом деле означает «быстрее и безопаснее»
Достижение более быстрого и безопасного кода не предполагает постепенного улучшения старых моделей. Речь идет о переосмыслении того, как безопасность интегрируется с развитием.
Во-первых, безопасность должна работать в режиме реального времени. Уязвимости не могут ждать, пока их найдут сканеры через несколько часов после написания кода. Они должны быть идентифицированы и решены во время генерации кода, в IDE разработчика или через сам AI-помощник.
Во-вторых, безопасность должна быть контекстуальной. Разработчики не будут доверять расплывчатым предупреждениям и действовать в соответствии с ними. Им необходимо понять, почему уязвимость имеет значение, как ее можно использовать и как выглядит безопасная альтернатива. Контекст превращает предупреждения в рекомендации, а рекомендации — в исправления.
В-третьих, исправления должны быть встроены. Обнаружение без исправления просто создает отставание. ИИ позволяет автоматически генерировать безопасные исправления, адаптированные к платформам приложения и стилю кодирования и доставляемые в виде запросов на включение, готовых для проверки.
Наконец, в этот поток необходимо включить расстановку приоритетов. Разработчиков не следует заставлять просматривать длинные списки проблем, ранжированных по абстрактным оценкам серьезности. Они должны видеть только те уязвимости, которые действительно имеют значение, уже дополненные надежными исправлениями.
Более быстрый и безопасный код означает объединение обнаружения, определения приоритетов и исправлений в одну собственную систему искусственного интеллекта, которая работает со скоростью разработки.
В действии: взгляд разработчика
Представьте себе разработчика, который пишет новую конечную точку API с помощью помощника по кодированию на базе искусственного интеллекта. Помощник предлагает код, который напрямую объединяет вводимые пользователем данные в запрос к базе данных. В старой модели эта уязвимость могла быть обнаружена через несколько часов при CI-сканировании, спрятанная среди сотен других предупреждений. К моменту сортировки код уже был объединен, и отставание выросло.
В новой модели уязвимость перехватывается в режиме реального времени. Разработчику показано, что запрос может быть использован для внедрения SQL-кода, дано объяснение того, почему это важно, и дана исправленная версия, в которой используются параметризованные операторы. Разработчик принимает исправление, фиксирует код и движется дальше. Уязвимость никогда не попадает в бэклог.
Разработчик воспринимает безопасность не как трение, а как сотрудничество. Безопасность становится товарищем по команде, а не препятствием.
В действии: взгляд команды безопасности
Теперь рассмотрим команду безопасности. В старой модели они получают бесконечные информационные панели, заполненные предупреждениями от нескольких инструментов, каждый из которых имеет свой уровень серьезности. Они тратят свое время, пытаясь сопоставить результаты, спорят о приоритетах и возвращают исправления разработчикам, которые уже пошли дальше.
В новой модели система сама фильтрует и контекстуализирует результаты. Выявляются только важные проблемы, и к ним уже предлагаются предлагаемые исправления. Команда безопасности переходит от сортировки шума к управлению политиками. Они определяют стандарты шифрования, аутентификации и обработки данных, и система автоматически обеспечивает их соблюдение. Их роль меняется от узкого места до фактора, способствующего развитию.
В действии: взгляд руководителя
Наконец, рассмотрим точку зрения руководителей. В старой модели руководителям говорили, что в их организации имеются тысячи открытых уязвимостей, многие из которых никогда не будут устранены. Риск был непрозрачным, соблюдение требований было реактивным, и общая картина представляла собой постоянное отставание.
В новой модели руководители получают возможность в режиме реального времени контролировать состояние безопасности своих приложений. Они знают, какие уязвимости существуют, как они соотносятся с обязательствами по соблюдению требований и как быстро они устраняются. Вместо отставаний они видят время цикла, измеряемое в часах. Безопасность становится источником уверенности, а не беспокойства.
Эта ясность имеет стратегическое значение. Это позволяет лидерам уверенно внедрять инновации, зная, что скорость не означает принесения в жертву устойчивости.
Стратегический сдвиг
Последствия этого сдвига очень глубоки. Для разработчиков это означает меньше перерывов и больше рекомендаций. Для служб безопасности это означает меньше сортировки и больше управления. Для руководителей это означает видимость и уверенность. Для организации в целом это означает конец ложного компромисса между скоростью и безопасностью.
Это не просто тактическое улучшение. Это стратегическая необходимость. Поскольку искусственный интеллект меняет индустрию программного обеспечения, организации, которые цепляются за старые модели безопасности, окажутся в затруднительном положении. Те, кто использует встроенную систему безопасности ИИ, будут действовать быстрее и безопаснее, чем их конкуренты.
Следующее десятилетие программного обеспечения
Индустрия программного обеспечения находится на перепутье. ИИ ускорил развитие до таких темпов, с которыми не может сравниться устаревшая система безопасности. Выбор очевиден: либо использовать инструменты, предназначенные только для обнаружения, которые создают очереди, либо использовать встроенную систему безопасности ИИ, которая обеспечивает исправления в режиме реального времени.
Будущее разработки не будет определяться только более быстрым кодом. Это будет определяться более быстрым и безопасным кодом. Это означает контекстное и автоматизированное исправление в реальном времени. Это означает объединение обнаружения, определения приоритетов и исправлений в единый поток. Это означает, что безопасность следует рассматривать не как второстепенную мысль, а как неотъемлемую часть процесса написания, проверки и развертывания кода.
Следующее десятилетие программного обеспечения будет принадлежать организациям, которые это понимают. Победителями станут те, кто воспримет ИИ не только как способ быстрее генерировать код, но и как способ быстрее его защитить. Скорость без безопасности – это безрассудно. Безопасность без скорости не имеет значения. Будущее принадлежит тем, кто достигает и того, и другого.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Сумит Сингх — основатель и генеральный директор Aptori, работающий с компаниями из списка Fortune 50 над созданием программ безопасности программного обеспечения, которые сохраняют скорость благодаря агентному искусственному интеллекту. Ранее он был соучредителем AppFormix (приобретенного Juniper Networks) и руководил инженерными инициативами в Juniper и… Подробнее от Сумита Сингха
