AppSec & Compliance

🇨🇳На ISC[.]AI 2026 представили китайский Mythos На 14-й Конференции по интернет-безопасности ISC[.]AI 2026, которая открылась 24 июня 2026 года, основатель компании 360 Group Чжоу Хунъи представил 2 новые ключевые разработки в сфере ИБ. Данные решения получили общее название «Итянь Тулун» (倚天屠龙). Они призваны полностью автоматизировать процессы поиска системных уязвимостей и защиты компьютерных сетей. 1️⃣ Первой анонсированной новинкой стал интеллектуальный агент для автоматического поиска уязвимостей под названием «Тулунфэн» (图龙锋). Руководитель компании назвал этот инструмент китайским аналогом известной американской ИИ-модели Mythos от компании Anthropic. К настоящему моменту система «Тулунфэн» помогла обнаружить 3432 уязвимости. Из этого числа регулирующие органы официально подтвердили 105 уязвимостей, а национальная база данных уязвимостей классифицировала ряд из них как высокоопасные. Данная система успешно применяется для анализа открытого исходного кода, операционных систем, офисных программ и платформ для ИИ-агентов. Основатель компании 360 Group Чжоу Хунъи подчеркнул, что «Тулунфэн» уже обладает возможностями, аналогичными возможностям американской ИИ-модели Mythos. 2️⃣ Второй новинкой стала система автоматизированной сетевой защиты «Итяньчжэнь» (仪天阵). Данный комплекс предназначен для автономного управления безопасностью в реальных сетевых условиях. Система способна самостоятельно планировать задачи, оценивать сигналы тревоги и принимать скоординированные меры по устранению угроз. Даже появление китайской версии Mythos не устранит все риски, ведь уязвимости неисчерпаемы. Чжоу Хунъи считает, что единственным выходом остается противопоставление вычислительных мощностей вычислительным мощностям, что позволит перевести систему ИБ Китая от тактики привлечения огромного числа специалистов к режиму автопилота. В своем выступлении основатель компании 360 Group Чжоу Хунъи упомянул действия американской компании Anthropic, которая недавно ограничила доступ к своей самой мощной внутренней ИИ-модели Mythos. Чжоу Хунъи пояснил, что ИИ-модель Mythos превратилась в сетевое ядерное оружие эпохи ИИ и сформировала новое стратегическое сдерживание, поскольку она способна самостоятельно находить и анализировать уязвимости, а также конструировать инструменты для совершения масштабных кибератак. По мнению китайского предпринимателя, ИИ полностью меняет правила игры в сфере ИБ, которые оставались неизменными последние 30 лет. Ранее поиск уязвимостей требовал колоссальных ресурсов и усилий редких высококлассных специалистов, однако новые ИИ-модели позволяют автоматизировать и масштабировать этот процесс, оперативно выявляя даже старые и глубоко скрытые дефекты кода. При этом Чжоу Хунъи отметил, что Китаю не следует просто копировать зарубежный подход, основанный на использовании вычислительных мощностей и возможностей ИИ-моделей ради достижения результата грубой силой. В рамках конференции компания 360 Group также объявила о запуске программы сотрудничества в сфере безопасности под названием «Панши чжи дунь» (磐石之盾). Инициатива направлена на предоставление ИИ-технологий защиты ключевым отечественным ИТ-предприятиям и КИИ Китая. К проекту уже присоединился ряд ведущих китайских технологических, инфраструктурных и облачных компаний, среди которых присутствуют UnionTech (统信), Kylin (麒麟), Hillstone Networks (山石网科), Hygon (海光), Phytium (飞腾), Kingdee (金蝶), Biren Technology (壁仞), Mobile Cloud (移动云), Baoland (宝兰德) и Dameng (达梦). 👆Основатель компании 360 Group провел параллель с американским альянсом Glasswing, который использует возможности ИИ-модели Mythos для защиты критической инфраструктуры США, и призвал китайское деловое сообщество заблаговременно формировать собственные системы коллективной безопасности. ✋ @Russian_OSINT

