不要让别人的技术债务让您失望-CSDN博客

关于技术债务的文章很多：什么是技术债务以及不同类型的技术债务；在设计，编码和更改代码时如何避免不必要地承担债务；多少技术债务使您的组织付出了代价；以及为什么以及如何以及如何多少和何时支付这些债务了。

但是，所有这些都忽略了系统中的大量技术债务和风险，这些风险和风险与您的开发人员在设计或草率的编码实践上捷径或不编写单元测试无关。尚不清楚的是，在您未编写的所有代码中，与所编写的代码相比，技术债务可能更多。

就像西班牙，希腊和葡萄牙的金融债务问题正在拖累全球经济一样，即使您一直在自己负责地管理债务，其他人软件中的债务问题也可能使您陷入困境。码。

Oracle，IBM或Microsoft的软件中的问题，或者开发人员不断从Internet下载的所有漂亮的免费开源软件，都成为您的问题。如果您正在使用其他人的软件（并且我们都在这样做），则必须为其他人的错误和疏忽，他们为使交付时间超过稳定性或安全性而做出的决策付出代价。您受制于它们的开发，测试和安全程序-或缺乏这些。而您则受制于他们使用的第三方和开放源代码，以及编写该软件的人员。

他们的错误变成了您的错误。他们的安全漏洞成为您的安全漏洞。他们的错误决定变成您的错误决定。

涉及的代码量和债务量可能非常庞大，比您自己编写的代码大得多。根据Sonatype的研究，典型的Java应用程序的80％是由开源组件和框架组装而成的，一个大型系统可以包含多达30个或更多的不同库或其他组件。

但是，您承担的第三方债务比框架，库和控件更大。系统还依赖于所有其他软件：操作系统，虚拟机和其余的运行时堆栈，容器，缓存技术和数据存储，以及部署和部署所需的所有工具。运行系统。

Gartner估计，2010年，全球“ IT债务”的总数（使所有该软件都处于最新状态并得到每个组织的完全支持）的成本约为5000亿美元，到2015年可能达到1万亿美元。

我们一直都在承担更多的债务。 Aspect Security研究了超过1.13亿个开源软件下载，发现超过1/3的下载的开源库具有已知漏洞。

我们面临的其他人的软件问题足够严重，也很普遍，OWASP现在明确要求组织将过时的软件组件用作十大软件安全风险之一：

实际上，每个应用程序都存在这些问题，因为大多数开发团队并不专注于确保其组件/库是最新的。 在许多情况下，开发人员甚至都不知道他们正在使用的所有组件，也不在乎其版本。 组件依赖性使情况更糟……

您还承担多少其他人的债务？

这种技术债务比您自己的代码中的债务更难理解和管理。因为它是您不理解的代码，所以您无法查看它们以了解它的严重程度，或者您可以查看但没有看到的代码。通常是您无法控制的代码，尤其是跨多个系统共享的通用平台技术，每个人都使用但没人负责的技术。它甚至可能是您根本不知道自己拥有的代码-已被某人下载并已成为系统的一部分而又没有其他人知道的代码。

为了弄清楚这个债务问题可能有多严重，您需要审核第三方和开源软件包以及相关性的代码。大公司可以（并且可能需要）使用Black Duck或Palamida或OpenLogic之类的工具来扫描并建立开放源代码以及其他库和组件的清单，以检查许可问题并及时了解此软件中所报告的漏洞。

较小的公司可以手动执行此操作，或者尝试使用WhiteSource ，这是一个SaaS扫描平台，对初创公司和小型公司免费，并且为许可证发现提供了免费的源代码扫描程序JNinka ；或签出OWASP Dependency Track Project （ OWASP依赖项跟踪项目）（一个开源项目，用于跟踪仍处于早期预发布状态的第三方软件）。

坚持下去以减少债务

了解了您必须担心的其他人的软件后，您有责任评估已继承的风险和问题，并紧跟漏洞和错误报告以及供应商补丁和升级。这比听起来要难。

正如OWASP解释的那样：

从理论上讲，应该很容易弄清楚您当前是否正在使用任何易受攻击的组件或库。 不幸的是，漏洞报告并不总是以标准的可搜索方式确切指定组件的哪些版本容易受到攻击。 此外，并非所有库都使用可理解的版本编号系统。 最糟糕的是，尽管CVE和NVD之类的网站变得越来越容易搜索，但并非所有漏洞都报告给易于搜索的中央信息交换所。

