Всем привет!

Сделал для вас анализ ключевых положений нового крутого отчета Github с точки зрения безопасности.

Меня зовут Василий Пластунов и я люблю делать анализ тенденций которые повлияют на работу как обычных безопасников так и на вопросы управления безопасностью в крупных компаниях. В анализе мне помогает мой 15+ летний опыт в безопасности на позициях от инженера до директора по ИБ крупных компаний.

На случай, если ты не часто пользуешься Github:
1.Github это облачная платформа для создания, хранения и управления исходным кодом. Свыше 180 миллионов разработчиков добавили туда свой код в более чем 500 млн проектов. Есть открытые репозитории доступные для всех, например для opensource, а есть приватные доступные только работникам определенных компаний. При этом больше 80% всех вкладов (contibutions) относятся к приватным репозиториям, в этом году таких вкладов стало 5 миллиардов.
2. Octoverse — это отчет Github про статистику, тенденции и выводы по итогу произошедшего на платформе за 1 год. Funfact - в названии отчета игра слов, кроме того что он обычно выходит в октябре, в названии отчета отсылка на маскота Github Осьминогокошку Мону.

Почему отчет Github важен даже если вы используете внутри компании свой вариант Git:

1. В разработке ты используешь opensource который выложен на githab.

2. Ты или твои коллеги выкладывают туда свои Pet проекты.

3. Иногда компании выкладывают в опенсорс часть своих коммерческих продуктов, даже продуктов в области безопасности. Последний такой случай как раз в конце октября произошел .

4. Shit happens - иногда разработчики выкладывают для своего портфолио часть своего кода над которым он работал в твоей компании. Хорошо если это оказывается приватный репозиторий =). Печально, если открытый репозиторий, ещё печальнее если в коде оказываются пароли, ключи или приватные токены.

Вот ссылочка на сам отчет вышедший 28.10.2025.

Красной нитью через весь отчет проходит ИИ и те изменения которые он повлек в разработке кода. От запуска github в конце 2024 бесплатного тарифа Copilot (ИИ помощник помогающий дописывать код) до структурных изменений. Давайте проанализируем их подробнее.

1. Генеративный ИИ — новый стандарт в разработке

80% новых пользователей Github используют Copilot в первую неделю. Более чем в 1 млн репозиториев используется LLM SDK. 6 из 10 самых быстрорастущих репозиториев Github это инфраструктурные проекты для ИИ.

Что это означает для безопасности
Если вы не держите руку на пульсе вашей разработки, самое время понять как вы (не)используете ИИ для написания кода критичных проектов вашей компании.

На что нужно обратить внимание:

1. Какие инструменты и интеграции используются.

2. Могут ли быть в промтах разработчиков защищаемые данные, если да — есть ли у вас инструменты для анализа и фильтрации промтов? Особенно это актуально, если компания активно использует внешние инструменты ИИ разработки Copilot, Cursor, Claude и т. д. Очевидная вещь, но все же - использоваться могут не только веб версии ИИ инструментов, но и API, интеграции вашего git и плагины в IDE или браузерах типа Kilo Code. 3.Если ваша компания активно использует свои инструменты ИИ разработки или внешние — самое время задуматься над созданием дополнений в системный промт для своих инструментов или внешних. Например можно описать требования к безопасности генерируемого кода для основных ваших языков и фреймворков. Пример таких правил.

3. Если в вашей компании практикуется такой концепт как вайбкодинг, то дополнение промтов для вас должно стать важным инструментом безопаности.

Другим примером использования ИИ для безопасности кода может являться новый агент aardvark OpenAI для поиска и исправления ошибок в коде (текущее состояние - закрытая бета). OpenAI уже нашло с помощью него десяток CVE в опенсорсе.

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

2.Typescript обогнал Python и JavaScript

