The scan passed. The review approved it. The code merged on Tuesday. On Thursday a dependency three levels down published a new version, and on Friday an agent opened four more pull requests against the same service. Nothing rescanned any of it.
What is application security monitoring?
Application security monitoring is the practice of watching an application's security posture over time instead of checking it once before release. It covers the code, the dependencies underneath it, and the pipeline that assembles them. It answers a question a point-in-time scan cannot: what is exploitable right now.
Which problem are you solving?
"AI application security" gets used two ways, and teams talk past each other because of it. If your app calls a model, you are securing an application that uses AI, which means watching prompts, outputs, and agent behavior. If a coding assistant writes your app, you are securing the code AI produces.
Most teams now do both, and the two halves need different controls. This article covers the second, and the part of the agentic development lifecycle that starts after the code merges.
What changes when agents commit code
Traditional application security management assumes a rhythm. A developer writes, a scanner runs, a reviewer triages, a fix ships. That rhythm has a pause in it, and the pause is where the scan happens.
Agents remove the pause. A codebase that changed twice a week changes twice a day. Every change moves the answer to the exploitability question, and the volume arrives faster than any review queue absorbs it.
Two things follow:
- The interval between scans starts to matter more than the depth of any single scan.
- The findings pile up faster than anyone triages them, which turns a monitoring problem into a prioritization problem.
What to monitor in an AI-assisted codebase
Dependency drift and new transitive risk
Agents select dependencies. They add packages to satisfy an immediate requirement, and each package brings its own dependencies that nobody chose. Your dependency tree grows in directions no architect approved.
Watch for three things:
- New direct dependencies an agent introduced,
- New transitive packages that arrived with them,
- Version changes in packages you already had.
Reachability changes after agent commits
A vulnerability in a dependency matters when your application can reach the vulnerable function. That call path is not static. An agent that refactors a service can make an unreachable vulnerability reachable without touching the dependency at all.
This is the argument for continuous reachability rather than a one-time assessment. The finding did not change. Your code did.
Secret exposure over time
Credentials leak through more paths in an agent workflow than a human one. An agent writes them into generated code, copies them out of a config file, carries them into a context window, or surfaces them in a trace. Repository scanning catches one of those four. The rest require looking outside the repository.
Point-in-time scanning versus continuous monitoring
A point-in-time scan is a photograph of a codebase that no longer exists. It tells you what your application looked like when the scan ran.
Continuous monitoring answers a different question, and the difference shows up in three places:
- Someone discloses a new vulnerability against code you already shipped. A scan cannot find what nobody had published yet.
- Reachability changed because your code changed. Same dependency, different exposure.
- Coverage gaps. A scan reports what it analyzed. Monitoring should report what it could not.
That last one deserves more attention than it gets. A mature program knows what it did not scan: unsupported languages, build environments that failed to resolve, repositories nobody connected. Teams that treat coverage as a number to maximize hide their gaps. Teams that treat it as a report surface them.
Why monitoring alone is not enough
Monitoring tells you what exists. It does not tell you what matters. That gap is where application security programs drown.
Three terms are worth separating. A finding is anything a scanner flags. A vulnerability is a real weakness in the code. An exploitable weakness is one an attacker can reach and use. Most programs measure the first and act as though they measured the third.
Severity scores describe potential harm, not risk to your application. CVSS (Common Vulnerability Scoring System) rates how bad a flaw could be in theory. It says nothing about whether your application calls the vulnerable code.
Reachability analysis asks whether a call path exists from your code to the vulnerable function. When nothing in your application can reach it, an attacker cannot exploit it, and its priority drops. Endor Labs uses function-level reachability to cut noise by up to 92%, which leaves teams working the share that represents real risk.
How to set up monitoring developers do not route around
Three rules:
- Report where the work happens. A finding in a dashboard nobody opens is not a control. A comment on the pull request that created the problem is.
- Send evidence, not alerts. Every finding should explain why it matters, show the call path, and point at a fix. Findings without evidence become triage work, and triage work gets skipped.
- Rank by exploitability. A queue sorted by severity buries the one reachable finding under twenty theoretical ones. A queue sorted by reachability puts a developer on the thing that matters first.
Runtime signals close the loop. Which reachable paths get exercised in production tells you which code-time findings deserve attention first. That connection turns monitoring into a ranking input rather than an alarm.
Frequently Asked Questions About Application Security Monitoring
What is the difference between application security monitoring and ASPM?
Application security posture management aggregates findings across tools and reports on program health. Application security monitoring watches an application and its codebase for changes in exposure. ASPM answers how the program is doing. Monitoring answers what is exploitable now.
How often should you scan a codebase agents commit to every day?
Scan on every pull request, and re-evaluate reachability whenever the dependency tree changes or someone discloses a new vulnerability against code you shipped. A weekly full scan is a reporting artifact, not a control.
Does monitoring replace pre-merge scanning?
No. Pre-merge scanning stops flaws from entering. Monitoring catches what changes after they enter. Programs need both, and the second is where most teams are thin.
Application security monitoring has to match the speed of agentic development. Watch the dependency tree. Watch reachability. Watch the paths credentials take out of the repository. Then rank what you find by what an attacker can reach, because volume without prioritization is the same as no monitoring at all.
See how Endor Labs ranks findings by what an attacker can reach, or book a demo.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help:
