# AEGIS — Supply Chain Security Architecture

- **Document ID:** ARCH-14
- **Phase:** B.2 — Data, Evidence, Supply Chain
- **Status:** Draft for review (post two-reviewer discipline)
- **Version:** 0.1
- **Date:** 2026-07-10
- **Owner:** Chief Security Architect
- **Depends on:** ARCH-06, ARCH-09, ARCH-12, ARCH-13
- **Consumed by:** ARCH-15 through ARCH-18

---

## 1. Purpose

Specify how AEGIS assures the integrity of everything it ingests as a **build-time**, **release-time**, or **runtime** dependency: source code, compilers, libraries, container images, model weights, Sigma rules, plugins, threat-intel feeds, and updates. Implements Phase-B constraint #7 (Secure Supply Chain) and extends elevation mandates #1 (Zero SPOT), #10 (Recovery Integrity), and #12 (Future Readiness) into the supply-chain domain.

Guiding principle: **treat every input as adversarial until proven otherwise, and re-prove regularly.**

## 2. Supply-Chain Surface

Categories of dependency:

| Category | Examples | Trust posture |
|---|---|---|
| **Build toolchain** | Node.js, Rust toolchain, npm/pnpm, cargo, Docker/BuildKit, GitHub Actions runners | Least-privileged CI; hermetic builds; pinned toolchain |
| **Source dependencies** | npm and cargo packages | SBOM; hash-pinned; SCA continuous |
| **Container base images** | Distroless / Chainguard / Alpine-hardened | Pinned digest; SBOM per image; scanned |
| **AEGIS-produced artifacts** | Container images, binaries, config bundles, plugin manifests | Signed under release hierarchy; reproducible |
| **AI models (weights)** | Qwen, Llama; per release channel | Hash-pinned; provenance-verified; canary-evaluated |
| **Detection content** | Sigma rules from community + AEGIS-authored | Signed contributor + review + fixture tests |
| **Threat-intel feeds (post-v0)** | Commercial + community | Signed feed; feed-reputation |
| **Plugins (v0.2+)** | Third-party | Signed publisher; sandboxed; capability-scoped |
| **Downstream customer artifacts** | Signed release + air-gap bundles delivered to customers | End-to-end verifiable |
| **CI/CD infrastructure** | GitHub, cloud CI runners | Least privilege; separate signing environment |

## 3. Principles

1. **Reproducible where practical.** Build outputs deterministically from a pinned input tree; document any non-reproducibility (e.g., timestamps embedded by tools) and neutralize where possible.
2. **Everything signed at every hop.** Signatures at build-time, at release-time, and at runtime-load.
3. **Provenance is a first-class artifact.** SLSA level 3+ for AEGIS-produced releases; verifiable attestations.
4. **SBOM per release.** Complete list; consumers can verify inclusions and check vulnerabilities.
5. **Continuous re-verification.** Signatures and SBOMs re-checked on load; long-lived artifacts re-verified on a cadence.
6. **Zero SPOT for signing.** No single signing key can produce a shippable AEGIS release without a multi-party attestation.
7. **Ceremony for keys.** Root signing keys live in HSMs and are used only via witnessed ceremonies.
8. **Transparency-log ready.** Prepare to publish hashes into a public witness log for post-quantum-era immutable disclosure.

## 4. Source-to-Binary Pipeline

### 4.1 Source Integrity
- Signed commits required for `main` and release branches; identity is one of a small enumerated set.
- Branch protection: mandatory review; two-approver for security-critical paths (Kernel, Cryptographic Identity, Evidence Chain, Watchdogs, Release Signing).
- Pre-commit hooks: secret scanning; SAST; dependency license check.
- The list of security-critical paths is itself a governed artifact (ceremony-controlled).

### 4.2 Hermetic Builds
- Build environments are ephemeral, reproducible container images with pinned toolchain versions.
- No network access at build time except to a pinned artifact mirror; the mirror serves only hash-verified artifacts.
- Rust builds use `cargo vet` (or equivalent audit trust registry) to constrain the trust set.
- Node builds use `npm ci --ignore-scripts` (no arbitrary post-install), followed by explicit script execution only for reviewed packages.

