开始推行对上线中间件的卡点

公司F团队准备从老业务用的一个开源短链接服务直接迁移到现在团队使用的新业务中。
相关运维同事建议进行稳定性和安全风险评估，因而开始介入该环节。
经过基本的打探和初步试用。基本摸清了该组件的型号：

• 组件陈旧有公开缺陷漏洞
• 管理端有暴露公网
• 依赖有安全缺陷
• 维护风险
  其维护语言属于风险比较多，且这边使用者比较少的，无法对新缺陷，那很快做出应对

当然，该组件的新版解决了以上漏洞问题。只需要对登录微信进行彻底公网安全屏蔽，仅限内网使用即可得到缓解

加固方案沟通

Y加固在aab格式上兼容性存在问题，特定机型会崩溃，厂家是以修复引擎的方式进行更新解决。
我们这边的解决方案就是增加云测，但是国外的用车没有支持相关的自动化，需要进一步的开发。
开发相关同学建议更换加固产品，但这并不能解决根本问题，即：无法验证兼容性的问题。
所以，归根结底还是应该实现云测自动化作为评估方法。
提前发现兼容性问题，已提交给厂商进行修复。
当然，我这里还认为这种TOP1000这种兼容性测试应该由加固厂家进行，而不是让每个客户自己去测试。
此外，还有一个挑战就是当安卓更新新版本的时候，我们需要follow这样才能保证我们的APP产品可以在新版google中兼容性最佳。
用车厂商如果能够推出新版OS或新机型过滤，就是最好了。