Notifications
Clear all
Topic starter
01/08/2026 10:47 pm
TL;DR: Codex Security scanned more than 1.2 million commits and identified 10,561 high-severity vulnerabilities by reasoning about application intent rather than pattern matching, including 792 critical findings during beta testing, according to Gecko Security. The underlying governance problem is that code alone cannot express business logic, trust boundaries, or deployment context, so semantic analysis without design inputs can still mis-rank real risk.
NHIMG editorial — based on content published by Gecko Security: semantic appsec analysis of Codex Security and broken access control
By the numbers:
- Recent analysis across 80 coding tasks spanning four programming languages found only 55% of AI-generated code was secure.
Questions worth separating out
Q: How should security teams use semantic appsec findings in release decisions?
A: Treat semantic findings as decision support, not automatic release blockers.
Q: Why do code scanners miss so many authorization bugs?
A: They usually look for known syntactic patterns rather than the application’s intended access policy.
Q: What do security teams get wrong when they think access management is enough?
A: They confuse the ability to grant access with the ability to govern it.
Practitioner guidance
- Add business-context inputs to appsec triage Require design documents, architecture diagrams, and threat models to accompany any high-severity semantic finding so teams can judge whether the bypass affects a public endpoint, internal service, or constrained admin path.
- Prioritise authorization checks over generic syntax findings Create a triage rule that broken access control, ownership validation failures, and privilege escalation paths outrank low-context pattern matches when release decisions are pending.
- Map application findings to identity controls Review code paths that enforce access decisions against IAM, PAM, and NHI governance requirements, especially where service accounts, tokens, or delegated permissions are embedded in application logic.
What's in the full article
Gecko Security's full article covers the operational detail this post intentionally leaves for the source:
- Its three-phase semantic analysis workflow for identifying access-control flaws across codebases.
- Examples of findings from beta testing across projects such as GnuTLS, Chromium, and PHP.
- The validation approach used to turn candidate flaws into proof-of-concept exploits.
- The company’s explanation of how deployment context changes severity for the same code pattern.
👉 Read Gecko Security's analysis of semantic appsec and authorization bugs →
Code-only scanning for authorization bugs: where does it fall short?
Explore further
01/08/2026 10:56 pm
Code-only appsec creates an intent gap: semantic scanners can reason about control flow, but they still cannot see business purpose, trust boundaries, or deployment context unless those inputs are supplied separately. That makes the real governance problem not detection speed but decision quality. Security teams need to know whether a finding represents an exploitable bypass in a public workflow or a contained issue inside a restricted service, because the same code pattern can carry very different risk.
A question worth separating out:
Q: How can organisations tell whether an appsec finding is actually high risk?
A: Test the finding against the real trust model. Ask whether the path is public, internal, or privilege-bound, whether it reaches sensitive objects or actions, and whether runtime controls such as SSO, network isolation, or service segmentation already limit abuse.
👉 Read our full editorial: Semantic appsec exposes why code-only scanning misses authorization bugs
