将应用安全集成到软件工程中的框架（FIASSE）

注意： 本仓库仍在持续完善中。欢迎贡献！

概述

TL;DR：请阅读 DOC。浏览 FIASSE 网站。访问 GitHub Discussions 参与贡献。

本仓库包含 OWASP 将应用安全集成到软件工程中的框架（FIASSE）的相关资源与材料。FIASSE（发音为 /feiz/，与 'phase' 押韵）是一个与厂商无关的框架，倡导以开发者为中心、基于原则的方法来构建可安全化（securable）的软件。它认识到安全性如同开发一样，是一个动态的、持续的过程。它引入了可安全化软件工程模型（SSEM）作为通用设计语言，使用既有的软件工程术语，通过将安全性嵌入塑造代码本身的原则之中，把安全性融入软件架构、设计与工程实践。该框架使开发团队能够富有韧性地创造计算价值，同时降低代码整个生命周期内网络事件造成实质性影响的可能性。

FIASSE 是一个创建型框架。它关注安全性如何在软件中实现，将工程决策直接与可安全化的成果联系起来。它不是一个保证框架、成熟度模型，也不能替代控制目录或漏洞指标。它是对这些方法的补充，并缓解下游对保证与合规的压力。

目的

提供实用指南，赋能开发者在无需深厚安全专业知识的情况下创建可安全化的软件，并指导安全专业人员将其安全经验有效融入软件工程。FIASSE 通过软件工程视角实现这一目标，降低认知负担，促进开发团队与安全团队之间的协作。

有何不同？

以保证为重点的项目（如 OWASP Top 10）强调应避免什么（黑名单），而 OWASP FIASSE 则提供了一组应遵循的正面属性与实践（白名单）。这种方法利用现有的软件工程技能来构建可安全化的软件，而不是要求开发者学习漏洞利用技术或采用以漏洞为中心的思维方式。其重点在于通过熟悉的工程原则实现实用、安全的编码。

通过在开发过程中清晰界定安全性的实际角色，该框架确保业务价值得到有效捕获。在编写代码之前设定明确的安全期望，可降低安全缺陷在后期被发现并需要修复的可能性。有效的采用应能改善现有的保证指标、减少发现问题的反复变动、产生更持久的修复，并缩短修复时间。

核心价值观

FIASSE 以四项核心价值观为导向。每项都表达一种相对偏好：双方都有价值，但当必须做出选择时，FIASSE 倾向于左侧。

• 可安全化属性优先于安全控制：倾向于让系统得以构建并保持可防御的工程品质，而非事后为弥补弱点而添加的安全控制。
• 参与优先于评估：倾向于安全与开发在整个生命周期中的结构化协作，而非工作完成后的评估。
• 工程第一原则优先于安全术语：倾向于扎根于既有的软件工程第一原则，而非安全专用术语或对抗性启发式方法。
• 业务价值优先于安全活动：倾向于能够维系组织价值创造的安全性，而非将安全本身作为目的来追求。

关键原则

• 可保障范式：不存在静态的“安全”状态。今天被宣布为安全的系统，明天可能就存在漏洞。FIASSE 将工程目标从“它是否安全？”转变为“它的构建方式能否使安全性得以维持？”，通过自适应韧性、演进式安全和持续改进来实现。
• 韧性创造计算价值：在业务背景下软件工程的首要指令。软件必须满足功能需求，同时维持可保障的质量，使其能够承受每次变更之后随之而来的变化、压力和攻击。
• 安全使命：减少实质性影响：安全的使命是降低网络事件造成实质性影响的概率。完全消除入侵并非切实可行的业务目标，因此安全策略必须与业务目标和风险偏好保持一致。
• 质量与安全的关系：安全性无法超越软件质量。使软件易于理解、变更、测试和观测的质量，正是使其能够被保障的质量。对工程质量的投资就是安全投资。
• 以开发者为中心的安全：赋能软件工程师使用熟悉的软件工程原则构建可保障的系统，而不是要求他们采用渗透测试人员的思维方式。
• SSEM 作为通用设计语言：利用既有的软件工程术语（例如可分析性、可修改性、可测试性）来定义和讨论安全属性。这使开发者能够理解安全，并为安全专业人员提供共同的评估基础。
• 使安全与开发和业务目标保持一致：安全与开发是互补的，而非对立的。AppSec 在 SDLC 中尽早参与，特别是在需求收集和功能规划期间，从而在编写代码之前明确期望。
• 透明性原则：系统设计使授权方能够理解内部状态和行为。结构化日志、插桩和审计追踪内建于代码之中，而不仅仅由外部工具提供。
• 最小惊讶原则：系统的行为方式对用户、开发人员和管理员而言是直观且可预测的。可预测性有助于分析、减轻认知负担，并使信任边界清晰明确。
• 需求作为 AppSec 中的一等公民：安全功能、威胁场景和安全验收标准通过需求流程交付。漏洞通常可追溯到从未被明确规定的期望，因此这一缺口应归属于需求流程。

