一个海外业务团队临时注册的新域名、一台测试结束后没有关停的云主机、一套仍能从公网访问的旧版管理后台，或者一个未纳入安全测试流程的 API，都可能成为攻击者进入企业环境的起点。

这些资产未必出现在配置管理数据库（CMDB）或传统资产台账中。即使已经登记，域名解析、公网地址、开放端口、应用版本和负责人也可能早已发生变化。因此，拥有一份“已知资产清单”，并不等于真正掌握了互联网攻击面。

Verizon 2026年数据泄露调查报告显示，利用软件漏洞已成为其调查的数据泄露事件中最常见的初始访问方式，占比达到31%。这意味着，企业既要修复漏洞，也要先回答一组更基础的问题：哪些资产正在暴露？它们是否确属本企业？攻击者能否到达？背后承载什么业务？

围绕这些实际问题，专注漏洞与暴露风险管理的网络安全公司Tenable提供的相关能力，覆盖外部资产发现、漏洞优先级分析以及Web与应用程序编程接口（API）安全测试。企业可以据此建立一条连续主线：先发现并确认资产，再判断风险和业务影响，随后开展应用测试，最后通过责任分配和复测验证风险是否得到有效处置。

企业的互联网攻击面包括哪些资产？ASM、EASM和CAASM有什么区别？

企业的互联网攻击面，是攻击者能够从公网观察、访问或利用的资产及其关联关系。它不仅包括官方网站和公网IP，还可能包括云资源、API、远程访问入口、遗留系统，以及由第三方托管但仍由企业承担业务责任的数字资产。

哪些互联网暴露资产容易被遗漏？

在实际运营中，容易脱离传统资产台账的对象主要有以下几类：

1. 域名与子域名。 除企业官网外，还包括地区站点、活动页面、经销商门户、招聘网站、品牌保护域名，以及开发、测试和预发布环境使用的子域名。

2. 公网基础设施。 包括公网IP、开放端口、服务器、负载均衡器、云端入口、内容分发节点、邮件服务和文件传输服务。

3. Web应用与API。 客户门户、员工入口、管理后台、电子商务系统、合作伙伴平台、移动应用后端，以及面向供应链或物联网设备开放的接口，都可能构成外部入口。

4. 远程访问与边界设备。 虚拟专用网络（V P N）、远程桌面、邮件网关、防火墙以及其他互联网边界设备，通常具有较高访问权限，需要重点关注。

5. 遗留及第三方资产。 已停止推广但尚未完全下线的网站、并购前遗留系统，以及由营销代理商、开发商或海外服务商维护的系统，容易因为责任边界不清而长期暴露。

DNS记录、数字证书、域名注册信息、名称服务器和页面反向链接也能帮助发现关联资产，但这些线索不能单独证明资产所有权。安全团队仍需结合云账户、采购记录、系统用途和业务负责人进行归属确认，否则发现范围越广，误归属和重复告警也可能越多。

ASM、EASM、CAASM和漏洞管理分别解决什么问题？

攻击面管理（ASM）是持续识别、分析和缩小潜在攻击入口的总体过程。其中，外部攻击面管理（EASM）强调从企业边界之外，以类似攻击者的视角发现互联网可见的域名、主机、云服务和Web应用，尤其适合寻找未知、遗留或未经批准的外部入口。

网络资产攻击面管理（CAASM）主要连接企业已有的安全与IT数据源，汇总和规范来自CMDB、端点、云平台、漏洞管理等系统的资产信息。简而言之，EASM更侧重回答“攻击者在外部能看到什么”，CAASM更侧重回答“企业内部各套工具掌握了什么，以及这些记录如何关联”。

传统漏洞管理通常在已知或已经纳管的目标上识别软件漏洞、缺失补丁和错误配置；Web应用安全测试则进一步检查运行中的应用如何处理身份、权限、输入和业务接口。它们的职责不同，但可以在同一暴露风险管理流程中相互衔接。

要让外部资产发现、内部资产信息和漏洞管理有效衔接，企业首先需要建立能够支持归属确认和风险判断的资产记录。对于适用网络安全等级保护要求的系统，中国现行推荐性国家标准GB/T 22239—2019《信息安全技术 网络安全等级保护基本要求》提出，应编制并保存与等级保护对象相关的资产清单，记录资产责任部门、重要程度和所处位置等信息。面向多域名、多云和出海环境，企业还可以根据实际管理需要，补充业务用途、具体负责人、所属环境、关联服务和生命周期状态，为外部发现结果的归属确认、风险评估和后续处置提供必要上下文。

多域名、多云和出海环境下，如何持续发现未知及遗留资产？

企业需要把互联网侧发现、内部数据校验和资产生命周期管理连接起来，才能持续识别多域名、多云及出海业务中的未知资产。一次性域名梳理只能形成某个时间点的快照，难以跟上云资源变化、业务上线和历史系统遗留的速度。

