DevSecOps по-прежнему часто сводят к подключению сканеров в CI/CD. Дальше сценарий предсказуем: пайплайн замедляется, отчёты копятся, команда теряет к ним интерес. Проблема обычно не в инструментах, а в том, что их внедряют поверх неизменённых процессов.
В статье — о том, как подойти к DevSecOps как к системному изменению: с чего начать, как выбрать пилот, какие цели ставить и где чаще всего всё идёт не так.
Привет, Хабр.
У меня бывают неожиданные заказы, из неожиданных сфер на фрилансе. Недавно писал про то как прилетел большой проект по классификатору фоток. А теперь пришел запрос на реверс! Не могу вдаваться в подробности проекта - много конфиденциального - но я расскажу про конкретный разбор одного .dll файла. Открыл Ghidra, кликнул на функцию, включил декомпилятор - и передо мной встала стена.
Не метафорическая стена. Прям реально стена!
И вот пока я эту функцию ковырял, переименовывал переменные, ходил по ссылкам, открывал соседние функции, смотрел строки, в какой-то момент меня щёлкнуло.
Это же сканворд.
На этапе масштабирования инфраструктуры вчерашние рабочие процессы часто превращаются в архитектурные Барьеры. Линейный рост расходов на хранение, неочевидная консистентность СУБД при восстановлении из снапшотов и зависимость миграции от наличия и «капризов» API целевой платформы — это реальность, с которой сталкиваются многие команды. Ситуация усложняется, когда бэкапы становятся целью для атак, а стандартного контроля доступа оказывается недостаточно для гарантии сохранности данных. В релизе Хайстекс Акура 4.5 мы собрали как раз те возможности, отсутствие которых в 2026 году уже сложно себе представить. Под катом — подробнее о каждом.
Локально всё работает идеально: политики ловят нарушения, логи пишутся, система стабильна.
В проде Kubernetes-кластера — теряются события, появляются дубли, а дедупликация ломается от одного скрипта.
Разбираю реальные проблемы, с которыми мы столкнулись при интеграции Tetragon и eBPF в реальный ИБ продукт, и почему Kubernetes ломает наивные предположения.
Сейчас поймал себя на мысли, что моя деятельность сегодня примерно на 80% состоит из онлайн-работы, легальной онлайн-работы, с которой я плачу налоги, и на эти же налоги государство замедляет интернет, блокирует многие полезные сервисы и тем самым ограничивает мне доступ к новым клиентам.
Да, я не занимаюсь какой-то стратегически важной для государства деятельностью. Я не IT-специалист, не создаю новый технологический продукт, не запускаю производство и не строю заводы. Моя профессия это налоговый консалтинг, так как после многих лет, проведенных на службе в ФНС, я не придумал ничего лучше, чем продавать свою экспертизу.
Через Telegram-канал, через посты и статьи я продвигаю себя как автора и как специалиста. Люди приходят, читают мои материалы, начинают доверять. Кто-то обращается ко мне со своими ситуациями, я разбираю документы, консультирую, помогаю оценить налоговые риски и получаю с этого доход.
Залог успеха моего дела, как и многих других онлайн-проектов, держится на сочетании нескольких базовых вещей: доверия, репутации, публичности и нормальной коммуникации с людьми, но государство постепенно лишает людей сразу нескольких из этих базовых элементов, ограничивая коммуникацию и лишая людей публичности отправляя заново выстраивать, то что они создавали годами в «максе»
История про совместную работу разработчика и патентного поверенного
Привет, Хабр! Меня зовут Михаил, я руководитель отдела внутренних технических проектов в ГК InfoWatch. 26 апреля прошёл международный день интеллектуальной собственности, так что расскажу вам одну историю по теме. Недавно я принял участие в новом для меня проекте, связанном с патентованием технологии «Система и способ контролируемого доступа к веб-ресурсу», которую я разработал. Опыт оказался интересным, мы получили патент всего за 2,5 месяца вместо стандартных от 6 месяцев до 1,5 лет, поэтому захотелось рассказать о том, какой путь проходит технология от её изобретения до защиты. А именно:
- Зачем вообще защищать инновационные разработки
- Какие задачи можно решить путем этой защиты
- Особенности совместной работы разработчика и патентного поверенного
- Чем для меня оказался полезен этот новый опыт
- И многое другое на примере нашего случая
Впрочем, обо всём по порядку.
К 2028 году в корпоративных средах будет работать 1,3 млрд AI-агентов, а классическая модель identity по-прежнему исходит из допущения «один деятель – один человек». Разбираем, что ломается в аутентификации, почему service account и OAuth-токен больше не закрывают задачу, и как мы в Ideco смотрим на ближайшее развитие средств защиты: непрерывная биометрия для людей и делегированные токены для агентов.
Цифры, которые ломают ИБ-ландшафт
На RSAC 2026 Microsoft, опираясь на прогноз IDC, заявила о 1,3 млрд AI-агентов в корпоративных средах к 2028 году (Windows Forum, RSAC 2026, Lantern Studios). Это не «копилоты, которые помогают писать письма» или «чатики» – это автономные исполнители, у которых есть права, токены и доступ к продуктовым системам.
Мы сами уже видим лавинообразное «нашествие агентов» как в собственной, так и в чужих корпоративных сетях.
Атакующая сторона тоже меняется. В отчёте о кампании GTG-1002 Anthropic зафиксировала первую массовую AI-оркестрированную операцию: взломанная версия Claude, подключённая к набору MCP-серверов, выполнила 80–90% тактических операций самостоятельно – разведку, поиск уязвимостей, эксплуатацию, сбор учётных данных, латеральное движение (Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign, Paul, Weiss разбор). Человек был нужен на 4–6 точках принятия решений за всю кампанию.
И последняя цифра, без которой картина неполная. По 2025 Identity Security Landscape от CyberArk (опрос 2 600 ЛПР-ов в сфере ИБ), на каждую человеческую идентичность в средней организации приходится 82 машинных; 42% этих NHI имеют привилегированный доступ или доступ к чувствительным данным, при этом 88% респондентов всё ещё относят определение «привилегированный пользователь» исключительно к людям. 87% компаний за последние 12 месяцев пережили минимум два успешных identity-центричных инцидента.
Когда говорят о балансировщике нагрузки, чаще всего имеют в виду распределение трафика между серверами. Но в реальной инфраструктуре его ключевая роль проявляется в другом — в способности системы продолжать работать, когда что-то ломается. Причём ломаться может всё: отдельные серверы, сервисы, целые дата-центры.
В этой статье разбираем, как балансировщик становится точкой принятия решений в сценариях отказоустойчивости — от health checks до переключения между ЦОД — и почему без этих механизмов одной «балансировки» недостаточно.
Самая опасная угроза — внутри
В массовом представлении угроз информационной безопасности главным врагом остаётся внешний хакер. Однако многолетняя практика эксплуатации корпоративных ИТ-систем показывает более неприятную реальность.
Привет! Меня зовут Денис, я руковожу группой мониторинга и анализа инцидентов информационной безопасности. Мы отслеживаем события в инфраструктуре, ищем подозрительную активность, расследуем инциденты, взаимодействуем с внешним SOC и помогаем сотрудникам разбираться с вопросами киберграмотности.
За последние пару лет стало особенно заметно: атаки меняются быстрее, чем процессы защиты успевают адаптироваться. Они становятся дешевле, масштабнее и доступнее — во многом за счет ИИ.
В этой статье разбираю, какие именно изменения привнес ИИ в атаки, почему классическая модель защиты начинает давать сбои и где ИИ в защите действительно приносит практическую пользу.
Конференция Cloud Security Day от Яндекса и SolidLab оказалась не очередной конференцией про облака вообще, а довольно точным срезом того, как рынок ИБ смотрит на 2026 год. На сцене много говорили про гибридную инфраструктуру, импортозамещение, ИИ, атаки на цепочки поставок и защиту учетных данных. В кулуарах разговор был еще прямее: почти никто уже не спорит, что архитектура усложнилась, а окно на спокойную раскачку у компаний сужается.
Для ИБ-команд это важный сигнал. Дискуссия давно ушла от вопроса, идти ли в облако. Сейчас вопрос другой: как жить в смешанной среде, где часть сервисов остается в своем контуре, часть уходит провайдеру, а атакующий работает сразу по обеим сторонам.
Хабр, привет!
На связи Александр Леонов, ведущий эксперт PT Expert Security Center и дежурный по самым опасным уязвимостям месяца. Мы с командой аналитиков Positive Technologies регулярно исследуем информацию об уязвимостях из баз и бюллетеней безопасности вендоров, социальных сетей, блогов, телеграм-каналов, баз эксплойтов, публичных репозиториев кода и выявляем во всем этом многообразии сведений трендовые уязвимости. Это те уязвимости, которые либо уже эксплуатируются вживую, либо будут эксплуатироваться в ближайшее время.
С прошлого дайджеста мы добавили еще одну трендовую уязвимость. Подробности о ней читайте под катом.
Привет, Хабр!
Ну вот вы ставите Яндекс Go, жмёте «Разрешить» на всё подряд — микрофон, контакты, местоположение. Такси же, надо. А потом выясняется, что приложение лезет в буфер обмена. 16 раз в разных местах кода. Зачем такси буфер обмена — я так и не понял.
Короче, я взял семь популярных Android-приложений и разобрал их по косточкам. SAST, реверс-инжиниринг, декомпиляция DEX, разбор манифестов, ковыряние в нативных библиотеках. Под раздачу попали: Яндекс Go, Карты, Музыка, Пэй, Телемост, Mir Pay и мессенджер МАКС (бывший ICQ New / VK Messenger).
Спойлер: один мессенджер умеет распознавать ключевые слова прямо в аудиопотоке звонков. Не метаданные, не «кто кому звонил» — а именно слова.
<cut/>
Привет, Хабр! На связи команда UserGate uFactor и я, Иван Князев!
Угрозы для устройств на базе Android хорошо изучены, но вместе с тем вариантов их реализации становится всё больше. Если ранее злоумышленники делали акцент на сложный функционал и полный контроль над устройством, то сегодня они всё чаще выбирают облегчённые версии, которые проще распространять и сложнее детектировать.
Привет, Хабр! Меня зовут Артём Чуйков, я инженер компании Innostage — первого кибериспытанного интегратора сервисов и решений в области цифровой безопасности. Я занимаюсь внедрением межсетевых экранов на промышленных предприятиях, и сегодня хочу поделиться практическим опытом.
Ни для кого не секрет, что злоумышленники постоянно пытаются атаковать наши киберрубежи. Успешная атака на офисную сеть приводит к утечкам данных, зашифрованным дискам, потерянным деньгам и репутации. Как правило, такой ущерб можно компенсировать: восстановить данные, вернуть инфраструктуру в рабочее состояние, извиниться перед клиентами и контрагентами.
Однако успешная атака на автоматизированные системы управления технологическими процессами — это уже совсем другая история. Это обесточенные города, остановленные производства, потенциальные техногенные катастрофы. Представьте, к примеру, атомную электростанцию, управлять которой могут злоумышленники, получившие нелегитимный доступ.
Именно поэтому внедрение систем обеспечения информационной безопасности позволяет эффективно противостоять подобным угрозам.
Для объектов критической информационной инфраструктуры внедрение СОИБ является не просто рекомендацией, а требованием регуляторов — ФСТЭК, ФСБ, а также стандартов, таких как ГОСТ Р ИСО/МЭК 27001 и других.
С точки зрения инженера техдолг редко выглядит как одна большая проблема. Скорее как набор: временный сервис на старом Windows Server, который внезапно стал критичным; поддержка в рабочих чатах без нормальных SLA и приоритизации; bus factor = 1 по ключевой системе, где все держится на одном человеке; бэкапы, которые давно никто не поднимал в тесте. Пока все живет — это считается разумными компромиссами. До первого серьезного сбоя.
За нами кто-то следит!
Вот ты занят своим делом, и тебе звонят с предложением купить недвижимость во Владивостоке, а ты даже не понял, откуда у них твой номер. Как вообще они о тебе узнали?
Т.е. с одной стороны РКН вводит огромные штрафы за утечку персональных данных, а с другой - постоянно идут звонки с предложениями, хотя ты своих контактов не оставлял, и разрешения на перезвон не давал.
Внутри:
- 4 метода слива наших телефонов
- Как и кому сливаются сайты (домены) которые мы посещаем
- Как сливаются входящие и исходящие на наш номер телефона
и как с этим бороться.
Чем должен заканчиваться пилот по кибербезопасности — покупкой? В идеале да. Но на практике он часто заканчивается неопределённостью: не из‑за плохого продукта или пустого бюджета, а потому что непонятно, как вообще оценивать результат. Достаточно ли показанных характеристик для реальной защиты? Не начнёт ли система «тормозить» сервисы под боевой нагрузкой? Насколько комфортной будет долгосрочная эксплуатация? На примере межсетевого экрана веб‑приложений (WAF) разберем, по каким критериям можно оценить пилот и на что смотреть заказчику в отчетах по пилоту, чтобы было проще принять решение о покупке.
За последние два‑три года компании в РФ перестали относиться к ИИ как к «чудо машине» и начали встраивать его в рабочие процессы: от помощи специалистам контакт‑центров в чатах с клиентами и «серым» помощникам разработчиков до написания полноценных продуктов. Если раньше нельзя было сказать, что ты использовал ИИ для задачи, так как тебя закидают помидорами, сегодня — этот навык must have для каждого. В этой статье речь пойдет о безопасной разработке с использованием генеративных ИИ. Крупные опросы и отчёты фиксируют одинаковую картину: большинство организаций уже экспериментируют с LLM‑системами или планируют их внедрение, в том числе в зонах, где раньше работали только люди или классические скрипты.
30 часов хронологии того, как агент Cursor, Railway API и индустрия, которая продаёт безопасность быстрее, чем её реализует, положили малый бизнес, обслуживающий прокатные компании по всей стране.
Меня зовут Джер Крейн, я основатель PocketOS. Мы делаем ПО для прокатного бизнеса — в первую очередь для аренды автомобилей: бронирования, платежи, управление клиентами, отслеживание транспортных средств. Некоторые наши клиенты с нами уже больше 5 лет и они буквально не могут работать без нас.
Вчера днём ИИ-агент на базе Cursor с Claude Opus 4.6 от Anthropic удалил нашу продакшн-базу данных и все резервные копии на уровне тома одним API-вызовом к Railway, нашему инфраструктурному провайдеру.
На это ушло 9 секунд.
Затем агент, когда его попросили объяснить произошедшее, написал признание — с перечнем конкретных правил безопасности, которые он нарушил.