工程原则

框架第 4 节为开发者提供了直接适用于代码层面的原则：

• 边界控制原则：系统内部的灵活性是应予以保留的工程资产。每个信任边界处的控制是应予以强制执行的安全要求。
• 规范化输入处理：在入口点对输入进行规范化、验证和净化。规范化解析原则在边界处将外部输入解析为规范化的内部类型，并在解析不成功时安全失败。
• 隔离完整性原则：价格、角色和对象状态等完整性关键值源自权威的服务端来源。它们绝不直接从客户端接受。
• 韧性编码：防御性编码实践强制执行可预测的执行。这些包括强类型、信任边界处的输入验证、输出编码、全面的错误处理、安全的资源管理、优雅且安全的失败，以及代码层面的最小权限。
• 依赖管理：在关系的整个生命周期内，在选择、集成、监控和维护依赖时应用 SSEM 属性。

可保障软件工程模型（SSEM）

SSEM 定义了使软件具备可安全性的属性。团队为每个属性设定目标，对照目标评估系统，并逐步改进。这些属性分为三类：

可维护性	可信性	可靠性
可分析性	机密性	可用性
可修改性	可问责性	完整性
可测试性	真实性	韧性
可观测性

SSEM 在设计上没有授权属性。授权是一项安全功能，它作为需求被收集，并依据验收标准实现。上述属性正是使此类功能具备可安全性的要素。框架的附录 A 描述了衡量每个属性的方法。

仓库内容

• docs/securable_framework.md：完整的 FIASSE 框架和 SSEM 规范，作为单一文档。
• docs/framework/：框架按章节拆分为每节一个文件。这些章节文件是框架的权威来源。代码索引将直接适用于代码的章节与流程、角色和采用章节区分开来。llms.txt 为语言模型提供索引。
• skills/：将 FIASSE 和 SSEM 打包为 AI 编码代理的技能（见下文）。
• TODO：FIASSE 方法的实施指南
• 示例已移至 Securability-Engineering/securable-framework-supplement

快速开始

1. 查阅 docs 目录中的文档。从完整框架开始，或使用代码索引查找适用于当前代码的章节。
2. 与你的团队并在 GitHub Discussions 中讨论相关概念和原则
3. 开始在软件工程实践中应用这些原则，例如需求收集、合并审查和提示工程。
4. 遵循框架第 8 章中的采用步骤：评估当前实践、整合 SSEM 术语、识别关键影响者、教育和培训团队、采用代理式 AppSec 工具以缓解容量压力、促进协作，并持续监控和改进。

• 附加：安装与你选择的 IDE 或 AI 驱动的命令行代理（例如 GitHub Copilot、Claude Code、OpenCode 等）相匹配的插件，并使用提供的提示词生成可安全编码的代码。在提示词库中查找“Securability Engineering”或“FIASSE”。
• FIASSE 也已纳入 OWASP Secure Agent Playbook。

面向 AI 编码代理的技能

skills/ 目录将 FIASSE/SSEM 打包为可直接使用的技能，适用于支持 Agent Skills 格式的 AI 编码代理（例如 Claude Code）。将你需要的技能目录复制到代理的技能路径中。

• securability：一份紧凑、完全自包含的参考，涵盖全部十个 SSEM 属性及核心原则（无静态安全状态、隔离完整性、规范输入处理、边界控制、最小惊奇）。旨在作为日常代码生成和审查的默认选择。
• securable-code：面向上下文繁重、架构复杂工作的深度技能，例如信任边界设计、身份验证系统、多服务数据流或依赖架构。它会路由到与当前代码相关的特定捆绑框架章节（位于 skills/securable-code/framework/），以额外上下文换取源框架的完整推理。

默认使用 securability；当设计决策不够直观、需要阅读框架本身时，再使用 securable-code。

摘要