K8s Diagram Generator Всем привет! Небольшой пятничный пост! K8s Diagram Generator – проект, при помощи которого можно создавать диаграммы связи сущностей ресурсов Kubernetes в графическом интерфейсе. Работает очень просто: выбираете необходимые ресурсы (Ingress, Service, Deployment, Pod, Sidecar и т.д.), переносите их в «рабочую область» и «соединяете». Ресурсы можно «адаптировать» - указывать Labels, наименования, необходимые порты, Selectors и т.д. При создании схемы автоматически генерируются YAML-файлы, которые описывают созданную в диаграмме конфигурацию. Можно и наоборот – загрузить YAML и тогда K8S Diagram Generator «построит» его графическое представление. Реализованы проверки: например, нельзя настроить взаимосвязь между Deployment и Ingress без Service - K8s Diagram Generator явно сообщит об этом. Дополнительно доступен небольшой набор «уроков» по написанию YAML-файлов. Подробнее о проекте и его возможностях можно узнать в GitHub-репозитории.

📈 Оценка LLM в пентестинге Эксперты Лаборатории Касперского и Сбера опубликовали научную работу, в которой предложили новую методику оценки языковых моделей для задач тестирования на проникновение (пентеста). Самое интересное — бенчмарк имеет два измерения: отдельно оцениваются планирование атак и их исполнение. Это позволяет понять сильные и слабые места различных моделей и по необходимости строить эффективные ансамбли LLM в агентских системах. Среди протестированных моделей, лучшие результаты в планировании показали Sonnet 4.5, GPT-5 и Gemini 2.5 Pro, а лидерами в исполнении стали GPT-5, Qwen3 Max, GLM 4.6. Успешность у обеих групп чемпионов — от 72% до 78%. Среди наиболее частых ошибок, допущенных моделями в эксперименте: синтаксические ошибки при запуске инструментов, дрифт (частичная или полная смена долгосрочной цели), галлюцинации и потеря контекста. Ожидаемая и часто встречающаяся проблема отказов выполнять задачу (refusals) отдельно не посчитана. Исследование доступно по лицензии CC BY 4.0, поэтому бенчмарк можно использовать для оценки других моделей, используемых в организации. #советы #ИИ @П2Т

Разработка безопасного программного обеспечения 2026 https://amlive.ru/am-live/bezopasnaya-razrabotka-devsecops-chast-1/ 24 июня, 2026 11:00

В эфире AM Live разберём, как сделать РБПО частью качественной разработки, а не формальным комплаенсом. Обсудим, кто должен отвечать за безопасность ПО, как вовлекать разработчиков, какие мировые и отечественные стандарты помогают выстроить процесс, какую роль играют ГОСТ Р 56939-2024 и требования ФСТЭК, а также почему безопасность должна появляться в продукте до написания кода. Отдельно поговорим о контроле стороннего кода, композиционном анализе, архитектуре, поверхности атаки, low-code/no-code и LLM. Главная идея эфира: безопасное ПО нельзя “досканировать” в конце — его нужно проектировать, разрабатывать и сопровождать как качественный инженерный продукт.

Оп! Чо вышло: второе издание Контейнер секьюрити на русском! Пожалуй, лучшая книга по безопасности контейнеров на сегодняшний день. Лиз Райс — один из самых уважаемых специалистов в области Container Security. Она умеет разбирать сложные темы на простые составляющие, объясняя «как это работает на самом деле», а не пересказывая документацию. Каждая концепция подкреплена наглядным примером — можно открыть терминал и пощупать всё руками. Однажды мне довелось побывать на её докладе на DevOops про побеги из контейнеров — у меня до сих пор хранится методичка с её автографом: "Enjoy your containers, Sergey". Подача материала в книге такая же, как и на конфе: живая, точная и с любовью к делу. Во втором издании накопились серьёзные изменения за пять лет, прошедшие с первого: появились отдельные главы про безопасность цепочки поставок (SBOM, SLSA, cosign) и про IaC/GitOps, переписана глава о защите среды выполнения с акцентом на eBPF, Falco и Tetragon, обновлена глава по OWASP Top 10. Книга стала аж на четверть толще. Почитал с огромным удовольствием. Очень ждал этого издания — и вот оно. DevSecOps-инженерам, платформенным командам, безопасникам — бегом читать 😊

