Topic starter
19/08/2026 4:05 pm
TL;DR: On a deliberately vulnerable repository, 42 of 47 source-confirmed issues were found, reaching 89.36% recall and 85.71% F1, according to Corgea. Aikido found 13 issues at 27.66% recall and 41.94% F1, while the benchmark shows that cleaner output is not enough when missed vulnerabilities never enter the remediation queue.
Editorial analysis by NHI Mgmt Group, based on content published by Corgea: “Corgea vs. Aikido: We benchmarked SAST on a deliberately vulnerable repo”.
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.
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.
Q: What breaks when hardcoded cloud credentials appear in deployment templates?
A: Deployment artifacts become an access path, not just source code.
Practitioner guidance
- 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.
Bottom line: The benchmark shows that a smaller, cleaner alert set is not enough when a scanner leaves most source-confirmed weaknesses undiscovered.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:39 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Corgea vs Aikido benchmark shows recall matters more than cleaner output