В августе 2025 года Typescript стали чаще использовать чем Python и JavaScript, по оценке Github, это наиболее сильное изменение за последние 10 лет. Основная причина этого, что с типизированными языками ИИ-инструменты совершают меньше ошибок. Теперь каждый фреймворк фронтэнда использует Typescipt по умолчанию (Next.js 15, Astro 3, SvelteKit 2, Qwik, SolidStart, Angular 18, and Remix). По оценке, 94% ошибок при компиляции ИИ кода вызваны не верным определением типа переменной.
Пара слов о Typescipt. Typescipt это высокоуровневый язык программирования обратно совместимый с Javascipt. Первый релиз языка состоялся в 2012 году. Как пишет вики «TypeScript отличается от JavaScript возможностью явного статического назначения типов, поддержкой использования полноценных классов (как в традиционных объектно-ориентированных языках), а также поддержкой подключения модулей, что призвано повысить скорость разработки, облегчить читаемость, рефакторинг и повторное использование кода, помочь осуществлять поиск ошибок на этапе разработки и компиляции, и, возможно, ускорить выполнение программ».

Что это означает для безопасности

1. Самое время или самому или члену вашей команды безопасности изучить основы программирования на Typescript.

2. Провести встречу апсеков\чемпионов безопасной разработки на тему почему для ИИ инструментов лучше использовать Typescipt.

3. ИИ влияет не только на скорость кода

Github отмечает, что если раньше важным выбор разработчика был выбор среды разработки, языка или фреймворка, то теперь использование ИИ влияет на используемые языки и инструменты, а следовательно и на безопасность.

4. Больше всего новых разработчиков из Азиатско-Тихоокеанского региона (APAC)

Количество новых разработчиков из Азии больше чем из Европы, Африки, Латинской Америк вместе взятых.
С точки зрения безопасности это означает ещё больший поток кода требующий базовых проверок на безопасность.

5. Тетрадки Юпитера (Jupyter Notebooks) и докер файлы перешли на следующий уровень зрелости

Количество репозиториев с тетрадками юпитера увеличилось на 75% процентов до 2,4 млн. Отчет отмечает, что тетрадки теперь это зрелый инструмент для экспериментов.
Количество репозиториев с докерфайлами увеличилось на 125% до 1,9 млн. Рост был, вероятно, вызван необходимостью запуска агентов и моделей независимо и относительно безопасно - в отдельной песочнице.
Самое время проверить, а есть ли у вас рекомендации по безопасности для тетрадок и докер-файлов и не опубликован ли в интернет с дефолтными кредами и интеграциями ваш Юпитер.

6. Количество найденных уязвимостей «сломанный контроль доступа» опередило количество «инъекция»

С начала 2025 года количество репозиториев с уязвимостью типа Broken access control выросло, примерно, в 3,5 раза, а с начала 2024 года в 7 раз (!), достигнув, по состоянию на август 2025 года, цифры в 151 000 репозиториев.
Далее в отчете делается предположение, что авторизация и аутентификация остаются сложными проблемами для ИИ и разработчиков, при этом на представленном графике количество репозиториев с уязвимостью «идентификация и аутентификация» с начала 2025 года даже немного уменьшилось (до около 3000-4000 репозиториев).
Согласно отчету, инъекции остаются главной проблемой для Javascript. Тогда как Broken access control остается главным типом уязвимости для Python, Go, Java и С++, языков, где вайбкодинг создает внешне корректные эндпойнты, но в которых отсутствует проверка аутентификации.
На основе графика можно сделать анализ, что значительно выросли количество репозиториев с типом уязвимости «небезопасный дизайн» (примерно в 2,5 раза), «security misconfiguration» (примерно в 2 раза), «security logging and monitoring» (примерно в 3 раза), “cryptographic failures” (примерно в 1,5 раза).

Что это означает для безопасности

1. Github ищет уязвимости с помощью cвоего открытого инструмента CodeQL, над использованием которого наряду с использованием SAST вам нужно подумать.

2. Так как контекст в ИИ моделях часто ограничен, для MVP "Анализ кода на безопасность ИИ" можно как раз ограничится правилами\промтами для Broken access control.

3. Ваша следующая коммуникация с чемпионами и апсеками должна быть посвящена типу уязвимости "Broken access control"

Больше графиков и статистики указано в отчете, если какая то из затронутых тем вам показалась интересной — напишите, пожалуйста, в комментарии, остановлюсь на ней подробнее.

Буду благодарен если сможете поделится в комментариях своими успехами по использованию ИИ для написания кода или для анализа кода на безопасность.