Manual queries are best when a developer wants an immediate answer to a specific question, such as whether a base image or dependency is risky. Automated rule-based scanning is better for repeatable checks tied to file changes or infrastructure edits. Most teams need both: one for targeted investigation, the other for consistent enforcement.
Why This Matters for Security Teams
Manual security queries and automated rule-based scanning solve different workflow problems, but teams often confuse them because both appear as “security checks.” Manual queries are interactive and decision-oriented: a developer asks a specific question about a base image, dependency, secret, or permission edge case and gets a fast answer. Automated scanning is enforcement-oriented: it repeatedly checks changes against known rules, catching regressions without relying on someone to remember the policy. That distinction matters because developer workflows move quickly, and the wrong control at the wrong point creates noise instead of signal. NIST SP 800-53 Rev. 5 treats configuration and change monitoring as separate control functions, which is why mature programs split investigation from enforcement rather than trying to make one tool do both. For background on the operational consequences of missed security checks, see the NHIMG coverage of the GitHub Action tj-actions Supply Chain Attack. In practice, many security teams discover the gap only after a risky change has already shipped, rather than through intentional developer feedback loops.
How It Works in Practice
Manual queries work best when the developer already has a hypothesis. A query can ask whether a package version is known to be vulnerable, whether a container base image includes a risky library, or whether a Terraform change introduces an exposed service. The value is speed and context: the result can explain why something is risky, not just whether it matches a rule. Automated rule-based scanning, by contrast, runs on every commit, pull request, or pipeline stage and compares code or infrastructure against predetermined conditions. That makes it suitable for repeatable checks such as forbidden secrets patterns, disallowed registries, or insecure IAM permissions. The most effective teams separate the two paths operationally:
- Use manual queries for triage, exception review, and architectural questions.
- Use automated scanning for baseline policy enforcement and regression detection.
- Keep rule logic versioned so developers can see why a change failed.
- Route findings into the same ticketing or review process to avoid duplicate handling.
This split aligns with the broader control logic in NIST guidance and the security practices described in the State of Secrets in AppSec, where remediation speed and developer behaviour are persistent gaps. For control depth, the NIST SP 800-53 Rev. 5 Security and Privacy Controls is the right reference point for mapping checks to policy outcomes. These controls tend to break down when teams rely on automated scanning for ambiguous risk decisions in fast-moving monorepos because the rule set cannot reliably infer developer intent or deployment context.
Common Variations and Edge Cases
Tighter automated scanning often increases developer friction, requiring organisations to balance enforcement strength against pipeline latency and false positives. That tradeoff is especially visible in polyglot repositories, generated code, and infrastructure-as-code stacks where a single rule can flag many benign changes. Current guidance suggests using manual queries for the judgment-heavy cases, then converting high-confidence findings into automated rules once the pattern is stable. There is no universal standard for this yet, but mature programs usually evolve from “ask first, scan later” to “scan by default, query for exceptions.” The same is true when teams support both application code and cloud infrastructure: a dependency risk question is better answered interactively, while a known-bad secret pattern should be blocked automatically. For identity-heavy workflows and machine-created assets, NHIs add another layer of complexity, which is why the Ultimate Guide to NHIs — What are Non-Human Identities is useful when policy scope includes service accounts, CI jobs, and automation tokens. The practical edge case is teams that over-automate early and then disable the scanner after too many false alarms, usually because the rules were written without developer workflow context.
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 NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-1 | Helps distinguish manual review from automated protection of data and code artifacts. |
| NIST SP 800-53 Rev 5 | CM-2 | Baseline configuration management underpins repeatable rule-based scanning. |
Use manual queries for targeted review and automated scans to continuously protect sensitive code and secrets.
Related resources from NHI Mgmt Group
- What is the difference between developer-native security testing and separate-console scanning?
- How do security teams decide between manual classification and automated content scanning?
- What is the difference between rule-based SOAR and true agentic security automation?
- What is the difference between behavior-based runtime security and rule-based runtime security?
