充当（更安全的）服务

有几种现代应用架构和开发方法，基本上都采用“使其更小，从而更高效”的形式。

微服务和函数即服务 (FaaS) 都依赖于高度集中的代码的概念。 现在，虽然大多数组织并没有将应用分解为数百个微服务或数千个功能，但他们倾向于这种设计。 这通常是因为它促进了敏捷开发，因为相对较小的团队可以比大型单片应用更快地设计、开发和完善服务。 毕竟，编写和测试 1000 行代码比运行 100,000 行代码的大型应用要容易得多。

但是微服务和 FaaS 还有另一个有趣的好处，但并没有得到应有的重视：安全性。

互联网上有很多讨论 - 我也读过其中的很多 - 试图确定“行业平均”缺陷和漏洞密度。 您会发现各种各样的估计，其中一些基于对开源源代码的实际扫描，另一些则基于自我报告的数字。 例如，美国国家航空航天局 (NASA) 自豪地宣称其极低的缺陷密度是航天飞机计划成功的原因之一。 还有一些基于 WhiteHat 等安全公司客观收集的数据的报告，但其数字主要关注每个应用的漏洞，而不一定关注每行代码的漏洞。

除了同意存在缺陷和漏洞密度之外，并没有关于缺陷和漏洞密度的真正共识。

然而，按理说，编写的代码行越少，可能引入的缺陷和漏洞就越少。 同样重要的是，查找漏洞或缺陷所需要搜索的代码行越少，您找到它并修复它的速度就越快。

事实确实如此的原因之一是范围。 如果我的微服务或功能专注于编码业务逻辑的一个方面，则需要更少的逻辑和更少的库来实现。 范围越小，意味着在实现额外逻辑所需的库（第三方或其他）中引入逻辑错误或漏洞的可能性就越小。 每次您必须包含另一个组件或调用另一个服务时，就会引入缺陷和漏洞的机会。

更少的功能或微服务接口也有助于提高代码的安全性。 每个接口（像 API 调用这样的入口点）都可能引入漏洞，因为您正在处理用户输入。 众所周知，用户输入应始终被视为可疑和潜在恶意的。

如果微服务降低了出现漏洞和缺陷的可能性，那么进一步缩小功能范围应该会进一步降低这种可能性。

现在，这并不是说微服务和 FaaS 本质上比三层和单片系统更安全。 草率的代码就是草率的代码，无论它有多少行。 但事实上，这两种架构都适合于开发和交付实践，从而可以产生更安全的代码。

在评估或实施微服务和/或 FaaS 时牢记安全优势实际上可以帮助防止代码膨胀以及防止引入漏洞。