昨天晚上做梦，梦见不知道在之前还是现在的哪家公司，跟同事老板谈hc，说到，当前最大的问题是，人力问题，是人力不够。只有人力解决了，这个team才能运转下去。我就问，那你们团队是做啥的呢？他说做扫描器和漏洞运营。梦里就开始回想在以前公司中，各种方法有效的效率提高和人力节省措施，我就回了一句，人力当然重要，不然事情做不起来，同时在有一定人力的情况下，方法更重要。接着，就开始就扫描器的使用高谈阔论了起来。
啥？扫描器不就一个工具么？有几个人不会用？
这里就讲一讲在甲方互联网公司，扫描器在具体实践中的用法，个人浅见，欢迎交流分享……头次发文，不知道会被喷到多惨……
一、扫描器哪里来？
以前就职的两家公司里，黑盒扫描器都是自研，白盒扫描器只有其中一家有。直到有一次某M公司来做分享，才知道，原来他们的黑白盒扫描器都是靠购买的，乙方提供产品和售后支持。当时纳闷儿，如果是乙方提供，就不怕到时候也不知道代码，添加规则的时候不能满足需求吗？M公司的专家解释，以前M也是自研扫描器，但是发现的问题是，扫描器的开发维护团队的目标，很多时候和具体运营的安全团队是不一致的，更新规则的效率效果也比较不好说；而乙方由于提供给多家服务，样本也更多，产品更专业，提供的服务也更好一些。回想起原来就职的两家公司里，除非扫描器的开发运维和安全工程师就在一个小团队，否则这其中的多个环节也确实很难保证扫描器的快速迭代。
除了比较大的公司，如果是初创公司或者是快速增长期的公司，购买一款质量有保证，售后服务好的扫描器产品都是个不错的选择。当然如果能挖到专业的扫描器大牛过来，进行产品开发，不仅少走很多弯路，还便于内部产品对接，就更好了。
二、扫描器谁来用？
刚入行的时候，发现扫描器定期通过全流量，域名或ip，进行扫描，然后推送到SOC上，安全工程师来进行报警运维，以及后续漏洞的分发。这是对扫描器最早的用户的认识。
随着时间的增长，遇到了一群群特别牛叉的小伙伴儿，见识了，除了常规安全工程师运维，还可以将安全工程师以外的员工动员起来，毕竟，安全不仅仅是一个安全团队的事情，而是一个公司，甚至还有公司外部人员一起来构建的生态。
三、扫描器怎么用？
- 常规黑盒扫描
收集和维护公司流量，ip和域名信息，对这些资产进行定期全量和增量扫描。
全量扫描，重点在于，要收集和维护公司的资产，并对资产进行有效的去重策略。周期要比增量扫描的周期长一些，这里的重点在于全，而不是快。去重也需要一套完整的策略，不过此处不作过多展开。
增量扫描，对比原有资产库，一旦发现有新增资产，立即进行扫描，这里的重点在于要快。因为如果在历史漏洞能够有效修复的情况下，新增资产出现新漏洞或高危漏洞的可能性更大，需要尽快发现并处理。
- 黑盒插件扫描
据Net Market Share 的7月份数据，占据全球浏览器排行榜首位的是Chrome浏览器，总市场份额为48.65%。实际工作中，也确实不少的程序员喜欢用Chrome浏览器。甚至于，不少浏览器直接使用的是Chrome的内核。
在这个前提下，开发Chrome浏览器扫描插件成为了可能。
由于黑盒扫描基于URL即可扫描发现漏洞的特性，只要通过Chrome或其内核浏览器浏览过的URL，都可以通过插件进行收集抓取，并进一步进行黑盒扫描。只要安全工程师将插件开发成功，并推广到公司的开发和测试安装使用，那么开发和测试在线下环境中就可以自行检测出漏洞，只要安全工程师准备好相应漏洞的修复方案，开发即可自行修复上线。无需等待产品上线，将安全风险暴露到外面后，外部或安全工程师再倒推给开发修复。不仅是降低了安全风险，也节省了安全工程师的工作成本。
- 黑盒自助扫描
仍基于拿到URL即可扫描或爬取漏洞的特性，可以将扫描器后台功能，开发成前台产品，供对漏洞了解并未达到专业程度的开发或测试使用。
产品形态可以就是简单的输入框，用户输入URL，点击扫描，即可对该URL进行黑盒漏洞扫描。
对于更深度的用户，也研发定期，批量，爬虫或接口扫描等功能……可以做的事情就很丰富了。
4.服务器扫描
这个原理是，抓取开发或测试的服务器上的日志，推到扫描器，进行定期自动化扫描。好处是一旦配置了，就能准确的收集到最新变动的代码的日志，并且中途无须人工进行更多的操作，只需等待结果即可。
需要注意的是，要尽量开发封装的agent，而不仅仅是接口，因为封装的agent在开发或者测试接入的时候成本更低，推广起来也更容易。如果公司内webserver类型不统一，那么可能需要开发Apache,Ngnix，lighttpd等多个适用版本来进行接入。
- 白盒代码扫描
白盒的代码扫描，理论上也可以运用方法3中，输入代码路径的方式进行自主扫描。还有一种方案就是，将白盒代码扫描，封装成一个脚本或者包，推广给开发，在开发常规开发的时候，跑一遍脚本或者包，显示哪里的代码可能会产生安全漏洞。
这个方案的难点有两点。一是，如果公司开发使用的是多种语言，那么包的适配和开发上可能就需要花比较多的心思。二是，白盒扫描本身产生的误报，想做好控制也比较难，这就要在漏报和误报间做好权衡，至少选择添加误报达到某一基准线的规则，并做好引导说明，否则容易败RP。
- 上线平台扫描
如果是比较专业的公司，代码上线，一般都会有上线的平台或者系统做支撑。
如果在上线前接入黑盒白盒扫描，并对漏洞进行修复，更是事半功倍。
需要注意的几个事情是：
第一，要和上线的平台打通，取得相应平台，以及平台的用户的支持，这部分建议还是先走试点然后逐步推开。
第二，接入黑白盒扫描，不要等到最终上线那一刻再去扫描，而是尽量将扫描的步骤提前，进行预扫描，加快速度，提高用户体验。
第三，对于扫描的结果，哪些可以不修复就上线，哪些必须修复后上线，必须制定相应的策略，明确不修复上线的风险确认方式。
第四，对于扫描器扫描规则的维护，需要在安全自己的系统中，而不是上线的平台。这样添加规则，设置白名单，能够不受上线平台的影响，自己掌握主动权。
最后，任何一种扫描器都不能解决所有的问题，有必要的情况下，对于重点业务可以通过设定策略，添加人工测试。
四、扫描器怎么维护？
衡量扫描器好坏最简单的就是漏报和误报率，如何尽量降低漏报和误报，是扫描器安全上的最主要目标。当然，稳定性，效率，速度不可忽视，不过此处不做详细说明。
1.漏报
漏报是难免的，重要的是每次发现漏报后能够更好的处理和解决，并且和误报做好平衡取舍。漏洞一旦通过各种非扫描器的渠道上报后，要有专门的人对该漏洞进行分析和规则添加。这其中，疑似漏报的漏洞的通知规则和方式，根据漏洞类型进行初步的过滤和筛选，以及后续的规则添加都可以进行策略制定，这些都可以提高工作的效率。
此外，对于基础资产，包括但不限于流量，域名，ip，代码路径相关信息，进行收集和维护，也是减少漏报的重要途径。不过，大公司资产分布较多，初创公司基础建设又有可能不完整，收集资产都是个不易的任务。根据过往有限的经验，如果安全团队有人力的话，最有质量的方案，是将资产梳理和资产数据，通过各种方式，汇总到自己的平台上，自己进行维护。如果依赖其他平台运维，后续无论是工作对接上，还是保证数据准确性上，都会有无穷无尽的麻烦。梳理资产确实是个比较需要耐心，恒心，毅力和沟通能力的工作。
2.误报
这里涉及到的是添加规则。如果是自研扫描器，非常非常建议，添加规则是通过动态配置，而非更新代码。因为规则本身就是不断变化的，如果每次规则变化都依赖开发，后续的麻烦，你懂的。
最后，安全不是一个团队的事情，而是联合公司内外各种力量建立起来的生态。
任何一种扫描器也无法扫描出全部的漏洞。
向奋斗在第一线的安全从业人员致敬。
本文转自d1net（转载）
