应用安全不仅仅是漏洞

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

代码天生易错

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

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

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

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

治标策略

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

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

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

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

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

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

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

治本策略

• 控制即代码与安全整合将可靠性视为安全的超集，全面考虑软件及系统中的控制机制：

• 业务控制逻辑（如财务系统的交易属性校验）
• 应用层安全控制（认证/授权检查、交易签名验证、服务网格交互）
• 漏洞防护逻辑（输入解析、API安全调用）
• 代码安全属性（内存管理、类型安全）
• 可靠性约束（数据地理边界、多可用区部署），需警惕约束与义务的潜在冲突。

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

• 开发者工具集成（左移策略）在IDE中集成缺陷检测、API建议、测试用例生成等功能，并将培训无缝融入工具链。

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

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

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

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

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

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

• 编译与构建配置通过编译器选项优化缓解常见缺陷。

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

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

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

以上内容编译自 philvenables