TFTHREATFADE
ProductDetectionHow it worksIntegrationsResearchSecurityDocsPlaygroundPricingEnterprise
GitHub
ProductDetectionHow it worksIntegrationsResearchSecurityDocsPlaygroundPricingEnterprise
HomeSecurity

Security claims should be evidence-backed.

ThreatFade documents its engineering controls and explicitly separates repository implementation from independent assurance. The web platform follows the same standard.

Control

Input boundary

Bounded request and PCAP inputs, finite-number validation and safe temporary PCAP handling.

Control

Application boundary

Rate limiting, request IDs, restrictive CORS and security headers.

Control

Runtime boundary

Non-root containers, dropped Linux capabilities and no-new-privileges controls.

Control

Identity boundary

OIDC/JWT validation with issuer, audience, JWKS and time-claim validation.

Control

Tenant boundary

Tenant-scoped detection persistence, RBAC and cross-tenant access denied by default.

Control

Supply chain

Dependabot, CodeQL, Gitleaks, pip-audit, SBOM generation and build provenance.

Trust boundary

Repository evidence

Tests, benchmarks, controls and documented validation are inspectable in the source repository.

Project validation

Published validation is explicitly scoped; it is not presented as a universal accuracy guarantee.

External assurance

Certifications, independent testing, contractual SLAs and customer-scale guarantees require separate evidence.

What the repository does not prove

The project does not self-certify SOC 2 or ISO 27001, independent penetration testing, independent detection validation, contractual SLAs, customer-scale performance guarantees, data-residency commitments or organization-level incident-response obligations. Those require separate evidence, controls, contracts or independent assessment.

THREATFADE / TINLANCE LIMITEDSource on GitHub