应用程序安全：从业者指南

表 1：开发人员和安全分析师对安全的不同看法

实质上

• 开发人员专注于从头开始安全地构建应用程序，将安全性视为他们需要在代码中实施的一系列最佳实践和要求。
• 安全分析师的工作重点是通过测试应用程序的防御系统、找出薄弱环节并提供专业的修复指导，确保应用程序的安全。

虽然他们的视角和侧重点不同，但这两种角色都是构建和维护安全应用程序所必需的。应用程序安全需要开发人员和安全分析人员在整个软件开发生命周期中进行协作和沟通。

安全开发人员实用指南

只有将安全嵌入设计中，而不是在部署后才贴上安全标签，才能取得成功。OWASP 2024 年十大主动控制措施为希望构建经得起审查的软件的开发人员提供了一个实用框架。每项控制措施都反映了从实际事件中吸取的惨痛教训，并将这些教训转化为开发人员在构建过程中可以采用的指导。对于正在应对云原生复杂性的团队来说，这些控制措施提供了一个蓝图，可以以一种可持续和相关的方式转移安全左翼。

实施访问控制

访问控制定义的是用户和服务可以做什么，而不仅仅是他们是谁。大多数数据泄露事件都不涉及证书泄露。相反，它们利用了过于宽泛的权限。粒度很重要。

• 明确定义角色、权限和范围。
• 避免使用隐藏在用户界面逻辑或客户端执行背后的 "软 "访问控制。
• 在微服务架构中，通过集中式身份提供商执行策略，然后在服务级别应用细粒度控制。
• 使用允许列表，而不是拒绝列表，并保持服务器端逻辑。
• 权限应可测试、可追溯、可审计。

正确使用密码学

密码学的失败更多是由于误用，而非算法失灵。

• 不要编写自定义密码。
• 不要手卷加密。
• 使用维护良好的库，这些库应经过审核并与您的语言相通。
• 了解何时使用对称加密，何时使用非对称密钥，以及为什么散列不是加密。
• 在云原生系统中，使用 AWS KMS 或 HashiCorp Vault 等托管服务保护机密。
• 传输层安全并非可有可无。
• 始终验证证书。
• 了解静态加密与传输中加密的影响，将密钥轮换作为常规操作任务，而不是危机应对措施。

验证所有输入并处理异常

从用户字段到应用程序接口调用，您的应用程序采集的所有内容都需要验证。无论是来自用户、第三方应用程序接口还是内部服务的数据，都要进行严格的验证，包括类型、格式、长度和字符限制。输入验证不是一种表面上的防御。它决定了下游组件的行为方式。

• 验证类型、格式、长度和字符限制。
• 要格外注意反序列化、XML 解析器和文件上传。
• 集中异常处理，避免堆栈跟踪泄漏。
• 抑制详细错误--向用户发送通用回复，但在内部记录完整的上下文。
• 在云原生系统中，在不暴露内部逻辑或基础设施的情况下，可预测地降低服务质量。

从一开始就解决安全问题

担保债务会迅速累积。将安全性作为设计要求，而不是事后审查项目。早在规划阶段就确定资产、威胁模型和信任边界。了解用户数据如何在应用程序中流动、存储在哪里以及谁可以访问这些数据。

• 在您的积压工作和冲刺计划中添加特定于安全的故事，而不是单独的清单。
• 对每个新服务或组件进行早期威胁建模。
• 跨角色协作--让架构师和开发人员与安全倡导者结成对子。
• 对于云原生构建来说，这意味着在第一个容器装船之前，就要考虑到IAM策略、公共暴露以及第三方服务的默认行为。

默认安全配置

默认设置会泄露您的身份。许多安全故障都源于错误配置的服务--未关闭的管理面板、启用的调试标志、放任的 CORS 策略或大范围开放的存储桶。

• 在代码和基础设施中加固默认设置。
• 关闭不需要的功能。
• 要求使用强密码、启用MFA、禁用不安全协议，并在整个协议栈中强制执行最低权限。
• 在 Kubernetes 环境中，限制 pod 权限、定义网络策略并配置生命周期较短的机密。
• 定期审核配置，并将基线执行自动化作为 CI/CD 管道的一部分。

确保组件安全

第三方代码扩展了功能和攻击面。像对待自己的代码一样认真对待开源依赖项。

