securability-engineering-review

SSEM 评估（评分与报告）

分析代码的可保障工程质量，并生成结构化的 SSEM 评分卡。本文件是评分标准、权重、严重程度分类和报告格式的权威依据。plays/securability-engineering-review.md 中的 play 是分步操作手册；请参阅它了解每一步的执行时机，而不是评分标准的具体内容。

与 FIASSE v1.0.4 保持一致。各属性的衡量指南见 data/fiasse/SA.*.md（附录 A）。

何时调用

用户提出以下请求时，触发此技能：

• 评估、审计、打分、评级或评价代码的可保障性
• 生成 SSEM 评分卡或 SSEM 评估报告
• 从可保障工程的角度审查合并请求／拉取请求
• 为项目建立安全态势基线
• 识别影响安全性的工程质量问题（而非以漏洞为中心）
• 回答“我应该从哪里着手加固这个代码库？”
• 检查 FIASSE/SSEM 合规性

相关说法：“为这段代码评估安全性”“它是否已准备好接受审计？”“X 的安全状况如何？”“它的可保障性如何？”“做一次安全工程审查”“提供一份安全态势报告”。

评分框架

每项属性的评分为 0-10。支柱得分是其属性得分的简单平均值。SSEM 总分是三个支柱得分的简单平均值。

支柱与属性（FIASSE v1.0.4 — 10 项属性，权重相同）

支柱	支柱权重	属性	每项属性的权重
可维护性	1/3	可分析性、可修改性、可测试性、可观测性	各 1/4
可信性	1/3	保密性、问责性、真实性	各 1/3
可靠性	1/3	可用性、完整性、韧性	各 1/3

支柱得分 = 其属性得分的平均值。 SSEM 总分 =（可维护性 + 可信性 + 可靠性）/ 3。

权重相同体现了 FIASSE v1.0.4 的立场：SSEM 的各项属性没有哪一项本质上比其他项更重要——特定情境下的严重程度应体现在发现项中，而非评分标准中。

评分标准（锚点）

分数	锚点
10	卓越的实现
8	实现良好，仅有轻微问题
6	实现合格，但存在明显缺口
4	实现较弱，存在重大问题
2	实现有限或较差

有证据支持时，可以在锚点之间插值评分。请确保评分与标准措辞保持一致。

属性清单（10 项评分内容）

每份报告都必须为以下每项属性给出 0-10 的数值评分：

可维护性

1. 可分析性（FIASSE v1.0.4 S3.2.1.1）— 清晰度、复杂度、命名、结构
2. 可修改性（FIASSE v1.0.4 S3.2.1.2）— 耦合、内聚、关注点分离
3. 可测试性（FIASSE v1.0.4 S3.2.1.3）— 覆盖率、可模拟性、独立性
4. 可观测性（FIASSE v1.0.4 S3.2.1.4）— 日志覆盖率、检测能力、故障路径可见性

可信性 5. 保密性（FIASSE v1.0.4 S3.2.2.1）— 敏感数据处理、最小权限、加密 6. 问责性（FIASSE v1.0.4 S3.2.2.2）— 审计跟踪、操作可追溯性 7. 真实性（FIASSE v1.0.4 S3.2.2.3）— 身份验证、令牌完整性、不可否认性

可靠性 8. 可用性（FIASSE v1.0.4 S3.2.3.1）— 资源限制、超时、优雅降级 9. 完整性（FIASSE v1.0.4 S3.2.3.2）— 输入处理、参数化查询、派生状态 10. 韧性（FIASSE v1.0.4 S3.2.3.3）— 错误处理、恢复、防御式编码

评分标准

分数范围	等级	描述
9.0–10.0	优秀	实现出色，几乎无需改进
8.0–8.9	良好	实现扎实，稍作改进即可受益
7.0–7.9	合格	功能可用，但存在明显的改进空间
6.0–6.9	一般	满足基本要求，但需要大幅改进
< 6.0	较差	存在需要立即处理的严重缺陷

严重性分类（针对单项发现）

严重性是对工程影响的判断，并非 CVSS 或 CWE 评分。FIASSE 不采用保障工具的严重性等级。请根据每项发现对 SSEM 分数以及系统保持可安全维护能力的影响进行分类。

