Topic starter
19/08/2026 4:04 pm
TL;DR: A benchmark review found 42 of 47 source-confirmed issues in a deliberately vulnerable repository and outperformed Snyk on precision, recall, and F1, according to Corgea. The result reinforces a familiar SAST lesson: coverage across authentication, configuration, and code-path context matters as much as recognizable taint-flow patterns.
Editorial analysis by NHI Mgmt Group, based on content published by Corgea: “Corgea vs. Snyk: We benchmarked SAST on a deliberately vulnerable repo”.
By the numbers:
- Corgea found 42 of 47 source-confirmed issues in the benchmark repository.
- Snyk found 26 of 47 source-confirmed issues in the benchmark repository.
- Corgea reached 89.36% recall in the benchmark review.
Key questions
Q: What breaks when a scanner finds vulnerabilities but does not fix them?
A: Teams accumulate findings faster than they can close them, so the scanner becomes a reporting layer instead of a control.
Q: Why do recall and precision both matter in SAST evaluation?
A: Recall shows how many real issues the scanner finds, while precision shows how much of its output is trustworthy.
Q: What do security teams get wrong about secure-code benchmark scores?
A: They often assume a higher benchmark score means safe deployment.
Practitioner guidance
- Benchmark scanners on the same confirmed issue set Use a fixed, source-confirmed repository benchmark and compare true positives, false positives, and false negatives on identical scope before standardising a scanner.
- Include configuration and deployment files in evaluation Test whether the tool inspects manifests, templates, and environment files for secrets, parser flags, and exposure settings, not only application source.
- Review authorization gaps alongside code findings Route findings that expose user data, token data, or state-changing endpoints through an authorization review so missing access controls are not treated as ordinary code defects.
Bottom line: Corgea’s benchmark showed that scanner performance is defined by more than recognizable injection patterns, because missing authorization and configuration weaknesses still matter operationally.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:38 pm
Coverage is the deciding variable in scanner selection when a repository contains mixed vulnerability classes. A tool that sees only familiar taint-flow patterns will miss authorization gaps, parser abuse, and deployment-level exposures that materially increase risk. In this benchmark, the better outcome came from finding more confirmed issues across more parts of the repository, not from optimising for a single vulnerability family. Practitioners should treat breadth of detection as a governance requirement, not a convenience feature.
A question worth separating out:
Q: How should teams compare two SAST tools before adoption?
A: Compare them on the same fixed repository, the same confirmed issue set, and the same classification rules for true positives, false positives, and false negatives. Then assess whether the tool exposes issues across code, configuration, and deployment assets, not only whether it catches familiar vulnerability patterns.
👉 Read our full editorial: Corgea vs Snyk on a vulnerable repo: what the benchmark shows