ADLC metrics: How to measure agentic development security | Endor Labs
ADLC metrics is an Endor Labs guide to measuring security in the agentic development lifecycle, where AI coding agents write code. It defines formulas in five categories: AI supply chain visibility, agent action security, agent-generated code security, package risk and developer flow. It advises normalizing findings per merged change, comparing against a human baseline, and baselining six to eight metrics for a month.
What it claims
Endor Labs argues that standard AppSec dashboard numbers stop carrying signal once coding agents (Claude Code, Codex, Cursor, GitHub Copilot) generate most changes. "PRs scanned" reaches 100% trivially, total findings grow with code volume, and scan pass rate stays high while a few risky changes get through. Post-commit scanners also miss what agents do before review: install scripts that run during npm install, reads of .env files, destructive shell commands. The guide replaces these numbers with ratio metrics. Its premise rests on Google Cloud's DORA 2024 report, which associated AI adoption with lower software delivery stability.
How it works
Each metric is a ratio with a stated data source. The normalization unit is either per merged change (suited to policy and process metrics) or per 1,000 changed lines (suited to changes of varying size). Pick one unit per metric and keep it fixed.
AI supply chain visibility has three measures:
- Approved ÷ discovered components, computed separately for agents, models, MCP servers and skills. For example, 0.6 for MCP servers means 40% are unreviewed.
- Median days from first appearance in telemetry to recorded review.
- Share of MCP servers and skills with a recorded permission review.
Agent action security centers on risky actions stopped before execution ÷ (stopped before + detected after). "Risky" covers four categories: destructive commands, sensitive file reads, credential access, and installs from unapproved sources. The guide requires recording whether a deterministic policy blocked the action or the model refused. Only policy blocks count as an auditable control. Supporting measures:
- Policy coverage across agents.
- Blocks per 100 sessions, by category.
- Prompt-injection success rate on a fixed test suite.
- Regression rate after a model, prompt or policy change.
Agent-generated code uses diff-based analysis so that pre-existing debt is not attributed to the agent. The core metric is confirmed introduced findings ÷ merged agent-authored changes, compared with the human rate on repositories of similar language, framework and risk tier. Agent authorship is tagged with commit trailers, PR labels or telemetry. Mixed edits need a fixed rule, such as majority of changed lines. The headline number is the share of findings with reachability or exploitability evidence (a call path or a taint flow), reported next to the false positive rate. Secrets are counted as confirmed live secrets, split by author type, plus the share caught at pre-commit.
Packages are measured three ways:
- Risky or nonexistent installs blocked before execution, as a share of attempts.
- Reachable vulnerable dependencies ÷ total vulnerable dependencies.
- Unapproved new dependencies ÷ merged changes that add dependencies.
Flow counter-metrics pair with each security metric:
- Blocked PR rate.
- Fix acceptance rate (remediations merged without major rework).
- Median time to fix, reported separately for each severity tier.
How to use it
Start with six to eight metrics spread across the five categories, baseline them for a month, then set targets per repository risk tier. Review cadence:
- Weekly: operational metrics (pre-execution stops, packages blocked, blocked PR rate, findings per change).
- Monthly: structural metrics (policy coverage, evidence-adjusted share, time to fix).
- Quarterly: trends reported to leadership.
Re-baseline whenever a new agent or model is onboarded. Treat AI-written code share as a segmentation variable, not a headline metric. Two external frameworks help with reporting: map action categories to the OWASP Top 10 for LLM Applications, and map scorecard rows to NIST SP 800-218A for regulated reporting.
Evidence
The guide contains no measured study of its own. The scorecard figures are labeled hypothetical. Package hallucination risk is attributed to Spracklen et al. (USENIX Security 2025), who found that models repeat invented package names across runs, which gives attackers predictable names to register. Endor Labs cites 83% fewer blocked PRs and up to 95% false positive reduction for AURI's AI SAST. The page itself labels these as vendor-reported figures, not benchmarks.
Limits
The page is vendor content that ends by recommending AURI and Coding Agent Governance as the data source. Each formula depends on telemetry that most teams lack: agent hooks, endpoint session data, and authorship tagging. The guide gives no thresholds and calls every target illustrative. It also flags failure modes:
- Pattern-based rules miss IDOR and authorization flaws, so a low finding count can mean blind tooling.
- Teams can raise the evidence-adjusted share by suppressing findings, so suppression rate should be tracked too.
- A low incident count means little without matching test volume and telemetry coverage.
Organisations named here
- Endor Labs
- IBM
- Google Cloud
- OWASP GenAI Security Project
- NIST
- USENIX Security
- OWASP
- AURI
- Claude Code
- Cursor
- GitHub Copilot
- Model Context Protocol
Technologies named here
- AURI by Endor Labs
- Coding Agent Governance
- Claude Code
- Codex
- Cursor
- GitHub Copilot
- MCP servers
- OWASP Top 10 for LLM Applications
- NIST SP 800-218A
- Model Context Protocol
- npm
- SCA
- Agent Security League
Techniques named here
- Metric normalization
- Discovered vs approved ratio
- Pre-execution vs after-the-fact split
- Diff-based analysis for introduced findings
- Reachability analysis
- Prompt-injection test success rate
- Regression rate after changes
Related in coding-agents
