应用安全不仅仅是漏洞

原创 tonghuaroot RedTeam 2025-03-02 10:36

应用安全不仅仅是漏洞，漏洞是驱动应用安全建设的有效抓手。

代码天生易错

核心理念：以系统可靠性为核心目标，兼顾控制验证与安全保障、安全漏洞治理的双重诉求。

应用开发天生具有复杂性。没有不存在漏洞的应用
。这些漏洞可能源自需求分析、设计阶段，也可能出现在实现及后续维护过程中，不同阶段的安全漏洞会引发不同的安全问题。

关键在于：将可靠性
作为核心目标，并将安全性视为其重要衍生成果之一。在日益数字化的世界中，这一点尤为重要，大多数软件风险（包括AI和模型系统）本质上是可靠性问题，而安全正是其核心子集。

本文并非对这一宏大主题的全面分析，许多领域（如形式化验证）甚至未被提及。我们的目标是通过案例说明：以可靠性为路径实现安全性
，才是更优策略，而非反向而行。

治标策略

• 代码分析

对源码、目标、可解释或可执行代码进行漏洞或其他缺陷检测，包括静态分析、动态分析和运行时分析。尽管这些技术已显著提升了软件安全性，但准确性（误报/漏报）和开发者工作流整合仍是重大挑战。

• 模糊测试（Fuzzing）

向软件接口（输入、UI、API等）注入海量随机输入，观察故障模式并分析其可利用性。

• 漏洞利用开发

通过多样化技术识别特定运行时环境或应用框架中的漏洞。

• 漏洞扫描

系统化探测运行时环境，通过直接发现或漏洞特征库匹配识别潜在风险。

• SBOM分析

随着SBOM的普及，通过分析SBOM中组件的已知漏洞推断系统风险。

• 渗透测试与红队攻防演练

综合运用多种技术探测软件或配置问题。但需警惕：某些组织可能将自动化扫描包装为“渗透测试”甚至“红队行动”。

• WAF 应用防火墙

动态拦截攻击流量的纵深防御工具。尽管存在争议（如协议栈分层阻断可能引发故障），但在应急场景中仍具价值，前提是不替代漏洞修复。

治本策略

• 控制即代码与安全整合

将可靠性视为安全的超集，全面考虑软件及系统中的控制机制：

• 业务控制逻辑
  （如财务系统的交易属性校验）

• 应用层安全控制
  （认证/授权检查、交易签名验证、服务网格交互）

• 漏洞防护逻辑
  （输入解析、API安全调用）

• 代码安全属性
  （内存管理、类型安全）

• 可靠性约束
  （数据地理边界、多可用区部署），需警惕约束与义务的潜在冲突。

• 需求工程

通过威胁建模等方法确保关键可靠性需求（包括安全需求）贯穿开发全流程。

• 开发者工具集成（左移策略）

在IDE中集成缺陷检测、API建议、测试用例生成等功能，并将培训无缝融入工具链。

• 构建流水线与软件保障

遵循SLSA等框架确保构建安全，通过持续集成/部署验证单元测试、集成测试与回归测试。

• 测试工程与业务控制测试

覆盖业务、应用、控制、安全与弹性逻辑的测试体系，包括安全API调用验证与常见漏洞（如CSRF）防护。

• 混沌工程

将安全测试融入混沌工程，通过合成事件探测控制机制有效性。现有攻防模拟工具在此领域仍有局限。

• 预防性维护预算

设立专项预算（建议初始占比10%），动态调整以应对可靠性需求。可借鉴SRE事故预算理念，平衡功能开发与系统稳定。

• 框架与API安全

通过集中化框架减少错误面，但需投入顶级安全资源进行持续审查。

• 安全语言/执行环境

采用Rust、Go等内存安全语言，结合CHERI等硬件能力降低漏洞风险。

• 编译与构建配置

通过编译器选项优化缓解常见缺陷。

• 模型验证

对ML模型进行与传统软件同等严格的测试验证。

• 测试/训练数据治理

确保数据溯源、隐私保护及完整性，维持测试覆盖度与代表性。

结论
：单纯聚焦应用安全易陷于治标困局。更优路径是直击本质，通过提升软件可靠性，实现安全性、控制保证等核心属性的协同增效。

以上内容编译自 philvenables