SAST в классическом DevOps - это отдельный mental overhead: завести Semgrep CI-template, написать конфиг под каждый язык, договориться о severity-политике, прикрутить отчёты к pipeline и не забыть про gating. Часто на это просто не хватает времени, и security-проверка либо стоит галочкой, либо вообще не запускается.
В Opsy security-проверки встроены в деплой. Включил toggle на проекте - перед каждым релизом сканер прогоняется по коду, findings показываются в той же UI-вкладке деплоя, policy решает можно ли катить дальше. Никаких отдельных пайплайнов и YAML-конфигов.
Zero-config: Opsy сам выбирает SAST-сканер по типу проекта
Opsy определяет тип проекта по содержимому репозитория (Maven/Gradle - Java, requirements.txt/pyproject - Python, go.mod - Go и так далее) и подбирает релевантные сканеры. Ничего настраивать не нужно - включил pre-deploy checks, и проект автоматически подхватывает свою конфигурацию.
Хочется точнее - можно выключить auto-select и выбрать конкретный набор плагинов через UI или передать в API. Архитектура pluggable: каждый сканер - отдельный модуль, новые добавляются без правок core.
Multi-CI: SAST в GitLab, Azure DevOps и GitHub Actions без отдельных лицензий
В классике security-фичи привязаны к провайдеру: GitLab Ultimate для GitLab, GitHub Advanced Security для GitHub, отдельный setup для Azure DevOps. У Opsy единый UX поверх всех трёх (см. интеграции и API) - в pipeline вставляется одинаковая SAST-стадия, артефакты собираются и парсятся в общий формат findings.
Policy gating: severity блокирует деплой в Kubernetes
Severity-матрица на уровне организации (часть общей системы Policy и Governance): critical блокирует деплой, high поднимает warning, medium/low/info - просто отображаются в UI. Findings нормализуются в единый формат: severity / rule_id / file / line / message / code excerpt. Решение видно прямо в UI деплоя, не нужно идти в отдельный security-dashboard.
Пример того что увидит инженер на деплое:
Audit и compliance: вся история SAST-runs привязана к деплою
Каждый запуск сканера хранится на уровне организации: кто инициировал деплой (через RBAC и доступы), какой коммит, какие findings, было ли gating-решение и кем оно одобрено. Это полезно как для разборов инцидентов, так и для compliance-вопросов: «покажите кто и когда катил в прод с открытыми critical-проблемами».
Ключевые моменты
- Auto-select сканеров по типу проекта - без YAML и ручного setup
- Semgrep для Python/Go/Node/JS/TS/PHP/Ruby
- Semgrep + SpotBugs для Java (Maven и Gradle)
- GitLab CI, Azure DevOps, GitHub Actions - единый UX без отдельных лицензий
- Severity policies: critical блокирует, high предупреждает, medium/low - в отчёте
- Findings с code excerpts и фильтрами по severity в UI деплоя
- История всех runs привязана к деплою - audit и compliance
- Pluggable архитектура: новые сканеры подключаются без правки core
- Per-project override через UI или API для тонкой настройки