Каждый день приходит куча писем: реклама, счета, письма от коллег, рассылки, спам. Если не разбирать, ящик лопается, и ты уже не понимаешь, где важное, а где мусор. С управлением уязвимостями то же самое: сканеры шлют находки постоянно, и если их не сортировать, ты утонешь.Read more
!!!Черновик!!!!
Сегодня разберем не гипотетическую угрозу, а реальный инцидент, который произошел из-за того, что кто-то оставил открытой дверь в цепочке поставок.
Что случилось
Злоумышленники получили доступ к Personal Access Token (PAT) от Docker Hub. Важный момент: у этого токена были избыточные права на запись. В итоге в официальный репозиторий Kong был загружен вредоносный образ. Внутри сидел майнер XMRig, который стучался на пул pool.supportxmr.com.
Самое противное, что этот образ не лежал где-то на пиратском сайте. Он был подписан тем самым доверенным аккаунтом, которому разработчики привыкли верить. Вредоносный образ находился в реестре с 22 декабря 2024 года по 3 января 2025-го. Если хотите проверить свои логи, ищите хэш: sha256:a00659df0771d076fc9d0baf1f2f45e81ec9f13179f499d4cd940f57afc75d43.
Как токен утек
Официальная причина утечки PAT не раскрыта. Но в мире CI/CD есть классический сценарий, который приводит к такому ровно так же часто, как и открытый ключ под ковриком. Это GitHub Actions и особенность под названием pull_request_target.
В отличие от обычного pull_request, этот триггер запускается в контексте базового репозитория. Если настроить workflow неаккуратно, код из пул-реквеста форка может получить доступ к секретам базового репозитория.
Я сам в практике видел, как люди настраивают CI/CD «на бегу», лишь бы работало, и оставляют токены с правами администратора. «Да кому он нужен, этот токен от реестра», — думал я раньше. После этой истории перестал. Один такой токен превращает ваш кластер в ферму для майнинга.
Архитектурные уроки
CI/CD — это часть поверхности атаки. Раньше считалось: если код прошел ревью и лежит в Git, он безопасен. Ага. Пайплайн — это такой же компонент инфраструктуры, как и Kubernetes. Если его скомпрометировали, он соберет и запустит всё, что скажет атакующий.
Доверие к реестру не заменяет проверку артефакта. То, что образ лежит в официальном Docker Hub, не значит, что он безопасен. Нужна криптографическая проверка. Тег — это как подпись на коробке: её можно переклеить. Digest — это отпечаток содержимого. Если его подменили, вы это увидите. Admission controller (например, Kyverno) должен отклонять образы, digest которых не совпадает с подписью.
Прозрачные логи (Rekor). Когда вы подписываете образ через Cosign (keyless), запись уходит в публичный лог Rekor. Если образ в реестре подменили, а подпись осталась от старого доброго коммита, Rekor это покажет.
Что делать прямо сейчас
Ротация секретов. Если используете PAT для реестров — убедитесь, что у них минимальные права (только push/pull).
Аудит workflows. Проверьте GitHub Actions. Используете pull_request_target? Убедитесь, что код из форков не получает доступ к секретам.
Проверка по digest. В настройках admission controller укажите проверку образов по digest, а не только по тегам.
Мониторинг. Настройте алерты на скачки CPU. Если кластер вдруг начал жрать 100% ресурсов в 3 часа ночи, возможно, у вас в поде поселился «гость» с pool.supportxmr.com.
Итог
Supply chain атака на Kong — классическая история о том, что самая слабая точка — не код, а люди и процессы. Это как с ключами от квартиры: можно поставить бронедверь, но если ключ оставить под ковриком, дверь не поможет. Проверяйте всё: от кода до подписи.
Обсуждаем статьи в Telegram-канале. Недушный ИнфоБез.
GitHub Advisory (оригинал): https://github.com/Kong/kubernetes-ingress-controller/security/advisories
Про pull_request_target (официальная документация GitHub): https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target
Rekor (прозрачный лог Sigstore): https://docs.sigstore.dev/logging/overview/
Инструкция по проверке digest в Kyverno: https://kyverno.io/policies/other/verify-image/verify-image/
!!!Черновик!!!!
Вайб-кодинг здорового человека: как я построил систему автоматизации для ИИ-разработки
В середине 2025-го мне стало интересно попробовать написать код с помощью ИИ. Не потому что мне кто-то рассказал про вайб-кодинг — я тогда вообще не знал такого слова. Просто было интересно: получится или нет. Через три месяца у меня была игра. Настоящая, с сервером, авторизацией и онлайном.Read more
!!!Черновик!!!!
Soft skills в DevSecOps: как быть инфобезопасником, которого не хочется выгнать
Безопасников никто не любит. Это факт. Не потому что мы плохие люди, а потому что наша работа — говорить «нет». Разработчик хочет выпустить фичу, а мы говорим «подожди». Бизнес хочет быстрее, а мы говорим «нельзя». Конфликт встроен в роль.
Можно с этим жить и дальше — приходить в конце проекта с папкой замечаний, слышать за спиной «опять этот пришёл» и видеть, как на встрече кто-то демонстративно тянется к окну. А можно попробовать иначе.Read more
В стратегиях есть башни. Ты ставишь их по карте, они не бегают за врагом и не лезут первыми в драку. Стоят и смотрят. Пока всё тихо, ты их вообще не замечаешь. Как только кто-то входит в радиус — тревога и огонь. Runtime security для меня выглядит так же: фоновая стража, которая молчит, пока всё нормально, и реагирует, когда началось что-то странное.Read more
В Dota есть автоатака. Ты не жмёшь кнопку на каждый удар: герой бьёт сам, пока цель в радиусе. Ты занят другим: позиционированием, способностями, картой. Автоатака работает по правилам, которые ты один раз задал. Policy as Code для меня выглядит так же. Правило описано один раз и дальше применяется без твоего участия. Не безопасник на встрече сказал «так нельзя», а admission controller отклонил манифест, потому что в нём нет resource limits.
Policy as Code — политики безопасности, описанные кодом. Не регламент в вики и не письмо в чат, а код в Git: версионируется, проходит ревью, применяется автоматически. Admission controller — компонент Kubernetes, который проверяет объект до того, как он сохранится в кластере. Разработчик получает фидбек сразу, а не через неделю на ревью и не после инцидента.
Почему дефолт — дыра
В обычном кластере политики живут в головах и в переписках. Кто-то помнит, что контейнеры не должны работать от root, кто-то помнит про лимиты, кто-то про доверенный registry. Но помнят не все и не всегда, а помнить бесполезно, если никто не проверяет. Манифест с privileged-контейнером спокойно доезжает до прода: на ревью не заметили, а после деплоя уже поздно. Правила на памяти и внимательности работают до первого отпуска или аврала. Код не забывает.
Я видел кластеры, где политики применялись руками. Специальный человек раз в месяц проходил по манифестам и оставлял комментарии. Потом он ушёл в отпуск, потом сменил проект, и политики тихо умерли. Никто не заметил: они никогда не были частью процесса. С кодом так не получится. Если политика в Git и её применяет admission controller, она работает, пока её не выключат осознанно.
Первая политика: запрет latest
Не пытайся описать всё сразу. Возьми одно правило, которое болит сегодня. Например, запрет тега latest:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: disallow-latest-tag
spec:
validationFailureAction: Audit # сначала аудит, потом Enforce
background: true
rules:
- name: require-image-tag
match:
any:
- resources:
kinds: [Pod]
validate:
message: Укажи тег образа, лучше digest
pattern:
spec:
containers:
- image: '*:*'
- name: no-latest
match:
any:
- resources:
kinds: [Pod]
validate:
message: Тег latest запрещён
pattern:
spec:
containers:
- image: '!*:latest'
Посмотри, что она отклонила бы:
kubectl get policyreport -A
Скорее всего, выяснится, что половина команды деплоит с latest и никто об этом не задумывался. Когда картина понятна, переключи политику на Enforce. Дальше добавь второе правило (resource limits), потом третье (запрет privileged). По одному, с наблюдением, чтобы не уронить прод.
Чего не делать
Не включай все политики сразу в режиме блокировки. Аудит сначала: политика проверяет, но не блокирует.
Не пиши политики ради политик. Каждое правило должно закрывать конкретный риск, иначе это шум, который все начнут обходить.
Инструменты
Kyverno — Kubernetes-native, правила на YAML. Для многих проще всего.
OPA Gatekeeper — политики на Rego. Мощный, но язык нужно учить, порог входа выше.
Conftest — проверка конфигов в CI, ловит нарушения до того, как манифест доехал до кластера.
Kubewarden — политики на WebAssembly.
Российские: Luntry. Сверь, какие функции Policy as Code входят в твою редакцию.
Для Kyverno и Gatekeeper есть открытые библиотеки готовых политик: не пиши с нуля то, что уже написано.
Policy as Code — не про то, чтобы запретить всё, а про то, чтобы правила работали без тебя. Без неё остальные практики работают вполсилы: можно харденить контейнеры, но без проверки манифестов root вернётся при первом удобном случае. Можно спрятать секреты в Vault, но если политика не запрещает класть их в переменные окружения, кто-нибудь положит. Начни с одного правила в режиме аудита, потом переведи в блокировку, потом добавь второе. Через месяц правила будут работать сами, а ты займёшься тем, что требует твоего внимания.
Обсуждаем статьи в Telegram-канале. Недушный ИнфоБез.
