漏洞修复:我们要意识到这不是我们推荐的修复方案，R&D和运维会按照它来进行。总会有
这样或那样的问题，使得无法修复正常的漏洞。比如系统太旧不能碰，或者使用的开源组件目
前没有漏洞修复补丁或者新版本，暂时无法修复漏洞或者放任自流；加固方案:如果漏洞无法正
常修复，应考虑加固，例如使用iptables限制端口访问。 长维修周期:对于一些购买的第三方系统，厂商的反应比较慢，反馈要等到两个月后版本升级。
除了加强之外，我们还应该考虑更深层次的问题，例如如何管理供应商以及如何促进发展合作
伙伴提高效率。补救方案:有时安全组提供的方案可能不符合实际环境，所以运维或R&D提供
自己的具体方案需要很长时间，漏洞管理系统和漏洞管理流程要支持提交补救方案的功能。 漏洞暂时搁置:如果某些漏洞可能暂时无法处理或需要延期，可以建立漏洞审查机制，对需要
修复但暂时无法处理的漏洞进行管理，形成预定任务，到期提醒，在此进行判断和通知。漏
洞复测:漏洞处置后，需要对漏洞进行复测，形成闭环。至于漏洞复测，这其实要追溯到第一
个环节，即漏洞检测。如果您已经实现了自动调用扫描器或HIDS等API接口进行扫描，那么
您只需要调用漏洞对应的API接口进行重新扫描并同步检测结果。如果是手工输入的渗透测
试漏洞，如果漏洞管理系统支持自定义漏洞检测插件，可以自定义，自定义后可以重用。如
果不能定制，只能进行人工复试。 在现实情况下，很难触发一些异常环境。知道如何触发取决于测试人员对“环境”的了解。因
此，在异常环境下测试软件安全性变得很困难。错误注入技术提供了一种模拟异常环境的方
法，而不必关心这些错误在实际中是如何发生的。
还没有评论，来说两句吧...