Project information

Scope, validation, and references

What the packs support, how they are validated, and which references inform them.

Scope

What the packs are designed to do

Supported

Connect an objective to evidence and monitoring
Show assumptions and organization-defined settings
Provide open CSV schemas for missing evidence
Generate queries for Microsoft Sentinel, AWS, and Splunk
Explain how to test, deploy, and review each result

Not established by the tool

Certification or a complete compliance decision
Compatibility with an untested schema, connector, or add-on
Automatic authorization, remediation, or human judgement
A clean result just because a query returned no rows
Deployment just because a page or pack was opened

How query checking works

The page checks structure, platform syntax, parameters, and source names in your browser. A green preflight is not a vendor-engine result, so run a short validation in Athena, Log Analytics, or Splunk before relying on it.

Coverage

How technology connects to a query

Queries run in Microsoft Sentinel, AWS, or Splunk. Other technologies provide data or evidence.

Direct query

The query reads the technology's own tables or API. Nothing is exported or forwarded.

Via Splunk

Forward records into Splunk using the documented sourcetype and fields. The existing SPL query can then cover products such as Okta, Veeam, Rubrik, Commvault, VMware, and Google Cloud.

Azure and AWS queries read vendor-specific tables and do not use this route.

Via CSV export

Export the required fields into one of the six open CSV schemas. CMDBs, ticketing systems, and Git history can provide this evidence.

Not covered in this release

CloudWatch Logs Insights — scoped, not implemented; use the published AWS Athena path
A native Google Cloud query family — GCP is covered through Splunk and the evidence contracts only
Any route not listed on the environment profile for that technology

Provenance

What has been validated

Every pack shows its validation status in the page and downloaded profile.

Validation status

Not tenant-validated means automated checks passed but the query has not run against a live tenant. Lab-validated means it ran in a controlled test environment. Field-reported means a practitioner reported running it; it is not independent verification.

At release 0.30.0, all 13 Splunk packs are lab-validated. The 26 Azure and AWS packs are not tenant-validated.

Content hashes

A manifest records a SHA-256 hash for every query and evidence template. Profiles identify the exact artifact they came from, and automated checks flag changes.

Machine-readable profile

Each pack exports JSON with its objective, evidence, settings, query, monitoring, outcomes, review boundary, validation status, and template hash. It is OSCAL-informed, not an OSCAL document. Inline evidence is represented by row count and columns; values are not written to the profile.

Corrections are published

An earlier release showed false preflight failures for some inline evidence queries
The check and its test coverage were corrected
The original defect is documented in the public changelog

Official sources

Standards and implementation documentation

These links go directly to NIST, Microsoft, AWS, and Splunk documentation.

NIST SP 800-53 Rev. 5Security and privacy controls NIST SP 800-53A Rev. 5Assessment procedures NIST OSCALMachine-readable control information CISA Cross-Sector CPGs 2.0The federal baseline written for small and medium organizations Sentinel watchlistsCreate and verify CSV-backed watchlists Azure custom logsLand evidence through a Data Collection Rule Log AnalyticsWrite and test KQL in the intended workspace Athena CSV dataRegister CSV data with a compatible SerDe Athena EXPLAINValidate SQL without scanning data Splunk CSV lookupsUpload, share, and define a lookup Splunk search referenceConfirm SPL commands and syntax