第一步：以核心域名和云账户为起点扩大发现范围

持续发现通常从一组经过确认的信息开始，包括总部及子公司的核心域名、品牌名称、已知公网IP、IP地址段、自治系统号（ASN）、云账户和域名注册信息。企业再沿着子域名、DNS记录、数字证书、注册邮箱、名称服务器和页面关联关系寻找候选资产。

对于多品牌或出海企业，初始范围还应覆盖海外子公司、历史并购企业、地区域名，以及由外包开发商、营销代理商或托管服务商维护的系统。这些资产可能使用企业品牌或处理企业数据，却没有及时进入总部的资产台账。

Tenable One Attack Surface Management可以从域名、子域名、IP、IP地址段、ASN及云环境等来源识别相关互联网资产，并观察外部足迹变化。在扩大外部可见范围后，企业可结合内部记录确认资产归属，并将发现结果纳入正式资产管理。

第二步：结合内部数据确认资产归属和业务责任

从互联网发现的域名或主机，只能说明它与企业存在关联线索，不能自动证明企业拥有或管理该资产。安全团队需要将外部发现结果与内部DNS、CMDB、云账户、采购记录、业务系统目录和供应商信息进行交叉验证。

确认资产时，不应只判断“是否属于本企业”，还应补充业务系统、所属地区、运行环境、数据类型、负责人和关键程度。例如，同一个品牌域名可能由海外业务团队申请、第三方服务商托管，却连接总部的客户或业务数据。只有同时确认技术归属、业务归属和运维责任，后续发现漏洞时才能找到适当的处置团队。

无法立即确认的对象可以保留为“待核实资产”，并记录发现依据和核实责任人，而不宜直接计入正式资产总量。这样既能保留潜在线索，也能减少误归属对风险统计和处置工作的影响。

第三步：持续监测变化，并按生命周期管理资产

多云环境中的资产会不断变化：云主机可能更换公网IP，临时测试环境可能重复创建，域名可能停止使用但仍保留解析，旧版应用也可能在业务迁移后继续对外开放。如果把一个IP简单视为一个固定资产，清单容易出现重复记录，漏洞和整改历史也难以连续追踪。

因此，企业需要综合使用完全限定域名、云资源标识、证书、DNS记录和业务标签识别资产，并记录其生命周期。资产可以依次处于“待核实、已确认、评估中、整改中、风险接受、待退役和已退役”等状态。只有相关域名解析、公网入口、云资源和关联服务经过验证关闭后，资产才适合被认定为已退役。

持续发现的效果也不应只用资产总量衡量。更值得关注的是：新增了多少未知资产，有多少资产尚未确认负责人，遗留系统从发现到关闭用了多长时间，以及资产变化后多久进入风险评估流程。这样，攻击面管理才能从定期盘点转变为持续运行的发现和处置机制。

发现互联网暴露资产后，企业如何判断哪些风险需要优先处理？

资产清单回答“环境里有什么”，暴露风险管理进一步回答“哪些资产和弱点组合更可能影响关键业务”。优先级不宜只看漏洞数量或单一严重等级，还应结合互联网可达性、真实攻击活动、业务重要性和现有防护措施。

风险优先级应考虑哪些因素？

通用漏洞评分系统（CVSS）提供了标准化的漏洞严重性衡量依据，但相同漏洞出现在隔离测试环境和互联网交易入口上，实际风险可能不同。反过来，一个评分并非最高、但已经出现广泛利用活动的边界设备漏洞，也可能需要优先处理。

企业可以围绕四个问题建立排序框架：

1. 攻击者能否到达？ 资产是否直接暴露于互联网？相关端口、页面或API是否可访问？前方是否存在有效的身份验证、网络限制或其他控制？

2. 弱点是否已有真实利用证据？ 是否存在公开利用代码或在野利用活动？攻击条件是否与当前配置相符？CISA维护的已知被利用漏洞目录（KEV）可作为漏洞优先级判断的重要输入之一。

3. 业务影响有多大？ 资产是否承载核心交易、客户数据、供应链连接、远程办公或生产管理功能？被入侵或中断可能影响哪些用户和业务流程？

4. 是否形成高风险组合？ 例如，公网管理入口、较弱的身份验证和高权限账户同时存在，通常比三个相互隔离的问题更值得优先关注；遗留Web应用、已被利用漏洞和关键数据连接同时出现，也会放大风险。

这也是漏洞管理向暴露风险管理延伸的关键：漏洞信息仍是基础，但还需要结合资产关键性、外部可达性、威胁活动和业务影响。借助Tenable的风险优先级分析，安全团队可以从大量发现中聚焦更值得优先处置的风险，并据此协调修复资源与整改顺序。