### 4.3 SLSA-Level Attestation
- Build produces:
  - Binary/container artifact.
  - SBOM (SPDX + CycloneDX).
  - SLSA provenance attestation (build parameters, source ref, hashes).
- All three are signed by build-time signing keys under the Release Signing Hierarchy (AS-K-09).

### 4.4 Reproducibility
- Deterministic timestamps, sorted file order, pinned locale, pinned toolchain versions.
- Two independent CI environments (e.g., self-hosted + cloud CI) produce the same hash for a given source tree; only concurring hashes are release-signed.
- Non-reproducibility of a specific artifact must be documented with rationale; the artifact is signed only after two independent builds concur *modulo* documented sources of non-determinism.

## 5. Signing Hierarchy for Releases

- **Root Signing Key (Z0-anchored)** — used only at ceremony, only to issue **Release Signing Sub-Roots**.
- **Release Signing Sub-Roots** — per release channel (stable, beta, air-gap-static). Long-lived (12 months), rotated by ceremony.
- **Release Signing Keys** — short-lived (24-72 h) leaves used by CI to sign a specific release; issued by Sub-Roots at ceremony/manual-trigger with two-party approval.
- **Configuration Bundle Keys** — separate hierarchy for configuration signing.
- **Detection Content Keys** — separate hierarchy for Sigma-rule signing (see §7).
- **Model Provenance Keys** — separate hierarchy for model weight attestation (see §8).

Distinct hierarchies mean compromise of a release-signing key cannot be used to sign detection rules or models, and vice versa.

## 6. Runtime Verification

### 6.1 Container Admission
- Deployment guides ship signed admission policies (Kyverno / OPA Gatekeeper) that require:
  - Image is signed by a known Release Signing Sub-Root.
  - Image has a SLSA-3+ provenance attestation.
  - Image digest matches a Z0-anchored release-hash registry entry.
- Kernel Runtime Integrity Verification (ARCH-13 §5) hashes loaded binaries + libraries at runtime and includes those hashes in Integrity Beacons.

### 6.2 Config Verification
- Kernel loads only signed configuration bundles; unsigned config fails to boot.
- Post-boot config reload verifies signature before applying.

### 6.3 SBOM at Runtime
- Every deployment can produce its current effective SBOM on demand.
- Continuous SCA scans the effective SBOM against a vulnerability feed; findings surface in AEGIS's own dashboard (self-monitoring).

### 6.4 Kill Switch
- The Kernel supports a **Halt-Unverified** capability: on release-hash-registry alarm, unverified components fail closed on next capability request.

## 7. Detection Content (Sigma Rules)

### 7.1 Contributor Trust
- Each rule source (community feed, vendor, AEGIS-internal) has a **Content Provenance Identity** (CPI) and a signing key.
- Rules are signed at source; AEGIS re-signs after review + fixture pass.
- Unsigned rules are quarantined.

### 7.2 Fixture Tests
- Every rule ships with at least one positive and one negative fixture.
- CI runs fixtures on rule ingestion; failure blocks publish.
- Fixtures are themselves signed and tracked as evidence per ARCH-12.

### 7.3 Deployment Path
- Rule bundles are signed by AEGIS's Detection Content Sub-Root at ceremony.
- Detection Engine verifies signatures on rule load; refuses on mismatch.

### 7.4 Ongoing Verification
- Rule performance is monitored; regression detects rules that suddenly change true-positive rate — surfaced to Detection Engineering review.

## 8. AI Model Provenance

### 8.1 Model Weights
- Model weights are large binary artifacts with heavy download costs; extra care required.
- Each release channel pins a specific model version + hash.
- Weights are downloaded once, hash-verified, and stored in an immutable local cache; runtime always loads from the cache and re-verifies.

### 8.2 Model Provenance Attestation
- Where the upstream provider (e.g., Qwen, Llama teams) publishes provenance signatures, AEGIS verifies and stores them.
- Where not, AEGIS captures the download URL, hash, and a documented delivery attestation (multi-mirror agreement + independent replication of the hash).

