DevSecOps без пайплайнов - Security & SAST в Opsy для Kubernetes
Security · SAST

DevSecOps без пайплайнов.

SAST до деплоя, policy gating по severity, multi-CI. Включил toggle на проекте - перед каждым релизом сканер прогоняется по коду, findings в той же вкладке деплоя, policy решает можно ли катить.

zero-config GitLab · Azure · GitHub policy gating audit

SAST в классическом DevOps - это отдельный overhead: завести CI-template, написать конфиг под каждый язык, договориться о severity-политике, прикрутить отчёты к пайплайну и не забыть про gating. Часто на это не хватает времени - и проверка либо стоит галочкой, либо не запускается.

В Opsy security-проверки встроены в деплой. Никаких отдельных пайплайнов и YAML-конфигов.

Zero-config

Opsy сам выбирает сканер по типу проекта.

Определяет язык по содержимому репозитория и подбирает релевантные сканеры. Настраивать не нужно - включил pre-deploy checks, и проект подхватывает конфигурацию.

Java (Maven / Gradle)Semgrep + SpotBugs
PythonSemgrep + Bandit
GoSemgrep + gosec
Node / JS / TSSemgrep + njsscan
Любой языкTrivy fs + npm/pip/go audit
Customвыбор плагинов через UI / API

Хочется точнее - можно выключить auto-select и выбрать конкретный набор плагинов. Архитектура pluggable: каждый сканер - отдельный модуль, новые добавляются без правок core.

Multi-CI

SAST в GitLab, Azure DevOps и GitHub - без отдельных лицензий.

В классике security-фичи привязаны к провайдеру (GitLab Ultimate, GitHub Advanced Security). У Opsy единый UX поверх всех трёх: в пайплайн вставляется одинаковая SAST-стадия, артефакты собираются и парсятся в общий формат findings.

GitLab CI

Инъекция SAST-стадии

Стадия в .gitlab-ci.yml, чтение артефактов из job.

Azure DevOps

Шаг в Azure Pipelines

Чтение build artifacts через REST API.

GitHub Actions

Workflow-job со SAST

Artifacts тянутся через GitHub API + ZIP.

Policy gating

Severity блокирует деплой в Kubernetes.

Severity-матрица на уровне организации (часть Policy и Governance): critical блокирует, high предупреждает, остальное отображается. Решение видно прямо в UI деплоя.

Critical
Block
High
Warn
Medium
Info
Low
Info
Info
Info

Пример того, что видит инженер на деплое:

Audit

Вся история SAST-runs привязана к деплою.

Каждый запуск сканера хранится на уровне организации: кто инициировал деплой (через RBAC), какой коммит, какие findings, было ли gating-решение и кем одобрено. Для разборов инцидентов и compliance: «покажите, кто и когда катил в прод с открытыми critical».

Безопасность на входе, а не после инцидента.

Развернём в тестовом контуре и пройдём ваш security-чеклист.