要确定您是否容易受到攻击，需要搜索这些数据库，并与项目邮件列表和公告保持同步，以查找可能存在漏洞的任何内容。如果您的组件中确实有一个漏洞，则应检查代码是否使用了带有漏洞的组件的一部分，以及该缺陷是否会引起您所关注的影响，从而仔细评估您是否确实存在漏洞。

也有一些通用服务可以提供帮助。诸如SANS @Risk或SecurityFocus漏洞摘要之类的合并的安全漏洞摘要经常提供有关常见软件包中安全漏洞的通知。 FS-ISAC和IT-ISAC等行业特定的信息共享和分析中心可为成员提供有关常见第三方和开源软件问题的通知。

修补以及修补和升级

知道问题有多严重是一回事。解决它是另一回事。

修补最新的dot版本是我们所有人都难以忍受的麻烦。即使补丁并不总是适用于您的软件使用方式，也要比对补丁外部技术感到遗憾要安全得多，这些补丁包括：Apache，Tomcat，Web服务库，客户端组件。后端代码可以（通常必须）进行更保守的管理。如果确实真的必须尽快安装每个Linux或Oracle RDBMS补丁，那么您的体系结构可能存在问题。

升级是一个更大的问题。通常没有什么好处，但是升级到最新的主要OS或DBMS版本或VM或其他关键软件会涉及很多成本和风险。这是您要进行的工作，因为您被供应商扣为人质 –因为要获得支持，唯一的方法就是升级到他们的最新，最强大的版本。

尽管您可能会在可伸缩性，可管理性或一项或多项功能中获得一些优势，但是升级项目通常更多地是在管理潜在的缺点：功能回归，兼容性问题，操作过程的更改以及对其他系统的依赖。大多数软件都会变大，而不是变好–更多功能，即使它们是您不需要或不想要的功能，仍然意味着在升级时需要进行更多的安装，配置和测试工作。您需要检查所有已更改的内容，然后重新进行所有测试和调整，重新查找和检查旧的变通办法，并为不需要的新问题或改进找到新的变通办法，并更新文档，脚本和过程。而且您必须执行的测试是最糟糕的测试：手动系统测试，操作测试和压力测试，这很昂贵，同时又使您对找到所有问题的信心不足。每个人都需要参与其中：开发，QA，Ops和其他共享依赖项的团队。

因此，在完成所有这些工作和成本之后，您仍然需要准备好应对生产中的问题。而且您还没有实现任何明确的业务价值。您已承担短期运营成本和风险，以便将来将其他运营成本和风险降至最低。充其量是最低的投资回报率。

开源–成为懒惰的客户，加入社区或分叉它

几乎每个人都在开发中使用开放源代码软件- 太令人信服了。

但是大多数组织在管理此软件方面做得很糟糕：

经理Sonatype进行的年度开源软件开发调查显示，虽然将近80％的公司依靠开源组件来进行开发，但四分之三以上的公司对此类库和框架的使用缺乏任何有意义的控制。大型开源组件存储库。

另一家供应商WhiteSource Software发现，所有软件项目中有85％包含过时的开源组件。

您有责任了解自己面临的风险，并在选择和使用开放源代码软件时将其最小化。这意味着要进行一些侦探工作，以确保项目处于活动状态并查看其是否存活，定期监视签到和论坛活动，当心作者消失或改变方向，让人们分道扬separate 。

Black Duck的Ohloh数据库是一个开始的地方：一个公共目录，其中包含有关数千个开源项目的信息，包括代码库的大小，社区的大小，最新提交和许可信息。或有Freecode （以前称为Freshmeat），可获取有关Linux，Unix和跨平台软件和移动应用程序的信息，尽管这些目录并不总是完整的或最新的。

另一个有用的信息来源是Coverity维护的数据库，该数据库通过扫描开源项目中的安全性和质量问题来发现错误。

对于您决定使用的每个开源软件

您可以成为用户，利用免费软件，并希望社区能够为您保持项目的活力。
您可以扮演积极的角色，向社区贡献修复和改进，并查看接受哪些更改。如果他们不接受您的更改，那么您将不得不担心将其与社区将来所做的任何更新保持一致。
如果该软件对您足够重要（并且如果许可允许），则可以选择分叉并自己提供支持。即使您似乎拥有内部必要的技术技能，这也不是琐碎的承诺。许多开源软件都是高度专业的，需要高度专业的技能和知识，这就是为什么值得首先使用的原因。即使是经验丰富的聪明开发人员也需要花费大量时间来解决它，以进行扩展和修复，现在，您必须长期承担这一责任和这些成本。