Open-Sourcing Wiz Custom Rules: Measuring and Closing the Coverage Gap
We mapped TrustOnCloud controls across 3 major cloud services and compared them against default Wiz coverage. Default coverage sits at roughly 34%.
Today we are releasing open-source Wiz Custom Configuration Rule (CCR) packages for AWS S3, Azure Storage, and GCP BigQuery. We mapped TrustOnCloud controls across those 3 major cloud services and compared them against default Wiz coverage. Default coverage sits at roughly 34%, solid for baseline posture, but regulated enterprises consistently need more. Each package includes a mapping of default Wiz rules to our controls and custom rules for the gaps.
Wiz Covers the Baseline. Regulated Enterprises Need More.
Approximately 70% of our customer base (Fortune 500 firms, government agencies, and regulated enterprises) run Wiz as their CNAPP. Over the past several years, we have built and maintained security controls across these environments and heard a consistent theme from our customers:
"Do you have a mapping between your controls and what Wiz covers by default?"
Today, we are open-sourcing the first set of packages that answer that question. Each package includes a mapping of default Wiz rules to our controls and Custom Configuration Rules (CCRs) written in Rego for the controls Wiz does not cover out of the box.
We are releasing AWS S3, Azure Storage, and GCP BigQuery together, with more services to follow.
Coverage at a Glance

Azure Storage sits at 54% Wiz baseline coverage (15 of 28 controls), AWS S3 at 48% (20 of 42), and GCP BigQuery at 3% (1 of 35).
We also weight each gap by its severity (using our CVSS-based score based on threat mitigation, threat impact, and control difficulty).

Not every missing control carries the same weight. AWS S3 has 2 very high and 9 high severity controls missing. Azure Storage has 1 very high and 3 high. GCP BigQuery has 3 high and 25 medium severity gaps.
| Control ID | Cloud Service | Description |
|---|---|---|
S3.C50 | AWS S3 | Verify account-level S3 Block Public Access is enabled on all AWS accounts, with BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets set to true. |
S3.C2 | AWS S3 | Verify the control blocking unencrypted requests and unauthorized TLS versions from IAM entities you control is properly implemented. |
S3.C20 | AWS S3 | Verify all S3 VPC endpoints are blocking any IAM entity not belonging to authorized AWS Organizations, OUs, and/or AWS accounts. |
S3.C36 | AWS S3 | Verify the control blocking change ObjectACL to public is configured. |
S3.C67 | AWS S3 | Verify all buckets block PutObject requests with an unauthorized KMS key. |
S3.C168 | AWS S3 | Verify SSE-C is blocked only when not required for each bucket. |
Storage.C40 | Azure Storage | Verify only authorized private endpoints are configured on storage accounts. |
Storage.C45 | Azure Storage | Verify only authorized IPs are permitted through each storage account firewall. |
Storage.C146 | Azure Storage | Verify required storage container blobs have immutability policies enabled. |
BigQuery.C8 | GCP BigQuery | Verify only authorized IAM entities are allowed to access the tables, views, and table data in each dataset. |
BigQuery.C14 | GCP BigQuery | Verify only authorized IAM entities are allowed to access sensitive rows of a table. |
Default Wiz coverage handles the most commonly used features well. Where gaps appear is in deeper, compliance-specific controls for niche or less commonly used features that regulated enterprises still need for audit readiness.
Open-Source CCR Packages
Each package includes:
- Mapping of Wiz default rules to TrustOnCloud controls (where coverage exists)
- Custom Configuration Rules (CCRs) for controls Wiz does not cover by default
One control traced end-to-end
Here is one example showing how a TrustOnCloud control maps through the full chain:
- TrustOnCloud Control: Storage.C49: Restricts cross-tenant replication to authorized accounts
- Wiz default rule mapping id: StorageAccount-019

For the full mapping of every control across each service, explore the repos directly:
Each CCR is written in Rego and integrates directly into Wiz. For a full technical walkthrough of implementation modes and code examples, see our Wiz Integration documentation.
What's Next
- More services. Expand CCR packages beyond Azure Storage, AWS S3, and GCP BigQuery, prioritised by customer demand.
- Sigma exploration. We are evaluating Sigma rules as a way to convert detective controls into deployable code across a broader set of security tooling beyond Wiz.
Closing Thoughts
Wiz has changed the enterprise cloud security market by delivering speed and visibility across cloud estates. Our goal is to complement that with depth for regulated environments and to share as much of that work as we can.
We are also looking at Sigma as a way to convert our detective controls into deployable code. If that proves viable, it would mean a broader set of security tooling beyond Wiz could benefit from the same control logic. More on that soon.
If you have questions about the CCRs, feedback on the packages, or want to see how this maps to your control framework, reach out. We would like to hear from you.

