Gecko Security versus ZeroPath: why semantic code analysis matters

At a glance

What this is: This comparison argues that semantic analysis is better suited than AST-only scanning for proving exploitability in distributed applications with business logic risk.

Why it matters: For IAM and security teams, the issue is whether findings reflect real authorization failure modes across services, repos, and runtime context, or just syntactic code patterns.

By the numbers:

• Broken access control tops the OWASP list at 100% of tested applications.
• Gecko Security says it reduces false positives by 50% compared with traditional SAST through semantic code understanding.
• Gecko Security says its pull request scans complete in under 60 seconds on average.
• Gecko says it has found 30+ CVEs in major open source projects like Cal.com, Ollama, and N8N.

👉 Read Gecko Security's comparison of semantic analysis and AST-based scanning

Context

Application security tools are judged less by how many issues they flag than by whether those findings map to real exploit paths. In distributed systems, broken access control and authorization bypass often span runtime behaviour, shared libraries, and service boundaries, which means code-only pattern matching can miss the control failure that actually matters.

The identity intersection is direct when application flaws expose user context, permission checks, or service-to-service authorisation paths. For IAM and PAM teams, that creates a familiar governance problem: if the analysis cannot prove where access is validated and where it is dropped, the organisation cannot tell whether the issue is a defect, a privilege design gap, or an identity control failure.

Key questions

Q: How should security teams choose between semantic code analysis and AST-based scanning?

A: Choose semantic analysis when your highest-risk defects involve authorization logic, shared libraries, microservices, or runtime-dependent call chains. AST-based scanning is still useful for syntactic flaws like injection, but it struggles when correctness depends on how code behaves across repositories and services. If a finding must prove exploitability, semantic context is the safer default.

Q: Why do broken access control issues survive normal application security testing?

A: They survive because many tools look for patterns inside a single file or repository, while the failure often lives in how multiple functions or services enforce the same rule differently. If the analysis cannot trace where permissions are checked, dropped, or assumed, it will miss the actual control failure. That is especially common in distributed systems.

Q: What do security teams get wrong about false positives in code scanning?

A: They treat false positives as a nuisance metric instead of a control-quality signal. High noise means analysts spend time validating artefacts rather than fixing real authorization defects. The better question is whether the tool consistently produces findings with evidence strong enough for developers and risk owners to act on without re-investigation.

Q: How should teams respond when a scanner can prove exploitability in a distributed system?

A: They should route the finding into the same remediation path used for confirmed access-control defects, not a generic backlog. A proven exploit path means the issue already crosses the line from theoretical weakness to actionable risk. The right response is to fix the permission boundary, then retest the chain end to end.

Technical breakdown

Semantic code analysis versus AST parsing

AST-based scanners understand syntax, not the full meaning of execution. They can spot a dangerous function call, but they often lose the thread when type information changes at runtime, especially in Python and JavaScript. A semantic model built from a code property graph and language-server type resolution can follow symbols across files, libraries, and services while preserving intent. That matters when the vulnerability is not an injection pattern but an authorization path that only exists when multiple functions are composed together.

Practical implication: teams should prefer analysis that can trace call chains and validate intent across repositories when business logic flaws are in scope.

Runtime context, architecture diagrams, and proof of exploitability

Static code alone rarely tells you whether a finding is exploitable in the target environment. Runtime telemetry, architecture diagrams, API specs, and design documents add the missing context by showing how the application is actually deployed and how permissions are supposed to work. When a scanner can connect those sources, it can describe exploitability conditions, generate a proof of concept, and explain business impact in a way developers and risk owners can act on. That shifts output from guesswork to evidence.

Practical implication: security teams should insist that findings include environment context and verification evidence before they reach remediation queues.

Cross-microservice authorization gaps

Microservice risk is often created by the seams between systems, not the systems themselves. Gateway validation can look correct while downstream services skip the same checks, or shared libraries can propagate flawed authorization assumptions across repositories. Semantically aware tooling can trace HTTP clients to endpoints, gRPC callers to service definitions, and message publishers to subscribers. That gives teams visibility into where user context disappears and where permissions are assumed rather than enforced.

Practical implication: teams running distributed applications should validate authorization at service boundaries, not just inside individual repos.

NHI Mgmt Group analysis

Semantic authorization failure is the real category problem: business logic breaches happen when tools see code structure but not the intended access model. That is why application security teams need analysis that can prove whether permissions are actually enforced at the point of use, not merely declared in the codebase. The difference matters across IAM, PAM, and application security because broken access control is often an identity failure expressed in code. Practitioners should treat semantic verification as the baseline for distributed authorization review.

