现代应用架构和开发有多种方法，其基本思路都是“缩小规模，从而提高效率”。
微服务和函数即服务（FaaS）都以高度聚焦的代码为基础。虽然大多数组织并未将应用拆分为数百个微服务或数千个函数，但都在逐渐采用这种设计。这通常是因为它有助于敏捷开发：相对较小的团队可以比开发大型单体应用更快地设计、开发并完善一项服务。毕竟，与多达100,000行代码的大型应用相比，编写和测试1,000行代码要容易得多。
但微服务和FaaS还有一个值得关注却未得到充分重视的优势：安全性。
网上有很多讨论试图确定缺陷和漏洞密度的“行业平均水平”，我也读过其中相当一部分。相关估算结果差异很大，有些基于对开源代码的实际扫描，有些则基于自行报告的数据。例如，NASA曾自豪地表示，其极低的缺陷密度是航天飞机计划取得成功的原因之一。此外，还有一些报告基于WhiteHat等安全公司客观收集的数据，但其数据侧重于每个应用的漏洞数，而不一定是每行代码的漏洞数。
对于缺陷和漏洞密度，业界并没有真正达成共识，唯一的共识是这种密度确实存在。
不过，按常理来说，编写的代码行数越少，引入的缺陷和漏洞可能就越少。同样重要的是，需要搜索的代码行数越少，发现漏洞或缺陷的速度就越快，而且可以认为，修复速度也会越快。
其中一个原因在于范围。如果微服务或函数专注于将业务逻辑的某个方面转化为代码，实现时所需的逻辑和库就会更少。范围缩小后，在实现额外逻辑所需的库（无论是第三方库还是其他库）中引入逻辑错误或漏洞的可能性也会降低。每增加一个组件或调用一项服务，都可能引入缺陷和漏洞。
减少函数或微服务的接口也有助于提高代码安全性。每个接口（例如API调用这样的入口点）都需要处理用户输入，因此可能引入漏洞。众所周知，用户输入始终应被视为可疑且可能具有恶意。
如果微服务可以降低出现漏洞和缺陷的可能性，那么将范围进一步缩小到单个函数，应该能进一步降低这种可能性。
当然，这并不是说微服务和FaaS本身就比三层架构和单体架构更安全。无论代码有多少行，草率编写的代码始终存在问题。但这两种架构确实更适合采用有助于提高代码安全性的开发和交付实践。
在评估或实施微服务和／或FaaS时，充分考虑其安全优势，确实有助于防止代码臃肿，并降低引入漏洞的风险。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。