TL;DR: It now supports scanning CodeQL query language rules, aiming to catch logic errors in security checks before they reach runtime, according to Semgrep. The practical lesson is that policy-as-code and code-scanning guardrails are only as reliable as the tooling that validates the rules themselves, not just the applications they inspect.
At a glance
What this is: Semgrep’s article says it can now scan CodeQL rules, highlighting that rule logic errors in secure guardrails can be caught statically instead of surfacing only at runtime.
Why it matters: IAM, AppSec, and platform teams that rely on policy-as-code need validation for the policies themselves, because a broken guardrail can leave insecure code or access checks looking compliant when they are not.
Context
Code scanning controls are only as trustworthy as the rules that define them. If a policy or query contains a logic error, teams may get a false sense of assurance while the underlying weakness still passes through the control.
This article sits at the intersection of application security, secure coding governance, and policy-as-code quality. The identity angle is indirect but real: when teams use code-defined guardrails to protect secrets, access checks, or secure development workflows, those rules become part of the control plane and need validation like any other security asset.
Key questions
Q: What breaks when a security rule contains a semantic logic error?
A: A broken rule can still parse cleanly while checking the wrong condition, which means the control appears active but no longer enforces the intended security outcome. In practice, this creates false assurance in code scanning, secrets checks, or policy-as-code workflows, so teams need validation for the rule logic itself, not only for the software under inspection.
Q: When should teams prioritise rule validation over adding more guardrails?
A: Teams should prioritise rule validation whenever security checks are being codified into scanners, IDE automation, or policy engines that gate developer behaviour. Additional guardrails do not help if the existing ones are semantically wrong. The first priority is proving that the rule definitions match the intended control before expanding coverage.
Q: What signs show that policy as code is drifting out of sync with control requirements?
A: Look for policies that still evaluate successfully while the underlying benchmark, cloud architecture or access model has changed. Other warning signs include unclear control mappings, inconsistent rule exceptions across teams, and decision logs that cannot be tied back to a named requirement. Those are governance drift indicators, not just implementation noise.
Q: How should security teams govern code-scanning rules and checkers?
A: Treat them as governed security assets with ownership, versioning, testing, and staged rollout. Rules that can influence secure coding, secret detection, or access decisions should be reviewed and verified before they become authoritative. That governance keeps analysis logic aligned with the control objective instead of assuming tooling correctness by default.
Technical breakdown
Static validation for CodeQL rules
CodeQL queries are themselves structured logic, not just text. When a query is malformed or contains a self-comparison bug, the analysis engine may still execute it without warning, but the resulting check no longer expresses the intended security condition. Static validation looks for inconsistencies in the rule definition before the rule is trusted in a pipeline or IDE. That matters because guardrails are only effective when the policy logic matches the security intent, not merely when syntax parses cleanly.
Practical implication: treat security rule logic as code that needs its own verification layer before deployment.
Parse trees, intermediate ASTs, and language support
Semgrep’s approach depends on turning CodeQL syntax into a parse tree, then into an intermediate abstract syntax tree, and finally into the engine’s generic AST. That translation layer is what lets one analysis engine reason about many languages and rule types in a common format. The technical challenge is not just language coverage but preserving semantics across representations. Any mismatch in that pipeline can alter how a rule is interpreted, which is especially sensitive when the rule is meant to govern developer security behavior.
Practical implication: validate translation fidelity for any security language or DSL before relying on it for enforcement.
Guardrail quality is a control problem, not just a developer UX problem
A guardrail that silently accepts an incorrect rule creates a control failure, not a mere usability issue. In policy-as-code environments, the policy layer becomes part of the security perimeter, so broken logic can undermine code scanning, secrets checks, or secure design enforcement even if the application code is sound. This is why code review alone is not enough for rule content. The rule itself needs detection, testing, and lifecycle governance as if it were any other security control.
Practical implication: put security rules under change control, testing, and review thresholds before they are allowed to enforce anything.
Threat narrative
Attacker objective: The objective is not direct compromise but control failure, namely a trusted security rule that no longer evaluates the intended condition and leaves weak code unchecked.
- Entry occurs when a flawed CodeQL rule or query definition is introduced into the guardrail set through normal development workflow.
- The faulty logic persists because the language server does not necessarily flag a self-comparison or equivalent semantic error in-editor.
- Escalation happens when the broken rule is trusted by scanners or IDE automation and begins validating the wrong condition.
- Impact is a false control state, where developers believe security checks are in place even though the intended policy is not actually enforced.
Breaches seen in the wild
- Millions of Misconfigured Git Servers Leaking Secrets: Nearly 5 million misconfigured Git servers expose sensitive secrets and credentials online.
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Secure guardrails need guardrails of their own: policy-as-code becomes part of the security control surface the moment teams use it to enforce coding or access rules. If the rule logic is wrong, the organisation can drift into a state where enforcement appears healthy but is semantically broken. Practitioners should treat rule validation as a first-class control, not an optional quality check.
Rule correctness is a control-plane issue, not just a code-quality issue: the article’s central lesson is that analysis languages can fail in ways ordinary compilation does not catch. That matters for application security, secrets governance, and any workflow where secure-by-default patterns are encoded as checks. Teams need testing, review, and change control around the rule artefacts themselves, not only the software they inspect.
CodeQL scanning for CodeQL is a useful pattern for policy assurance: validating security logic with a second analysis layer creates a meta-control that can catch mistakes before they reach runtime or CI enforcement. The broader implication for AppSec and IAM-adjacent policy engines is that the governance of controls must extend to the definitions of the controls. Practitioners should assume every machine-enforced rule can fail semantically unless it is independently checked.
Semgrep’s 99.999% parse rate claim is less interesting than what it signals about expectations: organisations increasingly want high-fidelity parsing and semantic handling for security languages because partial support creates blind spots. That raises the bar for tooling selection and for internal assurance processes. Practitioners should demand evidence that a policy engine can represent the full rule set they intend to enforce.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: Top 10 NHI Issues
What this signals
Rule validation is the missing layer in many policy-as-code programmes: teams often invest in guardrails for developers but not in the correctness of the guardrails themselves. Once security logic is encoded in scanners or IDE extensions, the rule set becomes operational infrastructure and should be tested accordingly. Practitioners should expect semantic failures, not just syntax errors.
A useful mental model is to treat policy definitions as control-plane assets. That means versioning, review, and negative testing should apply to detection and enforcement rules with the same seriousness as to application code. For teams already struggling with secrets hygiene, this matters because broken developer-facing checks can let bad patterns persist until they become incident material.
For practitioners
- Validate security rules before they enforce anything Add static checks for rule logic, not just syntax, so self-comparisons, unreachable branches, and malformed conditions are caught before deployment.
- Put policy-as-code under change control Require review, test cases, and approval for security rules in the same way you would for application code that can change access or detection outcomes.
- Test guardrails against known-bad examples Build negative test fixtures that deliberately include broken patterns, then confirm the scanner flags them before the rule set is trusted in CI or the IDE.
- Treat security DSLs as governed assets Track ownership, versioning, and rollout status for CodeQL, Semgrep, and similar rule files so the organisation knows which checks are authoritative at any moment.
- Audit developer-facing security automation Review IDE extensions and command-line workflows to confirm that the same guardrail logic is being applied consistently across authoring and build stages.
Key takeaways
- The core risk is not that code-scanning guardrails exist, but that the rules behind them can be logically wrong while still appearing valid.
- Semgrep’s example shows that static analysis can be extended to validate security rule logic before the rule reaches CI or the IDE.
- For practitioners, the control to strengthen is rule governance itself, including testing, review, and negative cases for policy-as-code.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Broken rule logic creates an enforcement misconfiguration in code-scanning workflows. |
| Recommendation — Review security checks as configuration assets and validate that each rule enforces the intended condition. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The article focuses on validating security logic embedded in development workflows. |
| Recommendation — Test security rules as part of secure architecture and coding governance before they are trusted. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest data are protected | Policy-as-code controls protect security outcomes by enforcing correct checks on developer workflows. |
| Recommendation — Use documented control testing to confirm security automation is functioning as designed. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is about validating software security logic and development-stage controls. |
| Recommendation — Apply application security controls to verify that developer-facing checks are correct and maintained. | ||
| MITRE ATT&CK | TA0005 — Stealth | Silent control failure lets weak patterns bypass detection without obvious alarms. |
| Recommendation — Map silent rule failure to stealthy bypass conditions and test for undetected policy gaps. | ||
Key terms
- Policy as Code: Policy as code stores authorization logic in version control and evaluates it through testable, reviewable rules. For agent governance, it makes runtime decisions reproducible and measurable, which is critical when actions can be triggered by untrusted content and executed at machine speed.
- Semantic Validation Gap: Semantic validation gap is the mismatch between what a filter sees in text and what an AI model understands as intent. It matters because an instruction can be rephrased, hidden in context, or embedded in retrieved content while still steering the model toward the same harmful action.
- Guardrail Validation: Guardrail validation is the process of proving that an AI control actually blocks, redirects, or records the behaviour it is meant to govern. For agentic systems, validation must include adversarial prompts, tool calls, and regression testing so the control is shown to work at runtime, not just in design.
- Domain-specific query language: A domain-specific query language is a specialised syntax built to express checks for a particular analysis engine or security use case. These languages are powerful, but they also create governance risk because small logic errors can change what the control really does.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and machine identity security. It helps security and identity practitioners build the governance muscle needed to manage controls that now operate as code.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org