Глюк-пакеты: как названия пакетов, придуманные ИИ, становятся угрозой

Помним про старые атаки typosquatting, которые актуальны до сих пор. Typosquatting в разработке - это загрузка в репозиторий вредоносного пакета с именем, похожим на название популярного и уже существующего пакета.

В свежей академической статье авторы проверяли гипотезу, что галюцинации пакетов являются распространенным явлением при генерации кода с использованием больших языковых моделей (LLM), и что это явление представляет собой новую угрозу для цепочки поставок в разработке ПО.

Для проверки этой гипотезы исследователи выполнили три задачи:
1. определили частоту, с которой LLM генерируют несуществующие или ошибочные названия пакетов при генерации кода на Python и JavaScript, и то, как настройки модели влияют на возникновение галлюцинаций;
2. определили повторяемость галлюцинаций;
3. выявили семантические особенности сгенерированных пакетов.

Методика исследования состояла из нескольких этапов. Сначала авторы сгенерировали датасет из входных запросов (промптов) для генерации кода. Затем передали этот набор запросов для каждой из 16 выбранных LLM. И уже на сгенерированном коде применили правила для поиска фрагментов кода, в которых производится подключение сторонних пакетов.

Каждый полученный пакет сравнивался с актуальным списком настоящих пакетов. Если этот пакет отсутствовал в списке, то помечался авторами как галлюцинация. Галлюцинаций накопилось аж 205474 штук. Большинство галлюцинированных названий пакетов не были семантически схожи с существующими популярными пакетами. Это значит, что название глюк-пакета было мало похоже на оригинальное название. То есть, эти названия не являются простыми опечатками.

После изучения исследования у меня остался один вопрос: как злоумышленник может эффективно использовать эту особенность ИИ в своих атаках? Очевидная схема: «нагенерировать» с помощью LLM подобные галлюцинации, и использовать полученный словарь для регистрации вредоносных пакетов. Но далеко не факт, что подобные галлюцинации LLM воспроизведет у разработчика. Поэтому злодею остается стрелять «из пушки по воробьям»: регистрировать как можно больше названий, напоминающих названия для легитимных зависимостей.

