Notifications
Clear all
Topic starter
01/08/2026 10:50 pm
TL;DR: Security findings without reachability, exposure, and control context create an “alert factory” effect, and Checkmarx cites research showing 80-90% of findings can be irrelevant while 72% of developers spend more than 17 hours a week on security tasks. Context-driven triage and automated remediation shift AppSec from severity labels to demonstrated exploitability and merge-ready fixes.
NHIMG editorial — based on content published by Checkmarx: context-driven AppSec triage and automated remediation
By the numbers:
- When 80-90% of findings are irrelevant, teams lose time on alerts that never needed sprint disruption.
- 72% of devs spend more than 17 hours each week on security-related tasks, and one in four spends more than 25 hours.
- Manual remediation processes failed to keep pace with attackers 88% of the time across critical actively weaponized vulnerabilities studied.
Questions worth separating out
Q: How should security teams prioritise vulnerabilities when code scans and runtime data disagree?
A: Treat runtime evidence as the tie-breaker.
Q: Why do authentication and permission boundaries change vulnerability risk?
A: Because a flaw in code is not automatically exploitable if the attacker cannot reach it or lacks the access needed to trigger it.
Q: What do teams get wrong about low-severity findings in public-facing workflows?
A: They assume low severity means low urgency.
Practitioner guidance
- Require exploitability evidence before prioritisation Gate backlog creation on reachability, attacker-controlled input, and compensating controls.
- Map findings to identity and exposure boundaries Record whether the vulnerable code sits behind authentication, privileged roles, network segmentation, or public workflows.
What's in the full article
Checkmarx's full analysis covers the operational detail this post intentionally leaves for the source:
- How Attackability analysis traces attacker-controlled inputs from ingress points to potential impact
- The specific evidence fields used to distinguish demonstrated exploitability from theoretical findings
- How Remediation Assist turns validated issues into minimally invasive pull requests
- The workflow integration details for review, testing, and merge of generated fixes
👉 Read Checkmarx's analysis of context-driven vulnerability triage and remediation →
Context-driven AppSec triage: are your findings actually exploitable?
Explore further
01/08/2026 10:58 pm
Context-driven exploitability is becoming the real triage standard. Severity scores alone do not tell engineering whether a finding should interrupt sprint work. The more useful question is whether an attacker can actually reach the code, influence execution, and bypass the controls already in place. That is why reachability, exposure, and control context now matter as much as the defect itself. For practitioners, the shift is from vulnerability counting to evidence-based prioritisation.
A question worth separating out:
Q: How should organisations move from validated findings to remediation?
A: Convert the confirmed risk into a reviewable pull request with the smallest safe code change, then run tests and inspect the diff like any other engineering change. That keeps the fix inside the development workflow and prevents security from becoming a separate queue of vague tickets. The key is to automate the handoff after evidence, not before it.
👉 Read our full editorial: Context-driven AppSec triage is reshaping vulnerability prioritisation
