AppSec remediation and endpoint remediation are not the same problem.
That distinction matters more now because much of the conversation about AI remediation has centered on code.
Understand the dependency chain. Determine whether a vulnerable component is reachable. Identify whether the exploitable condition exists. Propose a workaround. Open a PR. Refactor the code.
That is valuable work. It is not endpoint remediation.
What AppSec Remediation Does — and Where It Stops
AppSec remediation is fundamentally a pre-deployment problem. A scanner identifies a vulnerability in source code or a dependency, and the remediation action is a code change — a pull request, a dependency bump, a refactor — that addresses the issue before it ships to production. AI has made this workflow significantly faster: tools can now traverse reachability graphs, suggest fixes, and open PRs autonomously.
The constraint is structural. AppSec remediation only addresses software your team wrote or manages the dependencies for. It operates before deployment. By design, it doesn't touch what's already running in your environment — the live production systems, the configured endpoints, the third-party software your development team didn't write, the OS-level settings that have drifted from baseline, the services that have been enabled or forgotten.
Code gets compiled, packaged, and deployed onto IT systems. Those systems then accumulate vulnerable software, misconfigurations, legacy components, and hardening gaps — and all of it still has to be addressed, regardless of how mature your AppSec program is.
The Endpoint Problem
Endpoint remediation means changing the state of systems already running across an enterprise.
Sometimes that means installing a vendor patch. Other times it means upgrading or uninstalling software, changing a configuration, applying a hardening control, or mitigating risk when no immediate fix exists. Then you have to verify that the change worked, confirm the exposure actually closed, and roll back safely if it didn't.
The attack surface that requires this kind of action includes:
Third-party software with known CVEs — browsers, PDF readers, remote access tools, compression utilities — software your team didn't write and can't fix with a pull request
Misconfigurations — SMBv1 enabled, insecure defaults that shipped with applications and were never changed, weak permissions on sensitive paths
Hardening gaps — deviations from CIS benchmarks or DISA STIGs that require active configuration changes, not software updates
End-of-life systems — software where the vendor stopped shipping patches; the exposure is real but there's no fix to apply, only compensating controls to put in place
Non-standard and legacy software — custom builds, in-house tooling, anything outside the standard package manager ecosystem that AppSec scanners don't model
None of this is addressable at the code layer. The PR workflow doesn't reach it. These are endpoint problems, and they require endpoint solutions.
Context Is Not Remediation
Doing endpoint remediation autonomously absolutely requires context.
You need to understand the endpoint — its software and configuration, dependencies, ownership, prior state, maintenance windows, approval requirements, and the boundaries within which the system is allowed to act. Building and maintaining that understanding is a prerequisite for safe autonomous remediation.
But it isn't the remediation itself.
Knowing that an endpoint is vulnerable is not fixing it. Understanding why it's vulnerable is not fixing it. Knowing how its components relate is not fixing it. Determining that it's exploitable is not fixing it.
Eventually, something has to change on the system.
That's the execution problem. And the security industry has historically invested much more heavily in understanding, detecting, and prioritizing risk than in increasing capacity to actually eliminate it. The Verizon 2024 DBIR puts average remediation time at 55 days for 50% of critical vulnerabilities — with a patch available and a team actively trying to apply it. For vulnerabilities that require endpoint-level action rather than a software update, the timeline is effectively indefinite for most organizations.
As one security engineer described it after running a hands-on proof of value: "We know the problems exist. What we lack is a reliable bridge from identification to execution."
Two Layers. Both Matter. Neither Replaces the Other.
AppSec and endpoint remediation are parts of the same larger problem. AI has enormous potential across the entire stack. Shifting security left — finding and fixing vulnerabilities before they reach production — is a sound strategy and worth continued investment.
But shift left was never designed to be the whole answer. Vulnerabilities reach production anyway. Third-party software accumulates CVEs regardless of how clean your codebase is. Configuration drift happens continuously. End-of-life systems stay in production longer than anyone plans for.
No single company will solve every layer of this problem. At Furl, we chose to go deep on endpoints — because knowing exactly what's wrong is necessary, and actually fixing it is a different problem entirely. An execution layer that investigates findings, generates environment-specific fixes, deploys them, validates they landed, and rolls back when they don't.
When you hear "AI remediation," it's worth asking which layer the vendor is operating on. If the answer is source code and pull requests, that's AppSec. Real and valuable — and not what closes the endpoint gap.