FortLock is read-only by construction, runs inside your boundary, and ships through a signed, provenance-attested supply chain. Most of what a security review asks for here is a property of the design — not a policy bolted on afterward.
The boundary is small on purpose. FortLock reads structure, not contents, and keeps your data in your environment.
FortLock issues only get / list / watch (k8s) and Reader/ReadOnly cloud roles. It never makes a create/update/delete call to your infrastructure — there is no code path that mutates a tenant.
Secrets are modeled as references — we record that a workload uses a secret, never its value. No secret material is read, logged, transmitted, or stored.
Self-hosted: the graph lives in your environment. The only outbound writes are opt-in — a PR comment, a change-request note, or a Slack message — using your credentials. Air-gapped deployments emit nothing.
An optional prediction corpus records types, counts, and hashes only — never names, configs, or values — and is hard-disabled with FORTLOCK_NO_CORPUS. The boundary is enforced in code and tested.
Enterprise SSO, least-privilege roles, and the same change-control discipline FortLock helps you enforce.
OIDC with every major IdP (Okta, Microsoft Entra ID, Google, Auth0, Keycloak, Ping) and SAML 2.0. MFA enforced at your IdP; the IdP's groups map to FortLock roles.
Role-scoped access; programmatic access via scoped, revocable API tokens stored only as a hash (the secret is shown once). Read-only tokens cannot mutate.
Privileged change actions require N-of-M approval; the requester cannot approve their own change. Named, versioned policies govern the gate.
Every consequential action — analysis, gate decision, approval, token change, login — is appended to a hash-chained ledger that fails verification on any edit. Exportable to your SIEM.
The integrity of the artifact you run is provable — the part most vendors can't demonstrate.
We're honest about status. The technical controls are in place and self-evidencing today. Formal third-party certifications are roadmap items — not yet initiated; we won't claim an attestation is underway before it is.
| Item | Status | Notes |
|---|---|---|
| Secure SDLC & supply chain | ✓ in place | SLSA provenance, SBOM, signing, digest pinning, scan gates |
| Access controls & SSO | ✓ in place | OIDC + SAML, RBAC, scoped tokens, SoD approvals |
| Tamper-evident audit & evidence automation | ✓ in place | Continuous, hash-chained control evidence |
| SOC 2 Type II (Security + Confidentiality) | planned | Controls implemented and self-evidencing; the formal observation window + CPA attestation are not yet initiated — planned once a design-partner engagement warrants it |
| Independent penetration test | planned | Planned prior to first production deployment; report available under NDA once completed |
| ISO 27001 | planned | Future — would reuse SOC 2 control evidence once that program begins |
| SAML 2.0 SSO / SCIM | ✓ SAML SCIM on request | Generic OIDC + SAML today; SCIM provisioning on request |
We answer questionnaires directly and provide architecture documentation, our control matrix, and the SBOM today. Formal pen-test and SOC 2 materials will be shared under NDA once those programs are complete.
Report a vulnerability or request documentation: security@fortlock.io
We practice coordinated disclosure and respond to verified reports promptly.