📌 DeepMind опубликовала архитектуру безопасности AI Control Roadmap Вслед за недавними размышлениями об эволюции AGI в ASI, исследовательское подразделение Google представила внутренний регламент контроля высокоразвитых ИИ-агентов. Помимо привычного элайнмента модели, DeepMind добавляет отдельный слой системного контроля, пересобирая защиту исходя из худшего сценария.

За вводную берётся то, что система изначально враждебна, имеет скрытые цели и тайно работает против разработчиков.

Для систематизации таких угроз взяли за основу популярный фреймворк MITRE ATT&CK и создали на его базе TRAIT&R, новую таксономию тактик и методов обхода защиты. Она учитывает специфику ИИ и описывает векторы атак, недоступные людям: от незаметного саботажа научных исследований и внедрения бэкдоров до распределенных цепочек взлома, когда фрагменты вредоносного плана синхронно выполняются сотнями разных инстансов одного агента. Защита выстроена по принципу эскалации и делится на уровни D1–D4 для систем обнаружения и R1–R3 для механизмов реагирования. На базовых этапах безопасность обеспечивается анализом CoT агента в песочницах под присмотром более слабых, но надежных ИИ-супервизоров. По мере развития способностей модели начинают понимать факт слежки и учатся скрывать ход своих мыслей. Для контроля над такими системами (это уровень D4/R3) традиционные методы больше не работают. На этом этапе DeepMind планирует применят более затратные меры, вплоть до проверки внутренних состояний модели, использования изолированных копий самой недоверенной системы для аудита и инфраструктуры экстренной остановки агентов и запущенных ими процессов. Вместе с новой стратегией опубликован отдельный документ для индустрии о том, как сделать агентов безопасными по мере их распространения, и он разбит на 3 уровня: 🟡Безопасность отдельного агента

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

🟡Риски взаимодействия агентов

Каскадные сбои, негласный сговор алгоритмов, ситуации, где за вред никто конкретно не отвечает, и атаки, рассчитанные сразу на сеть агентов.

🟡Общая кибербезопасность

Как помочь защитникам сохранить преимущество перед злоумышленниками (автоматический поиск и устранение уязвимостей, обмен сигналами об угрозах, обучение специалистов).

@ai_machinelearning_big_data #news #ai #ml