### 8.3 Canary Evaluations
- Every model is subjected to a canary eval suite before promotion to production:
  - Standard capability benchmarks (control).
  - Adversarial evals: prompt-injection resistance, refusal-manipulation, hallucination-in-security-context.
  - AEGIS-specific evals: correlation reasoning, evidence-citation correctness, redaction adherence.
- Regressions block promotion.

### 8.4 Runtime Load Verification
- L2 runtime hash-verifies weights on load; mismatch triggers alarm.
- AI Engine records model provenance in every AI request's audit record (ARCH-11 pipeline).

## 9. Plugin Governance (interface only in v0; full in ARCH-15/B.3)

- Every plugin has a signed manifest declaring capabilities, resource limits, network egress needs.
- Publisher identity is verified against a known publisher registry; unknown publishers are quarantined.
- On install: 4-eyes; capability grant per manifest.
- On execution: sandbox (ARCH-15); audit every capability use.
- Kill-switch: `Kill-Plugin` revokes and halts; broadcast on control bus.

## 10. Air-Gap Update Path

### 10.1 Bundle Format
- Air-gap release bundle = signed archive containing: images, config, detection content, model weights, SBOM, SLSA provenance, verifier CLI.
- Bundle signed by Release Signing Sub-Root for the air-gap channel.

### 10.2 Delivery
- Physical media or one-way transfer.
- On ingress: bundle hash verified against a Z0-anchored public key; signature verified; SBOM parsed; SCA run against embedded vulnerability feed.
- After ingest: components extracted to release registry; deployment tools verify at install time.

### 10.3 Rollback
- Previous bundle retained; rollback verified via same path.

## 11. Continuous Vulnerability Management

- SBOM watched by SCA continuously; findings tracked per severity per component.
- Automated PRs for low-risk dependency bumps; manual review for higher-risk.
- Time-to-remediate SLOs per severity documented and reported.

## 12. Transparency and Verifiability

### 12.1 Public Verification
- Release hashes published to a durable public log (Sigstore Rekor or equivalent).
- SBOM published per release.
- SLSA provenance published per release.
- Verifier CLI open-source and reproducibly-buildable.

### 12.2 Zero-SPOT Signing
- Release Signing Sub-Root operations are ceremony-controlled with a minimum of two operators + an auditor observing.
- Future readiness: threshold cryptography for signing (n-of-m).

## 13. Independent Architecture Review

### 13.1 Hidden Assumptions

| Assumption | Handling |
|---|---|
| npm/cargo ecosystems remain trustworthy enough with SBOM + SCA. | Continuous scan; policy-controlled trust tiers per dependency. |
| Reproducibility of TypeScript/Node builds is achievable. | Partially yes with disciplined builds; documented sources of non-determinism; two-CI concur; roadmap improves over time. |
| Community Sigma rule sources will remain viable. | If not, AEGIS's own detection content pipeline can produce rules. |

### 13.2 SPOFs

| Finding | Response |
|---|---|
| **F-1.** *CI infrastructure compromise → bad release.* | Two independent CI environments produce the same hash; ceremony signing is not automatic; drift alerts. |
| **F-2.** *Vulnerability feed provider outage → SCA can't update.* | Multiple feeds; local cache with staleness alerts. |
| **F-3.** *Model provider takes model offline.* | Local cache retains; multiple mirrors; documented mirror procedure. |

### 13.3 Privilege Escalation

| Finding | Response |
|---|---|
| **F-4.** *Compromised contributor merges a backdoored dependency.* | Two-approver on security-critical paths; SAST + SCA; dependency review of any new dep; provenance-check. |
| **F-5.** *Signing key stolen and used to sign malicious release.* | Short-lived leaf; sub-root ceremony-controlled; transparency log surfaces unexpected releases publicly. |

### 13.4 Trust-Boundary Violations

| Finding | Response |
|---|---|
| **F-6.** *Sigma rule content leaks internal detection secrets.* | Rules are classified C; internal-only sub-set stays private; community-contributed rules kept separate from AEGIS-authored. |

