CodeQL 2.27.2: проверьте собственные Go-запросы и macOS CI

В обновлении CodeQL изменили граф потока управления для Go. Добавились узлы, недостижимые участки исключаются, изменились границы basic blocks. Старые запросы, завязанные на прежнее представление CFG, могут потребовать правок. Например, BasicBlocks::Cfg удалён.

Отдельная ловушка — traced analysis компилируемых языков на macOS. Режимы autobuild/manual не поддерживаются на macOS 27 с любым Xcode, а также на macOS 26 с Xcode 27. GitHub рекомендует для этих режимов оставаться максимум на macOS 26 и Xcode 26. Работа над режимом none не означает, что он уже заменил этот путь.

Перед обновлением runner проверьте матрицу ОС/SDK и свои QL-паки. Новая версия анализатора сама по себе не доказывает, что конкретный репозиторий проверяется прежним способом.

Изменения и ограничения GitHub

Библиотека хакера

🧑‍💻 Какие навыки помогают вам в разработке в 2026 году?

Что вы чаще используете в работе? В каких задачах помогает ИИ, а где проще справиться самостоятельно?

Мы решили собрать портрет современного разработчика — и приглашаем вас поделиться своим опытом. Расскажите, какие навыки вам пригодились и как вы используете ИИ. Если обходите его стороной, нам тоже интересно узнать почему.

Опрос анонимный и займёт около 5 минут. Результаты опубликуем в общем большом исследовании.

👉 Пройти опрос

ZAP в CI: порядок jobs влияет на результат

Automation Framework выполняет задания сверху вниз по плану. Если passiveScan-wait поставить до spider или импорта запросов, ждать ему ещё нечего. Отчёт стоит формировать после того, как закончилась нужная проверка.

При запуске с cmd и autorun по умолчанию код выхода 0 означает завершение плана без ошибок и предупреждений, 1 — ошибки, 2 — предупреждения. Это не автоматическое утверждение «уязвимостей нет».

Чтобы CI реагировал на security alerts, в exitStatus задают errorLevel или warnLevel. Порог включает выбранный риск и выше, значения кодов выхода тоже настраиваются. Обычно этот job ставят последним.

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

Устройство Automation Framework

Библиотека хакера

SOPS: удалить получателя ещё не значит сменить ключ данных

Если ключ участника команды скомпрометирован, одной правки .sops.yaml недостаточно. Здесь три разные вещи: список получателей, ключ шифрования файла и сами пароли или API-токены внутри.

В SOPS рекомендуют сначала убрать скомпрометированный ключ из конфигурации. Затем для каждого затронутого зашифрованного файла выполнить два шага. Пример для файла secret.sops.yaml:

sops updatekeys secret.sops.yaml
sops rotate --in-place secret.sops.yaml

updatekeys синхронизирует получателей с конфигурацией. Проверьте предлагаемые изменения перед подтверждением. rotate создаёт новый ключ данных и перешифровывает значения, а --in-place сохраняет результат в файл.

Только после обновления затронутых файлов меняйте пароли и API-токены внутри. Иначе свежие секреты могут оказаться доступны прежнему ключу.

Уже прочитанный секрет или старую копию файла эта процедура не отзывает. Ротация ключа SOPS также не меняет сам API-токен у его провайдера.

Порядок ротации из документации SOPS

Библиотека хакера

#cheat_sheet

У образа есть подпись. Чья?

В keyless-проверке Cosign важно заранее определить, какому подписанту вы доверяете. Наличие корректной подписи от постороннего издателя не выполняет вашу политику доверия.

У cosign verify для этого есть два параметра:

— --certificate-identity задаёт ожидаемую identity подписанта.
— --certificate-oidc-issuer задаёт ожидаемого OIDC-провайдера identity подписанта.

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

По умолчанию Cosign также сверяет digest образа с digest в payload подписи. Параметр --check-claims=false отключает проверку утверждений в payload. Это не безобидный способ убрать ошибку в CI.

Даже корректная подпись ожидаемого издателя не доказывает отсутствие уязвимостей в образе. Она отвечает на другой вопрос: соответствует ли подписанный артефакт заданным условиям доверия.

Sigstore: проверка identity, issuer и claims

Библиотека хакера

#resource_drop

Falco: одно or меняет смысл детекта

Есть условие для открытия файла процессом Apache:

evt.type=open and proc.name=apache

Хочется добавить nginx. Но при дописывании or proc.name=nginx через override Falco просто присоединяет текст к исходному условию. Получается логика «Apache открывает файл ИЛИ nginx делает что угодно».

Если нужны открытия файлов обоими процессами, итоговое условие должно группировать имена:

evt.type=open and (proc.name=apache or proc.name=nginx)

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

Локальный override загружается после базового определения. Для новых настроек используйте секцию override с нужным действием append или replace. Старый верхнеуровневый append: true помечен устаревшим.

Перед внедрением проверьте в лаборатории и события, которые должны вызвать алерт, и те, которые должны пройти без него. Сам алерт ещё не подтверждает инцидент.

Falco: override и приоритет логических операторов

Библиотека хакера

#cheat_sheet

Отчёт CSP пришёл. Блокировки могло и не быть

Заголовок Content-Security-Policy-Report-Only помогает увидеть нарушения будущей политики, но сам ресурсы не блокирует. Это режим наблюдения перед включением ограничений. Через HTML meta-тег его задать нельзя, нужен HTTP-заголовок.

В руководстве web.dev strict CSP строится на nonce или хешах скриптов, а не только на списке разрешённых доменов. Выбор зависит от того, как отдаётся HTML:

— Для серверного рендеринга подходит nonce: криптографически случайное непредсказуемое значение, новое для каждого ответа. Постоянный nonce в шаблоне эту задачу не решает.
— Для статического или кешируемого HTML подходят хеши inline-скриптов. Изменились пробелы внутри скрипта, изменился и хеш.

strict-dynamic распространяет доверие на скрипты, которые динамически создаёт уже доверенный скрипт. Поэтому инъекция в URL такого загрузчика всё ещё опасна.

Перед включением блокировки уберите несовместимые inline-обработчики и javascript: URI, проверьте приложение локально и на staging. Report-Only поможет оценить нарушения на реальном трафике. Затем ограничения включаются заголовком Content-Security-Policy.

CSP дополняет исправление XSS, а не заменяет его. Полные образцы политики и порядок внедрения есть в руководстве web.dev.

Библиотека хакера

#resource_drop

Security-лог не должен становиться хранилищем токенов

Для расследования отказа в доступе нужны время, приложение, действие, результат и контекст пользователя. Полный заголовок Authorization для этого обычно не нужен. Зато его запись создаёт ещё одно место, откуда можно украсть токен.

OWASP предлагает связывать события одной операции через interaction ID. Так можно сопоставить запрос, ошибку проверки и итог операции, не складывая в журнал пароли, ключи шифрования и значения сессий.

Отдельная ловушка: поля лога тоже могут прийти от атакующего. Переводы строк CR/LF и разделители требуют обработки, а значения нужно кодировать под формат вывода. Иначе пользовательское поле способно превратиться в поддельную строку журнала.

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

Проверяйте и отказ логирования: заполненный диск, недоступное хранилище, потерю прав записи. Журнал не должен сам становиться причиной отказа приложения.

OWASP Logging Cheat Sheet

Библиотека хакера

#cheat_sheet

RuntimeDefault не обязательно включён по умолчанию

В Linux seccomp ограничивает системные вызовы процесса. В Kubernetes профиль RuntimeDefault можно запросить явно. Фрагмент спецификации Pod:

spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault

Так профиль запрашивается на уровне Pod.

Если профиль не указан, решает конфигурация kubelet. При включённом seccompDefault используется RuntimeDefault, иначе документированный вариант по умолчанию — Unconfined, без seccomp-ограничений.

Есть два существенных ограничения:

— Профиль определяет container runtime. Набор разрешённых вызовов может различаться между runtime и версиями. Рабочая нагрузка способна сломаться, если нужный syscall запрещён.
— Контейнер с privileged: true работает как Unconfined. Назначением seccomp-профиля это не исправить.

Включение node defaulting не дописывает поле в YAML Pod. Для проверки фактически применённого профиля документация предлагает смотреть runtime specification через crictl inspect. Начните с части узлов и проверьте рабочие сценарии перед расширением внедрения.

Kubernetes: профили seccomp и RuntimeDefault

Библиотека хакера

#cheat_sheet

capa: от совпадения к ручной проверке

HTTP, XOR, создание процессов: capa ищет в программе признаки таких возможностей по набору правил. При статическом анализе это ещё не доказательство, что файл выполнил каждое действие.

Флаг -vv показывает, какие признаки совпали с правилом и по каким адресам их искать при ручном разборе. Для просмотра результатов есть Explorer Web и standalone HTML для локальной работы.

Упаковка и обфускация могут скрыть признаки, а установщики и рантаймы — усложнить трактовку. На скриншоте — исходный пример Explorer с capa 7.0.1 от 2024 года. Это иллюстрация интерфейса.

Репозиторий и примеры
#tool_of_the_week

Библиотека хакера