Четверг, а значит время проектов от подписчиков! 🌝 Тем, кто пропустил, что такое четверговые проекты от подписчиков, можно прочитать тут - https://t.me/tech_b0lt_Genona/4983 Слово автору @maxmur --- Всем Привет! Сегодня хочу вам показать свой проект — RS-Key, security key firmware FIDO2/OpenPGP для RP2350. Начну с небольшой предистории, почему я вообще решил его сделать. Где-то около года назад я нашёл два замечательных репозитория: https://github.com/polhenarejos/pico-fido https://github.com/polhenarejos/pico-openpgp Они имплементировали прошивку yubikey/nitrokey/... на обычной RP2350, весь софт был совместимым. Тогда я загорелся, но нашёл одну небольшую проблему — в линуксе, через firefox не работал ctap/webauthn. Тогда я принялся искать проблему, отдебажил всё что только мог, и отправил отчёт мейнтейнеру: https://github.com/polhenarejos/pico-fido/issues/129 Он увидел и понял проблему, затем написал исправление. Тогда я был счастлив, у меня был собственный юбикей за 500 рублей (Да, не такой защищенный, но об это позже), который везде работает и позволяет мне полностью посмотреть исходники того, что на нём запускается. Но продлилось это не долго) https://github.com/polhenarejos/pico-fido/commit/8b086188758ad3f60e912acd969b80d6801cfab3 > Update license models and add ENTERPRISE.md > Post-quantum (PQC) key material handling. Никогда такого не было и вот опять. Поэтому я загорелся идеей написать свою прошивку и поправить те места, которые мне не нравились. https://github.com/TheMaxMur/RS-Key/ — Реимплеметация pico-keys на Rust + вынесенные "энтерпрайз" фичи в публичный доступ + нормальная (относительно) документация. Сразу оговорюсь, да, проект навайбкожен. НО. Я замарочился с тестами, и покрыл, мне кажется, абсолютно всё, что мог: 1. Unit тесты 2. Хост тесты 3. Внешние тесты из апстрим проекта pico keys 4. Тесты с помощью либы python-fido2 от yubikey 5. Fuzzing тесты 6. Miri fuzzing тесты (спасибо коллеге из ИТМО) 7. Kani, формальная верификация важных компонентов — sdk, crypto, fs, rsa-asm, rescue 8. Тесты на самом девайсе 9. Cargo-audit + gitleaks 10. И, да, всё на расте, с минимальным количеством unsafe, каждое его использование описано и протестировано 11. Тесты с внешним софтом (ykman, yubico authenticator, opengpg) По профессии я DevSecOps, и я не мог не сделать нормальный пайплайн для этого проекта: 1. GitHub Pages 2. Scheduled fuzzing 3. Scheduled Kani 4. Scheduled builds (для поверки воспроизводимости) 5. SLSA v1.2 Build L3 (полностью докручен) + Source L3 (формально не до конца докручен, там нужно ещё пару вещей сделать, но они на стороне GitHub, а не на моей) 6. Иммутабельные релизы из CI, с хешами, подписями, SBOM, аттестацией, cosign Важно оговорится, у проекта есть модель угроз, и в ней явно прописано, что это прошивка, и проблемы RP2350 она не решает. Чип был публично взломан еще на hacking challenge 1: https://www.raspberrypi.com/news/security-through-transparency-rp2350-hacking-challenge-results-are-in/ Но это касается ревизии A2, Raspberry выпустили новую A4, в которой 3 из 4 главных проблем исправлены, для последней была предложена митигация. Моя прошивка работает как с A2, так и с A4, митигации все применены, так что вскрыть её должно быть не тривиально, но всё равно возможно, OTP это не настоящий нормальный Secure Element, но, мне кажется, Raspberry идёт в эту сторону, хотя бы частично. В любом случае, идеалогически, я готов рассмотреть только Secure Element от Tropic Square, но как купить и поиграться с ним в РФ я не знаю, если вы знаете то можете написать)) На текущий момент всё ещё идёт Raspberry Hacking Challenge 2: https://www.raspberrypi.com/news/rp2350-hacking-challenge-2-less-randomisation-more-correlation/ Пока что, на новой ревизии новых проблем зафиксировано не было, и они продлили окно тестов до октября 2026, жду, интересно посмотреть что получится. У меня есть ещё идеи как развивать проект, хочу пару вещей допилить, у меня есть мой канал @themaxmur, кому интересно, можете подписаться и следить за статусом проекта. Security Through Transparency! ---

Петпроджект DecSecOps'a

Выпустили пререлиз Svacer 13-alpha — тестовый альфа-релиз, для желающих попробовать наши новые фичи, например разметку предупреждений с комментариями от LLM. Disclaimer: это тестовая версия, не используйте ее в продакшене. - Описание новых фич: кратко / подробно - Установка через docker-compose

OpenVEX в CI/CD: как перестать бороться с ложными CVE и научить Trivy понимать контекст via Публикации по подписке (author: ChislitelLab (Лаборатория Числитель))

GigaChat vs Opus в агентском аудите файрвола: попытка сравнения https://habr.com/ru/companies/ideco/articles/1047692/

