In classic DevOps, SAST is its own project: wire up a Semgrep CI template, write a config per language, agree on a severity policy, plug reports into the pipeline, and remember to add gating. Often there is just no time, so security scans either become a checkbox or never run.
In Opsy, security checks are built into deploy. Flip the toggle on a project - the scanner runs before every release, findings show up in the same deploy view, and policy decides whether the rollout proceeds. No extra pipelines, no YAML configs.
Zero-config: Opsy picks the SAST scanner by project type
Opsy detects project type from the repo (Maven/Gradle - Java, requirements.txt/pyproject - Python, go.mod - Go, and so on) and selects the right scanners. Nothing to set up - enable pre-deploy checks, and the project gets its own configuration automatically.
Need finer control - turn off auto-select and pick a specific plugin set in the UI or via API. The architecture is pluggable: each scanner is its own module, new ones drop in without touching core.
Multi-CI: SAST in GitLab, Azure DevOps and GitHub Actions - no extra licenses
Classic security features are tied to a provider: GitLab Ultimate for GitLab, GitHub Advanced Security for GitHub, separate setup for Azure DevOps. Opsy gives you a single UX over all three (see API & integrations) - the same SAST stage is injected into the pipeline, and artifacts are collected and parsed into a unified findings format.
Policy gating: severity blocks the Kubernetes deploy
Severity matrix at the org level (part of the broader Policy & governance system): critical blocks the deploy, high raises a warning, medium/low/info show up in the UI for review. Findings are normalized to a single format: severity / rule_id / file / line / message / code excerpt. The decision is visible right in the deploy view - no need to jump to a separate security dashboard.
A sample of what an engineer sees on deploy:
Audit and compliance: every SAST run tied to the deploy
Every scanner run is stored at the org level: who triggered the deploy (through RBAC & access), which commit, which findings, whether a gating decision was made and by whom. Useful for incident reviews as well as compliance asks like “show me who shipped to prod with open critical findings.”
Highlights
- Auto-select scanners by project type - no YAML or manual setup
- Semgrep for Python/Go/Node/JS/TS/PHP/Ruby
- Semgrep + SpotBugs for Java (Maven and Gradle)
- GitLab CI, Azure DevOps, GitHub Actions - one UX, no separate licenses
- Severity policies: critical blocks, high warns, medium/low show in report
- Findings with code excerpts and severity filters in the deploy UI
- Full run history tied to the deploy - audit and compliance
- Pluggable architecture: new scanners drop in without touching core
- Per-project override via UI or API for fine-grained control