Категория

Уязвимости

AI-отчёты об уязвимостях: как не утонуть в потоке находок низкого качества

AI-отчёты об уязвимостях: как не утонуть в потоке находок низкого качества

Команда приёма уязвимостей получает всё больше отчётов, которые выглядят убедительно, но плохо воспроизводятся. AI помогает быстро писать текст, поэтому качество доказательств становится важнее объёма описания. Главный риск — потратить время инженеров на длинн…

Читать →
spectre ai workloads isolation controls hero

Побочные каналы в облаке: что учесть при размещении AI-нагрузок

AI-нагрузки часто размещаются в многоарендной облачной среде: рядом могут работать пользовательские функции, расширения, обработчики данных и вспомогательные сервисы. Побочные каналы напоминают, что изоляция важна даже тогда, когда прямого доступа к памяти нет…

Читать →
ml platform ssrf cloud secret theft hero

SSRF в ML-платформе: как защитить облачные секреты от кражи через AI-инфраструктуру

Экспериментальная ML-платформа часто получает доступ к моделям, артефактам, хранилищам и временным облачным ролям. Если такой сервис доступен извне, обычная серверная ошибка превращается в путь к секретам и данным обучения. Главный риск — считать AI-инфраструк…

Читать →
frontier ai vulnerability burst appsec hero

AI-поиск уязвимостей: как AppSec принимать поток находок без автопилота исправлений

Автономный поиск уязвимостей меняет нагрузку AppSec: проблема становится не только в том, чтобы найти дефект, но и в том, чтобы проверить поток находок, убрать повторы и безопасно довести исправление до владельца. Если AI-находки сразу превращаются в задачи бе…

Читать →
agentic dependency remediation controls hero

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

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

Читать →
llm vulnerability remediation controls hero

LLM для исправления уязвимостей: как автоматизировать изменения и не создать новые риски

LLM можно использовать не только для приоритизации уязвимостей, но и для подготовки исправлений. Однако автоматизация исправлений опасна, если модель сама меняет код без тестов, владельца и плана отката. Команда получает длинный список CVE, но исправления заде…

Читать →
SharePoint в CISA KEV: как быстро провести первичную проверку без разрушения следов

корпоративный портал в CISA KEV: как быстро провести первичную проверку без разрушения следов

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

Читать →
Иллюстрация к статье: AI coding agents и EDR: почему полезная автоматизация похожа на атаку и как снизить риск
Агенты

AI-агенты для кода и EDR: почему автоматизация похожа на атаку и как снизить риск

AI-агенты для кода помогают писать изменения, запускать проверки и готовить запрос на слияние. Для команды разработки это ускорение, но для EDR такие действия могут выглядеть как поведение злоумышленника: массовое чтение файлов, запуск команд, обращение к сети…

exposed mcp server inventory controls hero
Агенты

Открытые MCP-серверы: как найти лишние AI-инструменты и закрыть доступ

MCP-сервер превращает внешний инструмент в часть AI-сценария, поэтому открытый или забытый экземпляр становится не просто сервисом, а каналом действий от имени помощника. Главный риск — оставить MCP-сервер доступным шире, чем нужно: с лишними инструментами, по…

Агенты

AI-агенты в кибертестах: как задать границы и аварийную остановку

AI-агент в кибертесте может быстро выполнять цепочки действий, но скорость становится риском, если границы задания описаны расплывчато. Тест должен иметь явную область, лимиты и аварийную остановку. Опасность появляется, когда агент получает слишком широкий до…

chatgpt sandbox isolation checklist hero
Агенты

AI-песочница для рабочих данных: как проверить изоляцию перед подключением

Песочница AI-инструмента выглядит безопасной, пока в неё не попадают рабочие файлы, секреты, журналы и внутренний код. Перед подключением к таким данным нужно проверить не название режима, а реальные границы изоляции. Главный риск — считать песочницу доверенно…

ai identity access review anomaly controls hero
Управление AI

AI в проверке доступов: как находить опасные права без лавины ложных тревог

Проверка доступов часто превращается в формальное согласование списков, где владелец приложения не успевает понять, какие права действительно опасны. AI может помочь, если он объясняет риск и не утверждает доступ автоматически. Риск появляется, когда модель ош…

ai token jacking api key controls hero
Управление AI

Кража AI-токенов: как защищать ключи к моделям и лимиты вычислений

Ключи к AI API становятся отдельным классом секретов: через них можно расходовать бюджет, использовать корпоративные модели, обходить правила шлюза и скрывать злоупотребление за легитимным сервисом. Проблема не ограничивается стоимостью запросов. Украденный кл…

model risk scoring before deployment hero
Управление AI

Оценка риска AI-модели перед внедрением: как выбрать модель без слепого доверия

Выбор AI-модели для корпоративного сценария безопасности нельзя сводить к качеству ответа в тестовом окне. Модель становится частью процесса, где есть данные, доступы, инструменты, владельцы и последствия ошибки. Главный риск — внедрить модель как универсально…

zero trust ai agents devsecops hero
Управление AI

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

AI-агент в инженерной среде не должен считаться доверенным только потому, что его запустил сотрудник или корпоративный инструмент. Он получает данные, вызывает средства разработки и может влиять на код, поэтому к нему нужны отдельные правила нулевого доверия. …

Уязвимости

600 файрволов за 5 недель: как GenAI ускорил взлом FortiGate без эксплойтов

Отчёт AWS: злоумышленник с невысокой квалификацией с помощью коммерческих LLM скомпрометировал более 600 FortiGate в 55 странах без единого эксплойта — только слабые пароли и открытый доступ.