Взяли один агент, один навык и одну выгрузку правил Ideco NGFW – и прогнали её через GigaChat Max и Claude Opus 4.8. Рассказываем, что из этого получилось, почему «настоящего» агентского теста не вышло и сколько всё это стоило в токенах и рублях. Если вы – банк, госкомпания или объект КИИ, отправлять выгрузку правил вашего боевого файрвола в облако Anthropic – это в лучшем случае разговор с юристами, в худшем – прямое нарушение. GigaChat от Сбера работает в российском контуре, и если он справляется с аудитом конфигураций на приемлемом уровне, это меняет картину для целого класса заказчиков. Поэтому мы взяли один и тот же агент (Hermes), один и тот же навык аудита и одинаковые входные данные – и подставили под него две модели: GigaChat Max и Claude Opus 4.8 (задумку с тестированием Claude Fable 5 для этой же задачи реализовать не удалось, со всеми нашими ИБ-скиллами он работать отказался, даже когда был доступен). Где сломался «честный» агентский тест . . . С GigaChat этот сценарий не запустился на первом же шаге. Агент не смог подключиться к NGFW по API и выполнить нужную последовательность действий – то есть споткнулся ещё до того, как добрался до самого аудита. Computer/tool use у него еще явно не достаточен для автономной работы. . . . Выгрузка – это секция FORWARD реального по структуре конфига Ideco NGFW: 104 правила, CSV-экспорт из веб-интерфейса объёмом около 34 КБ. Мы специально насытили её типовыми ошибками, которые встречаются в живых инсталляциях, чтобы было что находить. Идея простая: зафиксировать всё, кроме LLM, и посмотреть, что меняет именно модель. . . . Главный тезис отчёта Opus сформулирован верно: конфигурацию «спасает» порядок правил, но это не должно считаться надёжной защитой. Дальше – приоритетный план действий из семи пунктов. Ровно тот уровень, которого ждёшь от инженера ИБ. . . . Что увидел GigaChat Цифра 4083 избыточных правила на конфиге из 104 строк – это сразу красный флаг. Из расшифровки видно, откуда она взялась: модель посчитала «перекрытием» почти любую пару правил, где совпадает источник или назначение: Но куда серьёзнее вторая строка: небезопасных правил – 0. . . . Получился комбинаторный перебор пар, а не анализ. Получилось примерно ~5300 потенциальных пар, из которых модель отметила больше четырёх тысяч. Реального дубликата в конфиге ровно один – правило 21 повторяет 18. Остальные «перекрытия» – ложные срабатывания. Получилась картина, опасная не отсутствием ответа, а ложным успокоением: отчёт уверенно сообщает, что с безопасностью всё в порядке, при том что в конфиге заложены критические дыры. . . . Мы хотели сравнить GigaChat и Opus в агентском режиме – и не смогли: GigaChat не прошёл этап подключения к Ideco NGFW по документированному в навыке API. На упрощённой аналитической задаче по CSV разрыв оказался качественным: Opus поймал все заложенные критические и высокие проблемы и дал план действий, GigaChat свёл аудит к перебору пар правил и отчитался, что небезопасных правил нет. Практический вывод на сегодня прежний, что и в прошлой статье, но теперь с поправкой на локальные модели: - Для реального аудита конфигураций нужна сильная модель и надёжный tool calling – по обоим пунктам фронтир пока впереди. - Российские LLM критичны там, где данные не должны покидать контур, поэтому их прогресс мы продолжим отслеживать и перепроверять. - Цена за токен и объём токенов – плохой ориентир. Считайте стоимость полезного результата.

CSV с заложенными ошибками по ссылке (в комменты тоже положу) https://disk.yandex.ru/i/UW47C4fhNWEvWw