确定风险优先级后，企业应根据资产性质和业务约束选择处置方式。除了安装补丁，还可以关闭不必要的服务、收回公网入口、调整访问策略，或通过网络分段和访问限制等补偿控制暂时降低风险。对于Web应用和API，主机及组件层面的漏洞检查只能覆盖部分问题，还需要在运行状态下验证身份认证、访问控制和输入处理等应用层行为。

Web应用和API频繁发版时，如何持续开展安全测试？

频繁发版环境需要把动态应用程序安全测试（DAST）纳入应用生命周期，而不是只在上线前安排一次渗透测试。EASM负责发现哪些应用和API暴露在互联网上，DAST则从运行状态验证这些目标是否存在应用层弱点。

EASM发现应用后，为什么还需要DAST？

传统漏洞扫描主要识别操作系统、网络服务、中间件和已知软件组件中的漏洞。DAST从应用前端或接口发起请求，遍历页面、链接、表单和API，观察运行中的应用如何处理身份、权限和输入。两类测试关注的层面不同，不能简单相互替代。

OWASP Top 10:2025涵盖访问控制失效、安全配置错误、软件供应链失效、注入和身份验证失效等重要Web应用风险。它适合作为测试范围和开发培训的参考，但并不是能够覆盖所有应用风险的完整清单。

API还需要单独关注对象级授权、身份验证、资源消耗、敏感业务流程和接口清单失控等问题。OWASP API Security Top 10:2023便包含对象级授权失效、不当资产管理和不安全使用第三方API等风险。

DAST也不应被视为静态应用程序安全测试（SAST）、软件成分分析（SCA）或人工渗透测试的替代品。自动化DAST适合持续覆盖较多应用和版本变化；代码分析可以更早发现开发阶段问题；人工测试则适合验证复杂业务逻辑和高价值攻击场景。

Web和API安全测试应按什么节奏运行？

应用安全测试可以根据资产状态和版本变化设置不同深度：

1. 新资产进入清单时进行基础检查。 先确认TLS证书、外部配置、页面范围和身份验证方式，识别较明显的安全问题。

2. 在测试或预生产环境进行较完整扫描。 对主要页面、表单、认证后功能和API开展深入测试，以降低对生产业务造成影响的可能性。

3. 重要功能变更后触发扫描。 身份认证、支付、文件上传、权限模型和API发生变化时，可以将安全测试纳入相应发布流程，而不必完全依赖固定周期。

4. 将适合的测试接入持续集成与持续交付流程。 Tenable One Web App Scanning支持通过容器在CI/CD流程中运行扫描。实施时应选择与生产环境区分的测试目标，并妥善保存扫描凭据和API密钥。

5. 修复后使用可比条件复测。 复测应尽量保持目标、认证方式和扫描范围一致，避免因为测试条件变化而误判问题已经解决。

Tenable One Web App Scanning可以映射运行中应用的页面、链接和表单，检查跨站脚本、SQL注入、易受攻击的第三方组件和其他应用风险，并支持单页应用。其API扫描支持基于OpenAPI规范的REST接口、GraphQL以及SOAP/WSDL。具体扫描效果仍会受到应用架构、认证配置、测试范围和扫描策略影响，企业应通过实际应用验证覆盖情况。

身份验证尤其关键。如果扫描器未能进入认证后的页面，扫描结果将主要反映未认证范围，难以覆盖登录后的业务功能。因此，企业应在授权和安全可控的条件下配置认证扫描，并验证会话是否保持有效。

外部发现和应用测试也可以直接衔接。Tenable One Attack Surface Management发现但尚未测试的应用，可进入Web App Scanning的待扫描应用清单，完成扫描后再转入已扫描状态。这样，企业可以识别哪些互联网应用仍处于“已发现、未测试”状态，减少应用安全测试只覆盖少数已知重点系统的情况。

应用测试产生的结果，只有进入责任分配、修复和复测流程，才能转化为实际的风险处置。因此，最后还需要从单项技术能力回到持续运营。

评估攻击面和Web应用安全方案时，企业应该重点验证哪些能力？

方案评估应验证一条完整工作流能否运行：发现结果是否准确，风险能否合理排序，应用能否深入测试，问题能否分配给责任团队，修复后能否复测。单看扫描速度、告警数量或界面效果，难以判断方案在企业环境中的实际适用性。

如何把发现、测试和处置纳入持续运营？

针对中国市场，Gartner关于持续威胁暴露管理（CTEM）的研究指出，仅依赖补丁或彼此割裂的整改方式，难以覆盖无法通过补丁解决的暴露风险；中国企业需要建立持续的暴露管理流程，并兼顾即时响应与长期安全韧性。企业可围绕范围界定、发现、优先级分析、验证和推动处置组织持续运营。CTEM需要人员、流程和技术共同配合。

