Map
Relate requirements to architecture, identities, data paths, owners, and source evidence.
Trust / Control evidence
Claims should have implementation receipts.
A transparent map of the controls Veriom implements today, the boundaries we still track, and the evidence a reviewer can inspect without confusing product behavior with certification.
Control map
Implemented, bounded, and still challengeable.
Each control pairs its intended protection with concrete engineering evidence and a known boundary. Release gates remain visible until they are actually complete.
Select a control
ImplementedRead the public security model
Workspace-scoped access
Application authorization and PostgreSQL row-level policies scope access to the active workspace.
Review evidence
API permission tests, RLS migrations, cross-tenant retrieval and cache tests
Known boundary
Some background workers require broader database visibility to claim jobs. Their queries and session context remain explicit review points.
This is a product control map, not a certification badge. Status describes the repository and deployment contract reviewed on 29 August 2026.
Assessment model
Compliance evidence is not a decorative checkbox.
Veriom can organise controls, artifacts, findings, exceptions, and review history. A qualified assessor and the applicable programme still determine certification or attestation.
Verify
Keep the exact artifact, freshness, collector, confidence, and contradiction behind each claim.
Review
Record supported, partial, gap, not applicable, or unknown without turning absence into assurance.
Decide
Preserve reviewer approval, exceptions, compensating controls, expiry, and change history.
17 open-source tools / five execution boundaries
One evidence model. Deliberately different permissions.
Repository, cloud, cluster, active-test, and runtime tools do not belong in one privileged process. Veriom declares the boundary and support state before it declares the tool.
| Tool | Support state | Evidence role | Execution boundary | Upstream license |
|---|---|---|---|---|
| Core mandatory repository sensorsRequired The core five-tool layer. Images are digest-pinned and missing coverage is reported as a gap. | ||||
| TrivyAqua Security | 0.72.0 | Vulnerabilities, secrets, licences, and configuration | Offline, disposable repository runner | Apache-2.0 |
| SemgrepSemgrep | 1.172.0 | Static application security testing | Offline, disposable repository runner | LGPL-2.1 |
| GitleaksGitleaks | 8.30.0 | Credential and secret detection | Offline, disposable repository runner | MIT |
| CheckovBridgecrew | 3.2.527 | Infrastructure-as-code policy | Offline, disposable repository runner | Apache-2.0 |
| SyftAnchore | 1.51.0 | CycloneDX software bill of materials | Offline, disposable repository runner | Apache-2.0 |
| Extended mandatory repository sensorsRequired Every audit runs these complementary sensors from reviewed images that bundle the database, rule, or policy they need. | ||||
| OSV-ScannerGoogle | 2.5.1 | Open-source dependency and licence intelligence | Offline runner with baked data and policy | Apache-2.0 |
| GrypeAnchore | 0.118.0 | Filesystem, container, and SBOM vulnerabilities | Offline runner with baked data and policy | Apache-2.0 |
| ConftestOpen Policy Agent | 0.69.0 | Organisation-owned policy as code | Offline runner with baked data and policy | Apache-2.0 |
| zizmorzizmor | 1.30.0 | GitHub Actions security | Offline runner with baked data and policy | MIT |
| HadolintHadolint | 2.15.1 | Dockerfile security and correctness | Offline runner with baked data and policy | GPL-3.0 |
| Dependency-CheckOWASP | 13.0.0 | NVD-backed software composition analysis | Offline runner with baked data and policy | Apache-2.0 |
| Scoped cloud and cluster connectorsConnector boundary These tools need infrastructure context. They are never placed in the credentialless repository runner. | ||||
| ProwlerProwler | Connector planned | Multi-cloud security and compliance | Customer-scoped credentials or in-cluster collector | Apache-2.0 |
| KubescapeKubescape | Connector planned | Kubernetes risk, misconfiguration, and compliance | Customer-scoped credentials or in-cluster collector | Apache-2.0 |
| kube-benchAqua Security | Connector planned | CIS Kubernetes Benchmark | Customer-scoped credentials or in-cluster collector | Apache-2.0 |
| Authorized active testingExplicit authorization Network probes require proof of target authority and a separately controlled execution service. | ||||
| OWASP ZAPOWASP | Execution service planned | Web and API dynamic application security testing | Allowlisted target, test window, and accountable owner | Apache-2.0 |
| NucleiProjectDiscovery | Execution service planned | Template-based web, API, network, and cloud testing | Allowlisted target, test window, and accountable owner | MIT |
| Runtime evidence feedCollector planned Runtime telemetry is ingested as timestamped evidence; Veriom does not ask the repository runner for host privileges. | ||||
| FalcoFalco | Evidence feed planned | Runtime workload and container detections | Customer-operated runtime collector | Apache-2.0 |
Mandatory repository versions are read from the runner lockfile. Digests remain the deployment authority. Connector tools are not enabled merely because they appear in this catalogue. Third-party names and marks belong to their respective owners.
Ask for the evidence behind a control.
Private launch teams can review current controls, accepted risks, data boundaries, deletion behavior, scanner provenance, and the release gates that still remain.