Notifications
Clear all
Topic starter
02/08/2026 11:48 am
TL;DR: 81% of organisations knowingly shipped vulnerable code and 98% experienced a breach tied to vulnerable code in the last year, according to Checkmarx, as AI-assisted development overwhelms manual triage and remediation. The governance shift is to move security decisions into pull requests, where evidence, accountability, and reviewable AI-assisted fixes can scale with delivery.
NHIMG editorial — based on content published by Checkmarx: manual appsec triage and governed AI remediation in pull requests
By the numbers:
- Checkmarx research found that 81% of organizations knowingly shipped vulnerable code, and 98% experienced a breach tied to vulnerable code within the last year.
Questions worth separating out
Q: How should security teams reduce application onboarding backlog without weakening governance?
A: Start by ranking applications by business criticality, data sensitivity, and access risk, then automate discovery and connector setup for the highest-value targets first.
Q: Why do AI-assisted development pipelines make vulnerability governance harder?
A: They increase code volume, dependency churn, and decision speed at the same time.
Q: What breaks when security decisions are made outside the pull request?
A: The main failure is loss of context and evidence.
Practitioner guidance
- Standardise pull request risk decisions Define one decision policy for false positive, acceptable risk, and action required so identical findings are handled the same way across teams.
- Move remediation evidence into the merge workflow Require approvals, discussion history, and exception notes to remain attached to the pull request rather than dispersed across tickets.
- Constrain AI-assisted fixes to reviewed diffs Allow AI to draft remediation pull requests or diffs, but block automatic merge.
What's in the full article
Checkmarx's full article covers the operational detail this post intentionally leaves for the source:
- The triage and remediation assist workflow inside pull requests, including how review and approval remain governed.
- The decision model for classifying findings into false positive, acceptable risk, or action required.
- The role of attackability, reachability, and exploitability context in prioritising vulnerabilities.
- How AI-generated remediation diffs fit into existing developer review processes without automatic merge.
👉 Read Checkmarx's analysis of pull request governance for scalable appsec execution →
Pull request governance for appsec: what changes for teams?
Explore further
02/08/2026 12:58 pm
Pull request governance is becoming the new security control point for software delivery. When code changes outpace manual review, organisations do not just accumulate findings. They lose the ability to prove that risk decisions were made consistently. The pull request creates a governed record of approval, rationale, and ownership, which is exactly what auditors and regulators expect when change velocity rises. Practitioners should treat pull request governance as a security and compliance control, not a developer convenience.
A question worth separating out:
Q: Who is accountable when AI-driven remediation or suppression is wrong?
A: Accountability should sit with the owning security and platform teams, not with the model itself. If AI changes prioritisation, the organisation still needs a human owner for policy, review thresholds, and override authority. That is especially true when AI decisions affect vulnerable code, workload exposure, or service account scope.
👉 Read our full editorial: Manual appsec triage is becoming a governance liability