严重性	标准
CRITICAL	单凭此项发现就导致某个支柱分数 ≤4；或因系统性缺失（例如，完全没有输入验证、没有审计跟踪、信任客户端环境）导致某项属性得分 ≤2。修复需要进行架构变更。
HIGH	单项发现导致某项属性得分 ≤4；或使某个支柱分数降低 ≥1.5 分。影响范围局部但普遍存在（例如，某个服务中普遍使用字符串拼接构造 SQL）。
MEDIUM	使单项属性分数降低约 1 分；涉及特定模块或模式。修复范围限于一个模块。
LOW	局部工程改进；分数影响 ≤0.5。
INFO	最佳实践建议；无可衡量的分数影响。

必需输入

如果代码库或输入不完整，请在评分前索取以下信息：

• 项目名称和简短描述
• 编程语言和框架
• 架构概述（一段话即可）
• 仓库 URL 或代码访问权限（或粘贴的代码）
• 任何值得参考的现有文档、测试状况或先前评估

如果缺少关键信息，请采取保守评分，并明确说明局限性。不要臆测覆盖范围、架构或运维控制措施。

分诊与抽样策略（适用于超过数千行代码的代码库）

大规模代码库不可能逐行通读。请有目的地抽样，并说明抽样内容。报告的可信度取决于抽样是否严谨，而非声称检查了全部内容。

检查优先级顺序：

1. 信任边界——所有入口点：HTTP 处理程序、队列消费者、RPC 服务、文件导入器、CLI 标志解析器。完整性、真实性和机密性分数的高低取决于这些边界。
2. 安全敏感模块——身份验证、授权、加密、会话、机密信息处理、审计日志记录、错误和日志处理逻辑。
3. 数据访问层——查询构造、ORM 使用、文件路径拼接、反序列化。
4. 架构接缝——公共接口、依赖注入接线、配置加载器、功能标志处理逻辑。
5. 横切基础设施——健康检查端点、指标、跟踪、定时作业。
6. 业务逻辑抽样检查——选取 2–3 个有代表性的模块；不要对未阅读的内容进行全面评分。

对于每个抽样检查的区域，请在报告中标明实际检查过的文件路径。对于未抽样的区域，请采取保守评分（最高为 6 分），并在评估说明中指出这一缺口。不要自信地将抽样结果推断到未抽样区域。

对于非常大的仓库，请将审查范围限定为单个服务、包或模块，并在范围说明中注明。聚焦的评分卡比含糊地覆盖所有内容更有价值。

流程

完整的分步操作手册位于 plays/securability-engineering-review.md。整体流程如下：

1. 范围与上下文 — 语言、框架、系统类型、数据敏感度、暴露面、生命周期、团队背景。
2. 检查代码，而非文档 — 打开文件；追踪流程；抽查测试。依据应是实际存在的内容，而非声称存在的内容。
3. 为每个支柱评分 — 可维护性（4 项属性）、可信性（3 项）、可靠性（3 项）。引用具体文件路径或模式，而非泛泛而谈。
4. 计算分数 — 属性 → 支柱（简单平均）→ 总体（简单平均）。展示计算过程。
5. 汇总报告 — 严格采用下方的三部分结构。

输出格式

报告必须严格按顺序包含以下三部分。即使评审内容很少，也不得跳过任何部分。

第 1 部分：SSEM 评分摘要

简洁的摘要块。具体的 ASCII 格式可灵活处理（评审内容较短时也可使用 Markdown 表格），但必须包含：

• 项目名称和日期
• SSEM 总体评分、等级和一句话状态评估
• 支柱摘要（可维护性 / 可信性 / 可靠性）——每项包含评分、等级和一句话关键发现
• 可维护性细分表 — 4 项属性（可分析性、可修改性、可测试性、可观测性），每项包含权重（25%）、评分和简短评估
• 可信性细分表 — 3 项属性（保密性、问责性、真实性），每项包含权重（33.3%）、评分和评估
• 可靠性细分表 — 3 项属性（可用性、完整性、韧性），每项包含权重（33.3%）、评分和评估
• 3 项主要优势，附具体证据（文件路径、模式名称或简短引文）
• 3 项主要改进机会，附具体建议

第 2 部分：详细发现

