OpenASOC · application security
OpenASOC puts first the vulnerabilities that are reachable in your code and already being exploited. It brings every code check into one flow: it runs analysers for code, dependencies, containers, IaC and web applications, merges duplicates and links related findings. Priority is based on CVSS, EPSS, KEV and context, plus a reachability check of the vulnerable code. A CI/CD gate stops a dangerous release and signs its verdict. Everything runs inside your perimeter.
Interface
Security dashboard: from thousands of analyser findings to a short queue of real risks and a signed release verdict.
Demo data.
Why now
According to Verizon DBIR 2026, a third party is involved in 48% of breaches. Third-party packages, pipeline tokens and keys in repositories have become an easy way in, while standalone scanners produce thousands of scattered findings with no priority. You need a single flow: every check, one queue and a release decision before production.
Attackers stole a TanStack token through GitHub Actions settings — and published infected package versions within six minutes. Manual dependency review can’t keep up with that pace.
TanStack postmortem, 11 May 2026The first wave in September 2025 hit more than 500 packages; the second, on 24 November 2025, reached 796. Yesterday’s trusted dependency can turn malicious today.
Kaspersky Securelist, DatadogThat’s 34% more than a year earlier. And 64% of the secrets found in 2022 have still not been revoked.
GitGuardian, 2026How it works
20 SAST and secrets analysers, 6 SCA tools, Trivy and Grype for images, Checkov and OPA for IaC, DAST engines and MobSF — launched from CI or the CLI.
Matches from different analysers merge into one record, and related findings are grouped. The team sees the problem, not scattered scanner reports.
A base score factors in CVSS, EPSS, KEV and context; correlation produces a 0–100 risk. For 6 languages, OpenASOC checks whether the vulnerable code is reachable.
The CI/CD gate decides whether a release can ship; in PRs, only new findings count. The verdict is signed with Ed25519 and verified with openasoc gate verify.
Capabilities
Semgrep, gosec, bandit, SpotBugs, PVS-Studio, Joern, Cppcheck, Infer and more — for Python, Go, JavaScript, TypeScript, PHP, Ruby, Kotlin, Java, C, C++ and C#. Secrets are found by gitleaks and TruffleHog.
6 SCA analysers: Trivy, Grype, Syft, OWASP Dependency-Check, ORT and ScanCode. Software composition in CycloneDX and SPDX; vulnerability status in OpenVEX and CSAF.
Containers: Trivy and Grype. IaC: Checkov and OPA/Rego policies for Terraform, CloudFormation, Kubernetes and Helm. DAST: 14 engine slots — ZAP, Playwright, Nuclei, ffuf, sqlmap-safe and more. Mobile builds: MobSF.
For C/C++, C#, Go, Java, JS/TS and Python, OpenASOC checks whether vulnerable code is reachable from your application and returns one of 10 verdicts. The team starts with what is really called.
The formula is open: base score 0–10 = 0.4·CVSS + 0.35·EPSS·10 + 0.25·KEV·10 + context. Correlating findings yields a final 0–100 risk and 6 evidence levels.
Matching findings from different analysers are merged; related ones are grouped across 11 link types. For disputed duplicates, you can enable an LLM judge.
Thresholds for SAST, SCA, secrets, containers, IaC, DAST, mobile and licences. In PRs, “new only” mode keeps legacy debt from blocking development. The verdict is signed with Ed25519.
GitHub Action, GitLab templates, an Azure Pipelines step; statuses and comments in Bitbucket and Azure DevOps. Tasks go to Jira, ServiceNow, YouTrack and Yandex Tracker; notifications to Slack, Teams, PagerDuty, Telegram and email.
A tamper-protected log, reports in PDF, XLSX, CSV, JSON and ZIP, and events to SIEM via a signed webhook. Evidence packs for SOC 2, ISO 27001, PCI DSS 4.0.1 and 152-FZ (Russian personal data law) — 23 controls.
Who it’s for
One deduplicated queue from every analyser, a 0–100 risk based on CVSS, EPSS, KEV and context, reachability analysis, gate thresholds for each check type and 9 vulnerability databases, including BDU FSTEC.
Checks as a ready-made step in GitHub, GitLab and Azure Pipelines, or via the CLI in any pipeline. Only new findings in PRs; tasks go straight to the tracker. The “OpenASOC Guard” VS Code plugin and SARIF export.
A tamper-protected log, SBOM in CycloneDX and SPDX, VEX, a signed verdict for every release and evidence packs for SOC 2, ISO 27001, PCI DSS 4.0.1 and 152-FZ.
Deployment
openasoc installer: init, generate, pull, up, down, status, logs, doctor, migrate, backup, restore, set-admin-password; upgrade --to with a snapshot and automatic rollback30-day pilot
We pick repositories and pipelines and agree on success criteria with AppSec and development.
We deploy inside your perimeter with the openasoc installer — in the first days of the pilot.
We scan your repositories in observation mode: the gate issues verdicts but doesn’t block merges.
A report: findings before and after deduplication, reachable vulnerabilities, what the gate would have stopped — and a decision on production rollout.
From you: a server inside your perimeter and access to repositories and CI. For air-gapped networks, we deliver vulnerability databases as signed offline packages.
Questions
We haven’t run our own accuracy benchmark, and we don’t promise numbers. OpenASOC doesn’t replace analysers — it brings 20 of them into one queue, merges duplicates and sets priorities. We measure the noise on your code during the pilot: how many findings before deduplication, how many after and how many of them are reachable.
There is no ready-made Jenkins integration. There’s a GitHub Action, GitLab templates and an Azure Pipelines step; in other build systems, checks and the gate run via the CLI — the scan and gate commands as a regular pipeline step.
No. In PRs, the gate can count only new findings, and thresholds are set separately for SAST, SCA, secrets, containers, IaC, DAST, mobile builds and licences. During the pilot, the gate runs in observation mode and doesn’t block merges.
Yes. Vulnerability databases, including BDU FSTEC, arrive as signed offline packages, and platform images are verified with cosign. No GPU needed.
Via a JSON webhook signed with Ed25519: the receiver can verify that an event came from OpenASOC and wasn’t altered. CEF, syslog and LEEF formats are not available.
No. The packs for SOC 2, ISO 27001, PCI DSS 4.0.1 and 152-FZ — 23 controls in total — collect evidence for auditors and speed up audit preparation, but they are not a certification.
There is no dedicated GOST R 56939 profile. Out of the box you get BDU FSTEC, SBOM, a tamper-protected log and a signed verdict for every release; we’ll work out how to fit them into your process during the pilot.
OpenASOC pilot
Submit a request — we’ll agree on the repositories, the pipeline and the success criteria.
We’ll contact you at the email you provided to arrange your OpenASOC pilot.
Other OpenZTA platforms