应用安全现状报告总结
核心观点：随着云原生架构、开源依赖和自动化流程的加速应用，应用攻击面正以超越安全实践的速度扩张。AI 辅助开发进一步加剧了这一速度，生成代码、依赖和配置的速度远超传统安全流程的治理能力。现代应用由数千个第三方组件构成，并以机器速度部署，这使得在代码进入生产后不可能修复所有问题。易受攻击的依赖项、暴露的密钥和配置错误不再是边缘案例，而是当今软件开发的结构性现实。同时，AI 系统引入了新的风险，并能够快速传播不安全的代码模式和模型依赖项。
关键数据和研究结论：
- 供应链攻击的兴起：软件供应链攻击已从边缘威胁转变为最可靠的重大损害路径之一。SolarWinds 数据泄露事件标志着转折点，证明了一个受感染的构建管道可以访问超过 18,000 个下游组织。2025 年，Shai-Hulud 蠕虫的出现标志着自复制供应链恶意软件的兴起，它通过收集受感染环境中的 npm 令牌和 GitHub 凭据进行自主传播。
- 依赖项和漏洞管理：超过 78% 的组织在生产环境中运行具有关键漏洞的应用程序。即使披露多年后，像 Log4Shell 这样的高影响问题仍然影响近一半的生产环境，突显了传统应用安全方法难以跟上依赖项蔓延的挑战。43% 的组织仍在运行 OpenSSL 1.0.1f，该版本受 Heartbleed 和其他高影响漏洞的影响，反映了未定期更新的基础镜像的广泛使用。
- 容器漏洞格局：超过 60% 的组织运行的核心系统包（如 tar 和 glibc）存在关键漏洞的容器。这些组件位于容器镜像的基础，并跨应用程序继承，这意味着单个易受攻击的基础镜像可以将风险传播到整个环境。77% 的组织在 90 天后仍然存在高或关键容器漏洞，表明在修复和运行时安全方面存在持续差距。
- 密钥管理：超过 31% 的组织在源代码存储库中暴露了有效的密钥，而 30% 的组织保留在 git 历史记录中，即使它们似乎已被删除，这些凭据也仍然可恢复。43% 的生产组织暴露了 AI/ML 凭据，反映了团队在没有建立适当的密钥管理实践的情况下快速集成 AI 服务。
- CI/CD 管道安全：25% 的存储库仍然依赖于遗留或过于宽松的 GitHub 令牌权限，增加了凭证滥用和未经授权的工作流程执行的风险。当与第三方操作和自动部署权限结合使用时，这些权限允许攻击者从代码更改到生产访问，几乎没有阻力。
- 基础设施即代码 (IaC) 安全：75% 的组织通过代码管理基础设施。IaC 包括云原生模板、Kubernetes 资源清单和配置驱动的容器部署。84% 的组织部署了未加密的存储资源，将数据暴露直接嵌入生产环境。80% 的组织缺乏 IaC 管理存储的足够日志记录和监控控制。
关键建议：
- 立即行动（0-30 天）：审查 CI/CD 身份验证令牌并限制权限为最低所需访问权限。优先解决可主动利用的 CVSS 10.0 漏洞。识别并在代码存储库、提交历史记录和 CI/CD 环境中旋转所有有效密钥。
- 短期计划（30-90 天）：集成 IaC 扫描到 CI/CD 管道中，对高风险配置设置阻止策略。实施依赖项扫描并强制执行已知恶意软件包。强制执行关键存储库的分支保护，要求签署提交并强制执行所有维护人员的多因素身份验证。
- 战略改进（90+ 天）：为 CI/CD 管道采用零信任。继续风险监控。建立批准的基础镜像标准并执行定期重建和更新。在注册表和持续监控运行时工作负载中实施自动化容器漏洞扫描。
结论：应用安全行业正处于转型期。组织已经采用了云原生架构、基础设施即代码和自动化管道等现代开发实践，但安全成熟度并没有跟上变化的速度。在 2025-2026 年，应用安全状况反映了这一点。那些将应用安全作为其开发过程的核心能力，而不是事后思考的组织将蓬勃发展。
