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 |
| 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.
- Integration bootstrap: source control, sign-in, ticketing, vulnerability data, cloud posture, SIEM and storage
- Guides: 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¶
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¶
FortProof is open source: code under Apache-2.0, documentation under CC BY-SA 4.0. Roadmap · Contributing · Security policy · Backlog · Source on GitHub