MLSecOps Practical Reference Guide

是什么启发你构建这个项目？

我反复在交付 ML、LLM 和 Agent 系统的团队中看到同样的模式：安全框架很多，但没有一个统一的地方可以把这些框架转化为日常决策——在哪里设置卡点、保留哪些证据、RAG 的访问控制与发布评审有何关系、SOC 应如何在系统上线后监控模型行为。

OWASP、MITRE ATLAS、NIST AI RMF、ISO/IEC 42001、OpenSSF 和 CSA MAESTRO 都很有价值，但它们使用的是不同的语言。在紧迫的交付压力下，安全工程师、MLOps 和架构师们只能把 PDF、博客文章和厂商文档拼凑在一起。

我想要的是一个开放的、以实践者为导向的参考——不是另一份标准，也不是产品宣传——让单个团队从威胁建模到治理的全过程中使用，同时不丢失生命周期这条主线。

你试图解决什么问题？

核心问题是：DevSecOps 和传统的 AppSec 都不能完全覆盖 AI 生产环境的风险。攻击面存在于数据、模型工件、Prompt、Embedding、检索流水线、Agent 和运行时行为中，而不仅仅是应用代码里。

第二个问题是：相关指南是零散的。团队在以下方面困难重重：

- 将威胁映射到具体的控制措施和工具；

- 区分产生证据的步骤与真正的发布卡点；

- 为安全或合规评审生成可审计的输出；

- 推广 LLM/RAG/Agent 模式时不必每次都重新设计架构。

本指南试图回答的问题是：“这个 Sprint 我们到底该做什么？”——通过生命周期控制点、证据包、威胁–控制–工具映射，以及针对常见部署模式的实施参考（附录 E）。

在本次发布的工作中，你的方法或流程是如何演进的？

最初它是一份综合性的文档：将现有框架串联成一个 MLSecOps 生命周期叙事。早期的读者（包括 GitHub Issue #1 和 #2）推动了更大的诚实度和可追溯性——哪些论断来自 OWASP/NIST，哪些是作者基于实施经验的观点，哪些是新兴研究。

这些反馈塑造了 v1.1.0：

- 每个主要章节都附带参考资料与来源映射；

- 与 OWASP AI Exchange 形成互补集成（而非重复）；

- 在第一章中提供更清晰的“指南一览”，方便管理者和新读者使用；

- 更强的上手体验：基于角色的阅读路径、波斯语摘要、GitHub Pages、PDF/DOCX 发布版本以及用于学术引用的 Zenodo DOI。

这个过程也让我意识到，这不是一份“一劳永逸”的手册。AI 安全发展很快——LLM、Agent、MCP、供应链——所以开源与社区审阅比假装文本永远不变更重要。本次发布是稳定的（v1.1.0），但模型是一种“活文档”：随着领域和读者反馈的发展，会持续通过 Issue、Discussion 和小版本进行更新。