Репозиторий содержит набор утилит для DevOps-инженеров: инструмент живёт в своём каталоге, имеет независимую версию (<инструмент>-vX.Y.Z) и, если для него есть поставка в контейнере, свой образ в GitHub Packages. Сейчас это cio (Container image optimizer) и sqlbrc (SQL backup, restore and clone); состав и версии — в README.md. Политика ниже распространяется на все инструменты репозитория, включая те, что появятся позже. Ниже — как сообщить об уязвимости и что считается предметом отчёта.

Версии у инструментов независимые: поддерживаемая версия — это строка инструмента, а не номер, общий для репозитория. Строка нового инструмента появляется в таблице вместе с его первым релизом, а сведения о текущих версиях — в README.md.

• Используйте приватный отчёт: вкладка Security → Report a vulnerability (https://github.com/DevOps-spb-ru/DevOps-Engineer-Tools/security/advisories/new). Так отчёт виден только мейнтейнерам.
• Не создавайте публичный issue и не публикуйте эксплойт до выхода исправления.
• Приложите: инструмент и версию (cio --version или sqlbrc --version), способ запуска (бинарь из релиза, локальная сборка, контейнер, служба systemd), команду воспроизведения и ожидаемое поведение.
• Что помогает для конкретного инструмента: для cio — версии Docker и Trivy либо команду запуска контейнера; для sqlbrc — версию PostgreSQL, значение postgres.mode и вырезанный до несекретных полей конфиг.
• Секреты, пароли, содержимое чужих образов и дампов баз в отчёт не включайте: достаточно описания.

Исправление выпускается для поддерживаемых версий затронутого инструмента (см. таблицу выше) и публикуется отдельным релизом с тегом <инструмент>-vX.Y.Z: версии у инструментов независимые, поэтому исправление в sqlbrc не требует релиза cio (и наоборот).

• cio: разбор аргументов, чтение образов через Docker Engine API, правила анализа, форматы отчётов (table, json), выход за пределы допустимых путей, коды возврата --fail-on.
• sqlbrc: обход проверок «своя ли база» (databases.pattern, pg.ValidateDBName) и server.read_only; сборка аргументов для pg_dump, pg_restore, psql и pg_isready; очистка базы при восстановлении (--clean --if-exists); каталог бэкапов и политика хранения (storage.dir, store.Plan); веб-интерфейс и API: аутентификация (bcrypt-хэши, сессии в памяти, предел неудачных попыток входа), защита от подделки запросов, cookie сессии, токены из auth.token_file, отказ выдавать API по cookie-сессии.
• Общее для инструментов: утечка чувствительных данных (секреты из истории сборки образа, пароли и токены в отчёте, файлы, записанные с недостаточно строгими правами) и выход за пределы каталогов, которые инструменту разрешены.
• Релизные артефакты любого инструмента: бинари из GitHub Release, SHA256SUMS, SBOM, attestation сборки, образы ghcr.io/devops-spb-ru/<инструмент> (включая метки и состав).
• Workflows репозитория: инъекция в run-блоки, не пиннутые экшены, избыточные права GITHUB_TOKEN, отравление кэша.

• Уязвимости в сторонних компонентах: Trivy, Docker Engine, PostgreSQL и утилиты pg_*, дистрибутивные пакеты базовых образов, сами сканируемые образы и обслуживаемые базы. Сообщайте в upstream; мы обновляем версии по своим каналам (Dependabot, .github/dependabot.yml).
• Доступ к docker.sock у cio: образ работает под непривилегированным пользователем, а доступ к сокету демона (root:root, 0660) выдаётся группой сокета (--group-add). Это осознанный компромисс, описанный в Container image optimizer/README.md.
• Требование прав pg_dump и pg_restore у sqlbrc: сервис запускает только перечисленные в sudoers утилиты от имени владельца кластера (postgres.sudo_user). Более широкие права sudo на сервере — вопрос конфигурации сервера, а не уязвимость сервиса.
• Находки в отчёте по чужому образу или чужой базе (уязвимости, секреты, ошибки сборки): это результат анализа, а не уязвимость инструмента.
• Развёртывание: доступность интерфейса в доверенной подсети, содержимое конфигов установки и пароли стендов — настройки конкретной инсталляции, а не код репозитория.

• Зависимости обновляются Dependabot: модули Go каждого инструмента (gomod в его каталоге), GitHub Actions, образы из Dockerfile. Сторонние экшены закреплены по SHA.
• Статический анализ по каждому модулю: golangci-lint с набором gosec, CodeQL и govulncheck (достижимые уязвимости зависимостей).
• Сканирование: Trivy (файловая система, Dockerfile, образ каждого инструмента) в CI; находки CRITICAL/HIGH (без исправления) роняют прогон, и те же уровни уходят в GitHub Security (отчёт не показывает находки ниже уровня «ворот»).
• Секреты: проверка всей истории репозитория gitleaks; правило secret-in-layer ищет секреты в истории сборки образа. В тестовых данных — только фиктивные значения.
• Релиз: SBOM и attestation сборки рядом с бинарями и образом, подпись образа cosign в keyless-режиме; публикация — только по тегу <инструмент>-vX.Y.Z.
• Новый инструмент добавляется по чеклисту CONTRIBUTING.md («Как добавить новый инструмент»): он получает собственные job'ы линта, проверки зависимостей, тестов и сборки, строку в этой политике и запись в таблице инструментов README.md. Поэтому охват политики не сужается с ростом числа инструментов.