### 13.5 Bottlenecks

| Finding | Response |
|---|---|
| **F-7.** *Air-gap update cadence too slow for critical patches.* | Emergency channel with pre-attested images; documented emergency runbook. |

### 13.6 Supply Chain (dedicated)

| Finding | Response |
|---|---|
| **F-8.** *Compiler backdoor (Ken-Thompson class attack).* | Detected only by cross-toolchain diverse-double-compile efforts; roadmap item; documented residual risk. |
| **F-9.** *Malicious package impersonation (typosquatting).* | Explicit allow-list of dependencies; dependency review; automated typosquat detection. |
| **F-10.** *Compromised container base.* | Distroless/hardened base; digest pinning; regular rebuild + re-scan. |
| **F-11.** *Upstream model weight replaced by attacker in registry.* | Hash-pinned + provenance-verified + canary eval; local cache immutable. |

### 13.7 AI-Specific Risks

| Finding | Response |
|---|---|
| **F-12.** *Model backdoored with a specific-trigger poisoning attack.* | Canary evals include AEGIS-specific eval suite; consensus across L2 primary + fallback; long-term trust decay if outputs diverge. |
| **F-13.** *Prompt-injection template smuggled into ai prompt-template bundle.* | Prompt templates are signed like detection content; changes reviewed; runtime hash-verified. |

### 13.8 Operational Risks

| Finding | Response |
|---|---|
| **F-14.** *SBOM churn creates review fatigue.* | Batching + risk-based triage + auto-approval for low-risk classes. |
| **F-15.** *Air-gap ingest requires human on both sides — slow.* | Rehearsed process; scripted where safe; emergency channel. |

## 14. Adversarial Architect Review

| Attack path | Design response |
|---|---|
| **A-1.** Compromise an upstream npm package that AEGIS depends on. | SBOM + SCA + dependency review; hash-pinned; runtime verification of critical libs (RIV — ARCH-13); trust-tier restrictions. |
| **A-2.** Compromise the AEGIS build system to insert a backdoor at compile time. | Two-CI reproducibility; ceremony signing not automatic; transparency log surfaces the release. |
| **A-3.** Compromise the model provider (upstream registry) to substitute weights. | Hash-pinned; local immutable cache; canary evals surface behavioral shifts; provenance attestation cross-checked. |
| **A-4.** Compromise a Sigma rule feed to disable specific detections. | Signed contributor + fixture-required + regression monitor; missing-detection anomalies surface. |
| **A-5.** Air-gap bundle tampered en route. | Signature + hash verification on ingress; Z0-anchored public key. |
| **A-6.** Insider signs a malicious plugin as "trusted publisher". | Publisher signing is ceremony-controlled; publisher trust reviewed; kill-switch available. |
| **A-7.** Long-persistence attacker slowly gains committer trust to a critical path. | Two-approver on security-critical paths; commit-signing identity is a small enumerated set; policy alerts on unusually-broad commits. |
| **A-8.** Cloud CI provider compromise. | Independent CI (self-hosted) reproduces; concurring hash required for release; transparency log. |

## 15. Attacker's First-Target Analysis and Redesign

**"If I were an experienced attacker, what part of this design would I target first?"**

**Model provenance for L2.** Reason: model weight artifacts are large, downloaded from third parties, and their behavior is not fully specified by hashes — subtle backdoors can produce behavior that passes standard benchmarks but misbehaves under specific triggers. Model provenance is also relatively new territory compared to source-code supply chain, so tooling and habits are less mature.

**Redesign response.**