• 维护所有正在使用的软件包、库和容器的清单。
• 使用检测漏洞和许可证问题的工具。
• 在可能的情况下，让您的依赖关系图保持浅层。
• 当无法打补丁时，可通过容器化或服务边界隔离高风险组件。
• 监控申报版本与实际生产运行版本之间的偏移。
• 不要只是扫描和遗忘--跟踪补救直至解决问题。

实施数字身份

身份是每项信任决策的基础。定义清晰、一致的认证机制。

• 在适当的地方使用联合身份--OIDC、SAML 或 OAuth2--但要了解每种协议能提供什么，不能提供什么。
• 使用自适应哈希函数（如 bcrypt 或 Argon2）存储密码。
• 代币管理很重要。
• 正确签署和验证 JWT，设置过期声明，并避免在其中包含敏感数据。
• 在分布式环境中，发行短期令牌并定期轮换凭证。
• 将人和机器的身份映射到明确的角色上，并利用自动化工具实施身份卫生管理。

使用浏览器安全功能

现代浏览器提供了强大的防御功能--如果开发人员能够启用这些功能的话。

• 使用内容安全策略 (CSP) 限制可执行的脚本、样式和资源。
• 启用第三方资产的子资源完整性（SRI）。
• 设置 HTTP 标头，如 X-Content-Type-Options、X-Frame-Options 和 Referrer-Policy。
• 首选安全 cookie，并正确设置 HttpOnly、Secure 和 SameSite 标志。
• 不要依赖客户来执行任何关键的事情。
• 在单页面应用程序中，要格外小心地处理会话存储、令牌撤销和错误消息传递，以避免用户之间泄漏状态。

实施安全日志记录和监控

您无法为您看不到的东西辩护。捕捉有意义的事件，并将其发送到支持分析和检测的中央系统。

• 记录与安全相关的事件--登录失败、权限升级、访问敏感资源。
• 日志格式应结构化、可搜索，并与跟踪标识符相关联。
• 在云原生环境中，将日志、指标和痕迹发送到一个通用平台，以便重建安全事件。
• 避免记录秘密、令牌或 PII。
• 不仅要监控警报，还要监控模式：突发请求、横向移动或意外出现的新服务。
• 记录不仅仅是为了 IR，它还是检测工程的核心输入。

阻止服务器端请求伪造 (SSRF)

SSRF 攻击会操纵服务器发出意外的 HTTP 请求，通常是向内部服务发出请求。在云原生环境中，SSRF 可以穿透防火墙到达元数据端点，从而暴露凭证或内部配置。

• 不要相信用户提供的 URL。
• 明确验证目标主机，避免开放重定向，并阻止向包含内部基础设施的 IP 范围发出请求。
• 尽可能使用允许列表和 DNS 引脚。
• 对工作负载进行分段，即使是被入侵的组件也无法在未经身份验证和授权的情况下访问关键服务。
• 在容器化系统中，配置网络策略以限制出口路径。

像这样的安全控制并不要求完美。它们要求遵守纪律、了解背景并不断改进。每一个精心实施的方案都能让您的团队更接近于通过设计实现自我保护的软件。

应用程序安全测试的类型

应用程序安全包含一系列策略和工具，旨在减少软件从开发到生产的攻击面。实际上，安全并不是一份清单。这是一门嵌入 SDLC 的持续性学科，您所选择的工具应反映您的环境架构、速度和威胁暴露程度。以下每个类别都有助于实现整体防御，但要在云原生环境中有效实施，还需要细致入微的了解。

针对 SDLC 的渗透测试

渗透测试模拟真实世界中的攻击，揭示应用程序在敌对条件下可能出现的故障。这就需要一个熟练的人工操作员--既能像攻击者一样思考，又了解系统内部运作的人。在云原生环境中，渗透测试的范围不仅限于代码库，还包括身份配置错误、权限过大、CI/CD 管道中暴露的机密以及托管服务的不当使用。

时机很重要。在开发后期或主要版本发布前进行五项测试，可以发现自动化工具所忽略的潜在架构缺陷。但不要把它当作一个复选框。在基础设施发展的同时，尽早整合和反复改进最有价值。

动态应用安全测试 (DAST)

DAST 在运行时进行操作。它由外向内探测运行中的应用程序，分析其在敌意输入下的表现。由于不需要访问代码，DAST 可以有效防止错误配置、身份验证失效和可利用的业务逻辑。但是，传统的 DAST 难以应对现代的微服务和应用程序接口。

