第一次用AppScan扫一个内部管理系统，洞扫报告出来237个问题。描工我盯着屏幕看了半天，洞扫发现其中180多个都是描工同一个Cookie没设HttpOnly属性，按URL参数不同被拆成了独立条目。洞扫这就是描工AppScan的典型风格——宁可错报一千，不肯放过一个。洞扫

它本质是描工个黑盒扫描器，工作原理不复杂：爬虫先把目标站点的洞扫URL、表单、描工参数全抓下来，洞扫然后拿漏洞库里的描工Payload挨个往里灌，看响应里有没有数据库报错、洞扫脚本回显、描工或者异常状态码。洞扫听起来简单，做起来麻烦。现代Web应用大量用JavaScript动态渲染，AppScan的爬虫经常爬不全，你得手动导URL列表或者配代理录制流量。我一般先用Burp跑一遍业务流程，把关键请求录下来喂给它，比它自己瞎爬靠谱得多。

配置扫描策略是个技术活。默认的“全面扫描”会把SQL注入、XSS、CSRF、路径遍历、命令注入全跑一遍，一个中等规模的站能扫四五个小时。赶时间的话，我会关掉那些误报率极高的检测项，比如“盲注时间延迟检测”——这玩意儿每个参数都要等30秒以上，扫完天都亮了。但关掉又怕漏，所以通常分两轮：第一轮快速扫，只开反射型XSS和报错型SQL注入；第二轮针对第一轮标记的可疑点做深度验证。

误报是绕不开的坎。AppScan判断XSS的标准是看Payload有没有原样出现在响应里，但有时候你提交<script>alert(1)</script>，服务器把它转义成了<script>，AppScan照样标红。你得点开“差异”标签页，对比原始请求和修改后的响应，看看到底是编码问题还是真漏洞。我见过最离谱的误报是一个静态HTML页面被报了SQL注入——因为服务器返回了500错误，而AppScan认为500就是注入成功的标志。实际上那个页面根本没有数据库交互。

不过它也有真本事。有一次扫一个老旧的Struts2应用，AppScan直接弹出一个远程命令执行的告警，Payload是OGNL表达式。我手动验证了一下，确实能执行whoami。这种已知框架漏洞的检测，AppScan的规则库更新还算及时，比自己去翻CVE列表快得多。

报告输出别直接甩给开发。AppScan默认的PDF报告有几十页，开发看一眼就扔了。我会把结果导出成CSV，按漏洞类型分组，每个类型挑一个代表性URL，附上请求响应截图，再写一句“修复建议：对参数id做整型强制转换”。这样开发改起来快，也不会觉得你在拿工具报告糊弄他。

最后说个细节。AppScan的扫描速度可以调，在“扫描配置-高级”里把线程数从默认的10改成30，能快不少。但别改太高，有些老服务器扛不住并发，直接503，反而拖慢整体进度。我一般设20，稳一点。

工具就是工具，它不会替你思考。扫出来的每一条都得自己过一遍，该忽略的忽略，该深挖的深挖。用久了你会发现，真正值钱的不是那几百个告警，而是你判断哪些告警值得看的那几秒钟。