Project information
A single place to understand what the packs support, where local validation is still required, and which standards and vendor documentation inform the implementation guidance.
Scope
The webpage checks query structure, platform shape, unresolved parameters, and evidence-source names in the browser. A green preflight means no local issue was detected. It does not replace the vendor engine: the page also gives a platform-specific tenant validation step, such as Athena EXPLAIN (TYPE VALIDATE) or a short-scope run in Log Analytics or Splunk Search.
Coverage
Queries only ever run in Microsoft Sentinel, AWS, or Splunk. Everything else you select is either a source those queries read or a system you export evidence from.
A published query names this technology's own tables or API — Azure KQL reads IdentityInfo, AWS Athena reads iam_credential_report. Nothing to export or forward. This applies to Microsoft Azure, Amazon Web Services, Splunk Enterprise Security, Microsoft Entra ID, Active Directory, AWS IAM, Azure Backup, AWS Backup, and the Azure and AWS configuration sources.
The published Splunk searches read vendor-neutral sourcetypes, not any vendor's own tables: directory:users, privileged:assignments, credential:inventory, backup:jobs, config:snapshot, and network:rules.
Forward a product into Splunk with the right sourcetype and fields and the existing query covers it, with no new query written. Emit one event per backup job to index=ops sourcetype=backup:jobs carrying resource_id and status, and the published CP-9 search covers Veeam, Rubrik, Commvault, Google Cloud Backup and DR, or a tool written in-house. The same holds for Okta and Google Cloud IAM on the identity controls.
Azure and AWS read vendor-specific tables, so they cannot absorb a third-party product this way and stay strict about the source you select.
Export into one of the five open CSV contracts the published queries join to. For a CMDB or a ticketing system this is not a workaround — supplying evidence the cloud cannot produce is exactly what those systems are for in this method. A CMDB feeds asset_inventory.csv; a ticketing system or Git history feeds change_approvals.csv.
Provenance
Every pack states its own validation status on the page, in the downloadable profile, and in the printed guide. Nothing is inferred from silence.
Not tenant-validated means structure, query generation, and preflight are covered by the automated test suites and the query has not been executed against any live tenant. Lab-validated means the maintainer ran it in a personally controlled environment on a recorded date. Field-reported means practitioners reported running it themselves — self-reported context, not independent verification.
As of release 0.17.0 every one of the 30 control and platform combinations is “not tenant-validated.” That is the accurate position and it is stated rather than left to be assumed.
A checked-in manifest records the SHA-256 of all 30 published query templates and all 5 evidence templates. A downloaded profile names the exact artifact it came from, and the value can be re-derived from the repository with sha256sum. Continuous integration fails if the manifest drifts from the files on disk.
Each pack exports a JSON implementation profile carrying the objective and its source, organization-defined parameters, the evidence contract, the platform implementation, the monitoring configuration, the bounded outcome vocabulary, the human-review boundary, the validation status, and the template hash. It is OSCAL-informed and not an OSCAL document — it has not been validated against any OSCAL schema, and the artifact says so in its own conformance block. Inline evidence you type is recorded as a row count and column list; the values are never written into the file.
Official sources
These links go directly to NIST, Microsoft, AWS, and Splunk documentation.