在云原生生态系统中，开发人员需要能够在容器化环境和协调系统中进行测试的工具--这些工具能够理解短暂服务，并与部署一起扩展。如果调整得当，DAST 可以在并入生产前充当回归门，捕捉静态工具无法推断的实际问题。

静态应用程序安全测试 (SAST)

SAST 会审查应用程序的源代码、字节码或二进制文件，查找已知的不安全行为模式。它的优势在于精确，尤其是在分析自定义代码时。它可以发现运行时工具可能永远无法发现的深层逻辑缺陷、不安全的 API 使用和竞赛条件。但它需要调整。如果不进行智能过滤，SAST 就会产生开发人员学会忽略的噪音。在云原生转变过程中，SAST 工具必须支持现代语言和框架、CI/CD 集成和版本控制基线。当静态分析与上下文信号（如代码的哪些部分处理机密或用户输入）配对时，它就会变得尤为强大，这样它就能根据实际风险对分析结果进行优先排序。

交互式应用程序安全测试 (IAST)

IAST 位于 SAST 和 DAST 之间。它通常在功能测试期间，在应用程序运行时从内部对其进行分析。通过检测代码库，IAST 可以观察输入是如何流经应用程序的，并将行为与代码层面的理解联系起来。与单独的静态或动态工具相比，它擅长实时识别漏洞并标记可利用的路径，误报率更低。对于采用 DevSecOps 的团队来说，IAST 提供了一条获得持续反馈的途径--将测试套件转化为安全审计。在云原生架构中，IAST 可以跨服务追踪漏洞，检测容器中不安全的库，并在 API 意外相互对话时显示可利用的逻辑。

应用程序接口模糊测试

模糊测试将畸形、意外或随机数据输入应用程序接口，以发现稳定性和安全性问题。与脚本测试不同，模糊器会发现您意想不到的行为。它们会发现触发异常、服务崩溃或泄漏敏感信息的边缘情况。在现代应用堆栈中，应用程序接口既是内部边界，也是外部接口，因此模糊测试变得至关重要。经过精心调试的模糊器以 OpenAPI 或 gRPC 定义等 API 规范为目标，边探索边学习，根据之前运行的反馈动态更改输入。将应用程序接口视为产品的团队必须优先考虑管道中的模糊测试，尤其是在向合作伙伴或公众公开新端点之前。

应用安全态势管理 (ASPM)

ASPM 不仅仅是一种工具。这是一种心态的转变。它侧重于所有安全发现的可见性、相关性和可操作性。当企业采用数十种工具（每种工具都会暴露出从代码到运行时的漏洞）时，ASPM 提供了连接组织。ASPM 用于统一和操作整个软件生命周期的安全性。

现代应用环境会从各个方向产生信号--SAST、DAST、SBOM、运行时遥测、身份配置错误--而这些信号往往是零散的、重复的，或者与业务优先级不一致。ASPM 可接收发现，将其映射到实际的应用架构，并将其与所有权、暴露和潜在影响相关联。其结果不仅仅是一份漏洞列表，而是一份优先级视图，显示了现在什么最重要、对谁重要以及为什么重要。

安全测试概览

表 2：应用程序安全测试方法比较

应用安全工具和解决方案

安全测试发现缺陷。它揭示了应用程序如何在敌对条件下被破解，以及攻击者可以在哪些方面获得优势。但仅靠测试并不能确保系统安全。保护需要的不仅仅是检测。这就需要一种工具，它能让您了解您正在运行什么，控制它是如何构建的，以及它是如何暴露的。

在云原生架构中，环境每小时都在发生变化，因此安全工具不仅需要扩展，还必须跨层综合上下文。仅靠扫描仪是无法发现易受攻击的组件的。综合平台可以。

Web 应用防火墙 (WAF)

WAF 可监控和过滤互联网与应用程序之间的 HTTP 流量。它能查找恶意模式--SQL 注入尝试、跨站脚本有效载荷、违反协议--并在它们到达您的后台之前将其拦截。WAF 可以争取时间。它们可以钝化机会性攻击。但它们并不能解决根本问题。在云原生设置中，WAF 需要跨多个入口点运行，并支持 gRPC、WebSockets 和API 网关等现代应用模式。依赖 WAF 作为主要防御手段，意味着团队发现漏洞时为时已晚。

漏洞管理