在实际分工中，安全团队负责维护发现范围、风险规则和验证标准；IT及云平台团队确认基础设施归属并处理补丁、端口和配置；开发与DevOps团队负责应用代码、认证、访问控制和API问题；业务负责人确认资产用途、关键性以及停机或风险接受决定；采购与供应商管理团队则需要明确第三方系统的整改和退役责任。

一家在中国运营的跨国制造企业曾面临类似问题：该企业同时管理本地机房、公有云和大量互联网业务系统。随着外部资产增加、应用频繁更新，传统盘点难以及时发现影子资产、遗留系统和未经测试的Web应用，也难以从大量漏洞中确定整改重点。企业结合Tenable Security Center、Tenable One Attack Surface Management和Tenable One Web App Scanning，管理已知服务器漏洞、持续发现互联网暴露资产，并对Web应用和API开展动态安全测试。通过关联基础设施、外部攻击面和应用风险，企业能够持续识别未纳管资产，并结合漏洞威胁与业务重要性安排整改顺序。对于同样面临多云、出海和应用频繁更新的企业，评估方案时也应关注资产发现、风险排序、应用测试和整改验证能否相互衔接。

概念验证和选型应重点检查什么？

企业可以使用一组已知资产、隐藏测试资产和有代表性的应用场景进行概念验证，重点检查以下能力：

1. 发现范围与准确性。 能否从核心域名出发找到已知子域名和候选资产？每项候选资产是否提供可解释的关联依据？

2. 动态变化识别。 新域名、新公网服务、IP变化和资产退役能否得到持续追踪？弹性地址是否会造成大量重复资产？

3. 业务上下文。 是否能记录业务系统、地区、环境、负责人、关键程度和数据类型，为风险排序提供依据？

4. 风险优先级。 是否综合公网可达性、利用活动、资产重要性和现有控制，而不是只按静态严重等级排列？

5. Web与API测试深度。 能否进入认证后页面、处理实际使用的前端架构，并按照企业采用的API类型开展测试？

6. 生产环境控制。 是否支持扫描窗口、速率控制、敏感URL排除、凭据保护和适当的扫描器部署方式？

7. 处置与复测。 发现结果能否进入现有工单或开发流程，分配给责任团队，并在修复后重新验证？

8. 中国市场部署条件。 扫描器、管理端和数据分别部署在哪里？哪些信息可能跨区域传输？日志、凭据和报告如何保存？如涉及本地部署、国产环境兼容或特定合规要求，应针对具体产品、版本和部署方式逐项验证。

企业最终需要的，不是一份不断增长的互联网资产清单，也不是更多彼此独立的扫描报告，而是一套能够持续回答五个问题的机制：哪些资产属于本企业，哪些正在对外暴露，哪些风险更可能影响关键业务，由谁负责处置，以及修复后是否已经通过验证。

当EASM扩大外部可见范围，漏洞管理识别基础设施弱点，DAST深入测试Web应用和API，暴露风险管理再把可达性、威胁活动和业务上下文连接起来，企业才更有可能把分散的安全发现转化为可持续推进的风险处置流程。

企业持续管理互联网暴露资产时的常见问题

1. 企业的互联网暴露资产包括哪些？

除网站和公网IP外，还包括子域名、云服务、Web应用、API、远程访问入口、遗留系统及第三方托管资产。对于可从互联网访问且与企业业务或数据相关的对象，企业应先纳入发现和归属核实范围，再决定是否纳入正式资产管理和风险评估。

2. 外部攻击面管理（EASM）与传统漏洞管理有什么区别？

外部攻击面管理（EASM）重点发现攻击者从外部能够看到的未知或遗留资产；传统漏洞管理主要检查已知资产中的漏洞和错误配置。两者结合，才能同时回答“哪些资产暴露在外”和“这些资产存在哪些风险”。

3. 多云和出海环境如何持续发现未知资产？

企业可以从核心域名、公网IP、云账户和品牌信息出发扩大发现范围，再结合内部记录确认资产归属，并持续跟踪资产变化与退役状态。Tenable One Attack Surface Management可以帮助企业发现互联网暴露资产并观察外部足迹变化。

4. 互联网暴露风险应如何确定优先级？

企业不应只看漏洞数量或严重等级，还要综合判断资产是否可从公网访问、漏洞是否已有真实利用活动、业务影响有多大，以及现有防护措施是否有效。Tenable的风险优先级分析可以帮助团队从大量发现中聚焦更值得优先处置的问题。

5. Web应用和API频繁发版时应如何开展安全测试？

企业可在新资产上线、重要功能变更、预生产测试和修复完成后安排动态应用程序安全测试，并将适合的扫描接入持续集成与持续交付流程。在完成相应集成和配置后，Tenable One Web App Scanning可与外部资产发现流程衔接，帮助识别尚未测试的互联网应用，并持续开展Web应用和API动态安全测试。