Open-Sourcing Wiz Custom Rules: Measuring and Closing the Coverage Gap
Director, TrustOnCloud
tl;dr: Today we are releasing open-source Wiz Custom Configuration Rule (CCR) packages for AWS S3, Azure Storage, and GCP BigQuery. We mapped TrustOnCloud controls across those 3 major cloud services and compared them against default Wiz coverage. Default coverage sits at roughly 34%, solid for baseline posture, but regulated enterprises consistently need more. Each package includes a mapping of default Wiz rules to our controls and custom rules for the gaps.
- Repos: Azure Storage | AWS S3 | GCP BigQuery
Wiz Covers the Baseline. Regulated Enterprises Need More.
Approximately 70% of our customer base (Fortune 500 firms, government agencies, and regulated enterprises) run Wiz as their CNAPP. Over the past several years, we have built and maintained security controls across these environments and heard a consistent theme from our customers:
“Do you have a mapping between your controls and what Wiz covers by default?”
Today, we are open-sourcing the first set of packages that answer that question. Each package includes a mapping of default Wiz rules to our controls and Custom Configuration Rules (CCRs) written in Rego for the controls Wiz does not cover out of the box.
We are releasing AWS S3, Azure Storage, and GCP BigQuery together, with more services to follow.
Coverage at a Glance

Figure 1: Wiz baseline coverage (blue) vs. TrustOnCloud expansion (green) across Azure Storage, AWS S3, and GCP BigQuery.
Azure Storage sits at 54% Wiz baseline coverage (15 of 28 controls), AWS S3 at 48% (20 of 42), and GCP BigQuery at 3% (1 of 35).
We also weight each gap by its severity (using our **CVSS-based score** based on threat mitigation, threat impact, and control difficulty).

Figure 2: Missing controls by severity across all three services.
Not every missing control carries the same weight. AWS S3 has 2 very high and 9 high severity controls missing. Azure Storage has 1 very high and 3 high. GCP BigQuery has 3 high and 25 medium severity gaps.
Here’s some examples of the controls not covered by default,
| Control ID | Cloud Service | Description |
|---|---|---|
| S3.C50 | AWS S3 | Verify account-level S3 Block Public Access is enabled on all AWS accounts, with BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets set to true. |
| S3.C2 | AWS S3 | Verify the control blocking unencrypted requests and unauthorized TLS versions from IAM entities you control (e.g., an SCP on your AWS Organization's root node) is properly implemented. |
| S3.C20 | AWS S3 | Verify all S3 VPC endpoints are blocking any IAM entity not belonging to authorized AWS Organizations, OUs, and/or AWS accounts. |
| S3.C36 | AWS S3 | Verify the control blocking change ObjectACL to public (e.g., an SCP and VPC endpoint policy) is configured. |
| S3.C67 | AWS S3 | Verify all buckets block PutObject requests with an unauthorized KMS key. |
| S3.C168 | AWS S3 | Verify SSE-C is blocked only when not required for each bucket. |
| Storage.C40 | Azure Storage | Verify only authorized private endpoints are configured on storage accounts. |
| Storage.C45 | Azure Storage | Verify only authorized IPs are permitted through each storage account firewall. |
| Storage.C146 | Azure Storage | Verify required storage container blobs have immutability policies enabled. |
| BigQuery.C8 | GCP BigQuery | Verify only authorized IAM entities are allowed to access the tables, views, and table data in each dataset. |
| BigQuery.C14 | GCP BigQuery | Verify only authorized IAM entities are allowed to access sensitive rows of a table. |
Default Wiz coverage handles the most commonly used features well. Where gaps appear is in deeper, compliance-specific controls for niche or less commonly used features that regulated enterprises still need for audit readiness.
Open-Source CCR Packages
Each package includes:
Mapping of Wiz default rules → TrustOnCloud controls (where coverage exists
Custom Configuration Rules (CCRs) for controls Wiz does not cover by default
One control traced end-to-end
Here is one example showing how a TrustOnCloud control maps through the full chain:
- TrustOnCloud Control: Storage.C49: Restricts cross-tenant replication to authorized accounts
- Wiz default rule mapping id: StorageAccount-019

For the full mapping of every control across each service, explore the repos directly:
- AWS S3: Full control mapping →
- Azure Storage: Full control mapping →
- GCP BigQuery: Full control mapping →
Each CCR is written in Rego and integrates directly into Wiz. For a full technical walkthrough of implementation modes and code examples, see our Wiz Integration documentation.
What’s Next
- More services. Expand CCR packages beyond Azure Storage, AWS S3, and GCP BigQuery, prioritised by customer demand.
- Sigma exploration. We are evaluating Sigma rules as a way to convert detective controls into deployable code across a broader set of security tooling beyond Wiz.
Closing Thoughts
Wiz has changed the enterprise cloud security market by delivering speed and visibility across cloud estates. Our goal is to complement that with depth for regulated environments and to share as much of that work as we can.
We are also looking at Sigma as a way to convert our detective controls into deployable code. If that proves viable, it would mean a broader set of security tooling beyond Wiz could benefit from the same control logic. More on that soon.
If you have questions about the CCRs, feedback on the packages, or want to see how this maps to your control framework, reach out. we would like to hear from you.
Author: Jonathan Rault, Director at TrustOnCloud
Jonathan Rault
Jonathan is the Director for Cloud Security and Risk Management @ TrustOnCloud, where he enables security-sensitive businesses and government agencies to define - and maintain - how to secure fast-evolving Cloud Services for their critical applications and confidential data.