漏洞管理不是扫描仪。这是对整个软件栈的风险进行识别、优先排序和补救的过程。这些工具可发现操作系统、容器镜像、应用程序库和配置基线中的 CVE。有效的计划会将这些发现与所有权、背景和固定的时间表结合起来。云原生环境使问题变得更加复杂--服务来来去去，容器每天都要重建，漂移会带来无声的风险。挑战不在于检测。这是相关性。要想知道哪些漏洞会影响生产中的可利用路径，就必须整合扫描仪、源控制、CI 管道和运行时可观察性。

软件材料清单 (SBOM)

SBOM是一份清单，是应用程序中使用的每个组件、库和依赖项的机器可读列表，包括版本和来源。它回答了一个简单而有力的问题：我们究竟在运行什么？随着攻击越来越多地针对供应链，SBOM 为可视性奠定了基础。它们不会检测漏洞，但会在漏洞被披露时告诉您是否暴露了。可靠的 SBOM 策略支持 SPDX 或 CycloneDX 等格式标准，并能自动集成到构建中。在零时差响应期间，它将成为您进行影响分析的最快途径。

软件构成分析 (SCA)

SCA 工具会扫描代码库中的开源依赖关系，并标记已知漏洞、许可证问题和转发风险。通过分析组件的使用方式，它们比 SBOM 更深入。强大的软件构成分析可以检测出您的应用逻辑是否可以实现易受攻击的功能，从而减少噪音，关注真正的威胁。在云原生应用程序中，服务可能依赖多种语言的数千个软件包，因此 SCA 变得至关重要。但是，只有当调查结果具有可操作性时，它才会产生价值--分流、映射到所有者，并嵌入到开发工作流程中。

云原生应用程序保护平台 (CNAPP)

CNAPP将工作负载保护、云安全态势管理、身份分析和 CI/CD 集成等多个安全学科结合到一个专为云原生系统打造的统一平台中。他们会跨层审视您的应用程序：从其运行的基础架构，到其发布的代码，再到其在运行时表现出的行为。我们的目标不仅仅是检测漏洞或错误配置，而是要了解它们是如何交织在一起的。单独来看，硬编码秘密的风险可能很低。再加上权限升级路径和公开曝光，这就变得十分紧迫。CNAPP 帮助团队消除信号碎片，关注可利用的风险，而不是噪音。

没有任何一种能力能确保应用程序的安全。而且，它们都不能取代架构规范或安全的编码习惯。但是，通过有意识地使用，它们可以扩展每个开发人员和安全工程师的工作范围，帮助团队建立信心，而不是假设。

合规不是安全，但也不是可有可无的

监管框架-- PCI DSS、HIPAA、GDPR、SOC 2、FedRAMP--并不能确保软件安全。它们规定了最低标准。它们强加了结构。它们使期望标准化。它们不能保证安全。通过合规性审核的系统仍然会被攻破。开发人员如果严格遵守要求，仍可能发布不安全的代码。

也就是说，合规很重要。它是软件所处生态系统的一部分。它促使领导层提出问题。它为客户和合作伙伴设定了期望值。它对如何处理数据、谁能访问数据以及留下什么样的审计线索都做出了限制。这些不仅仅是文书工作方面的问题，还会影响到架构、部署和日常开发选择。

对于从业人员来说，诀窍在于理解合规性与真正的安全决策之间的交叉点：

• 当 PCI DSS 4.0 强制要求对客户端脚本完整性进行监控时，这就不仅仅是一个复选框了--这是对 Magecart 式供应链攻击的真正防御。
• 当 SOC 2 要求进行访问审查和日志记录时，就是在强制明确谁能接触什么--以及如果出了问题，如何知道。
• 当 GDPR 要求将数据最小化时，它就会推动您缩小爆炸半径和清理数据边界。

合规可以是一种强制功能。它可以推动团队采用安全的默认设置、记录决策并建立可重复的控制。但如果把它当作安全成熟度的代表，就会变得很危险。通过审计并不意味着系统具有弹性。这意味着系统符合别人定义的基准线，而别人往往没有考虑到您的具体威胁模型。

目标是使合规性和安全性保持一致，而不是混为一谈。如果操作得当，合规性就会成为构建自我保护软件的副产品。如果做得不好，它就会变成一堆 PDF 文件，说您很安全，直到您不安全的那一天。

应用程序安全常见问题