Pre-deploy SAST, severity-based policy gating, multi-CI. Flip a toggle on a project - before every release the scanner runs over the code, findings appear in the same deploy tab, and policy decides whether it can ship.
SAST in classic DevOps is separate overhead: set up a CI template, write a config per language, agree on a severity policy, wire reports into the pipeline and not forget gating. Often there's no time - so the check is either a checkbox or never runs.
In Opsy, security checks are built into deploy. No separate pipelines or YAML configs.
It detects the language from repository contents and selects relevant scanners. No setup - enable pre-deploy checks and the project picks up the configuration.
Want more precision - turn off auto-select and pick a specific set of plugins. The architecture is pluggable: each scanner is a separate module, and new ones are added without touching core.
In the classic setup, security features are tied to the provider (GitLab Ultimate, GitHub Advanced Security). Opsy gives one UX over all three: the same SAST stage is injected into the pipeline, and artifacts are collected and parsed into a common findings format.
A stage in .gitlab-ci.yml, reading artifacts from the job.
Reading build artifacts via REST API.
Artifacts pulled via GitHub API + ZIP.
An org-level severity matrix (part of Policy & governance): critical blocks, high warns, the rest is shown. The decision is visible right in the deploy UI.
Example of what an engineer sees on deploy:
Every scanner run is stored at the org level: who initiated the deploy (via RBAC), which commit, which findings, whether there was a gating decision and who approved it. For incident review and compliance: «show who shipped to prod with open criticals and when».
We'll deploy into a test environment and go through your security checklist.