Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
В России измерили частотность ошибок при программировании на разных языках. В лидерах Python, Java, PHP, C#
Дата публикации: 19-08-2026 14:29:00
Российская ИБ-компания неожиданно столкнулась с гигантским объемом работ по выявлению уязвимостей программного кода, который генерируют отечественные ИТ-компании, финтех и реальный сектор экономики. Платформа управления безопасной разработкой ПО AppSec.Hub обработала внушительный объем в 550 млн строк кода (на май 2026 г., объем кода под анализом), находками стали 3 млн уязвимостей. Одна из причин роста — вайбкодинг, а среди лидирующих языков программирования по числу находок в области уязвимости названы Python, Java, PHP.
Основное содержимое страницы с новостью.
19 Августа 2026 17:29 19 Авг 2026 17:29 |
Российская ИБ-компания неожиданно столкнулась с гигантским объемом работ по выявлению уязвимостей программного кода, который генерируют отечественные ИТ-компании, финтех и реальный сектор экономики. Платформа управления безопасной разработкой ПО AppSec.Hub обработала внушительный объем в 550 млн строк кода (на май 2026 г., объем кода под анализом), находками стали 3 млн уязвимостей. Одна из причин роста — вайбкодинг, а среди лидирующих языков программирования по числу находок в области уязвимости названы Python, Java, PHP.
Число обнаруженных в коде российских компаний уязвимостей за год выросло на 70%, до 3,1 млн находок, однако очередь на их исправление остается стабильной. Рост связан главным образом с увеличением поступившего объема кода, на май 2026 г. под анализом находилось 550 млн строк. Такие выводы содержатся в клиентской аналитике платформы управления безопасной разработкой ПО AppSec.Hub разработчика в сфере ИБ AppSec Solutions. С документом ознакомился CNews.
В анализ вошли как российские ИТ-компании (веб- и мобильная разработка), так и финтех-компании и компании реального сектора. Профили кода — от мобильных и веб-приложений на распространенных стеках (Java, Python, C#, JavaScript) до крупных корпоративных систем и системного кода (C/C++). Обезличенные данные 4 214 кодовых баз общим объемом около 510 млн строк кода — именно такой массив был проанализирован. Основное окно наблюдения охватывало период с января 2025 г. по май 2026 г.
Из-за вайбкодинга объемы коды существенно выросли, проверять его стало сложнее
AppSec Solutions заявила, что сделала свыше 3,1 млн находок, собранных практиками статического (SAST), компонентного (SCA) и динамического (DAST) анализа. Основная причина роста числа находок, по мнению авторов исследования, — подключение к платформе большого количества новых кодовых баз, а не деградация уже написанного кода. Одна из причин роста объемов — применение ИИ при генерации кода.
«Количество кода, особенно с массовым применением вайбкодинга, продолжает расти», — констатировали в AppSec Solutions.
С начала 2025 г. по май 2026 г. объем анализируемого кода вырос примерно с 333 млн до 510 млн строк, а число кодовых баз под наблюдением — с 2 563 до 4 214. При этом только за 2025 г. прирост составил 33% по объему кода и 36% по числу баз. По итогам 2026 г. объем кода клиентов компании должен увеличиться до 630 млн строк, или еще на 43%. Число кодовых баз увеличится до 5550, а находок — до 3,8 млн (+45%), ожидают в компании. Очередь на разбор ИБ ожидается в 1,52 млн, или на 14% больше, чем в 2025 г.
По числу находок лидирует PythonВ AppSec Solutions привели ключевую статистику по уязвимостям. Универсально «безопасного» стека нет, считают в компании. По плотности серьезных находок на 1000 строк лидирует Python (2,11), но это небольшая база (около 1 млн строк в зоне риска), где плотность неустойчива. Крупнейшие стеки — JavaScript и Java (по примерно 9 млн строк в зоне риска) — держат умеренную плотность, но по абсолютному числу серьезных находок впереди Java (около 2,4 тыс.), в PHP находок мало, но 8 из 10 из них — серьезные. У C# плотность по всем находкам вторая (1,78), но серьёзное — лишь около четверти из них, у C++ наоборот — находок мало, но серьёзны все (плотности совпадают: 0,98).
«Универсально "безопасного" языка нет: приоритеты настраиваются под конкретный стек. Это сравнение на срез, а не тренд: плотность зависит от того, насколько разобран код, поэтому её изменение во времени говорило бы о ходе разбора, а не о качестве кода. Язык сам по себе не "виноват" — высокая плотность Python сосредоточена в ограниченном числе кодовых баз; вопрос не "какой язык хуже", а "где в вашем портфеле концентрируется серьёзное и какого оно рода"», — пояснили в компании.
Если брать состояние всего объема находок на срез, то исправлено — 33,7%, ожидают разбора — 44,9%, разобрано (получили вердикт) — 21,5%.
Находки в языках программирования. Источник - аналитика AppSec Solutions
Что касается статистики по профилю критичности открытого риска, то на Critical приходится 3,0%, High — 19,7%, Medium — 31,1%, Low — 46,3%. Серьезные (High + Critical) — около 23%, и эта доля остается стабильной.
Распределение по типам анализа выглядит так: собственный код (SAST) — 60,4% открытого риска, сторонние компоненты и зависимости (SCA) — 38,1%, динамический анализ (DAST) — 1,5%. При этом у зависимостей выше концентрация серьезного уровня уязвимостей: доля High + Critical в SCA — 28,0% против 20,6% у SAST.
OWASP Top-10 (доля внутри рейтинга) распределена следующим образом. На контроль доступа (A01 по шкале OWASP) приходится 44% и первое место каждый год начиная с 2023 г. На криптографические сбои (A02) приходится 31%, небезопасный дизайн (A04) — 13%.
Не найти, а разобратьВ AppSec Solutions указывают, что если число находок выросло на 70%, то очередь на их разбор — всего на 18%. С ростом числа уязвимостей совершенствуются и методы борьбы с ними.
Очередь на разбор ИБ-специалистами растет медленнее появления находок и не «тяжелеет». Выросшая пропускная способность разбора успевает перерабатывать приток, поэтому очередь прибавляет медленнее, чем поступают находки. Доля серьезного уровня уязвимостей (High+Critical) в очереди держится около 20% — очередь растет за счет охвата, профиль критичности не ухудшается.
При этом, по оценкам AppSec Solutions, накопленный «технический долг» в самих компаниях может не разбираться и не закрываться годами из-за загруженности инженеров: 69% еще не исправленных находок ждут разбора инженера ИБ — именно это, а не поиск уязвимостей, остается узким местом всего процесса.
«Разбирается и закрывается долг медленно — медианный срок исправления критических находок за год вырос со 103 до 153 дней, а из уязвимостей, уже переданных в разработку, реально закрывается лишь от 12% до 50%», — сообщили в компании.
При этом значительная часть потока — технический шум: до 81–88% первичных вердиктов сканеров оказываются ложными срабатываниями, и этот коридор устойчив все четыре года наблюдений. «Просеивать этот шум вручную — значит тратить дефицитное время инженера ИБ на то, что не является риском», — указали в компании.
Как пояснили в компании, сканеры совершенствуются, но необходимы не только сканеры, а автоматизация приоритезации уязвимостей, экосистемный подход, когда задействованы несколько инструментов безопасности, становится жизненно необходимым. При этом на фоне роста «ИИ-кода», который пишется в 100 раз быстрее и в больших объемах, чем «хэнд-мэйд», эта проблема стоит все острее, добавили в AppSec Solutions.
А вот доля действительно серьезных (High + Critical) уязвимостей годами не меняется и держится в коридоре 20–23% открытого риска, то есть примерно каждая четвертая-пятая находка из тех, что требуют действий сейчас.
«Контроль доступа остается лидирующей категорией среди опасных уязвимостей уже на протяжении многих лет: в рейтинге OWASP Top-10 категория Broken Access Control удерживает первое место каждый год начиная с 2023 г., а ее доля выросла с 41% до 44%», — рассказал руководитель продукта AppSec.Hub компании AppSec Solutions Кирилл Гаранов.
«Накопившийся долг по зависимостям имеет давнюю историю, и значительная его часть носит инфраструктурный характер. При этом единого типового профиля угроз не существует: у одних компаний доля критических находок составляет единицы процентов (около 7%), у других приближается к половине потока (до 50%), а конкретный "портрет" рисков определяется технологическим стеком и составом используемых сканеров. Это означает, что "безопасных" стеков не бывает — у каждого свое уязвимое место», — добавил он.
В AppSec утверждают, что главная задача не «найти больше», а свернуть избыточный поток сырых срабатываний сканеров в обозримый список задач. За полгода наблюдений конвейер платформы сжал 18,7 млн сырых срабатываний до 9,4 тыс. групп задач на исправление — почти в две тысячи раз.
«Путь по воронке нагляден: дедупликация убирает основную массу повторов и сокращает 18,7 млн срабатываний примерно до 428 тыс. уникальных находок — в 43,6 раза, — из которых разбора требуют около 312 тыс. Дальше в дело вступает автоматика», — рассказали в компании.
Авторазбор и ИИАвторазбор стал основным механизмом — и резко сократил время разбора, утверждают в компании. Доля разбора по правилам (в т.ч. ИИ-помощниками) по портфелю выросла с 41% (январь 2025) до 58% (январь 2026) и остается выше половины (52% в мае 2026). Там, где автоматизация созрела, общее время разбора резко упало: в одном наблюдаемом случае медиана снизилась с 20,9 дней (2023) до 0,1–3,8 дней в 2024–2026, в другом — практически до нуля при почти полностью автоматическом разборе. Правило срабатывает мгновенно, а ручной разбор занимает десятки дней.
При этом пропускная способность выросла почти в девять раз. Разобрано за 2024 г. 57 тыс. находок, за 2025 г. уже 518 тыс., а за пять месяцев 2026 г. — еще 268 тыс., прогноз на 2026 — около 610 тыс.
«Платформа переварила массовый онбординг, а не захлебнулась в нем», — констатировали в компании.
К анализу растущего в том числе из-за вайбкодинга объема кода подключают ИИ-помощников. Массовый отсев обеспечивают два механизма — настроенные правила разбора и ИИ-помощник разметки срабатываний. В компании отмечают высокую точность работы ИИ.
«Когда ИИ-помощник помечает находку как ложную, он оказывается прав в 85–100% случаев (на крупнейшей проверенной выборке из около 149 тыс. решений — порядка 97%). На реальных уязвимостях помощник намеренно осторожен, поэтому финальное подтверждение серьезного риска остается за человеком: так, модуль убирает шум, но не заменяет инженера», — рассказали в компании.
В результате доля автоматического разбора по портфелю выросла с 41% в январе 2025 г. до 58% в январе 2026 г. — больше половины первичного разбора закрывается без участия человека, а там, где автоматизация настроена и созрела, правила берут на себя до 86% разбора.
После сжатия и отсева шума инженеру остается кратно меньший и уже упорядоченный поток. Оставшиеся находки приоритизируются: наиболее критические уязвимости поднимаются наверх и первыми передаются в исправление. Связанные находки объединяются в группы корреляции, и, закрывая одну задачу, разработчик закрывает сразу целую группу однотипных уязвимостей. Так «стена алертов» превращается в короткий список действий, а дефицитное время инженера ИБ уходит на реальный риск, а не на просеивание миллионов сырых сигналов.
Мнение экспертовЭксперты указывают, что рост объемов кода, о котором сообщает компания, — это действительно одна из тенденций в отрасли.
Как заявил CNews DevSecOps Lead в coMind, архитекторы AI-Native, Данила Александров, рост настоящий, и он общий для всей индустрии.
«Причина в том, что генерация кода подешевела на порядки: пока строка стоила человеку часов работы, объем сдерживался бюджетом и здравым смыслом, а агенты это ограничение сняли. По свежему отчету Veracode за 2026 г., примерно 44% задач на генерацию кода заканчиваются уязвимостью в результате, и за год этот показатель практически не изменился», — заявил эксперт.
При этом у него есть «две оговорки».
«Первая: строки — грубая метрика объема. Модели переписывают файлы целиком и щедро добавляют шаблонный код, поэтому часть прироста в замерах объясняется самим способом подсчета. Вторая: рост числа срабатываний сканеров еще не значит, что код стал хуже. Свыше 80% потока составляют ложные срабатывания, а доля действительно критичных находок со временем не меняется. На вывод о тренде это не влияет: нагрузка на проверку растет в любом случае», — отметил Данила Александров.
По его словам, вайбкодинг сократил стоимость создания функции до минут, а стоимость ее проверки почти не изменилась, поэтому разрыв между созданным и проверенным кодом растет: по данным Apiiro, разработчики с ИИ-ассистентами пишут в три-четыре раза больше кода, а находок безопасности в нем до десяти раз больше.
«При этом модель не несет ответственности за результат и уверенно воспроизводит типовые ошибки: слабую проверку вводимых данных, небезопасные запросы, ключи доступа, записанные прямо в код. Профессиональная среда отвечает на то же самое иначе: агенты работают в "харнессе", то есть в упряжке из правил, инструкций и методик проверки, а готовый код проходит контроль человека и автоматических анализаторов. Там, где процесс выстроен, объем растет без потери качества», — отметил эксперт.
По словам Данила Александрова, узкое место сместилось с написания кода на его проверку.
«Непроверенные строки попадают в эксплуатацию и расширяют поверхность атаки, а найденные уязвимости копятся в очереди на исправление: специалистов по защите приложений хронически не хватает. По данным Positive Technologies и SuperJob, за 2025 г. число вакансий в информационной безопасности выросло на 26%, хотя рынок вакансий в целом сократился на 13%», — указал эксперт.
По словам специалиста, в сгенерированном коде ошибки к тому же тиражируются: одна типовая уязвимость повторяется в десятках мест, которые писала одна и та же модель. Поэтому безопасность из отдельного этапа перед релизом превращается в часть конвейера: сканирование при каждом изменении, автоматический разбор находок, расстановка приоритетов по реальному риску. Ручной разбор таких объемов уже не масштабируется.
Эксперт добавил, что в его компании код пишут агенты и они же помогают его проверять.
«Разработка идет внутри конвейера с контрольными точками качества: каждое изменение проходит статический анализ (SonarQube, Semgrep и подобные), проверку открытых зависимостей, поиск секретов и ревью, к которому подключается ИИ-агент. Правила безопасности заданы агентам заранее в инструкциях и методиках, поэтому типовые уязвимости отсекаются до того, как код увидит человек. Разбор находок тоже автоматизирован: агент собирает контекст по каждой уязвимости, предлагает вариант исправления и готовит описание для специалиста. Объем кода растет быстрее, чем число экспертов по безопасности, поэтому рутинную часть проверки выполняют машины, а за человеком остаются решения и ответственность», — указал Данила Александров.
Как полагает СЕО сервиса ИИ-разработки Na2ta Solution Натали Антро, раньше одним из ограничителей объема разработки была скорость, с которой человек физически способен написать код. Сейчас этот барьер постепенно исчезает. Один разработчик с ИИ может за то же время написать значительно больше кода, а благодаря вайбкодингу создавать работающие приложения начали и люди, которые раньше вообще не занимались разработкой.
При этом скорость проверки кода не выросла пропорционально скорости его генерации. Поэтому возникает довольно очевидный разрыв: кода становится больше и появляется он быстрее, а его все так же необходимо тестировать, проверять на уязвимости и сопровождать.
«Сам по себе код, написанный с помощью ИИ, не обязательно менее безопасен. Скорее меняется масштаб проблемы. ИИ позволяет очень быстро развивать кодовую базу, но с той же скоростью могут распространяться и ошибки. Неудачное или небезопасное решение, которое раньше осталось бы в одном участке кода, теперь может быть воспроизведено в нескольких компонентах еще до того, как его обнаружат», — констатировала эксперт.
По словам Натали Антро, сейчас ИИ одновременно создает дополнительную нагрузку на AppSec и становится инструментом для ее решения. Автоматизировать можно не только поиск уязвимостей, но и их анализ, приоритизацию, предложение исправлений и генерацию тестов. При этом критические исправления, на ее взгляд, все еще должны проходить независимую автоматическую проверку и, где необходимо, ревью специалиста.
«Таким образом, мы научились производить код быстрее, чем проверять его. Следующим логичным этапом становится такая же масштабная автоматизация контроля качества и безопасности кода», — констатировала эксперт.
«Степень риска сильно зависит от контекста использования. Если мы говорим об Open Source проектах, и правки вносятся исключительно сгенерированным кодом, то все зависит от политик проекта по отношению к контрибьюторам. Например, кто-то прямо просит подписывать ИИ-код, чтобы ревьюер знал об этом. Насмотренность, опыт также позволяют понять, что это вайбкод, если он сложно читается или слишком много сгенерировано одной правкой», — рассказал Казбек Мамакаев, тимлид команды разработки защиты на уровне веб-приложений DDoS-Guard
Если мы говорим про корпоративную среду, то это просто очередное внедрение в качестве инструмента разработчика, которое позволяет минимизировать рутинную механическую работу, считает эксперт. Кодинг — самая объемная по затратам времени, но интеллектуально незначимая часть. Задача программиста — придумать решение. ИИ-агенты же могут забрать на себя рутину в виде написания кода. В конечном счете проводить финальные проверки и принимать решения должен именно человек, констатировал эксперт.
Схожие новости
Классификация: Экономика. Схожих патентов: 0. Схожих новостей: 9. Тональность: 0. Информативность: 11.89. Источник: www.cnews.ru.