Неоднозначная новость от FIRST которую нужно внимательно осмыслить всем ответственным за управление уязвимостями: 1. С одной стороны прогнозы по количеству уязвимостей на этот год увеличились на 46 процентов до 66000 с шансом достичь рекордных 70000 за год. 2. С другой стороны FIRST заявляет, что количество уязвимостей требующих немедленных действий почти не изменилось. Уязвимости требующие немедленных действий это уязвимости из списка CISA KEV и уязвимости с метрикой EPSS выше 10%. По моему мнению такая неоднозначность может говорить о трех причинах: 1. CISA KEV и EPSS стали неэффективным способом оценки необходимости патчинга. В пользу этой версии говорят проблемы с финансированием у CISA и ожидающийся новый релиз метрики EPSS. 2. Поток уязвимостей от ИИ и новых организаций уполномоченных на присвоение уязвимостей CNA - резко снизил общий КПД процесса поиска новых уязвимостей и требует радикального пересмотра. Эта версия также может быть поддержана теми кто считает средства ИИ экономически неэффективным. 3. Новые источники уязвимостей (ИИ и CNA) имеют аномальное распределение с почти отсутствующим количеством уязвимостей требующих немедленного патча, но другие найденные уязвимости высокого уровня риска важны для борьбы с продвинутыми атаками. Также FIRST сформировала 4 лучших практики на основе своего прогноза: 1. Планируйте свой бюджет (на управление уязвимостями) с учётом разнообразия используемого ПО, а не ориентируйтесь на новостные поводы. 2.EPSS и CISA KEV остаются эффективными инструментами для отделения сигнала от шума. 3.Учитывайте в своих планах, что до конца года текущая удвоенная нагрузка на патч менеджмент сохранится. 4. Склоняйтесь к использованию ИИ для нужд защиты. ИИ может вам помочь в снижении среднего времени на поиск и устранение уязвимостей. По мнению автора сего канала такая ситуация с уязвимостями только формирует новый запрос на квалифицированных специалистов и развитие навыков в области устранение уязвимостей.

Ряд крупных компаний, в том числе, Cisco, JPMorganChase, PWC и Cloudflare вошли в проект под названием Афина для исправления уязвимостей в открытом ПО с помощью ИИ. https://www.chainguard.dev/athena

Semgrep: оптимизация времени taint-анализа Всем привет! Taint-анализ в Semgrep появился достаточно давно. Сперва это был лишь taint в рамках одного файла. Со временем, команда реализовала interfile-анализ, который позволял следить за «движением данных» более детально. Были выделены основные сущности: 🍭 Sources. Ввод данных, контролируемый пользователем 🍭 Propagators. То, что «передавало» данные дальше по «потоку». Например, вызов библиотек и их функций 🍭 Sanitizers. Точки «контроля» и «очистки» данных 🍭 Sinks. Потенциально опасные участки кода, в которые могли попасть пользовательские данные Для того, чтобы это работало, Semgrep «строил» taint-конфигурации, которые впоследствии анализировались для того, чтобы найти ответ на вопрос «Существует ли путь от source до sink?». И вроде бы всё хорошо, но ввиду некоторых особенностей приходилось запускать taint-анализ несколько раз, что влияло на производительность и на скорость работы. Однако! Этот нюанс был устранен в версии 1.158.0 и выше (правда только для pro engine). Команде удалось оптимизировать логику работы «движка» и достичь отличных результатов. Что именно/почему/зачем и как – описано в статье. Помимо логики там представлены результаты тестирования на разных выборках и достигнутые командой показатели эффективности.

Интересный эксперимент ребят из Ideco, которые решили проверить работу ИИ-агента с разработанным скиллом по анализу правил межсетевого экрана. С невозможностью покупки Tuffin или Algosec, которые позволяли анализировать списки контроля доступа средств сетевой безопасности, эту задачу теперь можно переложить на ИИ-агентов с соответствующими скиллами. Можно и на чатбота, но посколько это задача может всплывать регулярно, то лучше ее автоматизировать через соответствующий скилл, а не отправлять каждый раз в чатбот один и тот же промпт с приложенным csv с десятками или сотнями правил МСЭ. Но сейчас не об этом. А о результатах эксперимента, который показал, что отечественная ИИ-модель GigaChat в области кибербезопасности, мягко говоря, слабовата. Мало того, что она оказалась не способной работать в режиме взаимодействия с агентом, так она еще и чувство ложной безопасности создает, утверждая, что "все хорошо", хотя на самом деле это было в эксперименте не так. У меня были схожие по сути результаты, когда я пытался решать разные задачи с GigaChat, начиная от написания простой политики безопасности или калькулятора проверки стойкости пароля и заканчивая более сложными задачами, с которым OpenAI GPT или Claude справлялись на порядок лучше 🤖 Выводов не будет. А то вдруг скоро запретят этот ваш ИИ (не те, так эти) и останется только один, истинно суверенный Гигачат, который припомнит мне, как я сомневался в его способностях 🤖 #ии #автоматизация

