DevSecOps中的技术债务仍然很重要吗？

尽管DevSecOps具有所有优势，但诸如技术债务之类的挑战仍然存在。在本文中，我来解释为什么这不是一件坏事。毕竟，确定问题是成功的一半。我还探讨了技术债务仍然存在的原因，如何使用技术债务，并探讨了开发人员的一些基本原则。

在继续之前，我应该先了解一下：我是技术债务的忠实拥护者。如果您在此之后仍在阅读，我将假定您与我在同一页面上，或者对想要学习更多的想法感到震惊，所以让我解释一下。首先：一个有罪的秘密。我喜欢技术债务。我的理由并不完全是无私的，但确实会成为我成为安全人员的一部分。技术债务将使我始终处于工作状态，使我可以投入一些有趣的项目，而且很多。但是，有比这更好的理由，那就是一旦确认了技术债务，我们至少会在某种程度上解决它。

因为，很明显，如果您的项目有技术债务（这是一个线索：他们都有），而且它是隐藏的，那么它就没有用了。比那更糟；它实际上会影响项目，因为您永远无法轻易知道自己所缺少的内容，但是可以解决。但是，如果可见，情况可能会发生变化，并且您可以改善问题-如果现在还没有，那么至少在将来。其原因归结为技术债务的定义。对我而言，技术债务有两种形式：有些事我们没做，但我们应该做的，还有我们本可以做出更好的决定。

如果我们知道自己没有做过的事情，那么我们以后可以在适当的时候再做。如果我们知道我们做出了次优的决定，那么我们可以进行更改。我们将在下面回到“适当的时候”。这一点很重要。

技术债务和DevSecOps

我们还应该明确地谈论DevSecOps，因为安全性通常是技术债务的一个隐藏主题。让我们定义DevSecOps：我对DevSecOps的首选理解是通过自动化，工具和文化变革将安全置于DevOps的实践，流程和交付的中心。

这是我多年来看到的一些与安全相关的技术债务的示例：

• 忽略对当前非公共API进行身份验证

• 集总能力

• 将角色硬编码为最初的期望，而不考虑未来的需求

• 将密码套件选择编译到应用程序中

所有这些都可以使用经典的开发方法或更敏捷的方法（例如DevSecOps）出现在项目中。实际上，我认为在许多情况下，采用经典开发方法的项目实际上比更敏捷或DevOps的项目更能补救技术债务。这是因为通常有一个定义明确的产品管理角色，可以收集各个发行版之间的客户需求，对其进行排名，并确定对“下一个发行版”进行优先级排序。在DevOps世界中，困难的功能（或困难的决定）容易陷入“局面”的底部。除非您合并请求，否则仅关注每冲刺功能会掩盖债务。如果您吞噬了“使用DevSecOps，安全是每个人的责任”的简单说法，那么这些问题将会更加复杂。

与更传统的方法一样，DevOps仍然保持安全性是复杂的，并且通常需要深入的知识。技术债务很容易产生，特别是如果您要让不是专家的人做出他们没有能力做的决定时。从上面举个例子：对安全最佳实践一无所知的人应该如何知道何时将密码套件编译到应用程序中以及何时不将密码套件编译到应用程序中？技术债务是一个安全问题，因为：

• 安全问题通常无法正常运行，因此不太可能被跟踪。

• 缺乏对安全性的深入了解，因为了解安全性影响的所有者，架构师和设计师人数很少。

• 安全性通常被保留到最后，因此很容易使它脱离TODO列表的底部。

因此，让我们更深入地研究为什么技术债务可以成为项目（尤其是开源项目）的资产。如上所述，在确认技术债务后，可以做出知情决定以补救该债务或暂时保留该债务。这就是上面“适当时”评论的重点：有时候，尽管这可能是不受欢迎的，但安全性还是仅次于可用性或特定的时间表。也许您的团队目前没有必要的专业知识或客户计划的知识，无法在此基础上做出明智的设计或实施决策。很好，但是您应该记录该决定以及作出该决定的原因，因为以后您可以重新访问它。而且，如果记录了此决定并且该项目是开源的。

案例研究

现在是时候进行技术债务如何帮助项目的案例研究了。让我们考虑一下特定接口上不包含加密。我们可以采取什么步骤来解决这个问题？首先是对其进行记录，因为这样它才能成为已知。我们至少应在四个地方进行记录：

1.在项目文档中，例如“我们用光了，现有的要求不包括证书管理。”

2.在产品文档中，例如“此API旨在在受保护的环境中使用，并且不应在公共Internet上公开。”

3.在源代码中，例如行内注释：

// 2018-05-02 (mbursell@redhat.com) Planned to use TLS 1.2 (check // for newer version) probably won’t need client // authentication. Don’t use ECC cipher suites. // Certificate management and revocation currently not specced.

4.在单元测试中，例如进行测试以查看数据是否以明文形式通过接口传输的测试，尽管该测试可能会失败。

这些有什么帮助？好的，项目文档可以创建更清晰的要求，产品文档可以让客户就如何安全地部署应用程序做出明智的决定，而源代码文档可以简化将来的实现。最后一个（单元测试）可能看起来很奇怪（谁想要一个在项目中失败的测试？）。但是，如果您确实要确保实现某项功能或某项功能，则项目仪表板上的红灯没有什么能让您诚实的。因此，现在我们已记录了已知且有用的技术债务。

基本上，我们想做的是避免怪罪（特别是当我们处于有可能成为接受者的危险中时）。好的文档应该使多个利益相关者受益，无论他们是建筑师，设计师，工程师，测试人员，运营，产品经理，项目所有者，销售和营销，支持还是客户。

做什么和避免什么

最后，您可以采取什么措施来鼓励暴露和记录技术债务的文化？这里有一些“要做”和一些“不要”。

做：

• 鼓励诚实。

• 记录一切。

• 记录“我突然想到……”的时刻。

• 在每次会议中都预留时间讨论技术债务。

• 考虑一个项目的“债务记录员”角色–可以在团队中轮流使用。

不做：

• 即使在事发后也要责备。

• 假设最好向客户隐藏技术债务。

• 因为尚未实现组件而推迟创建单元测试。