针对每个支柱，写明：

• 支柱名称、评分、等级
• 优势：列出具体证据（文件:行号、模式、观察结果）
• 弱点：列出具体示例或位置，并说明影响
• 建议：按以下格式编号列出：

  1. **[Title]** (Severity: CRITICAL/HIGH/MEDIUM/LOW/INFO)
     - Issue:    [Specific problem]
     - Impact:   [Effect on the pillar score and on the system]
     - Solution: [Actionable steps]
     - Expected Improvement: +[X.X] points
  

单项发现的格式请使用 templates/finding.md。 完整报告模板请使用 templates/report.md。

第 3 部分：附录 A — 评估检查清单（50 项）

官方检查清单：

• 可维护性（20 项）：可分析性（5 项）、可修改性（5 项）、可测试性（5 项）、可观测性（5 项）
• 可信性（15 项）：保密性（5 项）、问责性（5 项）、真实性（5 项）
• 可靠性（15 项）：可用性（5 项）、完整性（5 项）、韧性（5 项）

每项标记为 [x]（通过）或 [ ]（未通过）；未通过时附上简短的行内说明。

最后附上检查清单摘要：

• 可维护性：N/20 项通过（NN%）
• 可信性：N/15 项通过（NN%）
• 可靠性：N/15 项通过（NN%）
• 总体：N/50 项通过（NN%）

完整示例（迷你版）

待审查的代码片段（Python，约 12 行）：

@app.post("/notes/{note_id}")
def update_note(note_id, body):
    sql = f"UPDATE notes SET body = '{body}' WHERE id = {note_id}"
    db.execute(sql)
    print("note updated " + note_id)
    return {"ok": True}

可分析性 — 4/10（较弱）。处理程序职责单一，但字符串格式化不安全；没有输入类型声明；没有提前返回；混淆了解析、持久化和响应构造。 证据：f"UPDATE notes SET body = '{body}' WHERE id = {note_id}"。

可观测性 — 2/10（极低）。print(...) 不是结构化输出。没有关联 ID、执行者或结果字段。失败路径不作记录。 证据：print("note updated " + note_id)。

完整性 — 2/10（极低）。通过字符串插值导致 SQL 注入；没有参数化查询；没有所有权检查（任何调用者都能更新任意 note ID——根据 FIASSE v1.0.4 S4.4.1.2，这违反了派生完整性）。 证据：同上；没有 current_user 推导。

问责性 — 3/10（较弱）。print 不是审计日志；缺少执行者、动作动词、带类型标签的目标 ID 和结果。 证据：print("note updated " + note_id)。

建议（高优先级） — 将 f-string 替换为按所有者限定范围的参数化查询，并输出包含 {actor, note_id, outcome} 的结构化 note.update 日志。预期改进：完整性 +5、问责性 +3、可观测性 +4、可分析性 +2。

报告大规模生成时应达到这样的具体程度——每项评分都配有代码锚定的观察，每项弱点都附有明确指出改动内容的修复措施。

模式标签参考

发现以下模式时，请为该发现标注其违反的 FIASSE/SSEM 原则。使用具体的命名标签，才能让报告具有可操作性——只说“代码处理认证不当”是不够明确的；而说“这是派生完整性违规（FIASSE v1.0.4 S4.4.1.2）——服务端的授权决策依赖客户端声明的 JWT 声明”则更有力。

