kirilurbonas/AegisLLM

# AegisLLM **一个由 GitOps 驱动、具备气隙隔离能力的平台，它从 Hugging Face 获取不受信任的开放权重模型，并将其转化为在 Kubernetes 上经过签名、扫描、策略门控、配备护栏且持续进行红队测试的生产级 LLM 服务。** 在过去十年中，软件供应链得到了安全保障。但*模型*供应链并没有。Hugging Face 的 checkpoint 是不受信任的第三方代码——一个经典的基于 `pickle` 的 PyTorch 文件在你加载它的瞬间就会执行任意代码。AegisLLM 像对待任何不受信任的依赖项一样对待每一个模型：扫描它，将其转换为不可执行格式，建立清单，签名，发布到内部 registry，并拒绝运行任何无法证明其出处的模型。 ## 状态 | 支柱 | 范围 | 状态 | |---|---|---| | 1. 安全模型供应链 | 摄取 → 扫描 → safetensors → AIBOM → 签名 → OCI registry → 验证 | ✅ 已实现 | | 0. 基础设施 | Terraform `kind` 集群、Zot registry、ArgoCD GitOps | ✅ 已实现 | | 2. 加固的 CI/CD + 准入网关 | Trivy → cosign → SLSA 溯源；Kyverno 拒绝未签名镜像和未验证模型 | ✅ 已实现 | | 3. 运行时安全网关 (FastAPI + guardrails) | | 🚧 计划中 | | 4. 持续的 AI 红队测试 (garak / promptfoo) | | 🚧 计划中 | | 5. 可观测性与治理 | | 🚧 计划中 | 有关完整的五大支柱设计，请参阅 [docs/architecture.md](docs/architecture.md)；有关 OWASP LLM Top 10 的映射，请参阅 [docs/THREAT_MODEL.md](docs/THREAT_MODEL.md)。 ## 快速开始 需要运行 Docker Desktop，以及 `uv`、`kind`、`kubectl`、`helm`、`terraform`、`cosign`、`oras`。 ``` make check # preflight: docker daemon + required binaries make tools # brew install anything missing make install # uv sync make supply-chain # Pillar 1 end-to-end, signed model in the local registry make demo-tamper # flip a byte in the weights — verification must FAIL make cluster # terraform: kind cluster + Zot registry + ArgoCD eval $(make kubeconfig) make gitops # apply the app-of-apps; hello service reconciles make clean-cluster # tear it all down ``` `make gitops` 需要一个可访问的 git URL —— ArgoCD 是从 git 进行同步，而不是从 你的工作树同步。它会使用你的 `origin` remote，因此请先 push 该仓库，或者 显式传递一个：`make gitops AEGIS_REPO_URL=https://github.com//aegisllm.git`。 `make supply-chain-offline` 在完全没有 registry 和 Docker 的情况下 运行 pipeline，并在签名后停止 —— 这在 CI 环境和飞机上非常实用。 ## 支柱 1：实际发生了什么 ``` huggingface.co │ aegis ingest pinned to a commit SHA, never a branch ▼ artifacts/staging/ │ aegis scan modelscan + picklescan; non-zero exit on CRITICAL ▼ │ aegis convert torch .bin → .safetensors, tensor-equivalence checked ▼ │ aegis aibom CycloneDX 1.6 ML-BOM: license, source, revision, hashes ▼ │ aegis sign sigstore keyless (demo) or keyed cosign (CI / air-gap) ▼ localhost:5001/models/… aegis push — weights + AIBOM + signature bundle as one │ OCI artifact; the AIBOM attached as an OCI referrer ▼ │ aegis verify pull, re-hash, verify signature. Tamper ⇒ exit 1. ``` 运行时的任何操作都不会去调用 Hugging Face。该 registry 就是气隙隔离的镜像。 这个门禁不是摆设：`tests/test_scan.py` 构建了一个真正的恶意 pickle，其 `__reduce__` 会调用 `os.system`，并断言扫描器能标记它，同时 pipeline 会拒绝 继续执行。 ## 支柱 2：未经验证的一律不运行 ``` make cluster && eval $(make kubeconfig) make supply-chain # publish a signed model make verifier-image # build + sign the verifier init container make kyverno keys-secret # install Kyverno and the AegisLLM policies make demo-admission # the gate, proven ``` `make demo-admission` 输出： ``` ── compliant pod (must be ADMITTED and reach Running) ── → the serving container sees: serving verified model from /models: aibom.cdx.json pytorch_model.safetensors ── unpinned (must be REFUSED) ── ✓ blocked by rule: model-must-be-digest-pinned ── external (must be REFUSED) ── ✓ blocked by rule: model-must-come-from-the-internal-registry ── no-verifier (must be REFUSED) ── ✓ blocked by rule: verifier-init-container-must-be-present ``` 这些策略也有离线单元测试 —— `make test-policies` 会针对每条 规则，断言哪些示例 pod 必须通过，哪些必须失败。削弱任何一条规则都会导致 CI 变红。（已通过故意削弱一条规则进行了验证：测试套件捕获了它。）一个 悄悄停止执行的准入网关比没有更糟糕，因为所有人都会继续 假设它在正常工作。 **关于其工作原理的真实情况**，因为显而易见的设计其实行不通： Kyverno 的 `verifyImages` 会从 *pod spec* 中读取镜像引用，而 作为 OCI artifact 发布的模型永远不会出现在那里。Kyverno 无法从 annotation 中验证 模型签名，任何声称它可以的人描述的都是 该工具并未实现的功能。因此，强制执行被分开了 —— Kyverno 证明 pod 的 **结构** 使得验证必然发生（摘要锁定、内部 registry、 存在验证器、镜像签名有效），而 verifier init container 负责执行 **加密** 并在失败时安全关闭。两者单独使用都不够。 [docs/architecture.md](docs/architecture.md) 解释了为什么这种分离是被迫的 而不是主动选择的，并记录了两个版本不匹配的情况（cosign v3 ↔ Kyverno 1.18， oras 1.2 ↔ 1.3），这两者失败的表现都极具误导性，看起来就像 缺少签名一样。 ## 威胁覆盖范围 | OWASP LLM Top 10 (2025) | 控制措施 | 支柱 | |---|---|---| | LLM03 供应链 | 模型扫描、签名、AIBOM、已签名的 OCI registry、准入网关 | 1, 2 ✅ | | LLM04 数据与模型投毒 | 溯源验证、safetensors、revision 锁定、准入网关 | 1, 2 ✅ | | LLM01 提示词注入 | 输入 guardrails + 红队测试网关 | 3, 4 🚧 | | LLM02 敏感信息泄露 | 输出 PII/密钥扫描 + 审计日志 | 3, 5 🚧 | | LLM05 输出处理不当 | 输出 guardrails、schema 强制执行 | 3 🚧 | | LLM06 过度代理 | 范围化的 RBAC、最小权限 | 3 🚧 | | LLM07 系统提示词泄露 | 提示词隔离 + 红队探测 | 3, 4 🚧 | | LLM09 误导信息 | grounding + promptfoo 断言 | 4 🚧 | | LLM10 无限制消耗 | 频率/token 配额 + 成本仪表盘 | 3, 5 🚧 | ## 布局 ``` supplychain/ Pillar 1 — the model supply chain CLI (`aegis`) infra/terraform/ kind cluster, Zot OCI registry, ArgoCD gitops/ app-of-apps + workloads reconciled by ArgoCD policies/ Pillar 2 — Kyverno admission policies examples/ compliant and deliberately non-compliant model-serving pods .github/ CI (lint, test, scan gate) and release (Trivy, cosign, SLSA) gateway/ Pillar 3 — FastAPI inference gateway redteam/ Pillar 4 — garak / promptfoo suites ```

标签：AI供应链安全, DevSecOps, GitOps, Linux系统监控, 上游代理, 子域名突变, 模型安全, 签名校验, 软件物料清单(SBOM), 逆向工具