Corgea vs Aikido benchmark shows recall matters more than cleaner output

At a glance

What this is: This benchmark compares Corgea and Aikido on a deliberately vulnerable repository and finds that Corgea’s higher recall captured far more source-confirmed application, API, Kubernetes, JavaScript, and configuration issues.

Why it matters: For AppSec teams, the result shows that triage efficiency is not a substitute for discovery depth, because missed findings never enter the remediation workflow at all.

Context

SAST evaluation is often distorted by overvaluing clean-looking output and underweighting missed issues. In practice, a scanner has to surface real vulnerabilities across application logic, APIs, configuration, and deployment assets before any precision advantage matters.

This benchmark uses a deliberately insecure repository, which is exactly the right kind of test when the question is coverage rather than cosmetics. The identity angle is indirect but real: hardcoded credentials, deployment templates, and access-control flaws all touch the governance of secrets and machine-facing access paths.

Key questions

Q: Why can a cleaner SAST result still be the worse outcome for AppSec teams?

A: Because a tidy result set can hide a larger failure: missed vulnerabilities never enter triage, backlog planning, or remediation. Security teams should judge SAST by how many source-confirmed issues it finds in their codebase, then use precision to compare noise among tools that already reach acceptable coverage.

Q: How should teams evaluate SAST tools on repository context rather than signatures alone?

A: Run both tools on the same repository, seed or label source-confirmed issues, and compare their results across authorization, request handling, configuration, and deployment artifacts. A tool that only matches common patterns may look acceptable on injection, but still fail on framework-specific or cross-file weaknesses.

Q: What breaks when hardcoded cloud credentials appear in deployment templates?

A: Deployment artifacts become an access path, not just source code. If scanners and governance controls do not flag those values, exposed machine credentials can persist in Kubernetes or CI files, creating a revocation and ownership problem that standard code review usually does not close.

Q: What is the difference between precision and recall in SAST buying decisions?

A: Precision tells you how many reported findings are real, while recall tells you how many real vulnerabilities the tool actually surfaced. In AppSec programmes, recall is usually the more important control when the goal is to avoid missed weaknesses, because unreported issues cannot be triaged or fixed.

Technical breakdown

Why recall is the controlling metric in SAST benchmarking

Recall measures how many source-confirmed vulnerabilities a scanner actually finds. In a codebase with mixed flaw types, a tool can look attractive if it produces fewer false positives, but that advantage collapses when it misses most of the real issues. Precision is still useful because teams need trustable output, yet precision only helps after the scanner has surfaced the vulnerability in the first place. In this benchmark, that difference was the story: one tool found far more confirmed issues, while the other produced a smaller but much less complete result.

Practical implication: score SAST tools on confirmed findings and false negatives first, then use precision as a secondary tie-breaker.

Why OpenGrep-style pattern detection can miss broader repository context

Traditional rule-based SAST engines are strong at recognizable sinks and well-known insecure patterns, but they can struggle when the weakness depends on framework conventions, authentication boundaries, or multi-file reasoning. That is why one scanner can catch injection or XXE while still missing authorization failures, SSRF, open redirects, or template injection elsewhere in the same repository. The core limitation is not static analysis itself; it is the narrowness of the pattern view when the code needs contextual understanding. Custom application logic is often where the highest-value findings hide.

Practical implication: test whether a SAST tool reasons across application context, not just whether it matches common vulnerability signatures.

How repository-sensitive flaws extend into NHI and secret governance

The benchmark repo included hardcoded AWS credentials in Kubernetes templates and other deployment-level weaknesses. Those findings matter because they expose machine identities and secrets, not just code defects. When credentials live in deployment artifacts, the security question shifts from source scanning to lifecycle governance: who can create, copy, rotate, and revoke non-human credentials, and how quickly can exposed values be invalidated? That is where AppSec, cloud security, and NHI governance intersect. A scanner that misses those paths leaves both code and machine access exposed.

Practical implication: pair SAST with secret discovery and NHI credential controls so deployment artifacts are governed as part of the attack surface.

Threat narrative

Attacker objective: The objective is to exploit unreported application and deployment weaknesses to reach code execution, data access, or credential abuse before defenders can remediate them.

1. Entry occurs through exposed deployment artifacts and insecure application paths in a deliberately vulnerable repository, including hardcoded credentials and unsafe request handling.
2. Credential and logic abuse follow when weak authorization, SSRF, open redirect, and template injection paths are left unreported by the scanner.
3. Impact is missed remediation, because confirmed vulnerabilities never enter the backlog and machine secrets remain available for later abuse.

