Featured · SMB
Small Business
The same engine at the scale that maps to the small-firm market: fewer systems, same evidence model, same drill-down.
Explore SMB Demo →Independent Engineering Project — Source-Verified
Policy-Driven Cryptographic Agility
A governed decision platform for cryptographic-agility policy and correlation-aware data-security risk — with a Python engine, a real read-only AWS connector, a hash-chained evidence trail, and a test suite you can run yourself.
105/106 tests passing (1 skipped) — verified this run
CI: lint + tests + dependency audit + SBOM on every push
0 known vulnerabilities (pip-audit)
Third-party pentest: required, not yet performed
What this actually is
This is a Python governance platform with two decision engines built on the same design philosophy: gather evidence from the systems that own it, evaluate it against a versioned policy, and produce a defensible, attributable, durably-logged recommendation — then stop short of enforcement and stop short of the final human call.
Cryptographic Policy Engine
Loads config/policy.csv, hashes it, and selects the highest-priority approved algorithm for a purpose-scoped candidate set — never substituting a signature algorithm for a key-encapsulation mechanism just because it ranks higher.
Deployability Check
check_deployability() separates policy approval from real-world readiness: validated-library coverage, certificate existence/expiry, algorithm/certificate mismatch, and institutional HSM custody for Restricted systems.
Data Security Decision Engine
Normalizes classification/DLP/identity/behavior/destination/asset/GenAI signals, renormalizes weights when evidence is missing (never scored as zero-risk), and discounts correlated signal pairs before recommending ALLOW / WARN / BLOCK.
What it is not, in the project's own words: neither engine implements cryptographic primitives or enforces anything. Real deployments still need HSMs/PKI/validated libraries for the crypto side, and real DLP/IAM/CASB systems for enforcement — this platform governs the decision, not the mechanism.
Verified from the source, not asserted in prose
Every line below was checked directly against the submitted codebase rather than taken from the project's own marketing copy.
claimstatus
01Test suite: 106 test functions across 20 files, run against Python 3.12 in this environmenttests/105 passed · 1 skipped
02CI pipeline runs lint (ruff), the full test suite, a dependency vulnerability scan (pip-audit), and SBOM generation on Python 3.11 and 3.12, on every push and pull request.github/workflows/ci.ymlconfirmed in repo
03pip-audit against the pinned runtime dependency (
cryptography>=46.0.6) reports no known vulnerabilities; the floor was deliberately raised past a documented CVE range (PYSEC-2026-35/36/2141/3552-3554)requirements.txtreproduced this run04Correlation discounting is real arithmetic, not a description: contributions are weight-renormalized over present signals, and each correlated pair is discounted by
correlation × min(contribution_a, contribution_b), capped so the adjustment can't exceed the raw scorecrypto_agility/security/correlation.pyread directly, 20 lines05The AWS connector is read-only in both supported modes (customer-approved evidence export, or local AWS CLI under the customer's own IAM/SSO), paginates Security Hub findings via NextToken instead of capping at one page, and retries CLI throttling with exponential backoffconnectors/aws.pyread directly, 98 lines
06Runtime is ~6,000 lines of application Python across 60 modules, plus ~1,160 lines of tests — a real, buildable codebase rather than a slide deckcrypto_agility/, connectors/, controlplane/counted this run
07"Independently penetration tested" or "SOC 2 compliant"SECURITY_PENTEST_SCOPE.md, compliance/SOC2_READINESS_CHECKLIST.mdexplicitly not claimed — see below
From raw signals to a governed decision
The authoritative crypto decision path, as implemented:
policy.csv→content hash→inventory validation→purpose-scoped selection→PQC / restricted checks→highest governed priority→APPROVED / NO_SUITE / hard-stop
Restricted data still requires an approved post-quantum candidate when one exists — the engine refuses a silent legacy fallback when it doesn't.
begin→collect→seal→immutable snapshot→consume
One collector queries customer systems once per run; both compute workers then consume the identical sealed snapshot, so duplicate external API traffic and non-reproducible point-in-time results aren't possible by construction. Evidence files are SHA-256 verified before a worker is allowed to consume them, and audit records are append-only and hash-chained.
Engineering discipline the tests actually exercise
106Test functions across 20 files (105 passing, 1 skipped, verified live)
60Python modules across the engine, connectors, and control plane
2Python versions covered in CI (3.11, 3.12), plus lint + dependency scan on both
1.2.0Current release tag (
rc1-smb-commercial) — the R prototype has been fully retiredCoverage isn't just the crypto/data-security engines: tests/ includes dedicated suites for the control-plane API, authentication, RBAC, rate limiting, encryption, job queueing, OpenAPI schema generation, AWS pagination/retry behavior, and enterprise-scale demo generation.
Security posture — what's built, and what's still a gap
The project's own security documentation is unusually direct about the difference between "implemented" and "certified." That distinction is preserved here rather than smoothed over.
Evidence integrityHash-chained, append-only audit records; immutable sealed snapshots; SHA-256 verification before consumption.
Tenant isolationTenant ID resolved only from a verified session; enforced at both the API layer (RBAC) and the storage layer (per-tenant envelope encryption).
Secrets handlingCredentials are references only — env vars, OS keyring, AWS Secrets Manager, or Azure Key Vault/managed identity. No private signing key material enters the application process.
Encryption at restAES-256-GCM envelope encryption, KMS/Key Vault-wrapped data keys — implemented for evidence data; not yet extended to the tenant registry or API-key store.
AreaStatusWhat the project says
Third-party penetration testNot yet doneScope and release gate are written (
SECURITY_PENTEST_SCOPE.md); the project states it "cannot be truthfully completed by source-code packaging" and must wait for an independent tester.SOC 2Not certifiedThe checklist is explicitly labeled "DRAFT — not a certification" and maps existing controls to Trust Service Criteria without claiming an audit occurred.
TLS in transitInfra-dependentAssumed to terminate at the customer's load balancer; not provided by this codebase.
Change management / monitoring pipelinePartially addressedCI now runs lint, tests, and a dependency scan on every change — directly closing two gaps the SOC 2 checklist itself had flagged as missing. Metrics/alerting for the API server and workers is still undefined.
Production operating historyNone yetNo real SLA history, failover exercise, or incident postmortem exists — the architecture supports horizontal scaling but hasn't been run that way in production.
Interactive Assessment Demonstrations
See the working platform.
These demos run the real reporting pipeline against generated data — not screenshots of a concept.
Demonstration environments: all organizations, systems, findings, and metrics shown are synthetic, generated locally to validate the pipeline at enterprise-scale volumes. They demonstrate the assessment workflow and do not represent an assessment of any real organization.
Featured · Regulated Industry
Financial Services
A synthetic 250,000-system banking environment: 189,503 findings, HNDL exposure, PQC readiness, and a unified finding explorer with capped interactive drill-down for browser performance.
Explore Banking Demo →Featured · Technology
Technology / SaaS
The same assessment architecture applied to heterogeneous cloud infrastructure plus emerging GenAI/LLM risk signals.
Explore SaaS Demo →More Demonstration Environments
Connectors and how it reaches customer systems
The engine itself is provider-neutral; connectors sit in a separate layer so the decision logic never has to know where evidence came from.
AWS Organizations / Config / Security Hub
Two safe modes: consume a customer-approved JSON export, or invoke the local AWS CLI under the customer's own IAM/SSO — this application never handles AWS credentials directly.
Microsoft Purview / Graph
OAuth2 via a registered Entra multitenant app; treated as one interchangeable provider adapter, not baked into the engine's architecture.
Azure Key Vault / managed identity
Used for both secret retrieval and production manifest signing, so private signing material never enters the application process.
SQL / S3 / Blob storage backends
Optional SQLAlchemy, boto3, and Azure Blob adapters for the evidence store and control-plane registry — the filesystem-backed default works standalone from a local or SMB/NFS-mounted directory.
Every evidence path is tenant-partitioned (data/evidence/tenants/<tenant_id>/runs/<run_id>/), and a worker cannot consume a run that hasn't been sealed.
Read the code, run the tests, judge for yourself.
Every claim on this page is traceable to a specific file in the submitted archive. That's a deliberate substitute for taking marketing copy on faith.
Explore the Interactive Demos →Interested in evaluating or deploying the platform? Contact TipTopTechKnowlogy to discuss evaluation and deployment options.
Independent technical project · Cryptographic agility · Data security decision engine · Source-verified, not self-graded