AppSec & Compliance

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

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

ЕС опубликовал план по повышению независимости от США в ИТ. План состоит из следующих основных инициатив: 1. Увеличение производства микроэлектроники в ЕС ( EU Chips act 2.0). 2. Строительство своих независимых ИИ дата центров и облаков (EU Cloud and AI Development act). 3. Стратегия по использованию открытого программного обеспечения. 4.План по использованию ИИ. Во всех этих инициативах явно упоминается кибербезопасность как приоритетное направление. Ранее довольно много программного обеспечения, включая средства кибербеза, прошло независимый аудит безопасности в рамках программы ЕС EU FOSSA и FOSSA 2. Программа по поддержке открытого ПО снижает риски остаться без патчей в эпоху уязвимостей массово находимых ИИ. Постепенно усилится конкуренция на рынке труда где кандидаты могли работать на рынок ЕС. Например Южная Европа и частично страны ЕАЭС.

Коллеги, доброго утра! На сайте ФСТЭК России опубликовано информационное сообщение о новой версии Методики ВУ и НДВ, а также - и впервые - выписка из Методики (6-4 УД). Методика вступила в действие с 12 мая 2026, все новые испытания необходимо планировать уже с ее учетом. Также считаю, что не будет нарушением NDA поделиться полученным ответом на вопрос: "Как быть с уже идущими работами"? Если работа идет давно и заканчивается в окрестностях июня-июля, то можно завершить по ранее утвержденному плану. Чем дальше от текущей даты - тем больше вопросов будет вызывать предоставление материалов, подготовленных в соответствии с прошлой версией Методики. Обратите внимание на Раздел 1 Методики. Явно зафиксирована рекомендация опираться на Методику при выстраивании процессов РБПО в соответствии с ГОСТ Р 56939-2024. Обратите внимание на Раздел 5 Методики. Там появились принципиально новые и важные моменты, в т.ч. таблица недостатков - отход от бинарной логики тех. заключения, в котором традиционно пишут, что "всё идеально".

Информационное сообщение к ней.

Выписка из обновлённой Методики ВУ и НДВ опубликована. 🎉🎉🎉

EU CRA is turning SBOMs into a continuous obligation The EU Cyber Resilience Act is changing SBOMs from a point-in-time compliance document to a continuous lifecycle requirement. For anyone shipping connected products into the EU market (especially aviation, defense, railway, energy), the obligations are to identify vulnerabilities, address them without undue delay and report actively exploited ones to authorities None of that works if your SBOM is a PDF refreshed quarterly. submitted by /u/Late-Aside8582 [link][comments] via DevSecOps news and discussions (author: /u/Late-Aside8582)

Вышел релиз Buildography 3.7.5 Это полноценный официальный релиз, расширяющий возможности мартовского пре-релиза с тестовым набором и скриптами, позволяющими проверить безопасность всех компиляций в сборке. Наряду со сборками для лицензий с кодом серии YMYCK (vendor id 101213) теперь мы также выпускаем сборки для лицензий с кодом серии XEKDC (vendor id 36343). Необходимые файлы находятся в папке sentinel-runtime вместе с обновлённой информацией readme.md. Схема именования архивов теперь имеет следующий вид.

buildography-v3.7.5+sentinel-xekdc.amd64.tar.gz
buildography-v3.7.5+sentinel-ymyck.amd64.tar.gz

Полный список нововведений и исправлений — в CHANGELOG.

MCP Hardening Guide Всем привет! Сегодня хотим предложить вам чтение на выходной! Статью, в которой собраны рекомендации о настройках безопасности при использовании MCP (~ 16 минут). Авторы рассматривают 6 основных разделов: 🍭 Network Isolation 🍭 Dependency and Supply Chain Security 🍭 Secrets Management at Runtime 🍭 TLS Configuration Hardening 🍭 Runtime Behavioral Monitoring 🍭 Pre-deployment Security Gate Для каждого раздела приводится краткое описание, небольшие примеры и перечень требований, по которым можно сделать самопроверку (verification checklist).

Формат презентации - html, но сама презентация рекомендуется к изучению. Презентация про самонописанную замену defectdojo (опенсорс платформа для менеджмента уязвимостей в коде) с ИИ автоматизацией. Радует, что каждый доклад про ИИ инструменты обсуждает в как минимум встроенный базовый гардрейл на регэкспах.

Git-pkgs proxy: защита от атак на цепочку поставок Всем привет! Одной из причин почему атаки на цепочку поставки ПО актуальны, является неконтролируемое обновление пакетов на «новые версии». И уже в этих «новых версиях» может быть много чего интересного. Да, пакетные индексы работают над тем, чтобы удалять такие вредоносные пакеты… Но это случается не сразу и может занимать дни, а то и недели. В текущих реалиях, когда time-to-exploit радикально сокращается благодаря ИИ, это может быть очень критичным. Для того, чтобы хоть как-то систематизировать и контролировать процесс обновлений, можно обратить своё внимание на проект git-pkgs proxy. Суть крайне простая: он представляет из себя proxy, который не даёт обновиться на новую версию пакета в течение X дней. Например, если lodash обновилась до версии 4.18.0, то в вашей сборке всё ещё будет использоваться версия 4.17.21 в течение 3-х дней. Временной интервал можно настраивать, о чём (и не только) подробно расписано в GitHub-репозитории проекта. Утилита работает более чем с 20-ю индексами, среди которых npm, PyPi, Conda, Maven, Debian, Helm и не только. Да, не все они «полностью» готовы, но Автор собирается развивать проект. А как вы работаете с проблемой отсутствия контроля обновления зависимостей?

