文章目录
-
- 背景：
- 解决方案
背景：
三方依赖安全风险管理与提升是我司推行的安全策之一略。交由测试部管理负责推进。
前天遇到的挑战是某后端部门排期出现问题，本应该做漏洞提升的时间被其他工作插入。时间有压力自然会想到变通之法。
团队有人A提出，是否有必要按照某软件报的漏洞信息实施安全提升工作。
特别是搬出来A之前在，其他企业的经验，即
1 报漏洞，不修漏洞
2 外部渗透爆出的特定风险才予以修复
以及进一步提出了安全升级工作的性价比多少
显然，这种说法是安全工作中的一个挑战。当时，测试部门相关领导就有点懵了。因为推动时间也蛮长了，做出了：只要升级一部分，易升级的组件即可。
基础团队的伙伴过来找，为什么特定组件不进行修复？基础的安全种子显然已经埋下。
在我了解了前因后果后做了进一步的分析：
我们的信息安全策略就是通过覆盖三防组件风险，降低我们产品自身的风险
开发团队消极应对的症结在于各子项目排期插入严重，只能诉诸于价值论
测试团队需要进一步支持，因为组件升级，许可证升级以及后续的编码安全建立都是一串蚂蚱
A前大厂的策略站不住脚
安全宣讲和必要的沟通是无法回避的
解决方案
- 针对项目排期问题：寻求项目同学提供支持
- 针对安全升级复杂度问题：了解到基础研发同学已做了预研，部分部门已推进完毕，将上述信息做了同步
- 针对升级方案推进者的疑惑进行答疑解答：推动者任务测试部门领导负责，需要为其提供行动的理论支撑。
- 针对升级方案被推进者：会议拉通，充分讨论，统一思想。
最终比较成功将该事件处理完毕。