代码中观察到的模式	违反的原则／属性	发现中的标签
服务端根据客户端声明的声明（req.user.email、request.body.user_id、X-Tenant-ID 请求头）决定谁能执行什么操作	完整性 — 派生完整性原则（FIASSE v1.0.4 S4.4.1.2）	“派生完整性违规”
将 req.body／**kwargs 直接展开到数据库更新或模型字段集中	完整性 — 请求面最小化（FIASSE v1.0.4 S4.4.1.1）	“请求面最小化违规；批量赋值”
通过拼接字符串构建 SQL 或 shell 命令；格式字符串中包含用户输入	完整性 — 信任边界的输入处理（FIASSE v1.0.4 S4.4.1、S4.3）	“信任边界输入处理”
将用户可控的片段与路径拼接，却未验证 ..／分隔符	完整性 — 信任边界；规范化 → 清理 → 验证（FIASSE v1.0.4 S4.4.1）	“路径规范化缺口”
jwt.verify 未固定算法／未指定受众／未指定签发者；或使用默认允许的算法列表	真实性（令牌完整性）	“令牌验证规范不足”
用 console.log／print／fmt.Println 代替审计跟踪；缺少执行者、目标、结果、请求 ID	可问责性 + 可观测性（FIASSE v1.0.4 S2.5、S3.2.1.4）	“非结构化审计跟踪”
裸 except:／catch (e) 将原始异常文本返回给客户端	韧性（优雅降级）；机密性（信息泄露）	“缺少具体的异常处理”
在模块级别、导入时创建全局变量（数据库连接、应用、配置）	可修改性（松耦合）；可测试性（可模拟性）	“导入时副作用”
ioutil.ReadAll(r.Body)／无限制的请求体缓冲区	可用性 + 韧性（资源限制）	“无界资源消耗”
信任边界表面大量使用 any 类型（TypeScript／动态语言）	可分析性；完整性（验证）	“信任边界类型擦除”
静默的 try { … } catch {}／不产生日志或指标的失败路径	可观测性（失败路径可见性）（FIASSE v1.0.4 S3.2.1.4）	“静默失败”
缺少健康检查／指标端点；仅根据外部探测来判断就绪／存活状态	可观测性（将检测机制内置于代码，而非从外部附加）（FIASSE v1.0.4 S3.2.1.4）	“仅依赖外部检测”

无需在每份报告中都完整列出此表。但当出现这些模式之一时，发现内容应通过标签注明相应原则，而不只是描述症状。

反模式（导致报告失去价值的事项）

• 捏造证据：不要引用你实际没有查看过的行号或函数名。如果某项内容未经核实，应保守评分，并明确指出这一缺口。
• 清一色打 7 分：如果每项属性都得到相同分数，说明你并未真正进行评估。不同属性的表现会有强弱之分，报告应体现这一点。
• 偏离主题，过度聚焦漏洞：这 不是 一份 CWE 渗透测试报告。SSEM 评估的是可分析性、可修改性等工程属性。发现的价值在于 工程改进，而不是漏洞利用方法。
• 泛泛而谈的建议：“改进错误处理”不具备可操作性。“将 app/handlers.py:42 中裸用的 except: 替换为 except (ValidationError, NotFound) as e:”则具备可操作性。
• 未接触代码就打分：如果你看不到代码，应如实说明，并拒绝为相应支柱评分——不要推断。
• 缺少计算过程：支柱得分必须展示其如何从属性得分推导而来。不要让读者猜测。
• 只抽样却声称全面评估：如果你抽查了 50 个模块中的 5 个，不要假装读完了全部 50 个并据此评分。标明抽样路径，并将未抽样部分的得分上限设为 6。

必需的评估标准

始终：

• 具体说明。引用可观察到的代码或架构证据，并注明文件路径或函数名。
• 采用相同权重（每个支柱占 1/3；Maintainability 内部各项占 1/4；Trustworthiness 和 Reliability 内部各项占 1/3）。
• 确保建议具备可操作性——读者应能根据你的文字提交 PR。
• 根据项目规模、领域、架构和预期用途，参照评分标准中的锚点进行评分。
• 如果证据不足，应保守评分，并在该属性的评估说明中指出局限性。

调用时的行为

调用时：

1. 如果项目背景信息不完整，询问缺失的信息。
2. 如果代码库规模较大，采用分诊策略；否则进行全面检查。
3. 按照上述流程参照评分标准打分。
4. 严格按照规定生成包含三个部分的报告。
5. 优先依据仓库证据，而非假设；如有证据缺失，应明确指出。

FIASSE 与 OWASP 参考资料

• FIASSE Framework v1.0.4
• FIASSE v1.0.4 SA.* — 附录 A（各属性的测量指南），见 data/fiasse/SA.*.md
• ISO/IEC 25010:2011 — 软件质量模型
• RFC 4949 — Internet Security Glossary
• OWASP 代码审查指南
• OWASP ASVS v5.0 — data/asvs/
• 分步操作手册：plays/securability-engineering-review.md
• 发现项格式：templates/finding.md
• 报告框架：templates/report.md