The security industry produces an abundance of metrics. Mean time to remediate. Mean time to detect. Number of critical findings. Percentage of repositories scanned. Compliance score. Risk score. Each of these has a use, and most of them are produced by every SCA and ASPM tool on the market. The problem is that none of them are designed for the developer.
If you put a developer in front of a typical security dashboard and ask them what they should do differently tomorrow, they will not have an answer. The metrics are too aggregated, too abstract, or measured against goals the developer does not own. The dashboard speaks to the security team's audit responsibilities, not to the developer's daily work.
This post is about a different class of metrics — the ones that change developer behavior. They are personal, actionable, and built for the workflow of someone who ships code. We will look at where to find them, how to display them, and how Safeguard exposes them in the surfaces developers actually look at.
What makes a metric developer-relevant
Three properties separate developer-relevant metrics from security-team-relevant metrics.
The first is personal scope. The metric should be about something the developer can affect through their own work. A team-level vulnerability count is not personal — the developer can fix some of it, but most of it is owned by other people. A "vulnerabilities you introduced this quarter" count is personal. The developer either introduced them or they did not.
The second is immediate actionability. The metric should be tied to something the developer can do today. "You have 12 outdated dependencies in your project" is actionable. "Your team's overall risk score is 6.4" is not — there is no clear action that moves the score, and the developer cannot tell whether they are responsible for it.
The third is trend visibility. The metric should be visible over time, in a way that lets the developer see the impact of their choices. A snapshot of "you have three findings" is less useful than a chart showing the developer's findings over the last twelve weeks. The trend is what makes the metric feel like a feedback loop instead of a report card.
Five metrics worth tracking
Across organizations running shift-left programs at scale, five metrics consistently show up as the ones developers engage with.
Findings introduced per PR. This metric counts how many new findings the developer's PR added to the project, broken down by severity. It is personal (only the developer's PRs count), immediate (it appears in the PR comment), and trend-visible (the project history shows it over time). When developers see this metric, they start checking dependencies more carefully before adding them.
Time-from-finding-to-fix in the developer's repos. This is the median time it takes for a finding in the developer's primary projects to go from detection to closure. It rewards fast response and exposes neglect. Developers who own a project with a long fix time start prioritizing remediation differently.
Dependencies pinned versus floating. This metric counts the percentage of dependencies in the developer's projects that are pinned to a specific version versus those that float on a range. Floating dependencies are a known source of supply chain risk because they can resolve to a newly compromised version. Developers who see this metric on their dashboard tend to convert floats to pins over time.
Waivers expiring soon. This metric counts the number of active waivers in the developer's projects that will expire within the next 30 days. A waiver that expires without action becomes a blocking finding, so this metric drives proactive cleanup. Developers see it as a to-do list, not a scolding.
Coverage gaps. This metric flags repositories the developer owns that are missing supply chain controls — no SBOM, no PR gate, or no policy bundle. It is not punitive. It is a checklist of "places where the safety net is incomplete." Developers who see this metric tend to fix the gaps without being asked.
Each of these metrics has the three properties: personal scope, immediate actionability, trend visibility. None of them require the developer to interpret a risk score or decode a CVSS calculation. All of them point at concrete next steps.
Where the metrics belong
A dashboard the developer has to log into is a dashboard they will rarely visit. Developer-relevant metrics need to live in the surfaces developers already look at.
The PR comment. Safeguard's PR comment template includes a small "your delta" section that shows findings introduced by the PR, alongside the project's overall posture. The comment is the most-read security artifact in most engineering organizations, and including the metric there is the highest-leverage placement.
The CLI. The safeguard scan command, when run on the developer's local project, prints a one-line summary at the bottom of its output. Something like "12 findings, 3 introduced this week, oldest 4 days." Developers who run the CLI regularly see the trend without going anywhere.
The IDE. The Safeguard editor plugin includes a status bar item showing the current project's health at a glance. A small badge with a number and a color. The developer does not need to interpret it deeply, but they notice when it changes. That ambient awareness is what shapes long-term behavior.
The personal email or Slack digest. A short weekly summary, one paragraph, sent only to the developer. "This week: you introduced 1 finding, fixed 3, and have 2 waivers expiring next week." Developers who would never log into a dashboard read the digest.
The discipline is to use the surfaces developers already inhabit and to be brief. A developer-relevant metric in the right surface, in one or two lines, beats a comprehensive dashboard the developer never opens.
What to leave off the developer dashboard
The metrics that belong on the security team's dashboard usually do not belong on the developer's. Confusing the audiences is a common mistake.
Aggregate risk scores. A 0-to-10 risk score for an entire project is useful for executive reporting and useless for developer action. The developer cannot tell which of their dozens of findings is driving the score, and the score itself is a black box.
Compliance percentages. SOC 2 readiness, PCI-DSS coverage, NIST framework alignment. These matter to the security team and to the audit team. They do not change developer behavior because the developer cannot map "make this 95% compliant" to a specific action.
Industry benchmarks. "Your project's risk is 30% above the industry average" is not actionable. The developer does not know what the industry average comprises, and they cannot reduce their score by 30 percent through any single action.
These metrics are not bad. They serve a purpose. But putting them in the developer's surface dilutes the metrics that would change behavior. Keep the developer dashboard focused on what the developer can do.
The negative-feedback trap
The metrics-driven failure mode to avoid is using metrics as a stick. A leaderboard of "developers with the most findings" is not motivating. It is alienating. Developers stop touching dependency code to avoid showing up at the top of the list, which is the opposite of the behavior you want.
The principle is to celebrate fixing, not to punish introducing. A leaderboard of "developers with the most findings closed this quarter" rewards the desired behavior. A weekly recognition of "fastest finding-to-fix this sprint" creates positive momentum. The same tracking infrastructure can produce either kind of leaderboard. Choose the one that motivates the work you actually want.
Safeguard's analytics views ship with both options, and we explicitly recommend the positive framing in our default templates.
Closing the loop
The reason developer-relevant metrics work is that they close the loop between action and outcome. When a developer introduces a risky dependency, they see the finding count tick up. When they fix it, the count ticks down. When the trend improves, the badge in their editor turns green. The feedback is fast, personal, and clearly linked to their behavior.
That feedback loop is what turns shift-left from a policy into a habit. Policies tell developers what they should do. Habits make them do it without thinking. The right metrics, displayed in the right surfaces, are the bridge between the two.
Most organizations have the data to produce these metrics today. The work is in selecting which metrics to show, where to show them, and how to frame them. Get those choices right and you will have developers who think about supply chain security on their own initiative — which is the shift-left outcome the industry has been chasing for a decade.