After enabling persisted query scanning, teams should review scan findings, confirm that the query inventory matches what is actually deployed, and verify that new persisted queries are covered before release. The goal is not just to detect vulnerabilities once, but to keep testing aligned with application changes so unsafe queries do not reach production unnoticed.
What teams should verify after turning on persisted query scanning
Once scanning is enabled, the first check is whether the scanner’s findings match the real query inventory, because a broken inventory makes the control look healthier than it is. Teams should also confirm that new persisted queries are entering the scan path before release, not after deployment, so application change and security testing stay in sync.
That matters because persisted queries often move through CI/CD as code, configuration, or pipeline artefacts, which means gaps can appear when the inventory is stale, a build path is bypassed, or a query is introduced by a new repository or branch that was not covered by the initial setup. A useful sanity check is whether the scanner is seeing the same set of persisted queries that engineering expects to ship, not just a sample.
- Review false negatives first, because missed queries are more operationally dangerous than noisy findings.
- Compare the scanner output to the deployed manifest, registry, or allowlist that defines approved persisted queries.
- Verify coverage for pull requests, release branches, and any pipeline path that can introduce a new query.
Where scanning fails in practice
The common failure mode is coverage drift: the scanner is enabled, but the underlying query set changes faster than the inventory or pipeline rules. That creates a blind spot where unsafe persisted queries can be merged or promoted without ever being checked. Treat this as a control integrity problem, not just a tooling problem.
Another issue is assuming that one successful scan proves the control is working. Persisted query scanning is only useful if it keeps pace with application changes, dependency updates, and new delivery paths. NHI lifecycle and visibility guidance is useful here because the same discipline applies: inventory, review, and rotation-style oversight only work when the asset list stays current. For build and release integrity, SLSA helps frame why provenance and protected build paths matter when you are trusting CI/CD outputs.
In practice, teams should watch for three signs of drift: queries that exist in the repository but not in scan results, queries that appear in production but not in the approved inventory, and release paths that can add or modify queries without triggering a fresh scan. If any of those show up, the issue is control coverage, not just vulnerability content.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Persisted query release paths need enforced authorization before promotion. |
| DE.CM-8 — Monitoring for Unauthorized Code Changes | Scanning must detect when query content changes outside approved controls. | |
| GV.RM-01 — Risk Management Strategy | Keeping scans aligned with change reduces residual application risk over time. | |
| Recommendation — Enforce release-path authorizations so only approved queries can reach deployment. Monitor CI/CD for unapproved query changes and alert on inventory drift. Treat scan coverage drift as a managed delivery risk and track it over time. | ||
| CIS Controls v8 | 16.9 — Perform Security Testing of CI/CD Pipelines | Persisted query scanning is a security test embedded in delivery automation. |
| 16.13 — Monitor and Validate the Integrity of Software | Teams must confirm the scanned inventory matches the software actually deployed. | |
| Recommendation — Integrate scanning into the pipeline and verify it runs before release. Validate that deployed persisted queries match the approved, scanned set. | ||
Practitioner Guidance
What to verify: Confirm that every persisted query has a traceable path from source control to scan output to release approval. If you cannot prove that path for a query, treat it as ungoverned until the inventory and pipeline are reconciled.
What to measure: Track inventory coverage, scan freshness, and the percentage of new persisted queries that are scanned before merge or release. A control that only reports on older queries is giving you lag, not protection.
Common mistake: Teams often validate that scanning is “on” but never test whether it is connected to the real delivery path. The safer assumption is that any untested branch, pipeline, or registry update can introduce an unscanned query.
Practitioner takeaway: The real objective is continuous alignment between what the application can ship and what the scanner can see, because persisted query scanning only reduces risk when inventory, pipeline coverage, and release gates move together.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
