Methodology

Every claim on this site maps to a specific field read from a provider's own API. This page lists all of them — what we read, what it proves, and what it doesn't.

If a control isn't listed here, we don't check it and we don't claim it.

Phishing-Resistant Identity

Live

Google Workspace — read-only OAuth (admin directory, roles, reports)

Admin MFA + Security Keys

We read: Directory API: users(isAdmin, isEnrolledIn2Sv, isEnforcedIn2Sv) + Reports API: accounts:num_security_keys, accounts:num_passkeys_enrolled
It proves: Every admin has 2-step verification enforced, ideally with a phishing-resistant passkey or hardware key.
It stops: Admin account takeover via credential phishing or MFA-fatigue — the shortest path to total domain compromise.

All-User MFA + Security Keys

We read: Directory API: users(isEnrolledIn2Sv, isEnforcedIn2Sv, suspended) + security-key counts from Reports API
It proves: What share of active users are on enforced, phishing-resistant MFA.
It stops: Credential phishing at scale and lateral movement through an unprotected account.

Password Policy

We read: Reports API: accounts:password_strength, accounts:password_length_compliance
It proves: Users hold strong, length-compliant passwords.
It stops: Credential stuffing, password spraying, brute force.

Super Admin Count

We read: Directory API: roleassignments for the built-in super-admin role
It proves: Full-access admin accounts are kept to a small number.
It stops: Blast radius — every extra super admin is another total-takeover target for helpdesk social engineering.

Less Secure App Access

We read: Reports API: accounts:is_less_secure_apps_access_allowed
It proves: No account can authenticate with a password alone.
It stops: Complete MFA bypass using a stolen password via legacy auth.

Hardened Code Hub

Live

GitHub organization — read-only GitHub App installation

Org 2FA Required

We read: GET /orgs/{org} → two_factor_requirement_enabled
It proves: Every member of the organization must use two-factor authentication.
It stops: Maintainer account takeover — the documented first step of most supply-chain worms.

Workflow Permissions

We read: GET /orgs/{org}/actions/permissions/workflow → default_workflow_permissions
It proves: The default CI token is read-only org-wide.
It stops: A compromised workflow pushing code, cutting releases, or minting provenance.

Secret Scanning

We read: GET /orgs/{org}/repos → security_and_analysis.secret_scanning
It proves: Leaked credentials are detected across active repositories.
It stops: Harvesting of committed tokens that unlock publish access.

Push Protection

We read: GET /orgs/{org}/repos → security_and_analysis.secret_scanning_push_protection
It proves: Secrets are blocked before they ever enter history.
It stops: The leak itself, rather than cleaning up after it.

Branch Protection

We read: GET /repos/{org}/{repo}/branches/{default}/protection → required_pull_request_reviews
It proves: Default branches require review before code lands.
It stops: A single compromised account silently pushing malicious code.

Provable Releases

Live

Public registry data — npm, PyPI, crates.io (no connection required)

Published Build Provenance

We read: npm: registry dist.attestations + SLSA provenance predicate · PyPI: PEP 740 attestations at /integrity/{project}/{version}/{file}/provenance · crates.io: version trustpub_data / crate trustpub_only
It proves: Your latest release carries cryptographic provenance (Sigstore / Trusted Publishing) binding it to a CI build.
It stops: A stolen publish token being used to ship a malicious version from someone's laptop — the exact mechanism behind recent registry worms.

Releases Linked to Verified Source

We read: Source repository named inside the provenance attestation, compared against your connected GitHub organization
It proves: The artifact people install provably came from a repository in the organization whose hardening we verified.
It stops: Breaking the chain — a signed package that was actually built somewhere you don't control.

Not available yet

Listed so nobody has to guess what's real:

·Microsoft 365 — Graph secure score + conditional access — not yet available
·Okta — Policy and factor enrollment — not yet available

What a PostureProof result does not prove

It is a point-in-time reading of specific settings, re-checked on a schedule — not a continuous audit of everything you do.
It is not a certification and not a substitute for SOC 2, ISO 27001, or a penetration test.
It says nothing about code quality, application vulnerabilities, cloud configuration, or endpoint security.
Passing every check does not mean you cannot be breached. It means the specific doors attackers use most often are shut.
We read what the provider's API reports. If a provider reports stale or incomplete data, our result inherits that.

Questions about a specific check? Ask us.