Preflight Audit
Preflight Security Gate
A consent-first GitHub integration for security audits, exact-scope cryptographic inventory and continuous assurance. Clients choose the repositories; Preflight receives only the permissions required for the selected service.
GitHub App onboarding
Customer-selected repositories. Read-only by default.
github.com/apps/preflight-security-gate
Preflight Security Gate requests only Metadata read and Contents read in its default audit mode. Installation is controlled by the GitHub account owner, who selects the exact repositories included in the engagement. Repository removal, suspension or uninstall revokes future Security Gate access.
Use the public GitHub App page to verify the application identity. Installation itself should begin from a controlled Preflight engagement: the portal creates a short-lived one-time onboarding state before sending the authorized user to GitHub consent. The onboarding control is enabled only when the required server-side GitHub App configuration is present. Secret values are never sent to this page.
Create engagement
The client engagement, confidentiality terms and authorised contacts are established before repository access.
Install with consent
GitHub shows the requested permissions and the client chooses the organisation/account and selected repositories.
Freeze exact scope
Repository IDs, exact commit SHA, included/excluded paths and build evidence are captured in the Preflight Engagement Manifest.
Inventory cryptography
A non-executing scanner identifies candidate algorithms, cryptographic providers and sensitive-key artifact paths without recording secret values.
Close coverage and review
Truncated or unbound scans are rejected. Unsupported or oversized artifacts require a scope-bound QMS coverage review, and every cryptographic finding requires controlled human disposition.
Revoke cleanly
Repository removal or app uninstall prevents new access and triggers controlled workspace cleanup and retention handling.
Cryptographic inventory gate
Repository evidence before quantum claims.
Security Gate produces deterministic cryptographic inventory candidate evidence for a frozen repository revision. A report cannot enter quantum-readiness merely because its digest is valid: exact scope must be bound, scan coverage must reconcile, and every finding must have a controlled human/QMS disposition. Finding-limit truncation forces a rescan. Unsupported or oversized artifacts remain blocking until a QMS coverage attestation binds the same scope, exact scanner counts and a tamper-evident skipped-artifact manifest digest.
Exact-SHA + scope binding
Every readiness-eligible inventory is bound to the repository, exact commit SHA and repository-scope digest. A changed commit or missing scope binding requires a new candidate.
Non-executing analysis
Security Gate inspects bounded source/manifests as data. It does not run repository code to discover cryptography.
Secret-safe handling
PEM, key, keystore, credential and environment paths are never content-scanned by the inventory engine; their presence is recorded for controlled review.
Fail-closed coverage
Finding-limit truncation is non-waivable. Unsupported or oversized artifacts require a QMS review bound to exact scanner counts and a SHA-256 skipped-artifact manifest digest.
Human-confirmed handoff
Regex/library detections are only candidates. QMS-traceable reviewer evidence is required before they become quantum-readiness assets.
Repository detection, coverage review and human disposition do not establish that a product is quantum-resistant, NIST validated, FIPS validated, certified or accredited.
Default permission posture
Read-only by default.
Repository content access is limited to the customer-selected repositories. Administrative, workflow-write and repository-content-write access are not part of the default audit mode. Optional checks, statuses or SARIF write-back require a separate client-enabled permission tier.