完整规则
任务说明
依赖包越来越多,我担心高危漏洞和许可证问题被拖到发布前才发现。我希望建立一套低成本持续检查方法,并让接单者根据真实升级经验区分“必须马上处理”和“可以观察”。 请从失败场景倒推方案 先完成经验复盘:请用5个真实依赖处置案例说明风险排序,包括无法立刻升级、升级破坏兼容和许可证判断不清时的处理经验。 再根据这些失败反推一套可执行设计: - 生成包含组件、版本和来源的软件物料清单。 - 扫描公开漏洞并按可利用性和影响排序。 - 识别许可证及可能与产品分发方式冲突的项目。 - 制定升级、替换、暂缓和持续监测的处理台账。 交付物为SBOM示例、风险台账和升级流程。成果中应把“正常路径、早期异常信号、定位顺序、恢复动作”放在同一个视图里。 执行约束 官方页面只用于核对现行规则和时间点;主体内容必须是接单者的实操判断、案例复盘和取舍建议。每条规则注明来源与查询日期,每条经验注明“亲历 / 协助办理 / 公开案例复盘 / 专业判断”之一。 通过条件 1. 依赖版本和来源可追溯。 2. 高危漏洞有处置时限。 3. 许可证冲突有人工复核标记。 4. 不能只有最佳实践,必须展示失败如何发生以及方案如何防住它。 范围限制:不重复代码lint或具体商标软著任务。