# 5. Vulnerability Management, ASM, EASM
This is a category that's quietly becoming one of the most fragmented and confusing in security, because every vendor in adjacent spaces (CSPM, EDR, penetration testing, threat intel) has shipped some kind of "attack surface" feature and now claims to do VM/ASM/EASM. Let's untangle it.
Context:
- VM (Vulnerability Management), the classic discipline: scan known assets, find CVEs, prioritize, patch, repeat. Tools: Tenable, Qualys, Rapid7, etc.
- ASM (Attack Surface Management), internal + external view of all your assets, known and unknown, including misconfigurations, exposed services, identity weaknesses, not just CVEs.
- EASM (External Attack Surface Management), specifically the outside-in view: what attackers see when they Google you, scan your IP ranges, find your forgotten subdomains, leaked credentials, exposed S3 buckets, shadow SaaS, etc.
The category is shifting from "scanner-centric" (find CVEs) to "exposure-centric" (find exploitable paths). Vendors love to claim they do both. Most do one well and the other poorly. Worse: most tools generate enormous lists of "vulnerabilities" with no useful prioritization, leading to the universal CISO complaint, "I have 80,000 criticals, where do I start?"
The right question is no longer "what are my vulnerabilities?" but "what's actually exploitable, by whom, and what would happen if they did?"
13 Questions to Ask VM/ASM/EASM Vendors
1. "How do you discover assets I don't know I have, and how often is that discovery refreshed?"
Why: Asset discovery is the foundation of everything. A VM tool scanning only your CMDB is missing the assets that get breached, shadow IT, forgotten dev environments, M&A leftovers, expired domains.
Good answer: Multi-source discovery (DNS, certificate transparency, BGP, cloud APIs, agent telemetry, passive network), continuous (not weekly), with confidence scoring. Red flag: "We scan what you tell us to scan."
2. "What's the difference between what your tool finds and what it can prove is exploitable in my environment?"
Why: CVSS scores are theoretical. A "critical" CVE on an isolated, non-internet-facing system with no sensitive data is often less urgent than a "medium" on your VPN concentrator. Modern tools should reason about exploitability, not just severity.
Good answer: Reachability analysis, exploit prediction (EPSS, KEV), business context, attack path modeling. Red flag: CVSS-only prioritization or "we use AI to prioritize" without methodology.
3. "Show me the exact prioritization logic. If I have 50,000 findings, how does your tool tell me which 50 to fix this week?"
Why: This is the operational question. A tool that doesn't ruthlessly prioritize is generating noise, not actionable work. Your patching team can't fix 50,000 things, but they could fix 50.
Good answer: Transparent scoring model, exploit availability, asset criticality, exposure path, business context, with the ability to adjust weights. Red flag: Black-box scores or "everything critical is critical."
4. "How do you handle authenticated vs. unauthenticated scanning, agent-based vs. agentless? What's the trade-off in my environment?"
Why: Each method has blind spots. Unauthenticated scans miss internal config issues; authenticated scans break things and need credentials; agents add coverage but bloat endpoints. Vendors have biases, surface them.
Good answer: Honest discussion of trade-offs, hybrid approaches, recommendations based on environment type. Red flag: "Our [single method] covers everything you need."
5. "For EASM specifically, show me your attack surface view of my company right now, before I sign anything."
Why: EASM vendors can demonstrate value in 30 minutes with no commitment by showing you your own exposed assets. If they can't or won't, they don't have the data they claim.
Good answer: Live, no-cost discovery report on your domains, with credible findings (subdomains, exposed services, leaked credentials). Red flag: "We need a 6-week onboarding to show value."
6. "How do you handle false positives, and what's your published FP rate by finding type?"
Why: FP rate is the silent productivity killer. A scanner that reports 1,000 vulnerabilities, 700 of them noise, has wasted your team's week. Mature vendors measure and publish this; immature ones don't.
Good answer: Published FP rates per finding type, validation workflows, customer-driven suppression. Red flag: "Our findings are validated" (by whom, how?).
7. "How do you integrate with my patching, ticketing, and remediation tools? Does a finding actually become a ticket someone owns, or does it die in your dashboard?"
Why: Findings without ownership are wallpaper. The integration into existing IT/Ops workflows is where most VM programs fail, not in detection.
Good answer: Bi-directional sync with ServiceNow/Jira, automated ticketing with ownership rules, SLA tracking. Red flag: "We export to CSV" or one-way push only.
8. "How do you measure remediation effectiveness over time, and can you show me trend data from real customers?"
Why: The point of VM isn't finding vulns, it's reducing them. Tools should help you measure mean-time-to-remediate (MTTR), backlog burn-down, and risk posture trends.
Good answer: Standard reporting on MTTR by severity, exposure window, risk reduction over time. Red flag: Reports focused on "vulnerabilities found" rather than "vulnerabilities resolved."
9. "How do you handle scanning of OT, IoT, cloud-native, containers, and APIs, or do I need separate tools?"
Why: The attack surface has fragmented. A VM tool built for traditional IT often can't safely scan OT, doesn't understand container ephemerality, and fails on API-only services. Get an honest map of strengths and gaps.
Good answer: Honest segmentation of strengths, partner ecosystem for gaps, native or via integration. Red flag: "We cover everything" (no one does).
10. "Can you reason about attack paths, chains of vulnerabilities, misconfigurations, and identity weaknesses that combine into a real attack scenario?"
Why: This is the modern frontier. A medium vuln + a misconfig + an over-privileged service account = a critical attack path. Tools that only find atomic findings miss the actual story attackers exploit.
Good answer: Graph-based attack path analysis, identity exposure mapping, "blast radius" modeling. Red flag: Flat findings list with no relational reasoning.
11. "How do you handle credential leaks, dark web exposure, and brand impersonation, or is that a separate product / partner?"
Why: External exposure increasingly extends beyond technical findings, leaked passwords, typosquatted domains, exposed source code on GitHub, mentions on criminal forums. Vendors handle this very differently; some include it, some upsell it, some don't do it at all.
Good answer: Clear scope of external monitoring included, partnerships disclosed, additional cost transparent. Red flag: "It's part of our platform" (verify scope and depth).
12. "How does your tool age, what happens to my data, custom rules, and historical trends if I switch vendors in 3 years?"
Why: VM is a longitudinal discipline. Trend data is enormously valuable for proving program effectiveness. Vendor lock-in here means losing your history of risk reduction.
Good answer: Open export, standard formats (CycloneDX, CSAF, OCSF), data portability commitments. Red flag: Proprietary formats with no published export path.
13. "Who's responsible for what once a finding is reported, your team, my team, the asset owner? And do you offer managed remediation or just managed scanning?"
Why: Many vendors are quietly moving to "managed VM" services where they not only scan but also drive remediation. This is good or bad depending on your team. Either way, the RACI must be explicit.
Good answer: Clear ownership matrix, optional managed services, defined SLAs by tier. Red flag: "We provide visibility, you handle remediation" (true but unhelpful), or, conversely, "we'll handle it all" with no specifics.
14. (Bonus) "What's your stance on continuous validation, do you actually try to exploit findings (BAS, automated pen testing) or just detect them?"
Why: The next evolution beyond VM is continuous validation, actively testing whether findings are exploitable in your specific environment, often via Breach & Attack Simulation (BAS) or autonomous pen testing tools. A vendor's stance reveals their roadmap maturity.
Good answer: Native validation capability, partnerships with BAS tools, or honest acknowledgment of where this fits. Red flag: Conflation of "we scan" with "we validate."
🎯 The Meta-Test
- Q1, Q3, and Q10 separate scanners from exposure platforms. A scanner finds CVEs. An exposure platform tells you what an attacker would actually do.
- Q5 is the credibility test for EASM. Real EASM vendors will show you your exposure today, free, in a sales conversation. Fake ones won't.
- Q7 and Q13 are the operational reality test. Findings that don't become work tickets owned by accountable humans = no risk reduction, no matter how good the scanner.
💡 Honest Observation
For "regular" companies, the trap in this space is buying tools faster than you can act on findings. A team that can patch 100 things a month doesn't need a tool finding 100,000 things, they need ruthless prioritization and integration into existing IT workflows.
The right purchasing sequence for most mid-market organizations:
- EASM first (cheap, fast, shows you what attackers see, often reveals shadow IT and surprises)
- Then internal VM (with strong prioritization)
- Then ASM/attack-path (once you have the basics under control)
Vendors who push the reverse sequence (sell you the platform first, discovery later) are optimizing for ARR, not your security posture.