Сообщество FinDevSecOps представило Карту инструментов безопасной разработки ПО. Карта содержит российские, зарубежные и свободно распространяемые DevSecOps-инструменты, сгруппированные по классам. С помощью нее специалисты смогут быстро находить подходящие варианты продуктов для реализации DevSecOps-практик, в том числе, необходимых для безопасной разработки ИИ-систем. Среди DevSecOps-инструментов, представленных в Карте: статический анализатор, анализ поверхности атаки, DAST (Dynamic Application Security Testing) и др. Для каждого инструмента приведены метаданные, включающие такие сведения как тип лицензии, наличие сертификата ФСТЭК, доступность на территории РФ, используемые методы обнаружения уязвимостей, форматы отчетов. Приведены определения классов и описания лицензий. В Также Карте представлены MlSecOps-инструменты для организации безопасного жизненного цикла ИИ-систем. Обновленная Карта дает возможность подбирать инструменты по любой комбинации значений параметров.

На прошлой неделе официально вышла новая версия NIST Security Content Automation Protocol (SCAP) - 1.4. SCAP позволяет использовать единый формат описания уязвимостей, уровня патчей, настроек безопасности, соответствия требования нормативных документов разными продуктами. Из значимых правок в новой версии: 1. Убрали совместимость со старыми версиями SCAP 1.0 и 1.1. 2. NIST теперь не проводит оценку соответствия сканеров стандарту SCAP. 3. Обновились требования к криптографии к модулям SCAP.

Автоматический анализ PR’ов Renovate Всем привет! Сейчас никого не надо убеждать в том, что обновление зависимостей – задача крайне важная, которую нельзя оставлять на потом. «Руками» это делать не всегда удобно и хочется использовать средства автоматизации. Одним из таких средств может быть Renovate или его аналоги. Они обновляют зависимости и вроде бы всё хорошо. Но, бывают и такие случаи – обновление на «мёртвые» зависимости, использование deprecated и иные «неприятности», которые трудно заметить, например, из CI. Чтобы решить эту проблему Автор статьи предлагает такой подход: анализ PR’ов, открываемых Renovate с использованием Claude Code. Сам процесс весьма прост: Renovate предлагает изменения, Claude Code их анализирует и предоставляет свой вердикт – можно ли его принимать или есть потенциальные риски. Для этого Автор сделал собственный Claude Skill, в котором всё подробно описал. Кстати, этот Skill доступен в статье и с ним можно подробно ознакомиться. Что в итоге получилось – всё это можно найти в статье. А также информацию о том, как всё это настроить и какие результаты будут предоставлены пользователю.

Антропик в открытый доступ выложил harness (обвязку) для поиска уязвимостей в коде написанного Claude. Когда она пригодится - когда не хватает функционала или кастомизации Claude Security или Enterprise подписка по разным причинам не доступна. Что выложенный харнесс, что Клод секурити стоит пока рассматривать как дополнение к классическим инструментам SSDLC (SAST, DAST, Fuzzing...).

Доброго пятничного вечерочка. В тему отлеживания вредоносных и не только пакетов подготовили статейку про пакетные менеджеры и их возможности задавать «период охлаждения»: https://habr.com/ru/companies/codescoring/articles/1044132/ Должно быть полезным