Proof of exploitability changes the triage model: findings without a working exploit path are often too ambiguous for fast remediation, especially in large engineering organisations. When a scanner attaches runtime evidence, a proof of concept, and mapped business impact, the issue becomes a risk decision rather than an abstract alert. That aligns better with NIST SP 800-53 Rev 5 Security and Privacy Controls and with how teams prioritise access-control defects. Practitioners should demand evidence that survives security and development review.

Cross-repository call-chain visibility: distributed applications fail at the seams, where one service trusts another to enforce the same rule. Semantic tracing across microservices and shared libraries exposes the hidden assumption that downstream systems will repeat upstream checks. In identity terms, this is a control continuity problem, not a scanner coverage problem. Practitioners should map where user context is validated, preserved, and lost across the full request path.

Fewer false positives matter because review capacity is finite: reducing alert noise is not a comfort metric, it is a governance issue. If analysts spend time on syntactic artefacts, the real access-control defect waits longer for review and remediation. The practical outcome is faster closure on defects that affect privilege boundaries, which is where application risk becomes identity risk. Practitioners should measure whether the tool shortens time to verified finding, not just time to first alert.

What this signals

Semantic application security is increasingly becoming an identity governance problem because the most damaging defects are often authorization failures, not just code defects. For teams running microservices or shared libraries, that means security tooling must prove where permission checks survive the request path and where they disappear.

Authorization continuity: this is the control question that now separates useful findings from noisy output. Teams should watch whether scanners can maintain context across repos, services, and runtime signals, because that determines whether a result is a real risk or just a syntactic artefact.

If your remediation process still treats all findings as equal, you will keep spending review capacity on issues that never become incidents. Mature programmes will increasingly prioritise evidence-backed findings that identify the exact boundary where user context or privilege was lost.

For practitioners

• Prioritise semantic analysis for authorization-heavy systems Use a semantic scanner on services where broken access control, IDOR, and multi-step privilege escalation are the dominant risks. Require the tool to trace call chains across files, shared libraries, and service boundaries before you trust the result.
• Require exploitability evidence for every high-severity finding Reject findings that do not include a proof of concept, a clear exploitability condition, and an explanation of business impact. That forces triage to focus on defects that can actually become breaches.
• Review authorization at service boundaries Map where gateway checks end and downstream enforcement begins, then verify that the same user context and permission logic survive each hop. Shared utilities and API gateways should not be treated as substitutes for local enforcement.
• Measure false positives against analyst time, not vendor claims Track how many findings are verified, dismissed, or duplicated during review. A tool that lowers alert volume but still consumes large amounts of analyst time is not improving governance.

Key takeaways

• The central issue is not code coverage, it is whether the tool can prove where authorization actually fails.
• Gecko’s analysis frames exploitability, runtime context, and cross-service tracing as the controls that separate real findings from noise.
• For appsec and IAM teams, the governance test is whether a scanner can show the exact boundary where privilege checks disappear.

Key terms

• Semantic Code Analysis: A method of examining code based on meaning and intent rather than only syntax or known patterns. It tries to understand how an application behaves across files, services, and call chains so it can detect logic failures that signature-based tools miss.
• Broken Access Control: Broken access control occurs when a system fails to restrict what an authenticated user, service, or workload can do. The issue often appears as missing checks, inconsistent enforcement, or excessive permissions. It is a structural weakness because attacks exploit the gap between verified identity and permitted action.
• Exploitability proof: Exploitability proof is evidence that a vulnerability can or cannot be turned into a working attack in a specific environment. It goes beyond severity scores by testing real paths, privileges, configurations, and dependencies that determine whether an attacker can achieve impact.
• Cross-Microservice Authorization Gap: A cross-microservice authorization gap appears when one service validates access but another trusts the request without repeating the same check. These gaps are common in distributed systems because security assumptions drift between gateways, shared libraries, and downstream services.

What's in the full article

Gecko Security's full comparison covers the operational detail this post intentionally leaves for the source:

• Concrete examples of the code-property-graph workflow used to trace cross-service call chains
• Detailed descriptions of the proof-of-concept generation process for exploitability validation
• Side-by-side product workflow examples for distributed repositories and shared library analysis
• Operational output examples showing how business impact is mapped to each finding

👉 Gecko Security's full post covers the exploitability workflow, cross-microservice tracing, and evidence generation details

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners building stronger access-control programmes. It is designed for security teams that need a common language for identity risk across applications, infrastructure, and operations.