总结
在选择安全工具时，开发者体验（DevEx）至关重要。安全应该让开发者的工作更轻松，而不是更困难。如果开发者必须离开他们的编码环境或使用其他仪表板来发现问题，这会减慢他们的速度，并使他们不太可能使用这些工具。
要以“正确的方式”实施安全工具，必须将它们直接集成到本地开发者工作流程中，将安全从障碍变成无缝的护栏。
本指南解释了如何设置无摩擦的安全性。它涵盖了如何将工具放置在IDE、预提交钩子或CI/CD中，以及如何设置它们，以便您的团队能够更好地工作，而不是更慢。
1. “左移”现实：在开发者所在之处与他们相遇
减少摩擦的核心原则是上下文。必须在开发者仍然专注于他们刚刚编写的代码时提供安全反馈。我们按与代码创建时刻的距离对集成点进行分类。
A. IDE
在代码保存或提交之前，安全工具应该在本地运行。
- 工具类型：静态分析 (SAST) 代码检查器、依赖检查器、秘密扫描器。
- **实施：**为 VS Code、IntelliJ 或 Eclipse 安装插件
- **为什么有效：**这就像一个拼写检查器。就像文字处理器立即用红色下划线标记拼写错误一样，IDE 插件会立即突出显示不安全的代码（例如硬编码的秘密或不安全的函数）。
B. 拉取请求
反馈的最佳时间是开发人员提交代码进行审查时，因为他们已经专注于质量并愿意接受批评。
工具类型
深度 SAST，秘密扫描，以及基础设施即代码 (IaC) 扫描。
实施
配置您的工具以直接在拉取请求中的相关代码行上发布内联评论。这意味着安全工具会像人工审阅者一样直接在失败的特定代码行上发布评论。
为什么有效
它让开发人员在他们选择的平台（GitHub、GitLab、Azure DevOps）中工作。他们不需要离开页面就能看到错误、理解风险并推动修复。
2. 速度重要：阻塞与非阻塞扫描
缓慢的构建显著降低开发人员体验，并可能导致安全工具被绕过。如果您的安全扫描为流水线增加了20分钟，开发人员将积极尝试绕过它。您必须根据速度分开您的扫描策略。
A. 同步（阻塞）扫描
这些扫描在流水线内部运行，并可能导致构建失败。它们必须快速（在5-10分钟内）。
运行内容
秘密检测、代码检查器、轻量级SAST和策略检查。
规则
如果扫描快速且确定性强（低误报），则使其阻塞。这可以防止新的简单错误进入代码库。
B. 异步（非阻塞）扫描
这些扫描繁重、耗时或容易产生噪音。它们绝不应阻塞标准的拉取请求。
运行内容
深度DAST扫描、模糊测试或全面回归测试。
策略
在计划（例如，每晚）或专用的暂存环境中触发这些扫描。
反馈循环
不要中断构建。相反，将结果传输到漏洞管理系统或为团队创建Jira票据以供稍后分类。这在彻底性与速度之间取得平衡。
3. 从检测到一键修复的进步
最佳安全工具不仅能够识别问题，还能提供可操作的修复指导。为了减少摩擦，应优先选择那些降低解决问题认知负担的工具。
自动化拉取请求
对于依赖更新（SCA），使用像Plexicus ASPM这样的工具。该工具会自动打开一个包含库修补版本的PR，开发人员只需审核并合并即可。
建议修复
确保您的SAST工具提供“复制/粘贴”代码片段用于修复。如果开发人员看到SQL注入警告，工具应向他们展示确切的参数化查询代码以供替代使用。
自动修复
一些先进的平台如Plexicus ASPM可以在代码提交之前自动对IaC模板（如Terraform）应用格式或配置修复。
正确的方式 vs. 错误的方式
| 功能 | 错误方式（高摩擦） | 正确方式（无摩擦） |
|---|---|---|
| 反馈位置 | 单独的安全门户或电子邮件通知 | IDE插件和拉取请求评论 |
| 时机 | 24小时后（夜间扫描） | 即时（预提交/CI） |
| 扫描速度 | 构建阻塞超过20分钟 | 快速检查阻塞；慢速检查是异步的 |
| 补救措施 | “修复此漏洞”（通用） | “这是修复代码片段” |
| 开发者行动 | 上下文切换和调查 | 流程内纠正 |
常见问题解答（FAQ）
问：添加IDE插件会影响系统性能吗？
现代安全插件设计旨在最大限度地减少资源使用，通常仅扫描活动文件以减少性能影响。然而，最好配置它们仅扫描您正在处理的活动文件，而不是整个项目，以节省资源。
问：如果阻塞扫描发现误报怎么办？
您必须有一个“破玻璃”或“风险接受”流程。允许开发人员通过必填评论（例如，“这是测试数据，不是真正的秘密”）来暂时关闭或忽略警报。稍后审查这些忽略，但不要今天停止构建。
问：我们应该扫描每次提交吗？
理想情况下，是的，用于轻量级检查。对于较重的扫描，通常在创建拉取请求时进行扫描即可，节省了与扫描每个推送到分支的单独提交相比的计算资源。
