DevSecOps：如果开发已经在进行中，从哪里开始

“我们需要 DevSecOps”这句话通常意味着“我们需要扫描仪”。他们会购买一台扫描仪，它会发现四千条评论，开发人员会忽略它们，六个月后该项目将因失败而关闭。错误不在工具中： 在与之前相同的位置寻找缺陷 - 最后，只是更快。

DevSecOps 的实际意义是相同的：检查是在其结果应用起来仍然便宜的时候执行的。提交中发现的秘密是三十秒的工作。在产品中发现了同样的秘密 - 密钥轮换、访问分析和与客户的解释。区别不在于搜索的质量，而在于搜索的时刻。

如果开发已经在进行中，您无法立即引入所有内容 - 传送带将停止。事实证明，以下顺序可以确保每个步骤在下一个步骤开始之前产生可测量的结果。

步骤 1. 库存（1-2 周）

存储库、管道、环境和退出点的列表。谁是所有者，什么部署在哪里，开放哪些外部地址。如果没有这张地图，任何自动化都会覆盖一个随机子集。周边外侧部分方便拆卸 外部资产审计 — 被遗忘的阵地经常出现战斗数据。

第 2 步：秘密（2-3 周）

最快的胜利。立即在所有存储库上启用秘密搜索，在单独的运行中扫描历史记录，轮换找到的密钥，并将存储移动到秘密管理器。在这里，我们还把事情整理在传送带本身的账户中：装配代理商几乎总是拥有过多的权利 - 一个话题 IDM/PAM 和访问控制.

步骤 3. 交付内容（3-4 周）

SCA 和 SBOM：您开始了解产品是由什么制成的。这同时也是安全性、许可纯度和进口替代的基础——没有供应的构成，谈论技术独立是没有意义的（进口替代和技术独立).

步骤 4. 代码分析和动态（1-2 个月）

SAST 在“仅新缺陷”模式下启用，DAST 在测试环境上启用。阻止构建和 SLA 进行更正的规则也显示在此处。手动分析和 渗透测试 它们是最后连接的：当自动化已经消除了噪音时，它们既昂贵又有意义。

失败的主要原因是无法处理的发现流。工作技术：

• Baseline. 第一次运行中发现的所有内容都被记录为已知债务并且不会被冻结。仅阻止新的缺陷，即先前版本中不存在的缺陷。否则，团队会在第一天得到一个旋塞。
• 阈值基于重要性，而不是数量。 “评论不得超过10条”是一条毫无意义的规则。 “修改后的代码中没有新的严重漏洞”-可执行。
• SLA 用于纠正而不是立即阻止。 严重 - 3 天，高 - 14 天，中等 - 在计划的发布中。延误是升级而不是停止管道。
• 一个追踪器。 安全缺陷与其他开发任务存在于同一位置。除了维护它的人之外，没有人会读取单独的“漏洞登记册”。
• 处理误报。 团队应该有一种简单的方法来将发现标记为不适用并有理由，并且应该在运行之间维持该决定。如果没有这一点，人们将在两周内失去对该工具的信心。
• 球队的安全，而不是高于球队。 开发团队中的安全冠军可以当场解决 80% 的问题。

• GOST R 56939 “开发安全软件”设定了流程框架：安全需求分析、威胁建模、静态分析、测试、配置管理。对于许多客户来说，遵守此标准是接受的条件。
• 重要的 CII 对象。 如果软件在重要设施内运行，则 187-FZ 下的要求将添加到开发过程中 - 请参阅。 「KII/187-FZ 的保护」.
• 俄罗斯软件注册。 要启用它，您需要确认供应和依赖性控制 - SBOM 在步骤 3 中提供的内容。
• 测试环境中的个人数据。 看台上的战斗基地副本是典型的、严重违反152-FZ的行为。正在决定中 掩饰和人格解体，而不是禁止测试。

第 1-30 天

• 已编制了一份包含所有者的存储库、管道和环境的登记册。
• 在所有存储库上都启用了秘密搜索，并且已扫描历史记录。
• 找到的密钥被轮换，存储转移到秘密管理器。
• 集会代理人的权利已被修改和限制。

第 31-60 天

• SCA 在每个构建上运行，SBOM 保存为发布工件。
• 确定关键性阻塞阈值并记录基线。
• 安全缺陷包含在通用开发跟踪器中。
• 修复 SLA 和升级程序已达成一致。

第 61–90 天

• SAST 在关键存储库上以“仅新缺陷”模式启用。
• 容器扫描和基础设施清单检查内置于管道中。
• DAST 至少在外部服务的测试环境上工作。
• 安全冠军已经任命，第一份指标摘要也已收集。