BERND KUHLEN所有笔记 ↗安全工作通常被描述为一扇大门：首先进行开发，然后有人检查结果。我本月的主要教训是，安全开发以循环方式效果更好。小型自动检查是在系统发生变化时进行的，发现的背景信息足以让人理解，补救措施成为普通工程的一部分，而不是特殊的清理项目。
我一直在关注这个循环的两个实际部分：安全警报和GitHub Dependabot警报。两者都不是新的，也不是一个完整的安全程序。但是，它们共同在早期暴露了两种常见的风险类别：代码和配置中的不安全模式，以及第三方依赖项中的已知漏洞。
只有当安全工具的发现可以被理解、确定优先顺序并据此采取行动时，才能创造价值。
安全提示是可执行的指导
一个好的安全检查器不仅仅是一个语法检查器。它将商定的工程规则转化为可重复的反馈。视项目而定，这可能包括检测嵌入式机密、不安全的外壳结构、薄弱的加密选择、过于宽泛的权限、不安全的基础设施默认设置或可疑的数据处理。
优势在于时机。与部署后发现的相同问题相比，在更改仍然很小时显示的警告更易于理解和修复。开发人员仍然记得这句话存在的原因，审查仍然是重点的，需要重新考虑的周围代码也较少。
但是，更多的规则并不能自动产生更高的安全性。一套嘈杂的规则会训练人们忽略输出。我发现从高信度检查开始，记录它们为何重要，只有在团队能够区分真正的弱点和无关的模式时才进行扩展，这样会更有用。
Dependabot 是收件箱，不是自动驾驶仪
Dependabot 警报提供了有价值的信息：依赖项受到已发布公告的影响，易受攻击的版本范围已知，并且可能存在升级路径。危险的解释是，每个警报都应立即触发盲版本升级。
每个警报都需要上下文：
- 易受攻击的组件是存在于生产中还是仅存在于开发工具中？
- 应用程序是否使用受影响的代码路径？
- 包裹是直接控制还是通过传递方式拉入？
- 建议的版本是否会引入破坏行为？
- 补偿控制已经减少了曝光吗？
严重性是一个起点，而不是完整的优先级。在无法访问的构建时组件中发布关键公告之前，可能需要注意暴露的请求路径上存在的中等严重性问题。该决定应将咨询、实际架构和安全更新的成本相结合。
锁定文件是安全边界的一部分
当包名称出现在清单中时，依赖关系管理尚未完成。解析后的依赖树很重要。Lockfiles使版本具有可重现性，显示实际安装的版本，并为自动扫描仪提供具体的图表以供评估。
这就引出了一个简单但重要的规则：同时更新清单和锁定文件，审查意外的传递性更改，运行完整的测试和质量套件，并避免合并没有人检查过的生成的依赖关系更改。自动化可以为变更做好准备；所有权仍属于接受变更的工程师。
质量之门需要摆脱虚假的信心
自动门之所以具有吸引力，是因为它们能给出明确的答案：通过或失败。这种清晰度很有用，但也会造成虚假的信心。扫描仪通过意味着其配置的规则未在其检查的材料中发现匹配的问题。这并不意味着设计是安全的。
对于本网站，自动门禁在部署之前会检查 JavaScript 语法、内部链接、引用资产、JSON 结构、重复 ID、共享指标和其他一致性规则。以安全为重点的检查自然可以放在旁边，但是架构仍然需要人为的问题：这个端点是否必要？浏览器需要这些数据吗？操作能否保持静态？最小的 IAM 权限是多少？如果计划流程失败会发生什么？
最有力的结果来自于将确定性自动化与深思熟虑的审查相结合。
优先级应清晰可见
警报数量的增加不是补救策略。当调查结果的状态和推理清晰可见时，调查结果就变得可控了。轻量级的工作流程就足够了：
- 验证 该发现适用于当前的代码和已部署的架构。
- 分类 曝光度、影响力和可利用性，而不是依赖一个分数。
- 决定 是更新、缓解、删除、暂时接受还是进一步调查。
- 记录 原因、所有者和预期的审查点。
- 验证 进行测试并在更改后进行第二次扫描。
这使得异常可以审查。抑制误报可能是合法的；默默地隐藏误报是不合法的。区别在于未来的维护者可能会质疑的解释。
安全默认值比重复提醒便宜
反复发现的最有用的结果之一不是另一次封闭式警报，而是更好的默认警报。如果重复出现相同的不安全配置，则持久的修复方法可能是模板、共享工作流程、可重用策略或自动选择首选的项目脚手架。
这一原则也塑造了投资组合。公共网站保持静态。S3 在 CloudFront 之后是私有的浏览器代码接收公共聚合数据，而不是原始操作记录。计划函数的写入目标很窄。这些架构默认设置在开始整理之前就消除了所有类别的应用程序风险。
我要讲五节课
快速反馈会改变行为。 开发期间的精确警告比几周后的长报告更有用。
噪音是一个安全问题。 低质量的警报会消耗注意力，而这些注意力本应花在有意义的发现上。
自动化提议；工程师决定。 依赖项更新仍然需要架构背景、测试和审查。
通行证是证据，不是证据。 工具涵盖已知模式；威胁建模和设计审查涵盖意图和系统边界。
最好的补救措施可以改善下一次变更的路径。 模板、策略和安全默认值比反复更正同样的错误要好。
接下来我想改进的地方
我的下一次迭代是让反馈回路一目了然地易于理解：将紧急风险与日常维护区分开来，将异常推理与调查结果接近，并衡量可操作的警报从检测到经过验证的补救的速度。
我还想更清楚地将这些检查与它们保护的架构联系起来。依赖性警报、IAM 政策调查结果和公共数据决策可能来自不同的工具，但它们都描述了同一个系统中的信任边界。
最后的外卖
安全开发不是通过添加一台扫描仪或启用一个警报源来实现的。当有用的信号提早到达，决策包括上下文时，它就会出现，正常的交付过程使安全路径易于理解和可重复。
这就是我正在尝试建立的例程：自动化程度足以保持一致，足够安静，值得信任，足够人性化，可以在工具无法做到时做出合理的决策。