The ROI Problem in Attack Surface Management
好的,我现在需要帮用户总结一篇文章的内容,控制在100字以内。用户给的原文是关于攻击面管理工具ASM的,主要讨论了ASM在实际应用中的问题,比如虽然能收集大量资产信息和生成警报,但难以证明风险减少,导致ROI不明显。 首先,我需要通读整篇文章,抓住核心观点。文章指出ASM工具通常提供大量信息,但缺乏有效的结果指标来证明风险减少。常见的指标如资产数量、变化次数等,并不能直接反映安全性提升。作者建议转向关注结果指标,比如资产所有权时间、危险暴露持续时间等。 接下来,我要将这些内容浓缩到100字以内。要确保涵盖ASM的现状、问题以及建议的解决方案。可能需要提到ASM收集的信息多但效果不明显,缺乏有效的风险减少指标,并建议关注结果而非数量。 然后,检查是否有重复或冗余的信息,确保语言简洁明了。例如,“攻击面管理工具通常收集大量资产信息和警报”可以简化为“ASM工具收集大量资产信息和警报”。 最后,整合所有要点,形成一个流畅的总结句。确保不超过字数限制,并且准确传达原文的核心内容。 </think> 攻击面管理工具通常承诺降低风险,但实际效果难以衡量。虽然能收集大量资产信息和生成警报,但缺乏有效指标证明风险真正减少,导致回报率难以评估。建议关注结果导向的指标,如资产所有权时间、危险暴露持续时间和废弃资产清理速度,以更准确地衡量风险降低效果。 2026-1-2 11:30:0 Author: thehackernews.com(查看原文) 阅读量:1 收藏

Attack Surface Management (ASM) tools promise reduced risk. What they usually deliver is more information.

Security teams deploy ASM, asset inventories grow, alerts start flowing, and dashboards fill up. There is visible activity and measurable output. But when leadership asks a simple question, "Is this reducing incidents?" the answer is often unclear.

This gap between effort and outcome is the core ROI problem in attack surface management, especially when ROI is measured primarily through asset counts instead of risk reduction.

The Promise vs. The Proof

Most ASM programs are built around a reasonable idea: you can't protect what you don't know exists. As a result, teams focus on discovery: domains and subdomains, IPs and cloud resources, third-party infrastructure, and transient or short-lived assets.

Over time, counts increase. Dashboards are trending upward. Coverage improves.

But none of those metrics directly answer whether the organization is actually safer. In many cases, teams end up busier without feeling less exposed.

Why ASM Feels Busy but Not Effective

ASM tends to optimize for coverage because coverage is easy to measure: more assets discovered, more changes detected, and more alerts generated. Each of those feels like progress.

But they mostly measure inputs, not outcomes.

In practice, teams experience:

  • Alert fatigue
  • Long backlogs of "known but unresolved" assets
  • Repeated ownership confusion
  • Exposure that lingers for months

The work is real. The risk reduction is harder to see.

The Measurement Gap

One reason ASM ROI is hard to prove is that most attack surface metrics focus on what the system can see, not what the organization actually improves.

Common attack surface management metrics include:

  • Number of assets
  • Number of changes

More meaningful attack surface metrics are rarely tracked:

  • How fast risky assets get owned
  • How long dangerous exposure persists
  • Whether attack paths actually shrink over time

Asset inventory remains foundational to measuring the external attack surface. Without broad discovery, it's impossible to understand exposure at all. The gap appears when discovery metrics aren't paired with measurements that show whether risk is actually being reduced.

Without outcome-oriented measurements, ASM becomes difficult to defend during budget reviews, even when everyone agrees that asset visibility is necessary.

What Would Meaningful ROI Look Like?

Instead of asking, "How many assets did we discover?" a more useful question is, "How much faster and safer did we get at handling exposure?"

That reframing shifts ROI from visibility to response quality and exposure duration. Things that correlate much more closely with real-world risk.

Three Outcome Metrics That Actually Matter

1. Mean Time to Asset Ownership

How long does it take to answer the basic question: "Who owns this?"

Assets without clear ownership:

  • Linger longer
  • Get patched later
  • Are more likely to be forgotten entirely

Reducing time-to-ownership shortens the window where exposure exists without accountability. It's one of the clearest signals that ASM findings are turning into action.

2. Reduction in Unauthenticated, State-Changing Endpoints

Not all assets matter equally.

Tracking how many external endpoints can change state, how many require authentication, and how those numbers change over time provides a much stronger signal of whether the attack surface is shrinking where it counts.

An environment with thousands of static assets but few unauthenticated, state-changing paths is meaningfully safer than one with fewer assets but many risky entry points.

3. Time to Decommission After Ownership Loss

Exposure often persists after:

  • Team changes
  • Application deprecation
  • Vendor migrations
  • Reorgs

Measuring how quickly assets are retired once ownership disappears is one of the strongest indicators of long-term hygiene and one of the least commonly tracked.

If abandoned assets stick around indefinitely, discovery alone isn't reducing risk.

What This Looks Like in Practice

Abstract metrics are easy to agree with and hard to operationalize. The goal isn't a new dashboard or a different set of alerts, but a shift in what's made visible: ownership gaps, exposure duration, and unresolved risk that would otherwise blend into asset counts.

Rather than emphasizing total asset count, this view surfaces:

  • Which assets are owned
  • Which are unresolved
  • How long ownership has been unclear

The goal isn't more alerts but faster resolution.

Turning ASM into a Control

ASM doesn't struggle because teams aren't working hard enough. It struggles because effort isn't consistently tied to outcomes that leadership cares about.

Reframing ROI around speed, ownership, and exposure duration makes it possible to show real progress. Even if the raw asset count never changes. In many cases, the most meaningful wins come from making the attack surface boring again.

A Concrete Starting Point

One way to pressure-test outcome-based ASM metrics is to make asset visibility broadly accessible across teams, not gated behind tooling silos. We've found that when engineering, security, and infrastructure teams can all see ownership gaps and exposure duration, resolution speeds up without adding more alerts.

That thinking led us to release a community edition of our ASM platform that exposes asset discovery and ownership visibility without cost or limits. The goal isn't to replace existing tools, but to give teams a way to measure whether exposure is actually shrinking over time.

If you want to pressure-test the ROI of your ASM program, try this: Ignore how many assets you have.

Instead, ask:

  • How long do risky assets stay unowned?
  • How many unauthenticated, state-changing paths exist today vs last quarter?
  • How quickly do abandoned assets disappear?

If those answers aren't improving, more discovery won't change the outcome.

Conclusion: Measure What Actually Changes Risk

Attack surface management becomes defensible when it's measured by what changes, not just what accumulates. Discovery will always matter. Visibility will always matter when measuring the attack surface. But neither guarantees that exposure is being reduced, only that it's being observed.

Attack surface management ROI shows up when risky assets get confirmed as owned faster, when dangerous paths disappear sooner, and when abandoned infrastructure doesn't linger indefinitely. Asset inventory provides the necessary breadth; outcome-oriented metrics provide the depth needed to understand real risk reduction.

At Sprocket Security, we try to think about attack surface management not only in terms of how many assets exist, but also how long meaningful exposure persists and how quickly it gets resolved. What matters most is that attack surface metrics make progress visible, not just inventory growth.

If an attack surface management program can't answer whether exposure is shrinking over time, it's hard to argue that it's doing more than reporting the problem.

Note: This article was expertly written and contributed by Topher Lyons, Solutions Engineer at Sprocket Security.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.


文章来源: https://thehackernews.com/2026/01/the-roi-problem-in-attack-surface.html
如有侵权请联系:admin#unsafe.sh