What every release goes through
1. Scans. Substrait scans for leaked secrets across the full history of the code, weaknesses in the code, dependencies with known vulnerabilities, container images, the running tool, infrastructure definitions and malicious packages. Your organisation’s own rules decide which findings block a release.
2. Classification and documents. Substrait reads the change and places it in your organisation’s own risk tiers, with a written reason. Each change then carries the documents that tier needs: a change summary, a technical design, a threat model, a risk analysis, a deployment plan, compliance tags and an API-change analysis. Each change is compared with the last build cleared for production.
3. People review where it matters. A build that is clean enough under your policy skips this step and is approved automatically. A build with too many issues, a change in a high-risk tier, or a change the check is unsure about goes to a person to review. Approvals can need one person or several, carry deadlines with escalation, and never let a builder approve their own change. A named reviewer can open the build they are asked to approve.
4. Record and release. Substrait writes a software bill of materials, a licence scan and a chain-of-custody record, then promotes the build.
Guided fixes
Substrait guides a builder who is not an engineer through each fix. A builder can claim a finding is a false positive; your infosec team reviews the claim, and repeated retries are capped.
