Scanning that survives the audit
Every finding is a security signal AND an admissible evidence row — chain-anchored the moment it lands, cross-mapped to the policies and compliance frameworks your organization is measured against, verifiable by your auditor without our credentials. Bring our scanners, bring your own, or run both. Same audit-ready record either way.
The obvious question
“How is this different from Vanta or Wiz?”
Vanta-class platforms detect and file a ticket. Cloud posture platforms detect and auto-fix at runtime. Neither ships an evidence trail your auditor can verify offline. We sit at the intersection.
- When a scan finds MFA disabled
- MFA disabled on 3 users
- What happens next
- Jira ticket queued for the admin to fix
- At audit time
- Auditor still asks for screenshots at audit time
- When a scan finds MFA disabled
- Public S3 bucket + attack-path graph
- What happens next
- One-click remediation via API
- At audit time
- Evidence trail is your problem at audit time
- When a scan finds MFA disabled
- MFA disabled + mapped to every framework your org is measured against
- What happens next
- One-click fix across the cloud, identity, and productivity platforms your business runs on
- At audit time
- The finding IS the evidence row — chain-anchored, verifiable offline by any auditor
Scan once, satisfy every framework it maps to
Every scanner check is pre-mapped through the Secure Controls Framework crosswalk. When a scan passes, the satisfaction chip lights up on every framework panel that mapped control belongs to — SOC 2, ISO 27001, PCI DSS, HIPAA, FedRAMP, NIST CSF, CMMC, CSA CCM, GDPR, and more. If SCF can see it, we scan aligned to it.
- Coverage tracks your organization’s framework mix — whatever you’re measured against, that’s what your scans satisfy
- Hundreds of controls mapped across every major framework via the Secure Controls Framework crosswalk
- Same source of truth as your compliance evidence graph — no re-mapping, no per-framework spreadsheets
- When SCF adds a new framework, your scanners inherit the mapping automatically
- SOC 2CC6.1
- SOC 2CC6.2
- ISO 27001A.8.5
- PCI DSS8.3.1
- PCI DSS8.3.6
- HIPAA164.312.d
- FedRAMPIA-2(1)
- FedRAMPIA-2(2)
- NIST CSFPR.IA-03
- CMMCIA.L2-3.5.3
- CSA CCMIAM-02
- GDPRArt. 32
- CIPAISP-3
SCF crosswalk propagates the pass across every framework the same underlying control belongs to. Whatever compliance mix your organization is measured against, one scan check satisfies every related requirement in one pass.
Signal source flexibility
Bring our scanners. Bring your own. Bring both.
Every other GRC-CCM platform makes you use their scanners. We ingest yours too. Six native scanners on the platforms you actually operate, plus six ingestion adapters that normalize the security tools you already trust — Prowler, Checkov, Trivy, Snyk, Wiz, OSV-Scanner — into the same audit-ready record. Whichever lane the signal comes from, everything that follows works the same way.
- GitHub16
- AWS12
- GCP10
- Azure10
- Slack8
- Google Workspace10
- ProwlerJSON
- CheckovJSON
- TrivyJSON
- SnykJSON
- WizJSON
- OSV-ScannerJSON
Whichever lane the signal comes from, it lands as the same object: chain-anchored, framework-mapped, lifecycle-tracked.
Findings move the way your VM policy says they should
Every finding is a first-class object routed through your organization’s vulnerability management policy. The SLA on a finding is whatever your policy calls for. Findings arrive continuously — instant via webhook where change happens fast, on your chosen schedule where it doesn’t — and can be sent to any work management platform (Jira, Linear, Asana, GitHub Issues) with bidirectional sync so a resolution in either place resolves it everywhere.
- SLA per severity, aligned to your VM policy — the thresholds you set
- Auto-escalation when the SLA slips, up your escalation chain
- Bidirectional sync with Jira, Linear, Asana, GitHub Issues — resolve once, resolve everywhere
- Every transition writes to an immutable activity log
- Slack + email alerts on new findings and SLA warnings, routed per your policy
- Critical1 day
- High7 days
- Medium30 days
- Low90 days
- InfoNone
Escalations route up your chain. Bidirectional sync with Jira, Linear, Asana, and GitHub Issues — resolve once, resolve everywhere.
The finding IS the evidence row
Every scanner-derived evidence row lands on the same SHA-256 hash chain that carries the rest of your audit events — policies, attestations, control state changes. Merkle checkpoints anchor via outside timestamp authorities. Your auditor verifies inclusion proofs against those authorities directly, without our credentials, without our cooperation, without waiting on us. If we disappeared tomorrow, the record still holds.
- Every scan run and every finding writes to a SHA-256 hash chain the moment it lands
- Merkle checkpoints are anchored via RFC 3161 timestamp authorities (DigiCert primary, Sectigo fallback)
- The verifiable-export bundle carries the inclusion proofs; any Big-4 QSA validates it offline against the TSA public certificate
- Seven-year default retention on the audit-trail record
No incumbent GRC-CCM platform ships cryptographic chain of custody on scanner output today.
- Scanner check
- GITHUB-002 · Organization MFA required
- Detected
- 2026-08-12 14:22:11 UTC
- Chain sequence
- #12,847
- Record hash
- sha256:a4b8ef92c7d1…
- Previous hash
- sha256:9c2f6d84b5a2…
- Merkle checkpoint
- #48 · anchored via RFC 3161
Findings cluster into drift — against your policies, not a generic checklist
When a scanner catches an MFA policy going down, the platform doesn’t just log the config change. It clusters the finding with related events, matches it against your published policy library, and surfaces the drift alert with the specific policy it contradicts and the fix path to resolve it — in one place, already routed.
- AI-mapped against your policy corpus, not a generic template
- Drift alerts group related findings into one actionable object
- Fix path attached where the write path is proven
- Full attribution of which policy, which control, which framework
Drift alerts cluster scanner findings, name the policy they contradict, and route the fix. AI-mapped against your policy library, not a Rego evaluation.
Fix path
The finding, and everything that has to happen to it
A finding is only useful when it becomes a fix. Every drift alert on this platform lands with the specific action wired to the specific system — not a ticket in a queue, not a screenshot in a folder.
Cloud misconfig lands.
SSH · console · screenshot · repeat
Someone opens the cloud console, hunts down the setting, makes the change, updates the ticket, and hopes the auditor accepts the screenshot as proof it stuck.
01 One click
The config change runs against the cloud provider directly.
Finding transitions to resolved on its own. Audit trail records who authorized and when — no screenshot in sight.
Identity drift surfaces.
cross-team pings · escalation delay
IT admin logs into the IdP admin panel, hunts the setting or user, makes the change. Auditor asks “how do we know?” — someone digs up an email thread.
02 One click
MFA re-enforced on the identity provider from the drift alert.
The audit record is chain-anchored the second the change lands. Auditor verifies against the timestamp authority, not against your word.
Source control drift.
sprint churn · engineer context-switch
PM opens a Jira ticket. Engineer looks at repo settings, changes them via the UI. Ticket closes. Nobody logs who authorized what.
03 One click
Branch protection re-enabled via the source control API.
Finding, fix, and audit event land on the same chain. Sprint doesn’t get churned to reach the same outcome.
When you’re ready for the platform to fire on its own — on high-confidence remediation, without waiting for the click — Trustworthy Autonomy is the up-tier surface.
Common questions
The questions buyers actually ask
Ready for scanning that survives the audit?
Get your first scan running in minutes. Turn every finding into evidence.