Генеративный ИИ повышает производительность разработки. Или нет?
В одном из комментариев в моем канале в Сетке появился вопрос: “а как вы измеряете эффективность разработки?”. Вспомню ключевой тезис в дискуссии CTO Day: измеряем бизнес-результатами и скоростью выпуска новых бизнес-функций в продукте.
Встретил свежую исследовательскую работу, в которой утверждается, что использование инструментов с ИИ увеличивает производительность разработчика на 26,08%. Значит, в этой работе должны быть метрики производительности и эффективности.
Методика исследования:
* три рандомизированных контролируемых эксперимента в реальных условиях на примере трех компаний (Microsoft, Accenture, анонимная компания из списка Fortune 100). В процессе эксперимента разработчикам был случайным образом предоставлен доступ к GitHub Copilot, либо они попадали в контрольную группу без доступа.
* Анализ данных проводился с использованием двухшагового метода наименьших квадратов (2SLS). Оценки 2SLS взвешивались по разнице в использовании между экспериментальной и контрольной группами за период.
* Для оценки влияния инструмента на производительность разработчиков использовались такие показатели, как количество выполненных pull request, количество коммитов кода и количество сборок кода, а также показатели использования Copilot, такие как количество предложений и количество принятых предложений.
Вот оно! Pull request, количество коммитов кода и количество сборок — ключевые показатели для оценки. Какие есть ограничения при оценке этих метрик:
* высокая вариативность в результатах, поскольку на производительность разработчиков влияет их опыт, навыки и типы выполняемых задач. Принцип распределения разработчиков на кластеры в данном эксперименте непрозрачен.
* Эксперименты проводились в реальных рабочих условиях, где на производительность разработчиков могли влиять различные факторы, не поддающиеся контролю, например, изменения в проектах или командные взаимодействия.
Действительно ли в количестве pull requests измеряется производительность разработки — вопрос все еще открытый.
В одном из комментариев в моем канале в Сетке появился вопрос: “а как вы измеряете эффективность разработки?”. Вспомню ключевой тезис в дискуссии CTO Day: измеряем бизнес-результатами и скоростью выпуска новых бизнес-функций в продукте.
Встретил свежую исследовательскую работу, в которой утверждается, что использование инструментов с ИИ увеличивает производительность разработчика на 26,08%. Значит, в этой работе должны быть метрики производительности и эффективности.
Методика исследования:
* три рандомизированных контролируемых эксперимента в реальных условиях на примере трех компаний (Microsoft, Accenture, анонимная компания из списка Fortune 100). В процессе эксперимента разработчикам был случайным образом предоставлен доступ к GitHub Copilot, либо они попадали в контрольную группу без доступа.
* Анализ данных проводился с использованием двухшагового метода наименьших квадратов (2SLS). Оценки 2SLS взвешивались по разнице в использовании между экспериментальной и контрольной группами за период.
* Для оценки влияния инструмента на производительность разработчиков использовались такие показатели, как количество выполненных pull request, количество коммитов кода и количество сборок кода, а также показатели использования Copilot, такие как количество предложений и количество принятых предложений.
Вот оно! Pull request, количество коммитов кода и количество сборок — ключевые показатели для оценки. Какие есть ограничения при оценке этих метрик:
* высокая вариативность в результатах, поскольку на производительность разработчиков влияет их опыт, навыки и типы выполняемых задач. Принцип распределения разработчиков на кластеры в данном эксперименте непрозрачен.
* Эксперименты проводились в реальных рабочих условиях, где на производительность разработчиков могли влиять различные факторы, не поддающиеся контролю, например, изменения в проектах или командные взаимодействия.
Действительно ли в количестве pull requests измеряется производительность разработки — вопрос все еще открытый.
👍4❤1🐳1
Атаки на GitHub-разработчика в 2024 году
Тренд «Platform Engineering» стал интересен не только компаниям, которые трансформируют свои процессы, команды и инструменты согласно новым подходам. Этот тренд также интересует и злоумышленников, которые используют возможности платформ разработки для проведения атак.
В этой статье я собрал коллекцию интересных уязвимостей и методов атак на пользователей крупной платформы разработки, обзор актуальных методов атак, выявленных в 2024 году. Понимание актуальных угроз позволяет лучше разобраться в необходимости улучшения практик безопасности в такой платформе на примере GitHub. Материал будет полезен как разработчикам, так и специалистам по информационной безопасности для защиты своих проектов.
Тренд «Platform Engineering» стал интересен не только компаниям, которые трансформируют свои процессы, команды и инструменты согласно новым подходам. Этот тренд также интересует и злоумышленников, которые используют возможности платформ разработки для проведения атак.
В этой статье я собрал коллекцию интересных уязвимостей и методов атак на пользователей крупной платформы разработки, обзор актуальных методов атак, выявленных в 2024 году. Понимание актуальных угроз позволяет лучше разобраться в необходимости улучшения практик безопасности в такой платформе на примере GitHub. Материал будет полезен как разработчикам, так и специалистам по информационной безопасности для защиты своих проектов.
👍3🔥2
Технологии AutoFix: исправление 2/3 багов с первой попытки
Вендоры крупных платформ разработки и стартапы с разной степенью успеха создают технологию AutoFix. В ее основе находятся LLM, которые анализируют уязвимость и ее контекст, а затем предлагают вариант ее исправления. Насколько хорошо у них это получается можно судить по текущим результатам:
* наиболее “зрелые” модели LLM способны исправить примерно 2/3 всех обнаруженных уязвимостей с первой попытки, но использование пользовательских подсказок позволяет улучшить этот результат;
* коммерческие и открытые модели имеют схожие показатели производительности при разной стоимости эксплуатации.
То есть, использовать Autofix можно, но внедрять исправленный код в прод без дополнительной верификации нужно аккуратнее. Например, исправление проблемы, связанной со слабым шифрованием или использованием небезопасных протоколов, может привести к сбоям в работе приложения.
Есть и другие ограничения:
* сложности с зависимостями и импортами: модели часто не могут правильно обработать сложные зависимости и импорты в кодовой базе. Например, когда LLM предлагает переписать код для использования методов безопасной сериализации, но не предлагает импортировать библиотеку для этой задачи.
* LLM могут предлагать новые зависимости для проекта, которые могут принести новые уязвимости в этот проект;
* недостаточный контекст: модели часто предлагают исправления, которые не соответствуют шаблонам проектирования или общей архитектуре проекта.
С учётом этих ограничений, разработчики технологий AutoFix используют пользовательские подсказки вместе с большим контекстом о коде. Пользователь может указать предпочтительные библиотеки (например, для логирования, алгоритмов шифрования и генерации случайных чисел).
Помимо инструкций от пользователя, увеличить точность ответов помогает механизм повторных попыток. LLM генерирует несколько исправлений для одной и той же уязвимости и таким образом увеличивает шансы на получение правильного варианта.
Вендоры крупных платформ разработки и стартапы с разной степенью успеха создают технологию AutoFix. В ее основе находятся LLM, которые анализируют уязвимость и ее контекст, а затем предлагают вариант ее исправления. Насколько хорошо у них это получается можно судить по текущим результатам:
* наиболее “зрелые” модели LLM способны исправить примерно 2/3 всех обнаруженных уязвимостей с первой попытки, но использование пользовательских подсказок позволяет улучшить этот результат;
* коммерческие и открытые модели имеют схожие показатели производительности при разной стоимости эксплуатации.
То есть, использовать Autofix можно, но внедрять исправленный код в прод без дополнительной верификации нужно аккуратнее. Например, исправление проблемы, связанной со слабым шифрованием или использованием небезопасных протоколов, может привести к сбоям в работе приложения.
Есть и другие ограничения:
* сложности с зависимостями и импортами: модели часто не могут правильно обработать сложные зависимости и импорты в кодовой базе. Например, когда LLM предлагает переписать код для использования методов безопасной сериализации, но не предлагает импортировать библиотеку для этой задачи.
* LLM могут предлагать новые зависимости для проекта, которые могут принести новые уязвимости в этот проект;
* недостаточный контекст: модели часто предлагают исправления, которые не соответствуют шаблонам проектирования или общей архитектуре проекта.
С учётом этих ограничений, разработчики технологий AutoFix используют пользовательские подсказки вместе с большим контекстом о коде. Пользователь может указать предпочтительные библиотеки (например, для логирования, алгоритмов шифрования и генерации случайных чисел).
Помимо инструкций от пользователя, увеличить точность ответов помогает механизм повторных попыток. LLM генерирует несколько исправлений для одной и той же уязвимости и таким образом увеличивает шансы на получение правильного варианта.
❤2👍2🔥2💯1
Выпускной: инсайты четвертой сессии на факультете стратегического управления
Собрал заметки на полях и ключевые мысли четвертой заключительной сессии в программе MBA:
⭐️ Навык управления энергией важнее навыка управления временем.
В очередной раз эта мысль прозвучала сразу в нескольких учебных модулях.
⭐️ В модуле «Актерское мастерство для менеджера» поймал такую цитату:
Важно уметь анализировать обстоятельства, классифицировать их по группам факторов и в зависимости от этого определять сценарий.
Например, сценарий ведения переговоров. И это следующее открытие.
⭐️ Как и в кинематографе, у переговорного процесса есть свой сюжет и есть свои «шаблоны проектирования».
Цели переговоров, сформулированные по SMART, делятся на две группы: must-цели, wish-цели. Достижение первых определяет успех переговоров. Достижение вторых — степень этого успеха.
На основе данных целей формируется дерево принятия решений — то есть возможные сценарии. Подобная формализация переговорного процесса делает его более предсказуемым и контролируемым для «режиссера».
Пожалуй, план подготовки к переговорам — это ключевой инсайт этого семестра, который я вынес из модуля «Техника ведения переговоров».
Записал эту мысль в модуле «Управление знаниями», чтобы позже подробнее изучить подходы и исследования, связанные с концепцией «Adaptive Space». Они лежат в основе трансформации крупных компаний. Возможно, что-то из этих подходов окажется полезным и для личной трансформации.
Пусть 2025 год принесет больше адаптивного пространства для исследований, создания и обсуждения гипотез. А если не принесет — создадим его сами.
С наступающим Новым Годом!
Собрал заметки на полях и ключевые мысли четвертой заключительной сессии в программе MBA:
В очередной раз эта мысль прозвучала сразу в нескольких учебных модулях.
«Задача лидера — создавать избыток энергии»
«Менеджер — это режиссер, который в предлагаемых обстоятельствах организует управление вниманием»
Важно уметь анализировать обстоятельства, классифицировать их по группам факторов и в зависимости от этого определять сценарий.
Например, сценарий ведения переговоров. И это следующее открытие.
Цели переговоров, сформулированные по SMART, делятся на две группы: must-цели, wish-цели. Достижение первых определяет успех переговоров. Достижение вторых — степень этого успеха.
На основе данных целей формируется дерево принятия решений — то есть возможные сценарии. Подобная формализация переговорного процесса делает его более предсказуемым и контролируемым для «режиссера».
Пожалуй, план подготовки к переговорам — это ключевой инсайт этого семестра, который я вынес из модуля «Техника ведения переговоров».
⭐️
«Потенциал лидера определяется количеством и качеством его последователей»
⭐️
«Нужно создавать адаптивное пространство — зону, где есть возможность исследовать, оспаривать идеи»
Записал эту мысль в модуле «Управление знаниями», чтобы позже подробнее изучить подходы и исследования, связанные с концепцией «Adaptive Space». Они лежат в основе трансформации крупных компаний. Возможно, что-то из этих подходов окажется полезным и для личной трансформации.
Пусть 2025 год принесет больше адаптивного пространства для исследований, создания и обсуждения гипотез. А если не принесет — создадим его сами.
С наступающим Новым Годом!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19🔥8🏆3❤1🤷1
Стою, жду, когда праздники закончатся 🙃
Чтобы рассказать сразу несколько новостей:
* Для авторской колонки в “Хакере” подготовил обзор перспективных исследований за 2024 год, которые точно нужно изучить, а результаты — применить в своих проектах уже в этом году. Есть что почитать на выходных.
* Опубликовал ключевые инсайты, которые накопил за период обучения на программе MBA в Президентской Академии.
* Вместе с командой завершили запись всех лекций курса по безопасности приложений и подготовились к запуску первого потока. Просто пока ждем, когда праздники закончатся.
Чтобы рассказать сразу несколько новостей:
* Для авторской колонки в “Хакере” подготовил обзор перспективных исследований за 2024 год, которые точно нужно изучить, а результаты — применить в своих проектах уже в этом году. Есть что почитать на выходных.
* Опубликовал ключевые инсайты, которые накопил за период обучения на программе MBA в Президентской Академии.
* Вместе с командой завершили запись всех лекций курса по безопасности приложений и подготовились к запуску первого потока. Просто пока ждем, когда праздники закончатся.
🔥11👍3😁1🤣1
Makrushin
Вместе с командой завершили запись всех лекций курса по безопасности приложений и подготовились к запуску
Суббота - хороший повод запустить что-нибудь. Например, авторский курс, который мы готовили с командой МГТУ им. Баумана и о котором я уже рассказывал.
В этот раз расскажу о процессе его подготовки. В цифрах:
* 24 недели от идеи до результата
* 314 слайдов и 12 студийных сессий для их записи
* 8 участников команды, которые отвечали за верстку и дизайн, запись и производство видео, составление учебной программы и клиентский опыт, разработку лендига, маркетинг и координацию всего проекта.
* курс лег в основу двух программ подготовки магистров в области ИБ. А значит, свободно доступен для студентов и выпускников НИЯУ МИФИ и МГТУ им Баумана.
Если среди моих подписчиков есть представители ВУЗов, которые хотят интегрировать этот контент в свои образовательные программы - пишите. Контакт для связи в описании группы.
В этот раз расскажу о процессе его подготовки. В цифрах:
* 24 недели от идеи до результата
* 314 слайдов и 12 студийных сессий для их записи
* 8 участников команды, которые отвечали за верстку и дизайн, запись и производство видео, составление учебной программы и клиентский опыт, разработку лендига, маркетинг и координацию всего проекта.
* курс лег в основу двух программ подготовки магистров в области ИБ. А значит, свободно доступен для студентов и выпускников НИЯУ МИФИ и МГТУ им Баумана.
Если среди моих подписчиков есть представители ВУЗов, которые хотят интегрировать этот контент в свои образовательные программы - пишите. Контакт для связи в описании группы.
🔥17😁3👍2
Как раскрасить граф активности любому пользователю GitHub
Любой пользователь GitHub может нарисовать себе «граффити» на своем графе активности. А еще он может сделать это на графе другого пользователя. Для этого должны быть выполнены три условия:
1. Пользователь, чей граф будет раскрашен, должен открыть issue или сделать push кода в репозиторий, в который у другого пользователя (назовем его «редиска») также есть возможность сделать push или принять pull request.
2. Этот репозиторий не должен быть форком.
3. Редиска должен знать email, который пользователь использовал при регистрации.
Эта уязвимость возникает из-за некорректной проверки email, который указан в git-коммите, и email пользователя. Если два email совпадают, то GitHub отображает коммит на графике активности.
Эту проблему уже используют не только редиски, но и исследователи, которые рисуют граффити в аккаунтах злодеев.
Любой пользователь GitHub может нарисовать себе «граффити» на своем графе активности. А еще он может сделать это на графе другого пользователя. Для этого должны быть выполнены три условия:
1. Пользователь, чей граф будет раскрашен, должен открыть issue или сделать push кода в репозиторий, в который у другого пользователя (назовем его «редиска») также есть возможность сделать push или принять pull request.
2. Этот репозиторий не должен быть форком.
3. Редиска должен знать email, который пользователь использовал при регистрации.
Эта уязвимость возникает из-за некорректной проверки email, который указан в git-коммите, и email пользователя. Если два email совпадают, то GitHub отображает коммит на графике активности.
Эту проблему уже используют не только редиски, но и исследователи, которые рисуют граффити в аккаунтах злодеев.
🔥7👍2😁2🤔2🙏1
Обзор перспективных исследований 2024 года
Результаты и идеи, полученные из чужого исследовательского опыта — незаменимый инструмент в арсенале security-инженера. Понимать новые поверхности атак, способы повышения наблюдаемости событий, внедрять инновационные инструменты — всё это супер-сила исследователя и ключевые элементы для построения эффективной стратегии защиты.
Давай разберем отчеты, чтобы понять, что можно применить прямо сейчас, а что требует дальнейшего изучения.
Результаты и идеи, полученные из чужого исследовательского опыта — незаменимый инструмент в арсенале security-инженера. Понимать новые поверхности атак, способы повышения наблюдаемости событий, внедрять инновационные инструменты — всё это супер-сила исследователя и ключевые элементы для построения эффективной стратегии защиты.
Давай разберем отчеты, чтобы понять, что можно применить прямо сейчас, а что требует дальнейшего изучения.
Denis Makrushin
Advanced Research Review 2024 · Denis Makrushin
Let’s talk about last year’s perspective research. Researchers have gathered a wealth of interesting material. Let’s go through the reports to see what can be applied in practice and what…
👍4🔥2
Adversary-in-the-Middle: эволюция фишинга
В новом материале для авторской колонки рассказал про актуальные инструменты проведения фишинга, в эпоху средств мультифакторной аутентификации. О том, как технологии AitM (Adversary-in-the-Middle) меняют процессы социотехнического тестирования, и почему кража пароля - больше не основная задача атакующего.
В новом материале для авторской колонки рассказал про актуальные инструменты проведения фишинга, в эпоху средств мультифакторной аутентификации. О том, как технологии AitM (Adversary-in-the-Middle) меняют процессы социотехнического тестирования, и почему кража пароля - больше не основная задача атакующего.
xakep.ru
Adversary-in-the-Middle: эволюция фишинга. Колонка Дениса Макрушина
Типичный сценарий социотехнического пентеста: собрал список корпоративных email-адресов, настроил инструмент для проведения фишинговых рассылок, провел рассылку, получил учетные данные сотрудников для доступа в корпоративную инфраструктуру.
👍2
Иногда нам надо снова вспоминать, что мы тут делаем и знакомиться друг с другом. Особенно с теми, кто недавно к нам присоединился. Меня зовут Денис Макрушин, и здесь я рассказываю про кибербезопасность, технологии и людей.
Если ты читаешь это сообщение, то знаешь, что информационная безопасность сегодня — критический навык для каждого профессионала в IT. Независимо от текущей позиции, постоянное совершенствование компетенций в области кибербезопасности становится не просто преимуществом, а профессиональной необходимостью. Гигиеническим навыком.
Вместе с командой мы собрали три ценных материала, которые помогут:
Вот, чем мы делимся:
Чтобы забрать материалы — не забудь подписаться на канал, и нажимай кнопку для получения контента
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥5⚡2😁2❤1
This media is not supported in your browser
VIEW IN TELEGRAM
APPSEC-01
Сегодня первый поток курса Безопасность Приложений начинает свое обучение.
Первое занятие начинаем с целеполагания. Каждый отвечает себе на вопросы: “зачем я собираюсь инвестировать свой ресурс в обучение и как представляю образ результата?”.
Затем, после знакомства с процессом обучения, знакомимся друг с другом и разворачиваем тестовый стенд для анализа защищенности, чтобы освоить инструменты. Для тех, кто хочет повторить упражнение, набор стандартный:
1. Kali Linux с утилитами для анализа поверхности атаки
2. OWASP Juice Shop для знакомства с наиболее распространенными уязвимостями (OWASP Top 10)
3. OWASP Zap или Burp Suite в качестве прокси.
Кстати, в блогах исследователей все чаще встречаю скриншоты интерфейса caido, который пытается подвинуть Burp на рынке. Если кто-то уже использует его для своих задач - поделитесь опытом.
Для тех, кто откладывал решение о начале обучения на последний момент, мы продлили возможность записаться в первый поток до 15 февраля.
Сегодня первый поток курса Безопасность Приложений начинает свое обучение.
Первое занятие начинаем с целеполагания. Каждый отвечает себе на вопросы: “зачем я собираюсь инвестировать свой ресурс в обучение и как представляю образ результата?”.
Затем, после знакомства с процессом обучения, знакомимся друг с другом и разворачиваем тестовый стенд для анализа защищенности, чтобы освоить инструменты. Для тех, кто хочет повторить упражнение, набор стандартный:
1. Kali Linux с утилитами для анализа поверхности атаки
2. OWASP Juice Shop для знакомства с наиболее распространенными уязвимостями (OWASP Top 10)
3. OWASP Zap или Burp Suite в качестве прокси.
Кстати, в блогах исследователей все чаще встречаю скриншоты интерфейса caido, который пытается подвинуть Burp на рынке. Если кто-то уже использует его для своих задач - поделитесь опытом.
Для тех, кто откладывал решение о начале обучения на последний момент, мы продлили возможность записаться в первый поток до 15 февраля.
🔥7👍6❤1✍1🤔1🥱1💯1🤣1
Один год вместе с LLM в кибербезопасности: как ИИ менял индустрию
В 2024 году большие языковые модели (LLM) кардинально изменили многие сферы, включая кибербезопасность. LLM научились не только помогать в поиске уязвимостей, но и предлагать их исправления. От симуляции атак и анализа уязвимостей до создания правил детектирования — LLM постепенно становятся незаменимым инструментом для разработчиков и специалистов по безопасной разработке.
В этой статье разберём, какие инновации принесли LLM в кибербезопасность, выделим инсайты и ключевые технологические ограничения, с которыми будем разбираться в 2025 году.
В 2024 году большие языковые модели (LLM) кардинально изменили многие сферы, включая кибербезопасность. LLM научились не только помогать в поиске уязвимостей, но и предлагать их исправления. От симуляции атак и анализа уязвимостей до создания правил детектирования — LLM постепенно становятся незаменимым инструментом для разработчиков и специалистов по безопасной разработке.
В этой статье разберём, какие инновации принесли LLM в кибербезопасность, выделим инсайты и ключевые технологические ограничения, с которыми будем разбираться в 2025 году.
Denis Makrushin
Один год вместе с LLM в кибербезопасности: как ИИ менял индустрию · Denis Makrushin
В 2024 году большие языковые модели (LLM) кардинально изменили многие сферы, включая кибербезопасность. LLM научились не только помогать в поиске уязвимостей, но и предлагать их исправления. От симуляции атак и анализа уязвимостей до создания правил детектирования —…
👍5❤2🔥2👏1
Дневник DevSec: спасти разработчика
Представим: у нас стоит задача придумать продукт, который должен спасти разработчика, и при этом он должен не мешать ему создавать. “Не мешать” - это одно из ключевых требований к ИБ-решениям. Заменим это требование: “он должен ускорять процесс разработки”.
Мы изучили атаки и убедились, что проблемы могут прилететь из разных мест в конвейере: начиная от атак на сам пайплайн и заканчивая конкретными библиотеками, которые используются в кодовой базе.
На рынке Application Security существует достаточное количество продуктовых категорий, которые решают одну и ту же задачу, но с разных сторон. Создавать еще одно решение - риск потратить ресурс. Только если результат не будет кардинально менять расстановку сил на поле “attack-defense”. Поэтому уточним задачу: разработать продукт, который спасет разработчика, и который будет эффективно использовать уже имеющуюся технологическую базу.
Эффективно - это значит, мы не будем собирать новые велосипеды, если старые еще работают. Мы будем добавлять инкрементальные изменения в существующие знания и подходы. Как минимум, нам предстоит разобраться во всех этих велосипедах.
Платформы вроде ASPM решают задачу эффективности, собирая под капотом актуальные appsec-технологии и добавляя инкремент: снижают шум от всех этих продуктов. И все же это не решает основную задачу: не тратить внимание разработчика на исправление security-проблем.
Мир движется к автономным и самовосстанавливающимся системам. Autonomous и self-healing в задачах кибербезопасности идут рука об руку. Например, недавно DARPA (то самое агентство, которое создало ARPANET) объявило грант на разработку self-healing системы для защиты прошивок. То есть DARPA предложила пересмотреть фундаментальные принципы защиты на уровне компьютерной шины.
Аналогичным образом для решения нашей задачи потребуется еще раз посмотреть на фундаментальные принципы безопасности в разработке приложений.
Представим: у нас стоит задача придумать продукт, который должен спасти разработчика, и при этом он должен не мешать ему создавать. “Не мешать” - это одно из ключевых требований к ИБ-решениям. Заменим это требование: “он должен ускорять процесс разработки”.
Мы изучили атаки и убедились, что проблемы могут прилететь из разных мест в конвейере: начиная от атак на сам пайплайн и заканчивая конкретными библиотеками, которые используются в кодовой базе.
На рынке Application Security существует достаточное количество продуктовых категорий, которые решают одну и ту же задачу, но с разных сторон. Создавать еще одно решение - риск потратить ресурс. Только если результат не будет кардинально менять расстановку сил на поле “attack-defense”. Поэтому уточним задачу: разработать продукт, который спасет разработчика, и который будет эффективно использовать уже имеющуюся технологическую базу.
Эффективно - это значит, мы не будем собирать новые велосипеды, если старые еще работают. Мы будем добавлять инкрементальные изменения в существующие знания и подходы. Как минимум, нам предстоит разобраться во всех этих велосипедах.
Платформы вроде ASPM решают задачу эффективности, собирая под капотом актуальные appsec-технологии и добавляя инкремент: снижают шум от всех этих продуктов. И все же это не решает основную задачу: не тратить внимание разработчика на исправление security-проблем.
Мир движется к автономным и самовосстанавливающимся системам. Autonomous и self-healing в задачах кибербезопасности идут рука об руку. Например, недавно DARPA (то самое агентство, которое создало ARPANET) объявило грант на разработку self-healing системы для защиты прошивок. То есть DARPA предложила пересмотреть фундаментальные принципы защиты на уровне компьютерной шины.
Аналогичным образом для решения нашей задачи потребуется еще раз посмотреть на фундаментальные принципы безопасности в разработке приложений.
👍10❤3👏2💯2
Инструмент для поиска проблем в GitHub Actions CI/CD
Изучили сценарии атак, в которых можно закрепиться в GitHub Actions, выполнить произвольный код и извлечь секреты. Ознакомились с рекомендациями от OWASP по защите процессов CI/CD. Поняли, что значительная часть этих рекомендаций отдается на откуп разработчику. Но все же нашли инструмент, который поможет ему выявить значительную часть уязвимостей.
В правилах для выявления есть сигнатуры для основных проблем:
* внедрение шаблонов для выполнения произвольного кода в процессе CI/CD;
* утечка секретов;
* избыточные права для GitHub Runners;
* Actions с существующими известными уязвимостями.
Еще один статический анализатор в нашем пайплайне. Кстати, сигнатуры можно адаптировать к другим платформам разработки.
Изучили сценарии атак, в которых можно закрепиться в GitHub Actions, выполнить произвольный код и извлечь секреты. Ознакомились с рекомендациями от OWASP по защите процессов CI/CD. Поняли, что значительная часть этих рекомендаций отдается на откуп разработчику. Но все же нашли инструмент, который поможет ему выявить значительную часть уязвимостей.
В правилах для выявления есть сигнатуры для основных проблем:
* внедрение шаблонов для выполнения произвольного кода в процессе CI/CD;
* утечка секретов;
* избыточные права для GitHub Runners;
* Actions с существующими известными уязвимостями.
Еще один статический анализатор в нашем пайплайне. Кстати, сигнатуры можно адаптировать к другим платформам разработки.
👍5🔥3👏2💯1
Ежегодные антифишинг-тренинги неэффективны
А еще:
* не выявлено существенной связи между недавним прохождением обучения и вероятностью успеха фишинга;
* существующие программы повышения осведомленности имеют низкую практическую ценность для снижения риска фишинг-атак (риск снижается всего на 1.7%);
* значительная часть пользователей (56%), которые прошли обучение, кликнули на фишинговую ссылку. Ну бывает, сначала прокликаешь слайды в тренинге, а затем прокликаешь все фишинговые ссылки🙃
Такие выводы можно сделать после изучения результатов исследования, в котором 19500 сотрудников в течение 8 месяцев получали фишинговые письма. Можно с этим не согласиться, но точно следует обратить внимание на то, как авторы предлагают повысить эффективность тренингов:
⭐️ повышать интерактивность тренингов и увеличивать степень вовлеченности пользователей;
⭐️ разрабатывать персонализированные сценарии, которые учитывают контекст пользователя;
⭐️ вместо формального «механического» прохождения тренинга, развивать «культуру безопасности», в которой пользователь осознанно оценивает риски.
А еще:
* не выявлено существенной связи между недавним прохождением обучения и вероятностью успеха фишинга;
* существующие программы повышения осведомленности имеют низкую практическую ценность для снижения риска фишинг-атак (риск снижается всего на 1.7%);
* значительная часть пользователей (56%), которые прошли обучение, кликнули на фишинговую ссылку. Ну бывает, сначала прокликаешь слайды в тренинге, а затем прокликаешь все фишинговые ссылки
Такие выводы можно сделать после изучения результатов исследования, в котором 19500 сотрудников в течение 8 месяцев получали фишинговые письма. Можно с этим не согласиться, но точно следует обратить внимание на то, как авторы предлагают повысить эффективность тренингов:
Please open Telegram to view this post
VIEW IN TELEGRAM
👻6😁4✍2👏2👍1🤔1😱1💯1
Алгоритмы автономного поиска уязвимостей
Пока готовился к заключительному модулю, в котором разбираем сценарии использования LLM в appsec-задачах, встретил еще одно успешное внедрение ИИ для поиска уязвимостей.
В прошлом году мы изучили результаты работ, в которых система смогла самостоятельно определить категорию уязвимости и даже пробовала их эксплуатировать. В этот раз исследователи интегрировали анализ исполнения программы с агентами, которые подключаются на каждом отдельном этапе атаки:
1. Сбор контекста о приложении.
2. Генерация промежуточного представления в виде AST, чтобы лучше оценивать контекст и повысить точность анализа. Из AST можно получить граф вызовов, который упрощает навигацию по коду приложения.
3. Обогащение графа дополнительным контекстом, например, HTTP-методами и состоянием механизмов аутентификации и авторизации.
4. Поиск уязвимостей и их валидация. Вот тут самое интересное: авторы применяют свой фреймворк Tree of Thoughts (ToT), который основан на “цепочке мыслей” (Chain of Thoughts, CoT). То есть шаг за шагом модель рассуждает об уязвимости, разбивая сложную задачу на последовательность более простых логических шагов.
Фреймворк ToT дает цепочку решений, и уже эта цепочка передается в алгоритм самоулучшения дерева Монте-Карло. Основа успеха в применении этого алгоритма - четко определенная и описанная “функция победы”. Функция определяет, является ли текущее состояние в дереве поиска выигрышным, проигрышным или нейтральным. И эта функция становится еще одним объектом рассуждения для LLM.
LLM рассуждает о функции победы 👉 LLM рассуждает о способах достижения этой победы 👉 LLM собирает контекст исполнения для этих способов 👉 Исследователь собирает деньги на покупку видеокарт😎
Пока готовился к заключительному модулю, в котором разбираем сценарии использования LLM в appsec-задачах, встретил еще одно успешное внедрение ИИ для поиска уязвимостей.
В прошлом году мы изучили результаты работ, в которых система смогла самостоятельно определить категорию уязвимости и даже пробовала их эксплуатировать. В этот раз исследователи интегрировали анализ исполнения программы с агентами, которые подключаются на каждом отдельном этапе атаки:
1. Сбор контекста о приложении.
2. Генерация промежуточного представления в виде AST, чтобы лучше оценивать контекст и повысить точность анализа. Из AST можно получить граф вызовов, который упрощает навигацию по коду приложения.
3. Обогащение графа дополнительным контекстом, например, HTTP-методами и состоянием механизмов аутентификации и авторизации.
4. Поиск уязвимостей и их валидация. Вот тут самое интересное: авторы применяют свой фреймворк Tree of Thoughts (ToT), который основан на “цепочке мыслей” (Chain of Thoughts, CoT). То есть шаг за шагом модель рассуждает об уязвимости, разбивая сложную задачу на последовательность более простых логических шагов.
Фреймворк ToT дает цепочку решений, и уже эта цепочка передается в алгоритм самоулучшения дерева Монте-Карло. Основа успеха в применении этого алгоритма - четко определенная и описанная “функция победы”. Функция определяет, является ли текущее состояние в дереве поиска выигрышным, проигрышным или нейтральным. И эта функция становится еще одним объектом рассуждения для LLM.
LLM рассуждает о функции победы 👉 LLM рассуждает о способах достижения этой победы 👉 LLM собирает контекст исполнения для этих способов 👉 Исследователь собирает деньги на покупку видеокарт
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9⚡4❤2🍌1
Дневник DevSec #2: когнитивное топливо
Оказывается, что продукт должен спасать разработчика не только от угроз, но и от других продуктов. Если спросить appsec-инженера, работающего в какой-нибудь BigTech-компании, сколько инструментов он использует в работе, то он перечислит десяток утилит. Коммерческих и опенсорс. Если быть точнее: 16 инструментов.
Представь, что твой рабочий день начинается с изучения дашборда, в котором накопились уязвимости. Тебе нужно убедиться, что эти уязвимости не дублируются, имеют правильный приоритет. Затем разобраться в причинах возникновения каждой приоритетной баги. Для этого, нужно пробежать марафон по нескольким разным инструментам с разным контекстом. После того, как этот этап завершен, нужно пробежать новый марафон по другим инструментам, чтобы уже исправить обнаруженные проблемы или передать их разработчику. Когнитивное изнасилование.
Когнитивная нагрузка - одна из ключевых, неочевидных метрик,которая меняется при добавлении нового инструмента в рабочий процесс. В некоторых исследованиях эта метрика описана как когнитивные затраты на принятие решений.
Представим, что у нас в рамках рабочего дня есть определенный запас когнитивного топлива - ресурса, который тратится на выполнение задачи, принятие каких-либо решений, переключение контекста между задачами, пролистывание ленты в соц сети. Когнитивное топливо безопасника уходит на анализ статистики, триажинг уязвимостей, их исправление, изучение вайтпейперов и TI-репортов. Ему не нужен еще один продукт с информативным интерфейсом и «без ложных срабатываний». Ему в принципе не нужен еще один источник срабатываний, когда есть 16 других.
AppSec-инженер хочет построить процесс, автоматизировать его и больше не тратить свое когнитивное топливо.
Оказывается, что продукт должен спасать разработчика не только от угроз, но и от других продуктов. Если спросить appsec-инженера, работающего в какой-нибудь BigTech-компании, сколько инструментов он использует в работе, то он перечислит десяток утилит. Коммерческих и опенсорс. Если быть точнее: 16 инструментов.
Представь, что твой рабочий день начинается с изучения дашборда, в котором накопились уязвимости. Тебе нужно убедиться, что эти уязвимости не дублируются, имеют правильный приоритет. Затем разобраться в причинах возникновения каждой приоритетной баги. Для этого, нужно пробежать марафон по нескольким разным инструментам с разным контекстом. После того, как этот этап завершен, нужно пробежать новый марафон по другим инструментам, чтобы уже исправить обнаруженные проблемы или передать их разработчику. Когнитивное изнасилование.
Когнитивная нагрузка - одна из ключевых, неочевидных метрик,которая меняется при добавлении нового инструмента в рабочий процесс. В некоторых исследованиях эта метрика описана как когнитивные затраты на принятие решений.
Представим, что у нас в рамках рабочего дня есть определенный запас когнитивного топлива - ресурса, который тратится на выполнение задачи, принятие каких-либо решений, переключение контекста между задачами, пролистывание ленты в соц сети. Когнитивное топливо безопасника уходит на анализ статистики, триажинг уязвимостей, их исправление, изучение вайтпейперов и TI-репортов. Ему не нужен еще один продукт с информативным интерфейсом и «без ложных срабатываний». Ему в принципе не нужен еще один источник срабатываний, когда есть 16 других.
AppSec-инженер хочет построить процесс, автоматизировать его и больше не тратить свое когнитивное топливо.
🤣6👍5🔥3💯2
На охоту за когнитивным топливом ❄️
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15👏5🤨2😎1
Необычные домены ловят необычные DNS-запросы
Если зарегистрировать домен, который совпадает с названием AWS-инстанса, то можно поймать интересный трафик.
Люблю исследования, в которых автор поднимает ханипот, чтобы собрать в нем аномалии и изучить какие-то неочевидные сценарии атак. Например, можно зарегистировать домен us-east-1.com, который совпадает с названием инстанса AWS us-east-1 и поймать следующие DNS-запросы:
1. от внутренних систем облачного провайдера, которые из-за мисконфигураций обращаются к внешнему ресурсу вместо внутренней инфраструктуры AWS
2. от почтовых security-шлюзов, которые в ответе ожидают какие-либо данные, влияющие на их конфигурацию
3. от сервисов хранения данных, которым также возможно что-то ответить.
Можно поймать не только DNS-запросы, но и внутренние автоматические почтовые рассылки от других AWS-систем. Эти письма также могут раскрыть информацию о конфигурации инфры.
Если бы домен us-east-1.com контролировал злодей, то он мог бы собирать интересную информацию о внутренних ресурсах и использовать ее для рассылки фишинга, в котором подготовил бы ссылку на вредоносную копию AWS Console.
Архитектор безопасности, проверь, что твои внутренние ресурсы не ходят по сторонним доменам.
Если зарегистрировать домен, который совпадает с названием AWS-инстанса, то можно поймать интересный трафик.
Люблю исследования, в которых автор поднимает ханипот, чтобы собрать в нем аномалии и изучить какие-то неочевидные сценарии атак. Например, можно зарегистировать домен us-east-1.com, который совпадает с названием инстанса AWS us-east-1 и поймать следующие DNS-запросы:
1. от внутренних систем облачного провайдера, которые из-за мисконфигураций обращаются к внешнему ресурсу вместо внутренней инфраструктуры AWS
2. от почтовых security-шлюзов, которые в ответе ожидают какие-либо данные, влияющие на их конфигурацию
3. от сервисов хранения данных, которым также возможно что-то ответить.
Можно поймать не только DNS-запросы, но и внутренние автоматические почтовые рассылки от других AWS-систем. Эти письма также могут раскрыть информацию о конфигурации инфры.
Если бы домен us-east-1.com контролировал злодей, то он мог бы собирать интересную информацию о внутренних ресурсах и использовать ее для рассылки фишинга, в котором подготовил бы ссылку на вредоносную копию AWS Console.
Архитектор безопасности, проверь, что твои внутренние ресурсы не ходят по сторонним доменам.
🔥8👍6👻3👏1
«Спасаем разработчика» на Кавказе
Мы уже рассказывали про атаки на разработчика и изучали уязвимости платформ разработки. Теперь исследуем методы и инструменты защиты конвейера и придумываем автоматизации, которые можно отдать AI-AppSec-инженеру (это тот, который не просит еду, только GPU-ресурсы).
И повод тоже есть: на Кавказе как раз на мероприятии «Код ИБ» собираются директора ИБ, которые смогут приземлить эти идеи в своем бизнесе.
Мы уже рассказывали про атаки на разработчика и изучали уязвимости платформ разработки. Теперь исследуем методы и инструменты защиты конвейера и придумываем автоматизации, которые можно отдать AI-AppSec-инженеру (это тот, который не просит еду, только GPU-ресурсы).
И повод тоже есть: на Кавказе как раз на мероприятии «Код ИБ» собираются директора ИБ, которые смогут приземлить эти идеи в своем бизнесе.
❤🔥4👍3👏2