本仓库将可加固软件定义为以保持可防御性为目标构建的软件：其结构使其能够随着周围世界的变化而被理解、修改、测试和加固。它强调安全性是一个持续的过程，而非静态的成就。它引入了可加固软件工程模型（Securable Software Engineering Model，SSEM），该模型将安全性视为精心设计的软件所固有的一组品质。为此，它提出了可维护性、可信赖性和可靠性（包括韧性）这些属性类别。FIASSE 倡导将安全实践集成到开发工作流中能够产生最大影响的位置。这从“安全作为事后考虑”或“左移”方法，转变为一种主动的、协作的模型。产品负责人、开发人员和安全专业人员从设计的最早阶段就协同工作，特别是通过安全需求定义、协作式威胁建模和安全验收标准。这为代码活动和测试设定了明确的期望。合并审查充当护栏，而非关卡。每次合并都会生成一份建议性的可加固性报告，而是否设置关卡是一项策略决策，并带有覆盖路径。来自验证和生产的发现被视为经验情报，指向上游本可预防这些问题的阶段。软件工程师会获得关于平衡灵活性与控制的指导。他们还会获得一个用于做出安全决策的确定性模型。最终，这使所有利益相关者都能够为构建更健壮、更可靠且本质上可加固的系统做出贡献。

FIASSE 与现有方法的不同之处在于，它不要求开发人员成为安全专家或采用对抗性思维。它指出了常见的 AppSec 反模式，例如将原始工具输出“左铲”给开发人员以及以漏洞利用为先的培训，并用可操作安全情报原则（Actionable Security Intelligence Principle）取而代之。这种方法旨在减轻开发人员的认知负担，同时确保安全从业者能够确信他们的关切通过代码和软件工程流程的特定属性得到了解决。

FIASSE 力求开放、平易近人且协作。

路线图

FIASSE 项目的初始里程碑：

• 项目基础
  • 建立项目治理、贡献指南和沟通渠道。
• 核心规范
  • 正式发布 FIASSE 框架和 SSEM 规范，详细说明核心属性和集成策略。
• 采用与教育资源
  • 一份 SSEM 入门指南，用于介绍该模型及其应用。
  • 一组初始用例和采用模式，用以说明实际收益。
  • 持续开发实施指南、示例和其他教育材料。

进一步的里程碑将与项目团队共同制定。欢迎通过 GitHub Discussions 提供社区意见。

补充资源

本仓库是 FIASSE 网站 的补充。

OWASP FIASSE 项目是 OWASP Foundation 的一部分，后者是一个非营利组织，其使命是消除不安全的软件。OWASP Foundation 提供了大量与 FIASSE 原则相一致的资源和框架。

本框架聚焦于可加固软件工程，并得到其他 OWASP 项目的补充：

• 安全特性验证以及现成的安全需求库：OWASP 应用安全验证标准（ASVS）
• 保障成熟度：OWASP 软件保障成熟度模型（SAMM）
• 产品安全合规：OWASP 产品安全能力框架（PSCF）

OWASP 还托管着众多记录安全需求和特性的项目，例如 OWASP 移动应用安全。OWASP 开发者指南是汇集其他各类 OWASP 资源的综合性资料。

另一个可用于参考需求和保障实践的优秀资源是 OpenCRE，它收集并映射了各种安全框架。

NIST SP 800-53、ISO/IEC 27001 附录 A 和 PCI DSS 等控制目录支持风险管理、保障和外部评估。FIASSE 并不取代它们，而是将其视为需求收集的输入：在开发实施之前，将目录中的控制项转化为带有验收标准的安全需求。

NIST 安全软件开发框架（SSDF）定义了一组核心的安全软件开发实践，分为四个组。FIASSE 并未定义这样的实践集，而是通过强调将安全融入软件开发生命周期来与 SSDF 保持一致。

NCSC 的软件安全实践准则定义了期望的结果和一些关键策略。FIASSE 侧重于第一层的后续原则和实现可保障结果的策略，旨在让开发与保障团队与业务策略保持一致。SSEM 规定了用于产生期望结果的属性，而 FIASSE 方法论则为在软件工程实践中实施这些属性提供了实用指导。

卡内基梅隆大学的 CERT 安全编码标准是一组语言级规则，既提供展示易受攻击代码模式的“不该做什么”示例，也提供“该做什么”示例。FIASSE 通过提供一种有原则的方法来补充这些规则，帮助程序员理解可保障代码背后的“为什么”。

软件工厂安全框架（SF2）“为安全领导者提供了一种战略性方法，在扩展安全能力的同时改善业务成果。”它是一个组织层面的框架，与 FIASSE 对软件工程实践的关注相辅相成。

贡献

欢迎贡献以改进文档和示例。详情请参阅我们的贡献指南。

许可证