Breaches seen in the wild

• TeamTNT worm 2020: A TeamTNT cryptomining worm spread through exposed Docker APIs and stole AWS credential files from every host it infected, Cado Security found.
• Laravel-Lang Composer compromise 2026: A stolen GitHub PAT let an attacker rewrite every Laravel-Lang release tag in May 2026, serving a PHP stealer of cloud, CI and SSH credentials.

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

Coverage debt is the real control failure here: a scanner that misses 34 confirmed issues creates a remediation gap larger than any precision gain can offset. In governance terms, the problem is not noisy output but invisible exposure that never enters the work queue. For practitioners, the control question is whether the tool’s recall is sufficient to protect the backlog from blind spots.

Repository context now matters as much as signature matching: application, API, and configuration flaws often coexist in the same codebase, but different scanners surface very different slices of that risk. That makes evaluation methodology part of the security control plane, not just procurement hygiene. For teams, the lesson is to validate depth on the exact repository class they run in production.

Machine identity exposure turns AppSec findings into NHI governance issues: hardcoded cloud credentials in Kubernetes templates are not just a secrets problem, they are a lifecycle problem for non-human access. Once deployment artifacts contain reusable credentials, the governance gap becomes revocation speed, ownership, and inventory. For practitioners, secret scanning and NHI controls must be evaluated together.

High precision is not a substitute for operational completeness: a cleaner result set can improve developer trust while still failing the programme if it leaves most real weaknesses untouched. That is especially true in custom code, where missed authorization and request-routing issues carry the highest business impact. For AppSec leaders, the benchmark reinforces that completeness is the first security requirement.

What this signals

Coverage debt is the operational risk most teams underprice: when a scanner misses large portions of a known-bad repository, the issue is not only analyst effort but the hidden backlog that never forms. For practitioners, the right comparison is whether the tool finds enough of the real weaknesses to support remediation prioritisation, not whether its output looks cleaner.

Hardcoded credentials in deployment artefacts should be treated as NHI exposure: once machine secrets appear in Kubernetes templates or similar files, the governance model has to include inventory, rotation, and revocation for non-human access paths. AppSec teams that separate code scanning from secret governance will miss part of the attack surface.

Context-aware analysis is becoming the differentiator in SAST: simple pattern engines can still catch injections, but teams increasingly need coverage across authorization boundaries, framework behaviour, and multi-file logic. That shifts evaluation away from marketing claims and toward proof on the exact repositories that matter.

For practitioners

• Test scanners against source-confirmed issues Use a deliberately insecure repository or seeded benchmark and score confirmed true positives, false positives, false negatives, recall, precision, and F1 on the same codebase.
• Separate default SAST from deeper analysis layers Validate whether the plan you are buying includes the full analysis depth you expect, because different layers may produce very different coverage on the same repository.
• Add secret and machine-identity checks to AppSec evaluation Treat hardcoded cloud credentials, deployment templates, and exposed tokens as part of the scanner comparison, not as a separate afterthought.
• Measure fix workflow, not just findings Check whether reported vulnerabilities translate into actionable backlog items that developers can fix without losing authorization, validation, or business logic.
• Score contextual weaknesses explicitly Include authorization gaps, SSRF, open redirect, and template injection in your evaluation rubric because those flaws are where context-aware analysis should outperform simple pattern matching.

Key takeaways

• The benchmark shows that a smaller, cleaner alert set is not enough when a scanner leaves most source-confirmed weaknesses undiscovered.
• Corgea’s higher recall changed the operational picture because 34 missed issues would never have entered the remediation queue.
• AppSec teams should evaluate SAST depth, secret exposure, and contextual reasoning together, especially where deployment files contain machine credentials.

Key terms

• False negative: A missed detection where a real threat is not recognised as malicious or important. In AI SOC environments, false negatives often arise when the system under-collects context, stops at the first plausible answer, or over-optimises for speed.
• Recall: The share of real weaknesses that the scanner successfully identifies. High recall reduces the chance of missed vulnerabilities, but if it is achieved by over-reporting, teams can become overwhelmed and stop trusting the results.
• Static analysis: Static analysis is the inspection of source code or configuration without executing it. It helps identify insecure patterns early, but its value depends on accuracy, timing, and whether the output is usable enough for developers to fix issues while they are still working on the code.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is suited to practitioners who need to connect application findings with credential lifecycle control.