From Web Dev to AppSec: My Journey into the Security Maze
Like many in this space, I didn’t start out in security. My intro to AppSec came during my years as a web developer, building government websites where security was paramount — but specialized tooling? Not so much. We weren’t ignoring security; we just assumed the basics would catch what mattered. Spoiler: they didn’t.
Our teams initially relied on things like npm audit, which was a bit like checking your house for structural issues using a flashlight and a healthy dose of optimism. When I became a tech lead, suddenly responsible for security deliverables, I was able to dedicate time to “solving” that problem. After a few too many late nights trying to manually connect & represent CVEs to actual project risk, I pulled in a dev-focused security scanner. At the time, it felt like a breakthrough. Not only could I report on the vulnerabilities, but I felt I could accurately represent risk in those environments.
Eventually, I joined one of the fastest-growing companies that built this kind of dev-first, shift left tooling. I spent a few years there — first as a Solutions Engineer (SE), then leading SE teams who supported customers across all shapes and sizes, from tiny startups to global enterprises. We had a front-row seat to how real AppSec programs were run, how tools were actually used (or ignored), and all of the highs and lows along the way.
My admiration for the shift-left model — “Let’s help developers fix early!” — slowly faded as I began to understand that something fundamental was missing. Tools were introducing new functionality, sure, but the assumptions behind them hadn’t changed. The more I listened to customers, the more I realized: modern applications had moved on, but the foundational technology and approach to security wasn’t keeping up.
The Shift-Left Conundrum: When Early Detection Isn't Enough
AppSec teams were underwater, and if we were going to get developers involved, we needed the right tools for the job –tools that would allow them to keep their momentum and limit context switching. Shifting left was the answer, and it seemed like a slam dunk. IDE plugins and SCM integrations provided information earlier in the SDLC, which, in theory, was going to allow for earlier remediation and less wasted time later on. While the intention and concepts were commendable, I watched as the real-life execution frequently fell short.
Here’s why:
- Results lacked the necessary context to properly prioritize during the development process. Developers would ask questions like:
- Was this going to wind up in prod?
- Was it something I introduced?
- Are we even using the vulnerable part of the library? These questions couldn’t be answered in an IDE.
- IDE scanners dumped all vulnerability results out for devs to sift through rather than only highlighting issues they had introduced.
- Checks run on newly opened pull/merge requests lacked proper workflows to deal with alerts then and there, often resulting in “merge it anyway” being the instruction given.
A form of “alert fatigue” quickly set in. Workflows necessary to deal with large volumes of vulnerabilities found at each integration weren’t there, and that gap led to the creation of a “just mute it” culture among the developers using the tools. Integration points meant to streamline security posture improvements became friction points and bottlenecks, where developers were tasked with solving a problem introduced by the tooling.
In an attempt to remedy the situation, AppSec vendors began work to link runtime insight to the scan results developers would receive. Connectors, agents, tagging (manual and automatic), and various other pieces were required, and getting them up and running demanded a significant level of effort from multiple teams in an organization. It was cumbersome, and the reward fell far short of the effort. An important side note to include; it was entirely contradictory to the story being told around “developer-first tooling”. Over time, trust in these developer-first tools eroded. They were bought to displace other AppSec tooling that wound up as shelfware, but they eventually took their own place on the shelf.
The Prioritization Puzzle: Why AppSec (And now Developers) Still Can’t Catch a Break
In reality, the shift-left philosophy and tools designed to help AppSec teams only served to “shift” responsibility for making sense of all the noise. Work wasn’t removed or streamlined, and since devs had other priorities, it went back to AppSec anyway.
AppSec engineers are still sifting through massive lists of issues, attempting to make sense of scan results, effectively fighting a never-ending battle since they lack the context necessary to properly prioritize risk. Was the vulnerable code even deployed? Was it running? Reachable? Exploitable? You’d be lucky to get one of those answers, let alone all four.
Risk scores, reachability flags, “fix now” filters, and countless other uncontextualized data points were created in order to remedy the situation — but they were all just educated guesswork dressed up with a slick UI and pushed by marketing teams. AppSec teams still had to sift, triage, and create tickets, while hoping devs would take them seriously.
The end result? Time wasted, trust eroded, and risk… still prevalent. Prioritization stayed broken because the tools hadn’t been built to see the full picture.
RASP: The Runtime Savior That Wasn't
Runtime Application Self-Protection (RASP) emerged as a solution to provide context by monitoring applications during execution. However, RASP solutions often introduced latency, required significant integration efforts, and were difficult (or in some cases downright impossible) to maintain in production environments.
Many organizations experimented with RASP but abandoned it due to its complexity and performance overhead. There was a desire and demand for the context a tool like RASP could provide. Several other tools emerged attempting to connect to the running application and provide more context for findings. The runtime vision was valid, but the execution wasn't there.
A Different Kind of Visibility: What Changed When We Looked at Runtime Differently
What really stood out wasn’t just the insights Oligo offered — it was how they got them. No source code access. No intrusive instrumentation or code modification. Just a lightweight eBPF sensor, a powerful piece of Linux kernel tech that’s been around for a while. And while eBPF itself isn’t a secret, using it well — especially to map open source components back to real runtime behavior — is no small feat.
Oligo figured that out. They found a way to connect the open source packages used by your application with what’s actually happening at the kernel level during execution. It’s not about observing code — it’s about observing behavior. And that shift in perspective changes everything.
What Oligo offers isn’t just an improvement — it’s a reset. It shifts security from speculation to reality, from a backlog of possible threats to a clear view of what’s running and what’s actually a risk. Known or unknown, disclosed or not, you finally have visibility where it matters.
Real-World Impact: Building Trust Through Results
I’ve been fortunate enough to see the results first hand. AppSec teams at organizations adopting Oligo are reclaiming significant portions of time. The hours spent combing through endless scan results, attempting to make sense of what’s important? Mostly gone. And it’s not just their time, but developer time, too. Time spent on integrations, implementation, training, and then, finally, prioritization, is reduced by an order of magnitude, leaving everyone to focus more on their actual jobs.
It’s refreshing to see how quickly that value shows up. Teams see meaningful results within hours, not several quarters down the road. There’s no massive hidden cost, workflow disruption, and no more arguing about whether a vulnerability is actually making its way to prod. Instead, there’s a real return on investment as teams that have been stuck in the AppSec triage loop for too long find relief through Oligo’s approach.
Embracing the Future of AppSec
Traditional AppSec tools were groundbreaking in their time, but the landscape has evolved. Modern applications require security solutions that provide direction, not uncontextualized lists. Oligo represents the next step in this evolution, offering solutions that provide the necessary context to prioritize and address real threats effectively, as well as protect our applications against the unknown.
For organizations seeking to enhance their security posture without overwhelming their teams, embracing runtime-focused solutions like Oligo is not just beneficial—it's essential.
