Насколько хорошо ИИ анализирует код, написанный им же?
Всем привет!
Автор статьи работает в Greptile, которая занимается разработкой агента для AI Code Review.
В процессе работы ему стало интересно, влияет ли используемая модель на то, сколько недостатков находится?
Или, если проще, насколько хороши модели в анализе кода, который написан ими же?
Для этого он подготовил данные и методологию:
🍭 Собрал данные из 500 PR, которые были написаны с использованием Claude Code и Codex
🍭 «Авторство» модели определялось через данные, получаемые из commit, названий PR и/или веток
🍭 Подготовил перечень дефектов, которые были в этих 500 PR
🍭 Запустил Codex и Claude Code в
🍭 «Почистил» результаты от комментариев, которые относились к «стилистике» и не являлись дефектами
Что получилось? Оказалось, что модели лучше ищут ошибки в коде, который написан другими моделями.
Разрыв не очень большой, но всё же присутствует.
Ещё одним интересным наблюдением оказалось то, что модель скорее всего допустит ошибку при разработке, которую она скорее всего пропустит в review.
Помимо этого, в статье есть ещё много интересного. Включая дефекты, которые находились при «рассуждениях», но пропадали из «финального вердикта».
Всем привет!
Автор статьи работает в Greptile, которая занимается разработкой агента для AI Code Review.
В процессе работы ему стало интересно, влияет ли используемая модель на то, сколько недостатков находится?
Или, если проще, насколько хороши модели в анализе кода, который написан ими же?
Для этого он подготовил данные и методологию:
🍭 Собрал данные из 500 PR, которые были написаны с использованием Claude Code и Codex
🍭 «Авторство» модели определялось через данные, получаемые из commit, названий PR и/или веток
🍭 Подготовил перечень дефектов, которые были в этих 500 PR
🍭 Запустил Codex и Claude Code в
/review 3 раза🍭 «Почистил» результаты от комментариев, которые относились к «стилистике» и не являлись дефектами
Что получилось? Оказалось, что модели лучше ищут ошибки в коде, который написан другими моделями.
Разрыв не очень большой, но всё же присутствует.
Ещё одним интересным наблюдением оказалось то, что модель скорее всего допустит ошибку при разработке, которую она скорее всего пропустит в review.
Помимо этого, в статье есть ещё много интересного. Включая дефекты, которые находились при «рассуждениях», но пропадали из «финального вердикта».
Greptile
Models are worse at reviewing their own code | Greptile Blog
We noticed GPT reviewed Claude's code better than its own, and vice versa. So we ran a thousand buggy PRs through both models to find out why.
❤4🤡1
DSO2026_DD.pdf
4.1 MB
State of DevSecOps 2026
Всем привет!
В приложении можно скачать отчёт от Datadog (~23 страницы), посвященный состоянию DevSecOps.
Для подготовки отчёта команда проанализировала результаты, генерируемые Datadog Code Security’s Software Composition Analysis.
В итоге получилось следующее:
🍭 87% организаций «обладают» хотя бы одной эксплуатируемой уязвимостью
🍭 Обновления библиотек занимают длительное время (медиана – «отставание» на 278 дней от самой новой major-версии)
🍭 Только 18% критичных уязвимостей остаются такими после уточнения базовой CVSS-оценки
🍭 32% организаций использовали публичные Docker образы через день после выхода новой версии
🍭 Аналогичное характерно и для JS и Python – 55%
Ничего революционного, ещё одно подтверждение того, что атаки на цепочку поставок сейчас занимают крайне объёмное место и важно уметь с ними работать.
В завершении отчёта можно найти набор общих рекомендаций о том, как можно повысить уровень защищенности при работе с open-source компонентами, цепочкой поставки и т.д.
Всем привет!
В приложении можно скачать отчёт от Datadog (~23 страницы), посвященный состоянию DevSecOps.
Для подготовки отчёта команда проанализировала результаты, генерируемые Datadog Code Security’s Software Composition Analysis.
В итоге получилось следующее:
🍭 87% организаций «обладают» хотя бы одной эксплуатируемой уязвимостью
🍭 Обновления библиотек занимают длительное время (медиана – «отставание» на 278 дней от самой новой major-версии)
🍭 Только 18% критичных уязвимостей остаются такими после уточнения базовой CVSS-оценки
🍭 32% организаций использовали публичные Docker образы через день после выхода новой версии
🍭 Аналогичное характерно и для JS и Python – 55%
Ничего революционного, ещё одно подтверждение того, что атаки на цепочку поставок сейчас занимают крайне объёмное место и важно уметь с ними работать.
В завершении отчёта можно найти набор общих рекомендаций о том, как можно повысить уровень защищенности при работе с open-source компонентами, цепочкой поставки и т.д.
❤3
Конфигурация сети в Linux: практика
Всем привет!
По ссылке доступна лабораторная работа от Iximiuz Labs(Ivan Velichko), в которой придётся поработать с настройкой сети Linux-хостов.
Условия простые: есть 2 сервера в одной сети. На одном – Ubuntu, на втором Rocky Linux. Надо проанализировать их конфигурацию и ответить на вопросы.
Примеры вопросов:
🍭 Какие названия у основных сетевых интерфейсов
🍭 IPv4/MAC-адреса рабочих станций
🍭 IPv4 адрес шлюза по умолчанию
🍭 Через какой интерфейс пакеты отправляются на указанный адрес и т.д.
Да, задания достаточно базовые, но! Это те знания, которые точно пригодятся, ведь без понимания работы сетей – никуда. И если вы начинаете с этим работать, то лабораторные – то, что надо.
Для запуска не требуется ничего устанавливать, всё доступно непосредственно на сайте в интерактивной «площадке».
P.S. Помимо этой лабораторной, на labs.iximiuz.com можно найти ещё очень много всего интересного – рекомендуем!
Всем привет!
По ссылке доступна лабораторная работа от Iximiuz Labs(Ivan Velichko), в которой придётся поработать с настройкой сети Linux-хостов.
Условия простые: есть 2 сервера в одной сети. На одном – Ubuntu, на втором Rocky Linux. Надо проанализировать их конфигурацию и ответить на вопросы.
Примеры вопросов:
🍭 Какие названия у основных сетевых интерфейсов
🍭 IPv4/MAC-адреса рабочих станций
🍭 IPv4 адрес шлюза по умолчанию
🍭 Через какой интерфейс пакеты отправляются на указанный адрес и т.д.
Да, задания достаточно базовые, но! Это те знания, которые точно пригодятся, ведь без понимания работы сетей – никуда. И если вы начинаете с этим работать, то лабораторные – то, что надо.
Для запуска не требуется ничего устанавливать, всё доступно непосредственно на сайте в интерактивной «площадке».
P.S. Помимо этой лабораторной, на labs.iximiuz.com можно найти ещё очень много всего интересного – рекомендуем!
iximiuz Labs
Inspect Network Interfaces, IP Addresses, and Routes on a Linux Host | Challenge
Practice reading the network configuration of Linux hosts: find interface names, IP and MAC addresses, the default gateway, and detect which routes a server uses to reach different destinations.
❤4
WIZ_CC_CS.pdf
6.2 MB
Claude Code: Security Best Practices
Всем привет!
Небольшой пятничный пост!
В приложении можно найти документ (~ 7 страниц), подготовленный Wiz и посвященный вопросам безопасности при работе с Claude Code.
Cheat Sheet содержит разделы:
🍭 Prompt Hygiene and Data Handling. Что (не) надо писать в prompt
🍭 Secure Code Generation. Рекомендации о том, как получить более безопасный код при его генерации
🍭 Supply Chain Attacks. Проверки на slopsquatting, работа с lockfile
🍭 Access Control. Ограничение возможностей агента, его полномочий и доступа к чувствительным данным
Каждый раздел содержит Action Item, в котором даются вполне конкретные советы и примеры того, как можно и нужно делать.
В завершение приводится небольшой перечень лучших практик по работе с агентами, MCP, встраиванию проверок в CI.
Ёмко, лаконично и по делу ☺️
Всем привет!
Небольшой пятничный пост!
В приложении можно найти документ (~ 7 страниц), подготовленный Wiz и посвященный вопросам безопасности при работе с Claude Code.
Cheat Sheet содержит разделы:
🍭 Prompt Hygiene and Data Handling. Что (не) надо писать в prompt
🍭 Secure Code Generation. Рекомендации о том, как получить более безопасный код при его генерации
🍭 Supply Chain Attacks. Проверки на slopsquatting, работа с lockfile
🍭 Access Control. Ограничение возможностей агента, его полномочий и доступа к чувствительным данным
Каждый раздел содержит Action Item, в котором даются вполне конкретные советы и примеры того, как можно и нужно делать.
В завершение приводится небольшой перечень лучших практик по работе с агентами, MCP, встраиванию проверок в CI.
Ёмко, лаконично и по делу ☺️
❤5👍2💩1
Patch The Planet
Всем привет!
В интернете можно найти много статей, в которых описано, что «классический» подход к управлению уязвимостями перестаёт работать.
В том числе это связано с развитием ИИ.
Уязвимостей находят больше, быстрее, формирование exploit’ов сократилось с месяцев/недель до часов.
Чтобы хоть как-то изменить/улучшить ситуацию OpenAI объединили усилия с Trail of Bits и реализовали инициативу Patch The Planet.
Её суть в том, чтобы, используя передовые AI модели и экспертный опыт людей, находить уязвимости и создавать обновления в ПО для их устранения.
Т.е. maintainer’ы не просто получают «У вас уязвимость, вот так воспроизвести», а полноценные рекомендации по устранению. Команда Patch The Planet активно работает с проектами и помогает тем, кто их разрабатывает.
В статье можно прочесть о том, как это примерно работает, какие проекты уже вошли в инициативу, какие ИБ-практики применяются.
А если вам хочется посмотреть на результаты, то рекомендуем обратить внимание на Patch The Planet Dashboard, в котором всё наглядно видно.
Всем привет!
В интернете можно найти много статей, в которых описано, что «классический» подход к управлению уязвимостями перестаёт работать.
В том числе это связано с развитием ИИ.
Уязвимостей находят больше, быстрее, формирование exploit’ов сократилось с месяцев/недель до часов.
Чтобы хоть как-то изменить/улучшить ситуацию OpenAI объединили усилия с Trail of Bits и реализовали инициативу Patch The Planet.
Её суть в том, чтобы, используя передовые AI модели и экспертный опыт людей, находить уязвимости и создавать обновления в ПО для их устранения.
Т.е. maintainer’ы не просто получают «У вас уязвимость, вот так воспроизвести», а полноценные рекомендации по устранению. Команда Patch The Planet активно работает с проектами и помогает тем, кто их разрабатывает.
В статье можно прочесть о том, как это примерно работает, какие проекты уже вошли в инициативу, какие ИБ-практики применяются.
А если вам хочется посмотреть на результаты, то рекомендуем обратить внимание на Patch The Planet Dashboard, в котором всё наглядно видно.
OpenAI
Patch the Planet: a Daybreak initiative to support open source maintainers
OpenAI introduces Patch the Planet, a Daybreak initiative helping open-source maintainers find, validate, and fix vulnerabilities with AI and expert review.
KubeBuddy: анализ ресурсов Kubernetes
Всем привет!
KubeBuddy – CLI-утилита, которая анализирует общее состояние кластера как со стороны ИТ, так и со стороны ИБ.
Реализованы проверки для:
🍭 Статусов узлов, потребления ресурсов, состояния
🍭 Идентификации
🍭 Выявления небезопасных привилегий в RBAC
🍭 Хранилищ, сервисов, сетевых политик и не только
В результате работы KubeBuddy генерирует отчёт в одном из форматов на выбор: HTML, Text, CSV.
А если вы используете Headlamp, то у KubeBuddy есть плагин, который позволяет отображать результаты его работы непосредственно в UI.
Больше информации о возможностях утилиты, способах отображения информации, запуске, настройке и проверках можно найти в GitHub-репозитории проекта или в официальной документации.
Всем привет!
KubeBuddy – CLI-утилита, которая анализирует общее состояние кластера как со стороны ИТ, так и со стороны ИБ.
Реализованы проверки для:
🍭 Статусов узлов, потребления ресурсов, состояния
pod🍭 Идентификации
pod с ошибками, перезапусками🍭 Выявления небезопасных привилегий в RBAC
🍭 Хранилищ, сервисов, сетевых политик и не только
В результате работы KubeBuddy генерирует отчёт в одном из форматов на выбор: HTML, Text, CSV.
А если вы используете Headlamp, то у KubeBuddy есть плагин, который позволяет отображать результаты его работы непосредственно в UI.
Больше информации о возможностях утилиты, способах отображения информации, запуске, настройке и проверках можно найти в GitHub-репозитории проекта или в официальной документации.
GitHub
GitHub - KubeDeckio/KubeBuddy: KubeBuddy - A Kubernetes scanning CLI for cluster health, security, RBAC, networking, workload,…
KubeBuddy - A Kubernetes scanning CLI for cluster health, security, RBAC, networking, workload, and configuration checks. Supports AKS and GKE best-practice checks, risk-path analysis, Headlamp int...
k8s_fin_svc.pdf
12.6 MB
Kubernetes Architecture in Financial Services
Всем привет!
В приложении можно найти электронную книгу (~ 169 страниц) от Авторов небезызвестного ресурса LearnKube.
Она посвящена нюансам, с которыми можно столкнуться при работе с Kubernetes в компаниях финансового сектора(да и не только, просто примеры из «того мира») .
Книга состоит из 7 глав:
🍭 Where Does the Tenant Boundary Belong?
🍭 One Delivery Path, Many Applications
🍭 Make Policy Enforceable and Exceptions Visible
🍭 Trust Across Service Boundaries
🍭 Healthy Components, Failing Requests
🍭 Reconstruct the Service's Dependencies
🍭 Replace the Runtime, Preserve the Service
Каждая глава описывает некоторую проблематику (например, как именно управлять разграничением доступа, управлением ресурсами и т.д.) и возможные пути решения.
Самое интересное – что это не просто синтетические данные или теоретические размышления на тему, а реальные проблемы реальных компаний финансового сектора.
Всем привет!
В приложении можно найти электронную книгу (~ 169 страниц) от Авторов небезызвестного ресурса LearnKube.
Она посвящена нюансам, с которыми можно столкнуться при работе с Kubernetes в компаниях финансового сектора
Книга состоит из 7 глав:
🍭 Where Does the Tenant Boundary Belong?
🍭 One Delivery Path, Many Applications
🍭 Make Policy Enforceable and Exceptions Visible
🍭 Trust Across Service Boundaries
🍭 Healthy Components, Failing Requests
🍭 Reconstruct the Service's Dependencies
🍭 Replace the Runtime, Preserve the Service
Каждая глава описывает некоторую проблематику (например, как именно управлять разграничением доступа, управлением ресурсами и т.д.) и возможные пути решения.
Самое интересное – что это не просто синтетические данные или теоретические размышления на тему, а реальные проблемы реальных компаний финансового сектора.
🔥2
DevSecOps Talks
Исследования рынков DevSecOps и MLSecOps Привет, друзья! Предлагаем вашему вниманию целых три (!) исследования, которые мы запустили: 🍗Исследование рынка безопасной разработки и DevSecOps 🍗Исследование рынка средств контейнеризации 🍗Исследование рынка безопасности…
Media is too big
VIEW IN TELEGRAM
Спасибо всем, кто принял участие в наших исследованиях DevSecOps, средств контейнеризации и MLSecOps. Среди участников мы случайным образом выбрали по три победителя:
Dmitry S
+79*****4549
В ближайшие дни свяжемся с победителями и расскажем, как получить призы.
А всем участникам спасибо за ответы — благодаря вам мы сможем увидеть реальную картину рынка и понять, куда движутся DevSecOps и MLSecOps.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2🔥1🥰1
Pluto AI: анализ безопасности кода
Всем привет!
Сегодня хотим рассказать проещё один сканер безопасности, использующий возможности AI – Pluto AI.
Он был разработан в качестве курсовой работы группой энтузиастов.
Процесс работы с ним достаточно простой:
🍭 Загрузка исходного кода напрямую или через ссылку на репозиторий
🍭 Анализ с использованием AI
🍭 Классификация сработок: критичность, CWE и т.д.
🍭 Вычисление уровня риска от 0 до 100
🍭 Генерация отчёта для предоставления всем заинтересованным
Его «AI-движок» позволяет находить 12 типов ИБ-дефектов: SQLi, XSS, использование жёстко закодированных паролей и т.д.
В качестве основной модели используется Gemini 1.5.
Помимо этого, Pluto AI генерирует рекомендации по устранению ИБ-дефектов и может «общаться» с пользователем через встроенный чат.
Вряд ли стоит ожидать от него чего-то сверхъестественного, но для ознакомления и изучения «внутренностей» может подойти.
Всем привет!
Сегодня хотим рассказать про
Он был разработан в качестве курсовой работы группой энтузиастов.
Процесс работы с ним достаточно простой:
🍭 Загрузка исходного кода напрямую или через ссылку на репозиторий
🍭 Анализ с использованием AI
🍭 Классификация сработок: критичность, CWE и т.д.
🍭 Вычисление уровня риска от 0 до 100
🍭 Генерация отчёта для предоставления всем заинтересованным
Его «AI-движок» позволяет находить 12 типов ИБ-дефектов: SQLi, XSS, использование жёстко закодированных паролей и т.д.
В качестве основной модели используется Gemini 1.5.
Помимо этого, Pluto AI генерирует рекомендации по устранению ИБ-дефектов и может «общаться» с пользователем через встроенный чат.
Вряд ли стоит ожидать от него чего-то сверхъестественного, но для ознакомления и изучения «внутренностей» может подойти.
GitHub
GitHub - 0xSaikat/pluto-ai: AI-Powered Code Security Analyzer. Pluto is a powerful CLI tool that uses AI to detect security vulnerabilities…
AI-Powered Code Security Analyzer. Pluto is a powerful CLI tool that uses AI to detect security vulnerabilities in your code. - 0xSaikat/pluto-ai
❤2👎1
Метрики масштабирования в Kubernetes
Всем привет!
(Автоматическое) масштабирование – крайне интересная тема. На первый взгляд она кажется достаточно простой. Но лишь на первый, пока не начнутся вопросы.
Масштабироваться реактивно? Проактивно? Как долго оставлять «неиспользуемые» ресурсы? Как контролировать масштабирование, чтобы оно не вышло из-под контроля?..
Автор статьи предлагает рассмотреть 5 метрик, которые могут помочь сделать процесс контролируемым.
Среди них:
🍭 Committed capacity percentage. То, насколько используются существующие мощности
🍭 Error rates. Что происходит в момент масштабирования?
🍭 Mean Time to First Byte (MTFB). Как много проходит времени с момента принятия решения о масштабировании до выполнения полезной работы сервисом, ресурсы которого масштабируются?
🍭 Application disruption. Влияет ли масштабирование на нарушение работоспособности запущенных приложений
🍭 Application churn. Что происходит, если средство масштабирования определяет потребность в 2,5 реплики, но такого быть не может?
По мнению Автора, отслеживание этих метрик может помочь оптимизировать процесс (автоматического) масштабирования.
Увы, статья детально не раскрывает каждую метрику в отдельности… Но! Автор собирается сделать это в отдельных статьях.
Помимо самих метрик в материале очень много интересных рассуждений на тему оптимального использования ресурсов.
Рекомендуем!
Всем привет!
(Автоматическое) масштабирование – крайне интересная тема. На первый взгляд она кажется достаточно простой. Но лишь на первый, пока не начнутся вопросы.
Масштабироваться реактивно? Проактивно? Как долго оставлять «неиспользуемые» ресурсы? Как контролировать масштабирование, чтобы оно не вышло из-под контроля?..
Автор статьи предлагает рассмотреть 5 метрик, которые могут помочь сделать процесс контролируемым.
Среди них:
🍭 Committed capacity percentage. То, насколько используются существующие мощности
🍭 Error rates. Что происходит в момент масштабирования?
🍭 Mean Time to First Byte (MTFB). Как много проходит времени с момента принятия решения о масштабировании до выполнения полезной работы сервисом, ресурсы которого масштабируются?
🍭 Application disruption. Влияет ли масштабирование на нарушение работоспособности запущенных приложений
🍭 Application churn. Что происходит, если средство масштабирования определяет потребность в 2,5 реплики, но такого быть не может?
По мнению Автора, отслеживание этих метрик может помочь оптимизировать процесс (автоматического) масштабирования.
Увы, статья детально не раскрывает каждую метрику в отдельности… Но! Автор собирается сделать это в отдельных статьях.
Помимо самих метрик в материале очень много интересных рассуждений на тему оптимального использования ресурсов.
Рекомендуем!
blog.appliedcomputing.io
Five key autoscaling metrics for Kubernetes
Earlier this year, I had the opportunity to chat with Courtney Nash at SREcon, and one of the things she reminded me is that “it’s OK to say that you’re an expert”.
🔥1🕊1
Композиционный анализ C/C++ проектов
Всем привет!
Разрешить зависимости, сформировать SBoM, проанализировать его на наличие уязвимостей и обработать их в соответствии с процессами, принятыми в компании.
Казалось бы, всё просто! Но дьявол, как и всегда, кроется в деталях. Особенно для C/C++ проектов, где (как правило) нет удобного пакетного менеджера/перечня зависимостей, который может послужить отправной точкой для исследования.
Как быть в этом случае? Ответ можно найти в статье от CodeScoring!
Ребята рассматривают:
🍭 Как можно выяснить название и версию библиотеки, с какими нюансами можно столкнуться
🍭 Как определить те зависимости, которые попали в конечный артефакт/поставку
🍭 Почему для одного ПО может быть 2 разных SBoM
🍭 Где взять дополнительную информацию о библиотеке перед включением её в SBoM
🍭 Как связать найденные пакеты с уязвимостями, если PURL (не всегда) присутствует и не только
Каждый вопрос раскрывается достаточно подробно, с примерами и рекомендациями.
Помимо этого, рассматривается очень много различного рода нюансов, с которыми можно столкнуться при композиционном анализе C/C++ проектов.
Однозначно к прочтению!
Всем привет!
Разрешить зависимости, сформировать SBoM, проанализировать его на наличие уязвимостей и обработать их в соответствии с процессами, принятыми в компании.
Казалось бы, всё просто! Но дьявол, как и всегда, кроется в деталях. Особенно для C/C++ проектов, где (как правило) нет удобного пакетного менеджера/перечня зависимостей, который может послужить отправной точкой для исследования.
Как быть в этом случае? Ответ можно найти в статье от CodeScoring!
Ребята рассматривают:
🍭 Как можно выяснить название и версию библиотеки, с какими нюансами можно столкнуться
🍭 Как определить те зависимости, которые попали в конечный артефакт/поставку
🍭 Почему для одного ПО может быть 2 разных SBoM
🍭 Где взять дополнительную информацию о библиотеке перед включением её в SBoM
🍭 Как связать найденные пакеты с уязвимостями, если PURL (не всегда) присутствует и не только
Каждый вопрос раскрывается достаточно подробно, с примерами и рекомендациями.
Помимо этого, рассматривается очень много различного рода нюансов, с которыми можно столкнуться при композиционном анализе C/C++ проектов.
Однозначно к прочтению!
❤7🔥4🥰2