你驻足于春色中,于那独一无二的春色之中.
每个Web安全学习者都有一个自己的扫描器梦。
当自己刚入门安全的时候，也是经历了从使用扫描器，到自己写自己的想要的功能的扫描器这个历程。但是从个人白帽视角、甲方视角和乙方视角所设计出来的扫描器都不尽相同，个人白帽扫描器和乙方扫描器相通的地方还多一点，都是预先对扫描目标未知，往往通过黑盒方式感知目标，希望尽可能的对漏洞规则进行覆盖，漏洞扫描思路也以通用性的漏洞发现思路为主，同时还会对扫描报告的呈现进行设计。
但是在甲方实践过程中，尤其是大一点的有一定SDL流程的互联网公司实践过程中，通用的乙方扫描器通常都是很难直接发现公司真正关注的一些高危漏洞的，SDL的流程使得低级的通用的大量漏洞往往在设计之初就被杜绝掉了，公司里复杂的网络环境，魔改的各种组件，其他的安全能力也都需要扫描器来单独适配
因此这里主要从甲方视角下的黑盒扫描器出发，对通用性的问题进行想到哪儿说到哪儿的讨论，不会聊到自己在实际设计中使用的黑科技。
扫描器建设和企业自身基础设施属性是密切相关的，企业的内部网络环境是如何设计的？扫描器的输入源需要覆盖哪些点？如何覆盖？根据输入源的体量要求的扫描周期是多久？根据扫描周期要求能够拿到多少预算？根据扫描周期要求如何设计分布式扫描的发包能力？
作为设计者，是否能够回答上述的问题。一个大型企业往往是由正式线上环境和开发环境的，有自己云能力的企业可能同时还会有自己的云上环境。那么扫描器的基础构架设计就需要有能力覆盖相互隔离的不同的网络环境。那么做分布式设计时，就需要合理分配扫描节点预算，同时配置对扫描节点的统一调度能力和节点动态扩展能力。
在设计基础构架时，也需要考虑扫描器需要满足内部哪些输入源，常见的输入源有IP、域名、交互流量，那么这些输入源是可以和其他研发设施对接，还是需要自己解决，如果是和研发设施对接，对方的数据周期是否满足扫描周期要求，如果是自己解决，就需要投入相应的研发能力中。
节点数量与扫描周期的平衡，这里需要预先设计扫描周期与节点之间的换算关系，按照传统的发包量来计算，在预期周期内扫描需要发送多少请求包，单台机器能够提供多大的并发能力，最终决定节点的部署数量。由于扫描节点往往都是占据大量的预算，最好是能够说清扫描节点预算投入必要性和价值。
分布式的设计构架，大多数都会采取一对多，一对多对一的设计模式，前者解决的是统一任务下发和结果呈现的问题，后者解决的是统一扫描能力管控的问题。
扫描能力是一个很宽泛的话题，首先应该想到的是在具备扫描基础构架之后，在这份构架之上应该承载哪些需求。常见的需求有企业内部网络资产测绘、安全漏洞扫描两大类，前者是动态反馈企业资产，包括主机、网络、应用等多个层次的指纹信息；后者是对安全风险进行扫描识别。
企业内部一般都会有自己独特的协议、独特的基础组件应用，网络资产测绘是否能够识别这些协议、应用，并且能够自动化的新增对企业内部未知协议和基础组件的识别就尤为重要。这也是乙方通用扫描器难以解决的问题之一。
安全漏洞扫描这一part的问题将会整体放到下一次的扫描规则这一节来重点说明。
同时，这里还要注意，像华为、小米等涉足IOT、移动等领域的企业还会有许多的非传统资产，这类智能设备也会在企业的网络中，扫描器是否有能力针对这一类应用进行扫描。
这里的扫描器能力还想提到的是对扫描能力本身的持续可视化监测以及和其他企业内部安全能力的联动。
在分布式的构架下，从输入源进入，到任务分发到节点，再到节点执行扫描，获取响应进行业务逻辑判断，再将判断结果反馈给调度中心，直到风险的发现。这一整条链路不仅涉及到扫描规则本身的有效性，还有整条链路里的任务反馈是否正常。因此需要设计考虑有效的监控以及排查、告警机制，来保证日复一日的扫描都是真实有效的。这部分一方面可以和企业内部自身的业务链路监控机制相结合，学习业务方的复杂链路监控体制，设计有效的正向监控体制。另一方面还可以结合靶场等验证设施，完成反向的监控机制。
扫描能力最后想到的一点就是多和其他安全能力沟通，一方面要保证扫描能力不会被其他安全能力所干扰，另一方面可以考虑参考其他安全能力的输出信息来辅助扫描器的漏洞风险决策。
企业的扫描器设计之初，往往是强需求驱动的，这就使得大多数在设计时无法做到充分的体系化评估。同时，决策层往往能够直接感受到的是发现的漏洞和未发现的漏洞数量，对于这种数量的感知也会使得执行者无法专注于底层架构的设计。扫描器尤其是业界一致认为都比较成熟的黑盒扫描器（IAST先不算进来）需要能够体现给决策层更多的能力价值，不局限于风险发现，才能获取到足够的资源来完善扫描器不被外人看到的内核能力。
下一章将会重点再谈谈扫描规则建设、漏洞生命周期管理、漏洞修复几个方面。