Вашей компании нужен герой — и он уже среди ваших разработчиков!
(#соавтор South HUB, Денис Макрушин.)

Если кто-то до сих пор слышит и соглашается с тезисом «безопасность замедляет разработку и душит инновации», то он плохо осознает с какой скоростью двигается прогресс. Раньше управленец C-level в технологической компании мог надеяться, что его бизнес или продукт не будут интересны кибер-преступникам, и они обойдут его стороной. Теперь же, когда злодеи повсеместно используют автоматизацию и регулярно мониторят возможности запрыгнуть в инфраструктуру компании любого масштаба — нельзя надеяться на «да кому я нужен».

Атаки, утечки и различные кибер-инциденты реально тормозят развитие. Иногда останавливают его полностью. Потому что когда «зашифрован прод», а данные клиентов текут в паблик — это не про развитие. А еще, оказывается, что недостаточно завернуть в свой пайплайн все необходимые security-инструменты. Недостаточно даже их правильно настроить и получать только важные результаты их работы.

Как обычно, секретный соус кибербезопасной компании — в ее людях и культуре. Уязвимость всегда проще и дешевле исправлять, когда она обнаружена в IDE разработчика, а не в проде у клиента. Практики и инструменты ИБ нужно двигать «влево» — ближе к началу жизненного цикла системы. Ближе к тому этапу, на которых рождается идея, гипотеза, бизнес-план, дизайн системы. А для этого, нужно понимать “кибербез” на уровне культуры топ-менеджмента и разработки.

В индустрии есть такое термин: Security-чемпион. Это не всегда выделенная роль. Это может быть сотрудник, который прокачивает себя в вопросах ИБ и приземляет экспертизу в своих повседневных задачах. Например, разработчик или тим лид, который понимает риски некачественного кода. CTO, который не ждет, когда появится CISO и принесет контроли в SDLC. CEO и CPO, которые знают, для чего проводить дополнительные security design review.

Чтобы запустить чемпионскую программу в своих командах разработки, нужно предварительно ответить на ключевые вопросы вопроса:
1. Как я создам внутреннюю мотивацию? Что будет драйвить разработчика развиваться в направлении безопасной разработки?
2. Какой ресурс я выделю для реализации программы? Смогу ли обеспечить реальное влияние security-чемпионов на SDLC-процессы?
3. Как буду постоянно развивать и поддерживать сообщество security-чемпионов?

И как только появятся конкретные ответы на эти вопросы, можно будет приступать к тактике. Кстати, отправной точкой для запуска программы может стать вот этот плейбук, подготовленный моим товарищем и поддержанный сообществом OWASP.

Культивируете ли чемпионов в своих командах?

Какие навыки прокачивать, чтобы зайти в кибербез сегодня, и зачем писать код на листке бумаги? 🤔

Новый выпуск подкаста с Денисом Макрушиным, директором по продуктам безопасной разработки в Яндекс , автором канала Makrushin 👨‍🏫

Таймкоды:
00:26 - Денис о своем пути в кибербез, о журнале Хакер и обучении в МИФИ
04:21 - Почему остался в кибербезе после окончания вуза?
07:45 - Формирование аналитического мышления в вузе
09:47 - Путь к преподаванию, аспирантура, специфика деятельности преподавателя
13:37 - Как удается разрабатывать курсы и где находить для этого время?
16:40 - Инструменты для анализа научных статей
19:08 - ИИ заменит программистов
20:49 - ИИ в QA
21:33 - ИИ как напарник программиста
22:29 - Роль системных архитекторов
24:23 - Как сформировать современную программу обучения для программистов?
31:05 - Как преодолеть стереотипы в преподавании?
34:56 - Про формирование системного мышления, организация и коммуникация в процессе обучения
40:14 - Зачем писать код на листке бумаги без ПК?
44:16 - Мотивация преподавателя и язык ассемблера для ИБ сегодня
47:25 - Какие навыки прокачивать, чтобы зайти в кибербез?

👉 Запись также доступна в VK 📺 RuTube 📺 и Яндекс.Музыке 🎵

Дополнительные материалы:
- The Fastest Research Platform Ever

#подкаст

Новая AI-модель для задач кибербезопасности

На прошлой неделе первый поток APPSEC-01 завершил свое обучение и передал эстафету новому потоку. На заключительном вебинаре мы рассмотрели сценарии использования ИИ для задач AppSec-инженера.

Пока мы обменивались идеями, Google опубликовал экспериментальную модель Sec-Gemini, которая предназначена для автоматизации SecOps-процессов. В бенчмарке CTI-RCM (Cybersecurity Threat Intelligence-Root Cause Mapping) эта модель опередила конкурентов. Фреймворк CTI-RCM позволяет оценить способности LLM в задачах определения контекста угроз, поиска связи между угрозой и уязвимостями, которые к ней привели.

Для AppSec-инженера интересна интеграция Sec-Gemini с источником данных об уязвимостях OSV. Теперь можно следить за зависимостями в своем ПО еще тщательнее.

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

Правила для выявления атак небезопасной распаковки архивов

Мы изучали уязвимость Zip Slip в Golang, когда атакующий может загрузить специально сформированный архив и выйти за пределы каталога, в который производится распаковка.

Проект Unsafe Unpacking Research собирает сценарии небезопасной распаковки в разных языках программирования и предлагает соответствующие semgrep-правила для их выявления в коде. Возможно, с помощью этих правил, AppSec-инженер, который уже устал находить в своих рабочих проектах тривиальные уязвимости, сможет разбавить рутину трудовых будней своих разработчиков. 👾

Провинциальный OSINT: определяем место

Обычный пользователь видит просто фото. А что на нем видит OSINT-исследователь?

Фотка сделана на крыше здания, которое расположено где-то на окраине крупного города. Задача: определить страну.

⭐️Задача со звездочкой: определить город.

База симуляций атак и правил для их обнаружения

Кто запускал инструменты симуляции атак, тот знает, насколько они бывают полезными для оценки способностей Blue Team. Автор репозитория AttackRuleMap пробует закрыть пробел между сценариями атак инструмента Atomic Red Team и Sigma-правилами для их обнаружения.

Полезная база, которая пригодится аналитику SOC, чтобы не дожидаться, когда к нему прийдет пентестер или Red Team, а самостоятельно оценить свои возможности.

Безопасная разработка и какие вызовы несет AI

Дубай. Вечер. Глеб рассказывает кому-то из участников CTO Day, почему он не расстается со своей кепкой, на козырьке которой написано . Можно догадаться, что это намек на фронтендерский бэкграунд Глеба, который уже давно с позиции технического директора смотрит на разработку, катит фичи в продукты, и рассказывает о нюансах управления R&D в своем подскасте.

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

⭐ Выпуск доступен на YouTube, ВК, Rutube, Spotify, Apple Podcast, Яндекс.Музыка.

«Спасаем разработчика» на Кавказе

Мы уже рассказывали про атаки на разработчика и изучали уязвимости платформ разработки. Теперь исследуем методы и инструменты защиты конвейера и придумываем автоматизации, которые можно отдать AI-AppSec-инженеру (это тот, который не просит еду, только GPU-ресурсы).

И повод тоже есть: на Кавказе как раз на мероприятии «Код ИБ» собираются директора ИБ, которые смогут приземлить эти идеи в своем бизнесе.

Необычные домены ловят необычные DNS-запросы

Если зарегистрировать домен, который совпадает с названием AWS-инстанса, то можно поймать интересный трафик.

Люблю исследования, в которых автор поднимает ханипот, чтобы собрать в нем аномалии и изучить какие-то неочевидные сценарии атак. Например, можно зарегистировать домен us-east-1.com, который совпадает с названием инстанса AWS us-east-1 и поймать следующие DNS-запросы:

1. от внутренних систем облачного провайдера, которые из-за мисконфигураций обращаются к внешнему ресурсу вместо внутренней инфраструктуры AWS
2. от почтовых security-шлюзов, которые в ответе ожидают какие-либо данные, влияющие на их конфигурацию
3. от сервисов хранения данных, которым также возможно что-то ответить.

Можно поймать не только DNS-запросы, но и внутренние автоматические почтовые рассылки от других AWS-систем. Эти письма также могут раскрыть информацию о конфигурации инфры.

Если бы домен us-east-1.com контролировал злодей, то он мог бы собирать интересную информацию о внутренних ресурсах и использовать ее для рассылки фишинга, в котором подготовил бы ссылку на вредоносную копию AWS Console.

Архитектор безопасности, проверь, что твои внутренние ресурсы не ходят по сторонним доменам.

На охоту за когнитивным топливом ❄️

Дневник DevSec #2: когнитивное топливо

Оказывается, что продукт должен спасать разработчика не только от угроз, но и от других продуктов. Если спросить appsec-инженера, работающего в какой-нибудь BigTech-компании, сколько инструментов он использует в работе, то он перечислит десяток утилит. Коммерческих и опенсорс. Если быть точнее: 16 инструментов.

Представь, что твой рабочий день начинается с изучения дашборда, в котором накопились уязвимости. Тебе нужно убедиться, что эти уязвимости не дублируются, имеют правильный приоритет. Затем разобраться в причинах возникновения каждой приоритетной баги. Для этого, нужно пробежать марафон по нескольким разным инструментам с разным контекстом. После того, как этот этап завершен, нужно пробежать новый марафон по другим инструментам, чтобы уже исправить обнаруженные проблемы или передать их разработчику. Когнитивное изнасилование.

Когнитивная нагрузка - одна из ключевых, неочевидных метрик,которая меняется при добавлении нового инструмента в рабочий процесс. В некоторых исследованиях эта метрика описана как когнитивные затраты на принятие решений.

Представим, что у нас в рамках рабочего дня есть определенный запас когнитивного топлива - ресурса, который тратится на выполнение задачи, принятие каких-либо решений, переключение контекста между задачами, пролистывание ленты в соц сети. Когнитивное топливо безопасника уходит на анализ статистики, триажинг уязвимостей, их исправление, изучение вайтпейперов и TI-репортов. Ему не нужен еще один продукт с информативным интерфейсом и «без ложных срабатываний». Ему в принципе не нужен еще один источник срабатываний, когда есть 16 других.

AppSec-инженер хочет построить процесс, автоматизировать его и больше не тратить свое когнитивное топливо.

Алгоритмы автономного поиска уязвимостей

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

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

1. Сбор контекста о приложении.
2. Генерация промежуточного представления в виде AST, чтобы лучше оценивать контекст и повысить точность анализа. Из AST можно получить граф вызовов, который упрощает навигацию по коду приложения.
3. Обогащение графа дополнительным контекстом, например, HTTP-методами и состоянием механизмов аутентификации и авторизации.
4. Поиск уязвимостей и их валидация. Вот тут самое интересное: авторы применяют свой фреймворк Tree of Thoughts (ToT), который основан на “цепочке мыслей” (Chain of Thoughts, CoT). То есть шаг за шагом модель рассуждает об уязвимости, разбивая сложную задачу на последовательность более простых логических шагов.

Фреймворк ToT дает цепочку решений, и уже эта цепочка передается в алгоритм самоулучшения дерева Монте-Карло. Основа успеха в применении этого алгоритма - четко определенная и описанная “функция победы”. Функция определяет, является ли текущее состояние в дереве поиска выигрышным, проигрышным или нейтральным. И эта функция становится еще одним объектом рассуждения для LLM.

LLM рассуждает о функции победы 👉 LLM рассуждает о способах достижения этой победы 👉 LLM собирает контекст исполнения для этих способов 👉 Исследователь собирает деньги на покупку видеокарт 😎

Ежегодные антифишинг-тренинги неэффективны

А еще:
* не выявлено существенной связи между недавним прохождением обучения и вероятностью успеха фишинга;
* существующие программы повышения осведомленности имеют низкую практическую ценность для снижения риска фишинг-атак (риск снижается всего на 1.7%);
* значительная часть пользователей (56%), которые прошли обучение, кликнули на фишинговую ссылку. Ну бывает, сначала прокликаешь слайды в тренинге, а затем прокликаешь все фишинговые ссылки 🙃

Такие выводы можно сделать после изучения результатов исследования, в котором 19500 сотрудников в течение 8 месяцев получали фишинговые письма. Можно с этим не согласиться, но точно следует обратить внимание на то, как авторы предлагают повысить эффективность тренингов:
⭐️ повышать интерактивность тренингов и увеличивать степень вовлеченности пользователей;
⭐️ разрабатывать персонализированные сценарии, которые учитывают контекст пользователя;
⭐️ вместо формального «механического» прохождения тренинга, развивать «культуру безопасности», в которой пользователь осознанно оценивает риски.

Инструмент для поиска проблем в GitHub Actions CI/CD

Изучили сценарии атак, в которых можно закрепиться в GitHub Actions, выполнить произвольный код и извлечь секреты. Ознакомились с рекомендациями от OWASP по защите процессов CI/CD. Поняли, что значительная часть этих рекомендаций отдается на откуп разработчику. Но все же нашли инструмент, который поможет ему выявить значительную часть уязвимостей.

В правилах для выявления есть сигнатуры для основных проблем:

* внедрение шаблонов для выполнения произвольного кода в процессе CI/CD;
* утечка секретов;
* избыточные права для GitHub Runners;
* Actions с существующими известными уязвимостями.

Еще один статический анализатор в нашем пайплайне. Кстати, сигнатуры можно адаптировать к другим платформам разработки.

Дневник DevSec: спасти разработчика

Представим: у нас стоит задача придумать продукт, который должен спасти разработчика, и при этом он должен не мешать ему создавать. “Не мешать” - это одно из ключевых требований к ИБ-решениям. Заменим это требование: “он должен ускорять процесс разработки”.

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

На рынке Application Security существует достаточное количество продуктовых категорий, которые решают одну и ту же задачу, но с разных сторон. Создавать еще одно решение - риск потратить ресурс. Только если результат не будет кардинально менять расстановку сил на поле “attack-defense”. Поэтому уточним задачу: разработать продукт, который спасет разработчика, и который будет эффективно использовать уже имеющуюся технологическую базу.

Эффективно - это значит, мы не будем собирать новые велосипеды, если старые еще работают. Мы будем добавлять инкрементальные изменения в существующие знания и подходы. Как минимум, нам предстоит разобраться во всех этих велосипедах.

Платформы вроде ASPM решают задачу эффективности, собирая под капотом актуальные appsec-технологии и добавляя инкремент: снижают шум от всех этих продуктов. И все же это не решает основную задачу: не тратить внимание разработчика на исправление security-проблем.

Мир движется к автономным и самовосстанавливающимся системам. Autonomous и self-healing в задачах кибербезопасности идут рука об руку. Например, недавно DARPA (то самое агентство, которое создало ARPANET) объявило грант на разработку self-healing системы для защиты прошивок. То есть DARPA предложила пересмотреть фундаментальные принципы защиты на уровне компьютерной шины.

Аналогичным образом для решения нашей задачи потребуется еще раз посмотреть на фундаментальные принципы безопасности в разработке приложений.

Один год вместе с LLM в кибербезопасности: как ИИ менял индустрию

В 2024 году большие языковые модели (LLM) кардинально изменили многие сферы, включая кибербезопасность. LLM научились не только помогать в поиске уязвимостей, но и предлагать их исправления. От симуляции атак и анализа уязвимостей до создания правил детектирования — LLM постепенно становятся незаменимым инструментом для разработчиков и специалистов по безопасной разработке.

В этой статье разберём, какие инновации принесли LLM в кибербезопасность, выделим инсайты и ключевые технологические ограничения, с которыми будем разбираться в 2025 году.

APPSEC-01

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

Первое занятие начинаем с целеполагания. Каждый отвечает себе на вопросы: “зачем я собираюсь инвестировать свой ресурс в обучение и как представляю образ результата?”.

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

1. Kali Linux с утилитами для анализа поверхности атаки
2. OWASP Juice Shop для знакомства с наиболее распространенными уязвимостями (OWASP Top 10)
3. OWASP Zap или Burp Suite в качестве прокси.

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

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

🎁 Еще один security-день, и три подарка для новых подписчиков, которые только начинают свой путь в кибербезопасности

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

Если ты читаешь это сообщение, то знаешь, что информационная безопасность сегодня — критический навык для каждого профессионала в IT. Независимо от текущей позиции, постоянное совершенствование компетенций в области кибербезопасности становится не просто преимуществом, а профессиональной необходимостью. Гигиеническим навыком.

Вместе с командой мы собрали три ценных материала, которые помогут:
🟢Определить карьерные треки и ключевые навыки для роста в AppSec, DevSecOps и security-исследованиях.
🟢Научиться находить и устранять потенциальные уязвимости в разработке.
🟢Заложить основу для работы в ИБ, даже если вы только начинаете.

Вот, чем мы делимся:
1️⃣Лекция — «Кто такой исследователь безопасности и как им стать»
✅ Понять, какие навыки необходимы для карьерного роста в кибербезопасности и, в частности, стать security-исследователем. Разобраться, как проводить исследования, генерировать гипотезы, с чего начинать процесс и как готовить результаты.

2️⃣Гайдлайн по проведению исследований
✅ Используя пошаговую инструкцию с теорией и практическими примерами, научиться строить проекты по исследованиям угроз и поиску уязвимостей, а также разрабатывать эффективные методы защиты.

3️⃣ Исследование GitHub: 1300 уязвимых репозиториев
✅ На конкретном примере разобраться, чем атаки на цепочки поставок опасны для разработчиков и компаний и как защитить свои проекты от этих угроз.

Чтобы забрать материалы — не забудь подписаться на канал, и нажимай кнопку для получения контента 👇