Software quietly runs the systems we rely on—our banks, logistics, communication, and cars. But for many AppSec teams, that software is a tangle of disconnected alerts and late-breaking vulnerabilities.
The shift-left movement wasn’t supposed to add noise—it was supposed to make security part of how we build. Now, with liability rising and complexity accelerating, that promise needs to become practice.
Hello Cyber Builders 🖖
When we first started working on what became Glev.ai, we weren’t chasing hype. We were chasing a problem—one that every AppSec team we talked to was quietly struggling with.
Application Security is not lagging due to a lack of tools. It is broken because the work is buried, disconnected, and constantly arriving too late.
This post marks the beginning of a series where I’ll share what we've learned, what we've built, and why it matters now more than ever.
If you would like to learn more, please do not hesitate to contact me. Let’s start with the “why.”
Initial posts
Why “Shift-Left” Matters and Will Matter
Software isn’t just running your app. It’s running the world—your car, your bank, your hospital, your elections. Every industry is now a software industry, whether it admits it or not.
I recently spoke with an executive from a large advertising company. My bias (which I am ashamed of) was that if you're doing ads, you should have tons of creative artists, creative directors, and be engaging in brainstorming sessions, doing fancy things. Imagine a Hollywood movie depicting these creatives... But the executive made it clear: they have 20,000 software developers. Because in ads, everything is now software-driven, with data analytics, machine learning, and AI powering the ad businesses.
How many so-called “software companies” have 20,000 software developers?
Sadly, every business carries the same hidden risk: insecure code baked into its foundation. The scary part? Most of it was never built with security in mind.
I don’t like fear-mongering, but CEOs must understand that if they continue to treat security as an afterthought, they're not just behind; they’re part of the following breach headline waiting to happen.
They’ll have:
Company Confidential Data Leak
Website, Ecommerce Site, Mobile App - Unavailable for hours
Personal Identifiable Information (PII) Leak
All these impacts are creating massive liability against regulators, customers, and shareholders.
And it is getting worse, as known vulnerabilities are growing faster than any team’s ability to patch them.
That chart above is reality. Nearly 40,000 CVEs were reported in 2024 alone. That's a 6x increase since 2015. 2025 is expected to have around 50,000 vulnerabilities (+25% from 2024).
In short, it’s time to act.
Regulatory and Liability Wake-Up Calls
The situation and its urgency have been known for years now. And, as often is the case in cybersecurity, when new threats and issues emerge, we typically start with regulations (at least in Europe), hacker conference talks, and public sector initiatives.
The EU Cyber Resilience Act now requires proof that your software is designed to be secure. I covered it two years ago (already!)
In the U.S., things are just as serious. Here’s what Jen Easterly (former CISA Director) said at Black Hat 2024:
“We are entering a software liability regime.”
Jen Easterly (Former US Gov CISA Director)
CISA has launched a Security Pledge, where companies pledge support for significant actions and are encouraged to report annually on their progress. See it here.
We Asked. AppSec Teams Spoke. Here’s What They Told Us.
We don’t need yet another tool - Appsec Teams
And they are 100% right. AppSec teams do not need yet another tool.
When we launch a new company at CyGO Entrepreneurs, we always start in the field, with practitioners who act and perform security work daily. We asked for a bit of their time and we listen, often ask, never pitch.
To build Glev, we had 80+ conversations, and we heard 5 major pieces of feedback
🧩 Too Many Issues, Too Little Clarity
"I’m drowning in issues lists."
AppSec leads are stuck playing air traffic control. They have a backlog of thousands of vulnerabilities in Jira and scanner results in dashboards. Some penetration test (pentest) PDFs, required by some customers as “annual checks,” are lost in email. Bounty reports are somewhere in a SaaS platform.
As a result, they miss real issues because nothing is centralized, deduplicated, or prioritized.
I need one source of truth that actually lets me act.
Appsec engineer at an e-commerce website
They don’t need another feed or tool.
🔍 Buried in Alerts, Starved for Context
"We waste hours triaging junk."
If you run a SAST, SCA, Secret Leakage, or DAST tool, you end up with many alerts, most of which are classified as “Critical” or “Very High”.
However, context matters: is it exploitable in our setup, given our data paths?
Imagine you end up with an alert on a SQL injection. You often do not know whether the parameter is linked to a user input, nor do you know if the previous call involved sanitization functions from the development team. Without that context, AppSec engineers become help desk agents, wasting time on false positives and continually seeking more information.
During our interviews, we spoke with an AppSec team working with 200 software engineers who had almost completely given up.
They said: “We are sending only critical issues to developers, and we put a reminder after 3 weeks to see if they fixed it; the best engineering teams ask questions and fix problems, the worst ones see their backlog keep growing.”
What you need is context-triage that understands your environment, not a checklist from a compliance report or out of a scanner.
🛠️ Detection Is Easy. Remediation? Not So Much.
"We find problems faster than we fix them."
Issue discovery is the easy part.
Detection and visibility used to be an issue when code security was not as mature as network or endpoint security. However, over the past 10 years, we’ve seen significant improvement, and we can now count hundreds of available solutions. Moreover, open source scanners are maturing, and large vendors are open sourcing mature tools (for example, Google OSV)
Remediation? That’s where AppSec bottlenecks are now. Developers are slammed. Fixes are unclear. Tickets sit untouched because no one has time to dig in.
AppSec teams need remediation workflows that scale—that simplify the obvious and make remediation tasks meaningful.
📚 Outnumbered 30 to 1—and Expected to Scale
"We can't be everywhere at once."
Based on our interviews, AppSec teams are outnumbered by engineering teams 30 to 1. They support every squad, every repo, every release—but they are still the one security team.
AppSec teams often find themselves repeatedly answering the same questions, re-explaining best practices, and onboarding developers who lack even the most basic knowledge.
This situation is not due to laziness; rather, it reflects being overwhelmed and overworked.
AppSec teams need to capitalize on the team’s collective knowledge, building an AppSec practice and culture across the organisation.
🔁 Security Shows Up Late. Always.
"Security always gets bolted on last."
AppSec teams often attempt to get involved early in the development process. Still, the security team frequently arrives late, coming in only after the design review, after the code freeze (really?), or even after a security breach has occurred.
Each time this happens, it triggers a frantic fire drill. The teams scramble to respond, while developers tend to push back against additional security measures. As a result, security risks are sometimes accepted simply because there is 'no time' left to address them.
What the AppSec teams truly aspire to is a workflow where security is integrated seamlessly into the development lifecycle, becoming a natural and proactive part of the process rather than an obstacle inserted after the fact.
They are not demanding impossible solutions; their goal is for security to be recognized and treated as the essential engineering discipline that it is—integral, proactive, and collaborative from the very beginning.
👇 What’s Next
These five problems aren’t theoretical—they’re daily reality for AppSec teams everywhere. If you’ve felt even one of them, you’re not alone.
That’s why we built Glev.ai. Not as another tool, but as a new way of thinking about software security—one rooted in empathy, real-world context, and finally giving AppSec teams the leverage they deserve.
In the next post, I’ll explain why AI alone won’t fix AppSec—and what mindset shift makes a difference.
Until then, I’d love to hear from you:
👉 Which of these five challenges hits closest to home?
👉 What’s your team tried—and what’s worked?
Hit reply, drop a comment, or share this with your AppSec crew. Let’s build security that scales—and that sticks.
Laurent 💚