mcpField
S
safety-critical-patterns

safety-critical-patterns

github.com/athola开发343107 次安装1 天前更新
代码仓库

关于 safety-critical-patterns

一套面向安全关键软件的编码准则，依据风险程度调整应用力度，适用于关键系统、金融交易和数据完整性代码。内容涵盖控制流、循环边界、断言及严格检查等规则。

主要功能

  1. 01限制复杂控制流与递归
  2. 02要求循环具备可验证上限
  3. 03关键路径避免动态内存分配
  4. 04强调断言和输入校验
  5. 05启用严格编译与检查

适用场景

  1. 01评估安全关键模块的代码
  2. 02检查金融交易逻辑
  3. 03审查数据完整性处理代码

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/athola/claude-night-market --skill safety-critical-patterns

安装后在 Claude Code 中输入/safety-critical-patterns确认已加载。

详细介绍

安全关键型编码模式

改编自 NASA 的安全关键软件 Power of 10 规则指南。

何时应用

严格遵循：安全关键系统、金融交易、数据完整性代码
选择性应用：业务逻辑、API 处理程序、核心算法
轻量应用：脚本、原型、非关键实用工具

“严格程度应与后果相匹配”——真正的工程原则

何时不应使用

  • 普通应用程序代码中，这些防御性检查会变成 prefer-invariants-over-fallbacks 所针对的臃肿代码（使用 conserve:code-quality-principles）

10 条规则（改编版）

1. 限制控制流

避免使用 goto、setjmp/longjmp，并限制递归。

原因：确保调用图无环，以便工具进行验证。
调整：如果能证明递归会终止（尾递归、深度有界），则可以接受。

2. 固定循环边界

所有循环都应具有可验证的上限。

# Good - bound is clear
for i in range(min(len(items), MAX_ITEMS)):
    process(item)

# Risky - unbounded
while not_done:  # When does this end?
    process_next()

调整：记录预期边界；为可能无界的循环添加安全限制。

3. 初始化后不进行动态内存分配

启动后避免在关键路径上进行堆分配。

原因：防止运行时分配失败。
调整：预先分配内存池；在热点路径中使用对象复用模式。

4. 函数长度约 60 行

函数应能容纳在一个屏幕或页面内。

原因：理解能力的认知限制依然存在。
调整：声明式代码可灵活处理；复杂逻辑则应严格遵守。

5. 断言密度

加入防御性断言，说明预期条件。

def transfer_funds(from_acct, to_acct, amount):
    assert from_acct != to_acct, "Cannot transfer to same account"
    assert amount > 0, "Transfer amount must be positive"
    assert from_acct.balance >= amount, "Insufficient funds"
    # ... implementation

调整：重点关注边界条件和不变量，而非任意配额。

6. 尽可能缩小变量作用域

在尽可能小的作用域内声明变量。

# Good - scoped tightly
for item in items:
    total = calculate(item)  # Only exists in loop
    results.append(total)

# Avoid - unnecessarily broad
total = 0  # Why is this outside?
for item in items:
    total = calculate(item)
    results.append(total)
7. 检查返回值和参数

验证输入；绝不忽略返回值。

# Good
result = parse_config(path)
if result is None:
    raise ConfigError(f"Failed to parse {path}")

# Bad
parse_config(path)  # Ignored return
8. 限制预处理器和元编程

限制宏、装饰器和代码生成。

原因：使静态分析成为可能。
调整：全面记录元编程；优先采用显式写法，避免魔法行为。

9. 指针/引用规范

限制间接层级；明确所有权。

调整：使用类型提示，避免可选类型深度嵌套，优先使用不可变数据。

10. 启用所有警告

从第一天起就使用最严格的设置进行编译和代码检查。

# Python
ruff check --select=ALL
mypy --strict

# TypeScript
tsc --strict --noImplicitAny

可能不适用的规则

规则可放宽的情况
不使用递归树遍历、深度有界的解析器组合子
不使用动态内存垃圾回收语言、短生命周期进程
函数不超过 60 行声明式配置、状态机
不使用函数指针回调、事件处理程序、策略模式

集成

从以下技能引用此技能：

  • pensive:code-refinement - 整洁代码和质量维度
  • sanctum:pr-review - 代码质量阶段
  • /harden - 在加固流水线中组合使用
  • /full-review safety-critical - 专项入口；当断言密度较低、循环无界或递归缺少终止性证明时，也作为自动检测项

违规输出格式

对于每项规则违规，请报告：

Rule N: <rule name>
Location: file.py:42
Anchor: `<verbatim source text at line 42>`
Issue: <what violates the rule>
Fix: <concrete remediation>
验证发现是否有依据（safety-critical:findings-verified）

将发现写入 .review/findings.json，运行引用验证器（Skill(imbue:review-core) 第 5 步），并删除验证器拒绝的发现，或将其标记为 UNVERIFIED。

退出标准

  • 10 条规则均对目标给出明确结论（适用／违反／不适用），不得悄然跳过
  • 每项报告的违规都引用具体的 file:line，并注明违反的规则编号
  • 判定为不适用的规则需说明原因（例如“此模块中没有动态分配”），不得省略
  • 对规则 2 下标记的循环，需检查是否能静态证明其上限；无界循环必须报告
  • 若规则 1 下标记的递归缺少终止性论证，则必须报告
  • 总结需说明目标是否适用于安全关键用途，或指出哪些规则阻碍了这一判断
  • 每项报告的违规都包含经 citation_verifier.py 确认的 Location + 原文 Anchor（退出码为 0）；否则，未验证的违规必须删除或标注为 UNVERIFIED。

来源

  • NASA JPL 的十大规则（Gerard Holzmann，2006）
  • MISRA C 指南
  • HN 上关于实际应用的讨论见解

评论

支持 Markdown