视频资料
- 应用问题：直接依赖，间接依赖，间接依赖的间接依赖…（是一个调用链路图问题）
- 依赖自身可能是恶意的，譬如上面（污染某个恶意组件）
- 一般恶意包如何攻击？
- 写一个相似的名字（打错字）
- 包负责人直接更新出漏洞版本
- 同名恶意包…
- 包攻击并感染…
- 关于同名恶意包的解读；外部仓库搞一个和内部仓库同名的，然后通过引入，系统自动同步外部恶意包到企业内部仓库。
- 这个很好理解，就是”包负责人卖控制权“给黑客。
- 有的软件动态加载外网URL，然后外网URL被接管后，直接替换成恶意包执行。
- 依赖污染问题：如何实现攻击？
- 直接提交恶意的包，然后自动化CICD就部署到线上了。
- 奈飞的方法论：发现 -> 预警 -> 缓解。
- 建设漏洞库。
- 爬各种数据源
- 各种信息整合成Json，然后可以通过数据驱动决策（该不该升级）
- 整成API，可被调用。
- 静态正则解析pom.xml ,menifest文件是不够的。
- 预存储依赖索引（jar包）
- 预存储依赖索引（镜像-操作系统）
- 预存出依赖索引（AMI，类似K8S这种）
- 运营模式：输入GAV，告诉我那些镜像使用了它。
- 漏洞预警也需要分层干（不是所有都升级），分层方式：
- 严重优先（CVSS评分）
- 有攻击方法优先
- 重要应用优先
- 一种分层升级的方法
- 打分表案例 -> 多个维度决策要不要管。
- 关于升级：找到最小升级版本
- 找到最优先解决的依赖（升级依赖组件也需要顺序）
- 升级最小版本
- 计算模式（算法）
- 找到最优先升级的组件（尤其是依赖图时）
- 找到负责人信息，以及包在哪个Git地址。
- 风险缓解：Gradle。
- 风险缓解：Yarn
- 风险缓解：Npm
- 开始推升级后，可以看依赖有漏洞应用数会下降，分为Blacklist（卡发布）、Deprecation（提醒）等..
- 什么东西比较难？接下来还可以干？
- 除了看使用了某组件外，也看有没有使用恶意的方法与函数。
- 一种可行方案：用IAST /RASP方式，拦截恶意方法？
- 供应链安全 - 与IAST / RASP 联动。
- 用一个机器人来干，不用人工干
- 避免人工升级，然后发现系统挂了，回滚…
- 机器人能否自动测试，通过后，人工点确认升级？
- 如何向管理层解释干这个事儿的价值，如何衡量‘越来越好’？
- 看清楚我们一共用了多少开源组件？
- 看清楚我们通常修复开源漏洞，需要多长时间？
- 对整体修复时间分阶段分层，看时间主要消耗在哪里？（越来越快）
若有收获，就点个赞吧
0 人点赞