1. **AEGIS-specific canary evals** in addition to standard capability benchmarks. Evals target: prompt-injection resistance, refusal-manipulation resistance, correct citation behavior, correct redaction adherence, hallucination rate in a security-reasoning context. Regressions block promotion. This defeats "passes benchmarks but not our task."
2. **Multi-model consensus for R/HR classifications** (already in place per D-04-2 / ARCH-03 §5): a single-model compromise doesn't produce silent misbehavior on the highest-stake classifications.
3. **Trust decay on divergence.** If L2 primary and fallback diverge on a canary evaluation, primary's trust decays; policy routes to fallback until reviewed. Attacker who compromises just one model gets progressively less use.
4. **Immutable local cache.** Once a model version is loaded and verified, the cache is immutable; a compromised registry cannot silently re-verify a different artifact.
5. **Model versioning tied to release hierarchy.** Each release channel pins model version; runtime refuses unpinned versions. This makes drift a release-time decision, not a runtime surprise.
6. **Second attack target after redesign:** the **npm/cargo ecosystem**. Response: dependency allow-list; two-approver on any addition; runtime library hashes verified via RIV; transparent-log-published SBOM enables the community to catch anomalies.

Repeated: further targets: **the release-signing sub-root ceremony**. If ceremony is compromised (rogue operator + collusion), the whole trust chain is at risk. Response: multi-party required at every ceremony; recording; auditor observer; drift monitor on release cadence and release surface; residual risk accepted with governance as compensating control.

No further high-impact silent-compromise vector identified at this abstraction.

## 16. Decisions

### D-14-1. Two-CI reproducibility as the signing pre-condition

- **Advantages.** Compromise of a single CI cannot ship a bad release; strong integrity assertion.
- **Disadvantages.** More CI cost; reproducibility engineering.
- **Security Impact.** *Strongly positive.*
- **Performance Impact.** N/A (build-time only).
- **Operational Complexity.** *Higher* — offset by significant integrity gain.
- **Maintainability.** *Positive* — reproducibility is a discipline that pays back in debuggability.
- **Scalability.** *Positive.*
- **Alternatives.** *Single-CI + signature.* Rejected — one compromise wins. *No signing.* Rejected.
- **Reason.** Best structural defense against build-time compromise.

### D-14-2. Separate signing hierarchies per artifact class

- **Advantages.** Compromise containment; audit clarity; per-hierarchy rotation.
- **Disadvantages.** More keys to manage.
- **Security Impact.** *Strongly positive.*
- **Performance Impact.** N/A.
- **Operational Complexity.** *Moderate.*
- **Maintainability.** *Positive.*
- **Scalability.** *Positive.*
- **Alternatives.** *Single hierarchy.* Concentrates trust; rejected.
- **Reason.** Zero SPOT applied to signing.

### D-14-3. AEGIS-specific canary evals as a promotion gate for models

- **Advantages.** Addresses the primary redesign target (§15); catches subtle behavioral regressions.
- **Disadvantages.** Eval design and maintenance is a real investment.
- **Security Impact.** *Strongly positive.*
- **Performance Impact.** N/A (release-time).
- **Operational Complexity.** *Moderate.*
- **Maintainability.** *Positive* — eval suites double as regression harnesses.
- **Scalability.** *Positive.*
- **Alternatives.** *Standard benchmarks only.* Insufficient; rejected.
- **Reason.** Model provenance is the primary attacker target; this is the primary defense.

### D-14-4. Transparency log for release hashes (Future Readiness path adopted early)

- **Advantages.** Public verifiability; catches unexpected releases; community defense.
- **Disadvantages.** Requires infrastructure or dependency on an external log.
- **Security Impact.** *Strongly positive.*
- **Performance Impact.** N/A.
- **Operational Complexity.** *Moderate.*
- **Maintainability.** *Positive.*
- **Scalability.** *Positive.*
- **Alternatives.** *No transparency log.* Rejected.
- **Reason.** Long-term durability of trust requires public verifiability.

## 17. Open Questions

- Q-14-1. Transparency log choice (Sigstore Rekor + self-hosted witness vs. multi-log). Resolved in ARCH-16.
- Q-14-2. Compiler diversity for Ken-Thompson-class defense. Roadmap.
- Q-14-3. Threshold-cryptography adoption for signing sub-roots. Roadmap tied to library maturity.
- Q-14-4. Threat-intel-feed governance for post-v0. Resolved in ARCH-18.

## 18. Change Log

- **0.1 (2026-07-10)** — Initial draft after two-reviewer discipline.