FortProof

Evidence-driven application security assurance. FortProof answers one question for every application your organization runs: is it built and run securely, and what is the proof?

It judges each security control from verified evidence (what your pipelines and systems actually did), never from configuration alone. Each verdict explains itself, and the results add up to OWASP SAMM maturity and OWASP ASVS coverage.

Start here

Tour	Eight screens from the demo world, with what each one shows
Getting started	The platform and its demo running on your machine in about 15 minutes, with Docker only
Install with Helm	Production on Kubernetes, with managed PostgreSQL and object storage
Evaluate with Docker Compose	A complete evaluation stack, including sign-in through Keycloak
Connect your organization	Your GitHub or GitLab, your rules, and your first application with verified evidence
Configure	Settings, integrations and the rules you can change
User guide	Daily use, role by role

How it works

repository → security pipeline → evidence (verified) → controls → findings → risk
           → remediation → re-scan → maturity (OWASP SAMM / ASVS) → reporting

• Evidence model: where evidence comes from, how it is verified and what each confidence level (C0 to C3, M1 and M2) means. Evidence model · the evidence type identifier
• Controls and rules: 48 controls with their proof, the tiering model, the risk model and the exception policy, all kept as YAML and changed by pull request. Control framework · Control catalogue · Risk model
• Security model: how the platform protects itself and the evidence it holds. Security model · Access control · Platform threat model
• Architecture: problem · platform · data model · pipelines · repositories · the project's own CI/CD · decisions (ADRs)

Integrations

Every integration is optional and starts unconfigured; until one is set up, the controls that depend on it show No evidence, never a pass.

• Connect your organization: from an installed platform to your first application with verified evidence
• Reference deployment on Azure: Container Apps, Entra ID, Key Vault and Sentinel, with GitHub, Jira and the scanners
• Guides: GitHub end to end · GitLab · Jira · SIEM and SOC · Cloud security · ASVS
• Writing a plugin

Operating it

Operations runbook · Backup and restore · Disaster recovery · Incident response · CVE emergency · Evidence integrity mismatch · Key rotation

Reference

External interfaces · REST API (from the OpenAPI contract) · Settings · Test strategy · OpenSSF Best Practices answers

Adopting it in your organization

The platform enforces its rules; your organization decides them. These are starting points to adapt and approve, not finished policy:

• Standards: secure SDLC · application classification · security requirements · threat modelling · secure architecture · security testing · vulnerability management · SBOM · supply chain · exceptions · evidence management · GitHub baseline · pipeline security · open source
• Maturity: SAMM assessment methodology · SAMM and ASVS mapping · KPIs and KRIs
• Privacy: privacy assessment · DPIA considerations
• Adoption kit: strategy, operating model, champions, data retention, RACI, risk register and rollout plan to copy and adapt. Adoption kit

The project

New here? The launch article explains the problem and walks through the product: Configuration isn't proof.

FortProof is open source: code under Apache-2.0, documentation under CC BY-SA 4.0. Roadmap · Contributing · Security policy · Backlog · Source on GitHub