Binary compliance checklists turn nuanced security posture into pass/fail. tenant-sec replaces that with maturity levels, per-service breakdowns, and scoring profiles that match your actual threat model.
71 controls. 9 domains. Four provisional provider assessments at a glance. Open the Controls Explorer →
Standard compliance frameworks reduce security capabilities to yes/no. When the bar is "does this capability exist?", every provider passes — and the assessment stops being useful for differentiating real posture.
A control you build and maintain with custom automation scores the same as a fully managed, policy-driven platform capability. The distinction matters operationally — but binary frameworks can't express it.
CMK encryption on S3 but not on the managed database. WAF on EC2 but not for the AI platform. A binary "yes" on the control hides that half the service portfolio doesn't support it.
When every provider can check the same boxes, the assessment carries no differentiating information. Security teams end up doing ad-hoc deep dives to find what the framework was supposed to surface.
Each control for each provider gets one of four leaf scores, or a mixed composite when capability varies across service types.
The platform does not expose this capability. No amount of tenant-side effort can achieve it. Accept the risk, implement an external compensating control, or change providers.
Achievable — but you must build and maintain custom automation. Scripts, Lambda functions, CI/CD guardrails, external tooling. The provider offers no managed path. Engineering cost is yours.
A managed capability exists but with constrained scope or configurability. You can enable it but cannot customize policy logic, algorithm, scope, or enforcement granularity. Take it or leave it.
Full managed capability with tenant-configurable parameters. Define policies, set thresholds, choose algorithms, scope to specific resources or OUs, integrate with external systems. The target state for enterprise-grade controls.
Capability varies across the provider's service portfolio. Contains per-service scores at L0–L3.
In scoring, you choose the aggregation function: min, mean,
p20, threshold:L2:0.8 — matching your risk tolerance.
Current 1.0-RC1.1 results. The heuristic index is not a certification or security verdict, and the underlying recommendations are awaiting human review.
| Measure | Google Cloud | Amazon Web Services | Microsoft Azure |
|---|---|---|---|
| Catalog completeness | 90% | 84% | 84% |
| Technical must-haves | PASS | PASS | PASS |
| Heuristic index | 81.6 / 100 | 80.7 / 100 | 75.5 / 100 |
| Human review | PENDING | PENDING | PENDING |
Run your own weights and must-haves → open the in-browser evaluator
62 tenant-operable controls have assessor-actionable L0–L3 criteria.
service_scoped: true signals that per-service mixed composites are expected.
Install with pip, point at your scoring profile, and get ranked output in seconds.
# Install pip install tenant-sec # Or clone and install in editable mode git clone https://github.com/ypapazov/tenant-sec pip install -e ".[dev]"
# Validate any YAML file against its schema tenant-sec validate providers/scaleway.yaml ✓ providers/scaleway.yaml is valid tenant-sec validate controls/iam/abac.yaml --type control ✓ controls/iam/abac.yaml is valid # Also cross-validates: unknown control IDs, unresolved service catalog aliases
# Score and rank providers against your scoring profile tenant-sec score \ --profile profiles/eu-regulated-fintech.yaml \ --providers aws,gcp,scaleway Rank Provider Overall IAM Enc Net ... Must-Haves 1 Google Cloud 98.9 100 98.3 100 ... PASS 2 Amazon Web Services 98.1 100 95.8 100 ... PASS 3 Scaleway 34.2 41.7 24.2 40.8 ... FAIL (4) # JSON and CSV output also available tenant-sec score --profile profiles/eu-regulated-fintech.yaml --format json
# Per-control breakdown for a single provider tenant-sec detail --provider aws --domain encryption ── ENCRYPTION ────────────────────────────────── enc.encryption-at-rest-default MIXED Encryption at rest — Default s3 L3 S3 encrypts all objects ... ebs L3 EBS default encryption ... rds L2 Must be enabled at creation ... enc.cmk MIXED Customer-Managed Keys enc.byok L3 Bring Your Own Key enc.external-key-management L3 External KMS (XKS)
# Side-by-side comparison tenant-sec compare \ --providers aws,gcp,scaleway \ --domain iam ── IAM ─────────────────────────────────────────── Control AWS GCP Scaleway iam.external-idp-federation L3 L3 L2 iam.privileged-access L3 L3 L0 iam.abac L3 L3 L1 iam.permission-boundaries L3 L3 L0 ...
# Export a provider profile as HTML, JSON, or CSV tenant-sec export \ --provider aws \ --format html \ -o aws-report.html tenant-sec export \ --provider scaleway \ --format csv \ -o scaleway-controls.csv
Scoring profiles are YAML files you create. They define which controls are mandatory, how domains are weighted, and how mixed composites are aggregated. No code changes required.
# profiles/eu-regulated-fintech.yaml name: "eu-regulated-fintech" description: > European fintech under DORA & GDPR. # Hard requirements — fail = flagged provider must_have: - control: "gov.preventive-policy" min_level: 2 - control: "enc.cmk" min_level: 2 - control: "log.immutability" min_level: 2 - control: "data.residency-guarantees" min_level: 2 # Domain weights (must sum to 1.0) weights: iam: 0.20 governance: 0.15 encryption: 0.20 network: 0.10 logging: 0.15 data: 0.10 compute: 0.05 incident: 0.03 supply-chain: 0.02 # How to aggregate mixed composites # p20 = conservative but not worst-case mixed_aggregation: "p20"
min
Worst-case. A single L0 service drags the control to L0. Appropriate for hard security requirements.
mean median
Central tendency. Outliers averaged out. Good for general enterprise baselines.
p10 p20
Conservative percentiles. The 20th percentile score must meet your bar — 80% of services above doesn't matter.
threshold:L2:0.8
Policy threshold: returns L2 if ≥80% of services are at L2 or above, otherwise L1. Expresses a quorum requirement.
You're evaluating providers for a multi-cloud or migration project. Drop your security requirements into a scoring profile and get a ranked comparison grounded in per-control evidence — not marketing material.
Clients adopting a new cloud provider. Auditors reviewing control coverage. The structured evidence text makes it defensible — every score cites exactly what was tested and why.
DORA, GDPR, NIS2 all demand evidence of supply chain security.
The data.residency-guarantees and data.sovereignty-controls
controls give you a structured basis for provider-selection justification.
Cloud providers can use this as a structured external view of their tenant-space capability gaps — grounded in what customers need, not internal engineering self-assessment.
Structured, versioned, open data set covering capability maturity across major providers. Researchers can track changes over time via git history and build their own analyses on top of the data.
The scoring engine runs entirely client-side as a static page. Paste your scoring profile, choose providers, and get ranked results — no data leaves your browser.
→ Open evaluatorControls, provider assessments, and framework mappings are YAML data validated by JSON Schemas. The scoring engine and CLI are the tooling layer around the data. The data is the primary artifact.
tenant-sec/ ├── schema/ # JSON Schemas (draft 2020-12) │ ├── control.schema.json │ ├── provider.schema.json │ ├── scoring-profile.schema.json │ └── service-catalog.yaml # 24 canonical categories │ ├── controls/ # 71 control definitions │ ├── _index.yaml # master index │ ├── iam/ # 13 controls │ ├── governance/ # 6 controls │ ├── encryption/ # 9 controls │ ├── network/ # 10 controls │ ├── logging/ # 6 controls │ ├── data/ # 8 controls │ ├── compute/ # 7 controls │ ├── incident/ # 5 controls │ └── supply-chain/ # 7 controls │ ├── providers/ # Assessments │ ├── aws.yaml # 62 tenant controls │ ├── azure.yaml # 62 tenant controls │ ├── gcp.yaml # 62 tenant controls │ └── scaleway.yaml # 62 tenant controls │ ├── mappings/ │ ├── ccm-v4.1.yaml │ └── nist-800-53-r5.yaml │ ├── profiles/ # Example scoring profiles │ ├── eu-regulated-fintech.yaml │ ├── general-enterprise.yaml │ └── data-sovereignty.yaml │ └── src/tenant_sec/ # Python CLI (Apache 2.0) ├── cli/ # validate / score / detail / compare / export ├── core/ # loader, registry, staleness └── scoring/ # engine, aggregation, ranking
tenant-sec validate runs schema + cross-reference checks.
tenant-sec is not a replacement for CCM, CIS, or NIST 800-53 — it augments them. Every control carries framework mappings in both directions: forward (control → framework IDs) and reverse (framework ID → controls).
Full mapping included. GRM, EKM, IAM, LOG, IVS, DSP families covered.
AC, AU, CA, CM, CP, IA, IR, SA, SC, SI families mapped.
Post-v1. AWS v5, Azure v5, GCP v4 planned.
Post-v1. Technique-level mappings planned.
No account. No install required for the browser evaluator. The data is CC BY 4.0 — take it, fork it, build on it.