Карантин это, конечно, не полноценный security gate, но "на безрыбье и рак - рыба". Кому-нибудь, для петпроектов например, может быть большего и не надо (пока).

Microsoft MDASH обходит Mythos и GPT-5.5 #microsoft #anthropic #mythps #openai #gpt #cybergym Microsoft выкатила MDASH — Multi-model Agentic Scanning Harness, и это интереснее обычной новости про «ещё один AI для безопасности». На публичном **CyberGym система набрала **88,45% и вышла на первое место: выше Claude Mythos Preview от Anthropic с 83,1% и GPT-5.5 от OpenAI с 81,8%. Главная деталь: MDASH не пытается победить всех одной моделью. Microsoft собрала инженерный конвейер из 100+ специализированных агентов: одни строят карту кода и поверхности атаки, другие ищут подозрительные пути, отдельная группа спорит о достижимости и эксплуатации, затем находки дедуплицируются и доказываются через PoC-входы. Это ближе к автоматизированной команде исследователей безопасности, чем к «сканеру на LLM». Почему CyberGym важен? Это не набор синтетических задач. Бенчмарк UC Berkeley содержит 1507 реальных задач по воспроизведению уязвимостей из 188 OSS-Fuzz-проектов. Агент получает описание уязвимости и уязвимую кодовую базу, а успех засчитывается только если он строит рабочий PoC, который падает на vulnerable-версии и не падает после патча. То есть измеряется не красивое объяснение бага, а способность довести гипотезу до воспроизводимого результата. Самый сильный вывод из MDASH: преимущество смещается от "какая модель умнее" к "какая система умеет ставить модели в правильные роли". Microsoft отдельно пишет, что результат получен на общедоступных моделях. Значит, разрыв создала не магическая закрытая модель, а оркестрация: индексация, threat modeling, debate-stage, доказательство, доменные плагины и повторяемая валидация. Хотя лично мне тейк про мы запустило 100+ агентов и оно разъебало давно понятен. Имея ∞ ресурсов конечно можно позволить себе запустить такую ораву агентов. Хочется увидеть уже хоть какую-то оптимизацию процессов без критичного ущерба в качестве, скорости и повторяемости нахождения уязвимостей, хотя на в white box режиме. Сейчас к этому стремятся как будто только Китайцы, а ИИ рынок США чахнет в своих выдуманных миллионах, миллиардах и триллионов долларов. Хотя я не отрицаю пользу мультиагентной системы в контексте того, что есть группа агентов, которая намеренно душнит других, чтобы те явно доказывали работоспособность PoC, а не делали уверенный вид что это PoC и он якобы проходит E2E проверки 🌚 @poxek_ai / Чат канала

Если ваша организация использует Claude и у вас тариф Enterprise - нужно планировать тестирование нового функционала доступного всем Claude Security. Это поиск уязвимостей в коде пока на Опусе 4.7. Поддержка на тарифах Claude Team and Max пока в планах.

Управление (утекшими) секретами при работе с VCS Всем привет! Рано или поздно, так или иначе, но секреты окажутся в кодовой базе. Но что делать и как быть? Начало ответа на этот вопрос можно найти в статье. Автор рассматривает полный жизненный цикл того, что (не) надо делать при работе с git-репозиториями и чувствительной информацией. Например: 🍭 Stop Hardcoding Credentials in Your Code (кто бы мог подумать). Про переменные окружения и работу с .*-ignore-файлами 🍭 Managing Secrets in Collaborative Environments. Использование Vault и его аналогов 🍭 Detecting Secrets Already in Your Git History. Сканирование репозиториев для выявления секретов 🍭 Review Findings and Remove False Positives. Оценка того, насколько сработки, полученные на предыдущем этапе, актуальны 🍭 Rewrite History with git-filter-repo. Инвалидация секретов, устранение секретов из кодовой базы По каждому разделу даётся небольшой набор рекомендаций и советов о том, что можно делать и каким средством автоматизации можно воспользоваться. В итоге получилась очень хорошая обзорная статья. Особенно для тех, кто только начинает погружаться в тему.

Your SBOM is about to be a compliance document, not just a nice to have We've been generating SBOMs for a year. They sit in a repo nobody opens. Our compliance guy asked about them once during an audit, I showed him a JSON file, he nodded, that was it. Under CRA that changes completely. SBOMs become legally required documentation and should be machine-readable, and continuously updated. Covering at least top-level dependencies for every product you ship to EU customers. They're not a nice artifact you attach to a release note anymore. They're basically evidence at this point. If your SBOM pipeline is we'll generate it when someone asks or the CI job does it but nobody checks if it's complete, now is the time to fix it. September 2026 is four months away and incomplete SBOMs are the kind of thing that looks fine until a regulator asks. Just thought you should know : ) submitted by /u/winter_roth [link][comments] via DevSecOps news and discussions (author: /u/winter_roth)

Доработка open source в "промышленных масштабах": https://habr.com/ru/companies/yandex/articles/1021478/