Glev Method part 2 : 7 steps to secure the code at the speed of AI
As AI starts writing the majority of code, the volume of potential vulnerabilities is about to multiply. Here is a 7-step method to move from mass detection to targeted remediation — and stay in control of your real risk.
In Part 1 of this white paper, we laid out a blunt diagnosis: when it comes to application security (AppSec), most software organizations are stuck in an operational dead end. Stacking siloed scanners produces an unmanageable volume of alerts, severity scores disconnected from real risk, and a cultural rift between security and engineering.
Part 2 is the answer to that diagnosis — a clear, repeatable methodology to break out of the paralysis. It gives security and engineering leaders the keys to regain visibility into the real risk in their code, eliminate the security debt buried in their existing applications, and prepare their organization for a new paradigm: code written massively with (by?) AI.
From mass detection to targeted remediation
Traditional vulnerability management treats every finding as urgent and pushes the entire backlog onto developers. The result is predictable: alert fatigue, ignored tickets, and genuine flaws lost in the noise.
The Glev Method inverts that logic. Its common thread is the elimination of noise: at each step, the system removes whatever does not deserve a human's attention — redundant alerts, misleading scores, false positives, duplicate tickets — until only the signal remains: the vulnerabilities that are actually exploitable, on the code that actually matters.
The payoff goes far beyond a shrinking backlog. It is, first, the reconciliation of security and engineering — two teams that used to pass risk back and forth now speaking a shared language of proven exploitability and shared priority. And it is the transformation of a paralyzing security debt into a process that is targeted, collaborative, automated, and genuinely scalable.
The Glev Method in 7 steps
1. Unify detection and group alerts by attack vector
Consolidate every source of security findings — automated scanners (SAST, SCA, IaC SAST, secret leakage) and human detection (pentests, Bug Bounty) — into a single point of view. Then group alerts that share the same attack vector: the path an attacker actually travels from entry point to sensitive sink. You analyze that shared path once, and the conclusion holds for every associated alert.
2. SAST or AI SAST? Both
A new generation of LLM-based "reasoning scanners" can read code contextually and catch business-logic flaws that pattern-matching SAST misses. But they are non-deterministic, token-hungry, slow, and create a conflict of interest when the AI reviews code it wrote itself. The method recommends a sequential hybrid approach: clean up traditional-SAST findings first, then run AI SAST on what remains — so you never burn tokens needlessly.
3. Drop prioritization by technical score
A CVSS score in isolation says nothing about real exposure. The method re-weights each finding with business context — deployment status, exposure (internal / authenticated / public), and application criticality — using an internal prioritization formula. A "Critical" flaw on an undeployed internal tool behind authentication is not an emergency; a publicly exposed "Medium" might be. This is how you escape the simplistic "we only fix Highs and Criticals" trap.
4. Filter out false positives
False positives can represent up to 90% of a scanner's findings, because a scanner reads code but does not understand it. Before anything reaches a developer, the method analyzes the exploitability of each alert — is there an unbroken path from a user-controlled source to a vulnerable sink, and is it protected? Findings are then sorted into three buckets: actually exploitable (fix now), potentially exploitable (monitor), and non-exploitable (mute).
5. Bring developers into remediation
Developers fix flaws under two conditions: the flaw is proven exploitable, and the task is frictionless. The method plays on four levers — provide proof of exploitability, group findings into coherent tasks, make the fix easy with standardized (and AI-assistant-ready) remediation guidance, and fit everything into the team's existing workflow rather than pulling developers out of their environment.
6. Capitalize on remediation
Classic vulnerability management stops at detect, triage, fix. The Glev Method adds a fourth step: capitalize. Every fix, every justified false positive, every context adjustment is captured and memorized, then reused to refine future detection, enrich business-context mapping, and automate the next similar fix. Each remediation becomes a reusable asset — and the organization gets measurably better over time.
7. Adapt security processes to team maturity
Imposing one uniform policy across an entire group is doomed. The method advocates adaptive security, tuned along two axes: compliance and criticality objectives (SLAs proportional to project importance), and the maturity of each product team — shifting security progressively "left," from post-production scanning toward true Security by Design.
Why this matters now
The stakes have never been higher. In the age of AI coding, the volume of code produced — and therefore of potential vulnerabilities — is about to explode. Organizations that keep stacking alerts will be overwhelmed. Those that put remediation at the heart of their AppSec will have the means to keep pace. The Glev Method is built precisely for this shift: regain control of your existing debt today, and stay master of the risk tomorrow, when machines write most of the code.
Read the full white paper
Part 2 details each step with concrete examples — the prioritization formula, blocked attack paths, the four remediation levers — and explains how the Glev platform automates the entire method through an AppSec Knowledge Base and a set of specialized AI agents.
