ACCESS
grant typecross-account IAM
write keys✕ never held
accessread-only
Read-only cross-account IAM
Blackfyre is granted a read-only role in your account — it is never handed a write key and cannot mutate your infrastructure.
View sourceSecurity · Apache-2.0Security,
Security,
in the open.
Blackfyre is a compliance and security platform, so its own controls are engineered, documented, and auditable line by line in a public repository. Read-only scanning, database-enforced isolation, tamper-evident evidence, and a private disclosure process. No trust required — verify it yourself.
Read-only scanningPostgres RLSSHA-256 evidenceApache-2.0Private disclosure
Verifiable posture
55
Read-only auditors
9
Frameworks
678
Controls
Free
Apache-2.0
Hardened with
Postgres · RLSArgon2idAES-256-GCMTLS 1.3S3 Object LockJWT + MFASAML / SCIM
Scanning
How scanning stays safe.
Blackfyre reads your posture and nothing else. It is granted a read-only, least-privilege cross-account role — it never holds write keys, and it never collects the data an attacker would want.
Cross-account access is a READ-ONLY IAM role — Blackfyre is granted, never handed, your keys.
No write permissions are ever requested; the scan role cannot mutate your account.
Least-privilege by construction — permissions are scoped to the posture data each auditor reads.
Scan workers hold no standing customer credentials; they assume the read-only role per run.
What it never collects
- Passwords, private keys, or secret values
- Customer PII or business data
- File contents, database records, or application data
- Network traffic payloads or packet contents
LEAST-PRIVILEGE
permissionsper-auditor
write actions✕ none requested
assume-roleper run
Scoped to what it reads
Permissions are scoped to the posture data each auditor reads. No write actions are requested; roles are assumed per run.
View sourceMINIMUM-DATA
pii✕ never read
customer records✕ never read
what it readsposture only
Never PII, records, or content
It reads posture, not data. No customer PII, no business records, no file contents — anything out of scope is dropped and logged.
View sourceNO STANDING CREDS
standing creds✕ none
secrets on queue✕ forbidden
lifetimescoped to run
Nothing left holding the keys
Workers keep no standing credentials and secrets never ride a queue — the role is assumed for the run and nothing outlives it.
View sourceHardening
Defense in depth, enforced by the database.
Isolation lives below the ORM, credentials are hashed with Argon2id, and every request clears auth, CSRF, and a tenant-bound connection before it reads a row.
The path every read clears
01 · Authenticate
A JWT session or Argon2id-hashed API key is verified — MFA and SSO enforced where enabled.
02 · CSRF check
State-changing requests must carry a matching double-submit CSRF token.
03 · Bind the tenant
The request opens a tenant-scoped Postgres connection that fails closed if the tenant is unset.
04 · Read a row
Row-level security enforces isolation in the database, below the ORM — not in application code.
Postgres RLS · fails closed
Tenant isolation is enforced by row-level security below the ORM — request-scoped and fails closed if the tenant is unset (ADR-0001).
Argon2id credentials
Passwords and API keys are hashed with Argon2id; runtime secrets live in AWS Secrets Manager per stage, never in code.
JWT + MFA, SSO, SCIM
JWT sessions with MFA, Google SSO, SAML, and SCIM provisioning; roles are auditor-scoped so access is least-privilege by default.
CSRF double-submit
State-changing requests clear a double-submit CSRF token layered over the auth check and the RLS-bound request connection.
AES-256-GCM at the field
Sensitive fields are encrypted with AES-256-GCM before they reach the database — AES-256 at rest, TLS 1.3 in transit.
mTLS & DLP hooks
Optional mTLS and DLP plugins extend the perimeter for teams needing mutual authentication or data-loss controls at the edge.
Evidence
Evidence you can prove wasn't touched.
Every artefact in the vault carries a cryptographic integrity hash and lands in immutable storage, so an auditor can verify the chain instead of taking your word for it.
INTEGRITY
SHA-256 per item
Each evidence item is hashed on write. Re-hash the artefact later and the digest either matches or the tamper is visible.
IMMUTABILITY
S3 Object Lock + versioning
Artefacts are written once with S3 Object Lock and versioning — they cannot be silently overwritten or deleted within the retention window.
CONFIDENTIALITY
AES-256-GCM PII
PII inside evidence is encrypted with AES-256-GCM before storage, so the vault holds proof without holding readable secrets.
SHA-256
Per-item hash
WORM
S3 Object Lock
Versioned
No silent delete
AES-256-GCM
PII encryption
Disclosure
Found something? Tell us privately.
We follow coordinated disclosure. Report privately and we credit you on release if you'd like. We do not chase researchers acting in good faith.
How to report
Please do not open a public issue. Use GitHub private vulnerability reporting on the repository, or email the security address. Include a description, impact, and steps to reproduce.
In scope: the code in this repository — auth bypasses, IDOR, injection, XSS/CSRF, SSRF, credential leaks, cross-tenant leakage, and crypto weaknesses. Full scope lives in the security policy.
What to expect
within 72hInitial acknowledgement
within 7 daysTriage + severity assessment
within 90 daysPatch released (sooner for critical)
at patch releaseCoordinated disclosure with credit, if wanted
Critical issues affecting auth or customer data get same-day attention. Dependencies are watched with Dependabot and GitHub secret scanning.
Verify
Don't trust it — read it.
Every control on this page is implemented in a public, Apache-2.0 repository. Clone it, audit it, and self-host it for free.