Deterministic runners
Gates execute in pinned, version-locked Docker images — SAST, SCA, secrets, IaC, complexity, dependency hygiene. Reproducible and offline; no host toolchain to pollute.
Platform
Inside the Forge gate engine.
Scan, audit, release and approve — built on deterministic runners, LLM judge panels, and an append-only registry. The same verdict bar whether you run it from a terminal or a tenant.
The engine
Four parts, one fail-closed verdict.
Deterministic where it must be, LLM-assisted where judgement helps, recorded everywhere.
LLM lanes + 5-judge panel
Claude or OpenAI power the analysis lanes; a serial panel — plan critic, security skeptic, delivery pragmatist, evidence auditor, reality check — reviews findings before the final gate.
Append-only registry
Every verdict is written with reproducibility headers — the SHA, framework version and tool matrix that produced it. Unified SARIF 2.1.0 output across all gates.
CLI and platform
Run forge from a laptop or CI, or drive audits from the multi-tenant web platform with admin approvals — the same gate engine and the same verdict either way.
What gets checked
29 gates across five families.
Deterministic gates run in pinned Docker runners; LLM lanes add a 5-judge review. Profiles are language-aware — Python, Node, Java and Flutter repos each get the gate set their stack warrants.
4
Tier-1 spine
The deterministic Python baseline on every audit — Bandit SAST, pip-audit SCA, a coverage floor, and an SBOM.
10
Quality
Maintainability per language — Lizard complexity, ruff/vulture/pylint, deptry dependency hygiene, PMD for Java, dart analyze for Flutter, ESLint/jscpd/knip for Node — plus API-contract, architecture, IaC, observability and documentation gates.
9
Security
SAST, SCA, container, IaC-security, secret-history, auth, encryption and security-logging gates — plus a phantom-dependency / slopsquatting check for hallucinated packages.
2
Governance
Row-level access-control enforcement and waiver hygiene — expired or over-long waivers are flagged, never silently honoured.
4
AI-control
Prompt versioning, audit-log verification, an entitlement firewall and an adversarial test pack — the controls specific to AI-built and AI-operated systems.
Two ways to run it
One repo, or a whole campaign.
The same gate engine and the same verdict bar, whether you gate a single service or orchestrate a release across dozens of repos.
Single repo
One repository, scaffolded once and gated on every release. Runs locally or in CI.
- 1
forge scan— discover the stack, scaffold .forge/ - 2
forge audit— run the profile-aware gate set + judge panel - 3
forge release— scrub, stage, verify, tag — push stays gated
Multi-repo campaign
A whole roster of repositories audited and released together from one deliver folder.
- 1
forge campaign init— scaffold the deliver folder + roster - 2
forge campaign audit— audit every repo, unified output tree - 3
forge campaign release— release the roster at one version - 4
forge campaign status— one verdict table across all repos
See it run against your repo.
We'll stand up a demo tenant against a repository you pick. Under 30 minutes from SSO handshake to first audit.