docs: Archive Sprint 3500 (PoE), Sprint 7100 (Proof Moats), and additional sprints

Archive completed sprint documentation and deliverables:

## SPRINT_3500 - Proof of Exposure (PoE) Implementation (COMPLETE )
- Windows filesystem hash sanitization (colon → underscore)
- Namespace conflict resolution (Subgraph → PoESubgraph)
- Mock test improvements with It.IsAny<>()
- Direct orchestrator unit tests
- 8/8 PoE tests passing (100% success)
- Archived to: docs/implplan/archived/2025-12-23-sprint-3500-poe/

## SPRINT_7100.0001 - Proof-Driven Moats Core (COMPLETE )
- Four-tier backport detection system
- 9 production modules (4,044 LOC)
- Binary fingerprinting (TLSH + instruction hashing)
- VEX integration with proof-carrying verdicts
- 42+ unit tests passing (100% success)
- Archived to: docs/implplan/archived/2025-12-23-sprint-7100-proof-moats/

## SPRINT_7100.0002 - Proof Moats Storage Layer (COMPLETE )
- PostgreSQL repository implementations
- Database migrations (4 evidence tables + audit)
- Test data seed scripts (12 evidence records, 3 CVEs)
- Integration tests with Testcontainers
- <100ms proof generation performance
- Archived to: docs/implplan/archived/2025-12-23-sprint-7100-proof-moats/

## SPRINT_3000_0200 - Authority Admin & Branding (COMPLETE )
- Console admin RBAC UI components
- Branding editor with tenant isolation
- Authority backend endpoints
- Archived to: docs/implplan/archived/

## Additional Documentation
- CLI command reference and compliance guides
- Module architecture docs (26 modules documented)
- Data schemas and contracts
- Operations runbooks
- Security risk models
- Product roadmap

All archived sprints achieved 100% completion of planned deliverables.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
master
2025-12-23 15:02:38 +02:00
parent fda92af9bc
commit b444284be5
77 changed files with 7673 additions and 556 deletions

View File

@@ -14,6 +14,7 @@ Assumptions baked into docs2
How to navigate
- product/overview.md - Vision, capabilities, and requirements
- product/roadmap-and-requirements.md - Requirements and roadmap summary
- architecture/overview.md - System map and dependencies
- architecture/workflows.md - Key data and control flows
- architecture/evidence-and-trust.md - Evidence chain, DSSE, replay, AOC
@@ -21,16 +22,27 @@ How to navigate
- modules/index.md - Module summaries (core and supporting)
- operations/install-deploy.md - Install and deployment guidance
- operations/airgap.md - Offline kit and air-gap operations
- operations/replay-and-determinism.md - Replay artifacts and deterministic rules
- operations/runbooks.md - Operational runbooks and incident response
- release/release-engineering.md - Release and CI/CD overview
- api/overview.md - API surface and conventions
- api/auth-and-tokens.md - Authority, OpTok, DPoP and mTLS, PoE
- cli-ui.md - CLI and console guide
- data-and-schemas.md - Storage, schemas, and determinism rules
- data/persistence.md - Database model and migration notes
- data/events.md - Event envelopes and validation
- security-and-governance.md - Security policy, hardening, governance, compliance
- security/risk-model.md - Risk scoring model and explainability
- security/forensics-and-evidence-locker.md - Evidence locker and forensic storage
- contracts-and-interfaces.md - Cross-module contracts and specs
- task-packs.md - Task Runner pack format and workflow
- testing-and-quality.md - Test strategy and quality gates
- observability.md - Metrics, logs, tracing, telemetry stack
- developer/onboarding.md - Local dev setup and workflows
- developer/plugin-sdk.md - Plugin SDK summary
- sdk/overview.md - SDK and client guidance
- benchmarks.md - Benchmark program overview
- training-and-adoption.md - Evaluation checklist and training material
- glossary.md - Core terms
Notes

View File

@@ -15,6 +15,26 @@
- Export Center: export runs and offline bundles.
- Authority: token issuance and administrative endpoints.
## Contracts and schemas
- OpenAPI specs live under docs/api/.
- JSON schemas live under docs/schemas/ and docs/contracts/.
## OpenAPI specifications
- docs/api/delta-compare-openapi.yaml
- docs/api/evidence-decision-api.openapi.yaml
- docs/api/graph-gateway-spec-draft.yaml
- docs/api/notify-openapi.yaml
- docs/api/proofs-openapi.yaml
- docs/api/taskrunner-openapi.yaml
- docs/api/vexlens-openapi.yaml
- docs/modules/export-center/openapi/export-center.v1.yaml
- docs/modules/findings-ledger/openapi/findings-ledger.v1.yaml
- docs/modules/vuln-explorer/openapi/vuln-explorer.v1.yaml
- docs/schemas/excititor-chunk-api.openapi.yaml
- docs/schemas/findings-evidence-api.openapi.yaml
- docs/schemas/findings-ledger-api.openapi.yaml
- docs/schemas/graph-platform-api.openapi.yaml
- docs/schemas/ledger-time-travel-api.openapi.yaml
- docs/schemas/policy-engine-rest.openapi.yaml
- docs/schemas/policy-registry-api.openapi.yaml
## Schema and contract catalogs
- docs/schemas: JSON schemas and OpenAPI fragments.
- docs/contracts: protocol and contract definitions.
- docs/api: API references and gateway specs.

View File

@@ -0,0 +1,30 @@
# Contracts and interfaces
Contracts are the authoritative specs for cross module interfaces. They
define data models, API expectations, and integration rules.
Why contracts exist
- Keep module boundaries stable across teams.
- Unblock sprint work by publishing versioned specs.
- Preserve determinism and offline compatibility.
Core contract areas
- Advisory key canonicalization
- Risk scoring jobs and profiles
- Mirror bundle and sealed mode
- VEX Lens and verification policy
- Policy studio and authority effective write
- Export bundle and findings ledger RLS
- API governance baseline
- Scanner surface and analyzer bootstrap
- RichGraph v1 reachability schema
Lifecycle
- Draft, published, deprecated, retired.
- Breaking changes require a new version and migration notes.
Related references
- docs/contracts/README.md
- docs/contracts/*.md
- docs/adr/*
- docs/specs/*

32
docs2/data/events.md Normal file
View File

@@ -0,0 +1,32 @@
# Events and messaging
Platform services emit strongly typed events with JSON schemas. Event files
use the pattern <event-name>@<version>.json and samples mirror the version.
Envelope types
- Orchestrator events: versioned envelopes with idempotency keys and trace context.
- Legacy Redis envelopes: transitional schemas used for older consumers.
Orchestrator envelope fields (v1)
- eventId, kind, version, tenant
- occurredAt, recordedAt
- source, idempotencyKey, correlationId
- traceId, spanId
- scope, payload, attributes
Legacy envelope fields
- eventId, kind, tenant, ts
- scope, payload, attributes
Versioning rules
- Additive changes stay in the same version.
- Breaking changes require a new @<version> schema and matching sample.
- Consumers should pin and log unknown versions.
Validation
- Schemas and samples live under docs/events/ and docs/events/samples/.
- Offline validation uses ajv-cli; keep schema checks deterministic.
Related references
- docs/events/README.md
- docs/runtime/SCANNER_RUNTIME_READINESS.md

34
docs2/data/persistence.md Normal file
View File

@@ -0,0 +1,34 @@
# Persistence and database
StellaOps uses PostgreSQL as the canonical system of record. This document
summarizes the persistence rules, schema layout, and migration approach.
Principles
- Determinism first: stable ordering, UTC timestamps, canonical JSON for hashes.
- Tenant isolation: every row carries tenant_id and row level security is used.
- Gradual migration: Mongo to Postgres via a strangler approach with rollback.
- JSONB for flexibility: semi structured payloads stay JSONB; core entities are normalized.
Schema families (authoritative DDLs)
- authority, vuln, vex, scheduler, notify, policy
- packs are included with policy
- issuer and audit are staged or proposed
Operational inputs
- Config template: docs/db/persistence-config-template.yaml
- Cluster provisioning: docs/db/cluster-provisioning.md
- Local dev: docs/db/local-postgres.md
Change control and verification
- Follow rules in docs/db/RULES.md for naming, constraints, and RLS.
- Use docs/db/SPECIFICATION.md as the schema source of truth.
- Verify changes using docs/db/VERIFICATION.md before release.
Migration notes
- Conversion planning: docs/db/CONVERSION_PLAN.md
- Module phased tasks: docs/db/tasks/PHASE_*.md
- Reports and verification evidence live under docs/db/reports/
Related references
- ADR: docs/adr/0001-postgresql-for-control-plane.md
- Module architecture: docs/modules/*/architecture.md

View File

@@ -0,0 +1,23 @@
# Advisory AI
## Purpose
Evidence-grounded analysis with guardrails and offline outputs.
## Inputs
- SBOMs and evidence bundles
## Outputs
- Structured findings and guidance artifacts
## Data and storage
- PostgreSQL and artifact store
## Key dependencies
- Scanner outputs
- Policy evidence
## Notes and boundaries
- Guardrails required for outputs
## Related docs
- docs/modules/advisory-ai/architecture.md

23
docs2/modules/attestor.md Normal file
View File

@@ -0,0 +1,23 @@
# Attestor
## Purpose
Log DSSE bundles to Rekor and provide verification.
## Inputs
- DSSE bundles from Signer or Scanner
## Outputs
- Rekor entries and inclusion proofs
## Data and storage
- PostgreSQL receipts and indexes
## Key dependencies
- Rekor (optional)
- Authority
## Notes and boundaries
- Does not sign
## Related docs
- docs/modules/attestor/architecture.md

View File

@@ -0,0 +1,28 @@
# Authority
## Purpose
Issue short-lived OpTok tokens with DPoP or mTLS sender constraints.
## Inputs
- Client credentials, device code, or auth code
- Signing keys and JWKS configuration
## Outputs
- JWT access tokens with audience and scope claims
- JWKS and optional introspection responses
## Data and storage
- PostgreSQL for clients, roles, tenants
- Valkey for DPoP nonce and jti caches
## Key dependencies
- PostgreSQL
- Valkey
- Optional KMS or HSM
## Notes and boundaries
- Does not issue PoE
- Tokens are operational and short-lived
## Related docs
- docs/modules/authority/architecture.md

View File

@@ -0,0 +1,22 @@
# Benchmark
## Purpose
Benchmark harness and ground-truth corpus management.
## Inputs
- Corpora, fixtures, and tooling
## Outputs
- Benchmark results and reports
## Data and storage
- Bench artifacts and fixtures
## Key dependencies
- Scanner and Policy
## Notes and boundaries
- Determinism and accuracy checks
## Related docs
- docs/modules/benchmark/architecture.md

View File

@@ -0,0 +1,22 @@
# BinaryIndex
## Purpose
Binary identity mapping for patch-aware matching.
## Inputs
- Binary identifiers and metadata
## Outputs
- Binary to advisory mappings
## Data and storage
- PostgreSQL
## Key dependencies
- Scanner analyzers
## Notes and boundaries
- Complements patch and backport handling
## Related docs
- docs/modules/binaryindex/architecture.md

22
docs2/modules/ci.md Normal file
View File

@@ -0,0 +1,22 @@
# CI Recipes
## Purpose
Deterministic CI pipeline templates and guardrails.
## Inputs
- Source code and build inputs
## Outputs
- Reproducible build and test flows
## Data and storage
- Pipeline templates
## Key dependencies
- Build tooling
## Notes and boundaries
- Offline-friendly pipelines
## Related docs
- docs/modules/ci/architecture.md

25
docs2/modules/cli.md Normal file
View File

@@ -0,0 +1,25 @@
# CLI
## Purpose
Automation and verification for scanning, export, and replay.
## Inputs
- User commands and offline bundles
## Outputs
- API calls and local verification reports
## Data and storage
- Local cache and artifacts
## Key dependencies
- Authority
- Scanner
- Signer
- Attestor
## Notes and boundaries
- CLI never signs directly
## Related docs
- docs/modules/cli/architecture.md

View File

@@ -0,0 +1,25 @@
# Concelier
## Purpose
Ingest advisory feeds under the Aggregation-Only Contract (AOC).
## Inputs
- Vendor and ecosystem advisories
## Outputs
- Raw advisory facts and linksets
- Deterministic exports
## Data and storage
- PostgreSQL vuln schema
## Key dependencies
- Authority
- PostgreSQL
## Notes and boundaries
- No derived severity at ingest
## Related docs
- docs/modules/concelier/architecture.md
- docs/ingestion/aggregation-only-contract.md

22
docs2/modules/devops.md Normal file
View File

@@ -0,0 +1,22 @@
# DevOps and Release
## Purpose
Release trains, signing, and distribution workflows.
## Inputs
- Build outputs and manifests
## Outputs
- Signed images, SBOMs, and release bundles
## Data and storage
- Release manifests and artifact indexes
## Key dependencies
- Signer and Attestor
## Notes and boundaries
- Supports offline kit packaging
## Related docs
- docs/modules/devops/architecture.md

View File

@@ -0,0 +1,23 @@
# Excititor
## Purpose
Ingest VEX statements under AOC and preserve conflicts.
## Inputs
- OpenVEX, CSAF VEX, CycloneDX VEX
## Outputs
- VEX observations and consensus views
## Data and storage
- PostgreSQL vex schema
## Key dependencies
- Authority
- Issuer Directory
## Notes and boundaries
- No policy decisions at ingest
## Related docs
- docs/modules/excititor/architecture.md

View File

@@ -0,0 +1,23 @@
# Export Center
## Purpose
Produce deterministic export bundles and offline layouts.
## Inputs
- Raw facts, policy outputs, SBOMs
## Outputs
- JSON exports, Trivy DB, mirror bundles
## Data and storage
- RustFS and PostgreSQL
## Key dependencies
- Signer
- Attestor
## Notes and boundaries
- Exports are deterministic and content-addressed
## Related docs
- docs/modules/export-center/architecture.md

22
docs2/modules/gateway.md Normal file
View File

@@ -0,0 +1,22 @@
# Gateway
## Purpose
HTTP ingress and routing for service APIs.
## Inputs
- External requests with tokens
## Outputs
- Routed requests and responses
## Data and storage
- Routing configuration
## Key dependencies
- Authority
## Notes and boundaries
- Optional in some deployments
## Related docs
- docs/modules/gateway/architecture.md

22
docs2/modules/graph.md Normal file
View File

@@ -0,0 +1,22 @@
# Graph Explorer
## Purpose
Graph indexing and exploration APIs.
## Inputs
- Graph snapshots and overlays
## Outputs
- Graph queries and exports
## Data and storage
- PostgreSQL and index artifacts
## Key dependencies
- Scanner and Policy outputs
## Notes and boundaries
- Supports offline export
## Related docs
- docs/modules/graph/architecture.md

View File

@@ -2,150 +2,38 @@
## Core services
Authority
- Purpose: issue OpTok tokens with DPoP or mTLS sender constraints.
- Inputs: client credentials, device code, or auth code.
- Outputs: JWT access tokens with tenant, audience, and scope claims.
- Storage: PostgreSQL for client and tenant data, Valkey for DPoP nonce cache.
Signer
- Purpose: produce DSSE envelopes and enforce Proof of Entitlement (PoE).
- Inputs: signing requests from trusted services and PoE proof.
- Outputs: DSSE bundles for SBOMs, reports, and exports.
- Storage: audit logs only; keys live in KMS or keyless providers.
Attestor
- Purpose: log DSSE bundles to Rekor and provide verification APIs.
- Inputs: DSSE bundles from Signer or Scanner.
- Outputs: Rekor entries and proofs, verification results.
- Storage: PostgreSQL for receipts and indexes.
Scanner (Web + Worker)
- Purpose: deterministic SBOM generation, inventory and usage views, diffs.
- Inputs: image digest or SBOM, analyzer manifests, policy snapshots.
- Outputs: SBOMs, diffs, reachability graphs, evidence bundles.
- Storage: RustFS for artifacts, PostgreSQL for metadata, Valkey for queues.
Concelier
- Purpose: ingest and normalize advisory sources under AOC.
- Inputs: vendor and ecosystem advisory feeds.
- Outputs: raw advisory facts, linksets, deterministic exports.
- Storage: PostgreSQL (vuln schema).
Excititor
- Purpose: ingest VEX statements under AOC and preserve conflicts.
- Inputs: OpenVEX, CSAF VEX, CycloneDX VEX.
- Outputs: normalized VEX observations and consensus views.
- Storage: PostgreSQL (vex schema).
Policy Engine
- Purpose: deterministic policy evaluation with explain traces and unknowns.
- Inputs: SBOM inventory, advisory facts, VEX evidence, reachability.
- Outputs: verdicts, effective findings, decision traces, derived VEX.
- Storage: PostgreSQL (policy schema).
Scheduler
- Purpose: impact selection and analysis-only re-evaluation.
- Inputs: advisory and VEX deltas, BOM index metadata.
- Outputs: rescan jobs and delta events.
- Storage: PostgreSQL (scheduler schema), Valkey for queues.
Notify
- Purpose: route events to channels with rules and templates.
- Inputs: scan and scheduler events.
- Outputs: deliveries to Slack, Teams, email, webhooks.
- Storage: PostgreSQL (notify schema), Valkey for queues.
Export Center
- Purpose: deterministic export bundles and offline mirror layouts.
- Inputs: raw facts, policy outputs, SBOMs and evidence bundles.
- Outputs: JSON exports, Trivy DB exports, mirror bundles, offline kits.
- Storage: RustFS and PostgreSQL.
CLI
- Purpose: automation and verification for scanning, export, and replay.
- Inputs: user commands and offline bundles.
- Outputs: API calls, local verification reports.
UI and Console
- Purpose: operator console for scans, policy, VEX, and notifications.
- Inputs: API responses, SSE streams.
- Outputs: operational workflows and audit views.
Advisory AI
- Purpose: evidence-grounded analysis with guardrails.
- Inputs: SBOM and evidence bundles.
- Outputs: structured findings and guidance artifacts.
Orchestrator
- Purpose: job DAGs and pack runs for automation.
- Inputs: job definitions and run requests.
- Outputs: run status, job artifacts.
- Storage: PostgreSQL (orchestrator schema).
Registry Token Service
- Purpose: issue tokens for internal registry and scoped pulls.
- Inputs: client credentials.
- Outputs: short-lived registry tokens.
Graph Explorer
- Purpose: graph indexing and exploration for evidence and relationships.
- Inputs: graph snapshots and overlays.
- Outputs: graph queries and exports.
VEX Lens
- Purpose: reproducible consensus views over VEX statements.
- Inputs: normalized VEX observations and trust weights.
- Outputs: consensus status and evidence refs.
Vulnerability Explorer
- Purpose: triage workflows and evidence ledger views.
- Inputs: effective findings and Decision Capsules.
- Outputs: triage actions and audit records.
Telemetry Stack
- Purpose: metrics, logs, traces, and dashboards.
- Inputs: service telemetry and audit events.
- Outputs: dashboards and alerts.
DevOps and Release
- Purpose: release trains, signing, and distribution workflows.
- Inputs: build artifacts and manifests.
- Outputs: signed releases and offline kit bundles.
Platform
- Purpose: cross-cutting determinism, offline, and identity rules.
CI Recipes
- Purpose: deterministic CI templates and guardrails.
Zastava
- Purpose: runtime observer and optional admission enforcement.
- Inputs: runtime facts and policy verdicts.
- Outputs: runtime events and admission decisions.
- [Authority](authority.md)
- [Signer](signer.md)
- [Attestor](attestor.md)
- [Scanner](scanner.md)
- [Concelier](concelier.md)
- [Excititor](excititor.md)
- [Policy Engine](policy.md)
- [Scheduler](scheduler.md)
- [Notify](notify.md)
- [Export Center](export-center.md)
- [CLI](cli.md)
- [UI and Console](ui.md)
- [Advisory AI](advisory-ai.md)
- [Orchestrator](orchestrator.md)
- [Registry Token Service](registry.md)
- [Graph Explorer](graph.md)
- [VEX Lens](vex-lens.md)
- [Vulnerability Explorer](vuln-explorer.md)
- [Telemetry Stack](telemetry.md)
- [DevOps and Release](devops.md)
- [Platform](platform.md)
- [CI Recipes](ci.md)
- [Zastava](zastava.md)
## Supporting and adjacent modules
Issuer Directory
- Trust registry for VEX issuers and keys.
VexHub
- Aggregation and distribution of VEX statements for downstream consumers.
SBOM Service
- Deterministic SBOM projections and lineage ledger.
Signals
- Reachability scoring, unknowns registry, and signal APIs.
TaskRunner
- Deterministic task pack execution with approvals and evidence capture.
BinaryIndex
- Binary identity mapping for patch-aware and backport-aware matching.
Benchmark
- Benchmark harness and ground-truth corpus management.
Gateway and Router (optional)
- Edge routing and transport abstraction for deployments that require a shared ingress.
- [Issuer Directory](issuer-directory.md)
- [VexHub](vexhub.md)
- [SBOM Service](sbomservice.md)
- [Signals](signals.md)
- [TaskRunner](taskrunner.md)
- [BinaryIndex](binaryindex.md)
- [Benchmark](benchmark.md)
- [Gateway](gateway.md)
- [Router](router.md)

View File

@@ -0,0 +1,22 @@
# Issuer Directory
## Purpose
Trust registry for VEX issuers and keys.
## Inputs
- Issuer metadata and key material
## Outputs
- Trust weights and issuer resolution
## Data and storage
- PostgreSQL
## Key dependencies
- Authority
## Notes and boundaries
- Consumed by VEX Lens and Excititor
## Related docs
- docs/modules/issuer-directory/architecture.md

24
docs2/modules/notify.md Normal file
View File

@@ -0,0 +1,24 @@
# Notify
## Purpose
Route events to channels with rules and templates.
## Inputs
- Scanner and Scheduler events
## Outputs
- Deliveries to Slack, Teams, email, webhooks
## Data and storage
- PostgreSQL notify schema
- Valkey queues
## Key dependencies
- Valkey
- SMTP or chat APIs
## Notes and boundaries
- Does not make policy decisions
## Related docs
- docs/modules/notify/architecture.md

View File

@@ -0,0 +1,22 @@
# Orchestrator
## Purpose
DAG workflows and pack runs for automation.
## Inputs
- Job definitions and run requests
## Outputs
- Run status and job artifacts
## Data and storage
- PostgreSQL orchestrator schema
## Key dependencies
- Scheduler and TaskRunner
## Notes and boundaries
- Focuses on job orchestration
## Related docs
- docs/modules/orchestrator/architecture.md

23
docs2/modules/platform.md Normal file
View File

@@ -0,0 +1,23 @@
# Platform
## Purpose
Cross-cutting rules for determinism, identity, and offline posture.
## Inputs
- Module policies and shared contracts
## Outputs
- Shared constraints and guidance
## Data and storage
- Docs and shared libraries
## Key dependencies
- All modules
## Notes and boundaries
- Defines baseline invariants
## Related docs
- docs/modules/platform/architecture-overview.md
- docs/modules/platform/architecture.md

27
docs2/modules/policy.md Normal file
View File

@@ -0,0 +1,27 @@
# Policy Engine
## Purpose
Evaluate deterministic policy and produce verdicts with explain traces.
## Inputs
- SBOM inventory
- Advisories
- VEX evidence
- Reachability
## Outputs
- Verdicts, effective findings, derived VEX
## Data and storage
- PostgreSQL policy schema
## Key dependencies
- Concelier
- Excititor
- Signals
## Notes and boundaries
- Only component that produces derived findings
## Related docs
- docs/modules/policy/architecture.md

22
docs2/modules/registry.md Normal file
View File

@@ -0,0 +1,22 @@
# Registry Token Service
## Purpose
Issue short-lived registry access tokens.
## Inputs
- Client credentials and scope
## Outputs
- Scoped registry tokens
## Data and storage
- PostgreSQL or in-memory cache
## Key dependencies
- Authority
## Notes and boundaries
- Tokens are short-lived
## Related docs
- docs/modules/registry/architecture.md

22
docs2/modules/router.md Normal file
View File

@@ -0,0 +1,22 @@
# Router
## Purpose
Transport abstraction for routing to service instances.
## Inputs
- Service registrations and frames
## Outputs
- Routed frames and responses
## Data and storage
- Routing state and endpoint descriptors
## Key dependencies
- Gateway
## Notes and boundaries
- Optional in some deployments
## Related docs
- docs/modules/router/architecture.md

View File

@@ -0,0 +1,22 @@
# SBOM Service
## Purpose
Serve deterministic SBOM projections and lineage.
## Inputs
- SBOMs from Scanner or uploads
## Outputs
- SBOM projections and lineage ledger
## Data and storage
- PostgreSQL and RustFS
## Key dependencies
- Scanner
## Notes and boundaries
- Append-only SBOM versions
## Related docs
- docs/modules/sbomservice/architecture.md

29
docs2/modules/scanner.md Normal file
View File

@@ -0,0 +1,29 @@
# Scanner
## Purpose
Generate deterministic SBOMs, diffs, and reachability evidence.
## Inputs
- Image digest or SBOM
- Analyzer manifests and config
## Outputs
- SBOM inventory and usage views
- Diffs and reports
- Reachability graphs
## Data and storage
- RustFS for artifacts
- PostgreSQL for metadata
- Valkey for queues
## Key dependencies
- RustFS
- PostgreSQL
- Valkey
## Notes and boundaries
- Does not decide pass or fail
## Related docs
- docs/modules/scanner/architecture.md

View File

@@ -0,0 +1,26 @@
# Scheduler
## Purpose
Select impacted images and trigger analysis-only re-evaluation.
## Inputs
- Advisory and VEX deltas
- BOM index metadata
## Outputs
- Re-evaluation jobs and delta events
## Data and storage
- PostgreSQL scheduler schema
- Valkey queues
## Key dependencies
- Scanner WebService
- Concelier
- Excititor
## Notes and boundaries
- Does not rescan by default
## Related docs
- docs/modules/scheduler/architecture.md

23
docs2/modules/signals.md Normal file
View File

@@ -0,0 +1,23 @@
# Signals
## Purpose
Reachability scoring, unknowns registry, and signal APIs.
## Inputs
- Call graphs and runtime facts
## Outputs
- Reachability facts and unknowns records
## Data and storage
- PostgreSQL and artifact store
## Key dependencies
- Scanner and Zastava
## Notes and boundaries
- Deterministic scoring with unknowns pressure
## Related docs
- docs/modules/signals/evidence/README.md
- docs/modules/signals/unknowns/2025-12-01-unknowns-registry.md

25
docs2/modules/signer.md Normal file
View File

@@ -0,0 +1,25 @@
# Signer
## Purpose
Produce DSSE envelopes and enforce Proof of Entitlement (PoE).
## Inputs
- Signing requests from trusted services
- OpTok and PoE
## Outputs
- DSSE bundles for SBOMs, reports, and exports
## Data and storage
- Audit logs only
## Key dependencies
- Authority
- OCI registry referrers
- KMS or Fulcio
## Notes and boundaries
- Does not write to Rekor
## Related docs
- docs/modules/signer/architecture.md

View File

@@ -0,0 +1,22 @@
# TaskRunner
## Purpose
Execute task packs deterministically with approvals and evidence.
## Inputs
- Task pack definitions and run requests
## Outputs
- Run status, artifacts, DSSE bundles
## Data and storage
- PostgreSQL and artifact store
## Key dependencies
- Signer and Attestor
## Notes and boundaries
- Supports sealed mode
## Related docs
- docs/modules/taskrunner/architecture.md

View File

@@ -0,0 +1,22 @@
# Telemetry Stack
## Purpose
Metrics, logs, traces, dashboards, and alerts.
## Inputs
- Service telemetry and audit logs
## Outputs
- Dashboards and alert rules
## Data and storage
- Telemetry store and dashboards
## Key dependencies
- All services
## Notes and boundaries
- Offline bundle support
## Related docs
- docs/modules/telemetry/architecture.md

22
docs2/modules/ui.md Normal file
View File

@@ -0,0 +1,22 @@
# UI and Console
## Purpose
Operator console for scans, policy, VEX, and notifications.
## Inputs
- API responses and event streams
## Outputs
- Workflow actions and audit views
## Data and storage
- Browser storage for preferences
## Key dependencies
- Backend APIs
## Notes and boundaries
- Offline-friendly, no external CDN
## Related docs
- docs/modules/ui/architecture.md

23
docs2/modules/vex-lens.md Normal file
View File

@@ -0,0 +1,23 @@
# VEX Lens
## Purpose
Compute reproducible consensus views over VEX statements.
## Inputs
- VEX observations and trust weights
## Outputs
- Consensus status and evidence refs
## Data and storage
- PostgreSQL
## Key dependencies
- Excititor and Issuer Directory
## Notes and boundaries
- Preserves conflicts and provenance
## Related docs
- docs/modules/vex-lens/architecture.md
- docs/modules/vexlens/architecture.md

22
docs2/modules/vexhub.md Normal file
View File

@@ -0,0 +1,22 @@
# VexHub
## Purpose
Aggregate and distribute VEX statements.
## Inputs
- Upstream VEX sources
## Outputs
- Normalized VEX feeds
## Data and storage
- PostgreSQL
## Key dependencies
- Excititor
## Notes and boundaries
- Feeds VEX Lens and Policy
## Related docs
- docs/modules/vexhub/architecture.md

View File

@@ -0,0 +1,22 @@
# Vulnerability Explorer
## Purpose
Triage workflows and evidence ledger views.
## Inputs
- Effective findings and Decision Capsules
## Outputs
- Triage actions and audit records
## Data and storage
- PostgreSQL
## Key dependencies
- Policy Engine and evidence bundles
## Notes and boundaries
- Triage is evidence-linked
## Related docs
- docs/modules/vuln-explorer/architecture.md

22
docs2/modules/zastava.md Normal file
View File

@@ -0,0 +1,22 @@
# Zastava
## Purpose
Runtime observer and optional admission enforcement.
## Inputs
- Runtime facts, policy verdicts
## Outputs
- Runtime events and admission decisions
## Data and storage
- Local cache and event stream
## Key dependencies
- Scanner WebService and Policy
## Notes and boundaries
- Does not compute SBOMs
## Related docs
- docs/modules/zastava/architecture.md

View File

@@ -0,0 +1,46 @@
# Replay and determinism
Deterministic replay lets any scan be reproduced byte for byte. The replay
system captures every input, environment detail, and output hash.
Core artifacts
- Replay manifest (canonical JSON)
- Input bundle (feeds, policies, tools)
- Output bundle (SBOM, findings, VEX, logs)
- DSSE envelopes for each artifact
- Merkle summaries for layers and feed chunks
Replay manifest sections
- scan: id, time, versions, crypto profile
- subject: image digest and layer merkle roots
- inputs: feeds, rules, tool hashes, env normalization
- policy: lattice and mute hashes
- outputs: hashes for SBOM, findings, VEX, logs
- reachability: graph and runtime trace references
- provenance: signer and optional ledger anchors
Deterministic execution rules
- Freeze time to scan.time unless explicitly overridden.
- Use stable ordering for traversal and output serialization.
- Derive RNG seeds from scan id and layer merkle roots.
- Canonicalize JSON before hashing or signing.
Verification and CLI
- stella scan --record produces manifest and bundles.
- stella verify checks hashes and DSSE signatures.
- stella replay re-runs with strict or what-if modes.
- stella diff compares manifests and highlights drift.
Storage
- replay_runs, bundles, subjects tables in PostgreSQL.
- CAS locations use content addressed naming.
Offline posture
- All inputs must be included in the replay bundle.
- Trust anchors are supplied via RootPack snapshots.
Related references
- docs/replay/DETERMINISTIC_REPLAY.md
- docs/replay/DEVS_GUIDE_REPLAY.md
- docs/replay/TEST_STRATEGY.md
- docs/runbooks/replay_ops.md

View File

@@ -0,0 +1,29 @@
# Operations runbooks
Runbooks capture operational procedures for incidents, replay verification,
policy emergencies, and airgap workflows. They are designed to be offline
and deterministic.
Runbook set (current)
- docs/runbooks/assistant-ops.md
- docs/runbooks/incidents.md
- docs/runbooks/policy-incident.md
- docs/runbooks/reachability-runtime.md
- docs/runbooks/replay_ops.md
- docs/runbooks/vex-ops.md
- docs/runbooks/vuln-ops.md
Common expectations
- Hash and store any inbound artifacts with SHA256SUMS.
- Record UTC timestamps and stable ordering in logs.
- Avoid external network calls unless explicitly permitted.
- Keep links to the relevant specs and schemas for verification.
Operational evidence
- Replay verification logs
- Policy decision evidence bundles
- Incident timelines and postmortems
Related references
- docs/operations/*
- docs/airgap/*

View File

@@ -0,0 +1,33 @@
# Roadmap and requirements
This document consolidates high level requirements and the public roadmap.
Implementation detail belongs in module architecture and ADRs.
System requirements (high level)
- Ingest SBOM formats: Trivy JSON, SPDX JSON, CycloneDX JSON.
- Auto detect SBOM type when missing.
- Cache and reuse layer analysis for delta scans.
- Enforce daily quota with HTTP 429 and reset at UTC midnight.
- Policy engine evaluates YAML rules and supports history.
- Hot load plugins without service restart.
- Offline first: no required internet access at runtime.
Non functional requirements (high level)
- Deterministic outputs and replayability.
- P95 cold scan and warm scan targets.
- TLS for inter service traffic.
- Observability for scan and policy metrics.
Roadmap
- Public milestones live on the project site.
Feature matrix (summary)
- Free tier includes core SBOM ingestion, policy, registry, and UI.
- Reachability DSSE and advanced attestation are staged.
- Offline update kits and sovereign crypto profiles are first class.
Related references
- docs/05_SYSTEM_REQUIREMENTS_SPEC.md
- docs/04_FEATURE_MATRIX.md
- docs/05_ROADMAP.md
- docs/03_VISION.md

View File

@@ -0,0 +1,43 @@
# Release engineering
Release engineering turns main into signed, reproducible, airgap friendly
artifacts. Builds must be deterministic and verifiable offline.
Release philosophy
- Every commit on main is releasable.
- Builds are reproducible and offline friendly.
- All artifacts ship with SBOMs and signatures.
Versioning and branches
- main: nightly images
- release/X.Y: stabilization branch
- tags X.Y.Z: signed releases
Pipeline stages (high level)
- Lint, unit tests, build, container tests
- SBOM generation and provenance
- Signing and publishing
- End to end tests and notifications
Artifact signing
- Cosign for containers and bundles
- DSSE envelopes for attestations
- Optional Rekor anchoring when available
Offline update kit (OUK)
- Monthly bundle of feeds and tooling
- Signed tarball with hashes and offline token
Release checks
- Verify SBOM attachment and signatures
- Run release verifier scripts
- Smoke test offline kit
Hotfixes
- Branch from latest tag, minimal patch, retag and publish
Related references
- docs/13_RELEASE_ENGINEERING_PLAYBOOK.md
- docs/ci/*
- docs/devops/*
- docs/release/* and docs/releases/*

20
docs2/sdk/overview.md Normal file
View File

@@ -0,0 +1,20 @@
# SDKs overview
SDKs provide client access to StellaOps APIs with offline friendly defaults.
The current SDK docs are outlines and will be expanded when generators land.
Current languages
- Go, Java, Python, TypeScript
Expected behavior
- Generated from OpenAPI specs with pinned versions.
- Auth helpers for token, DPoP, and mTLS flows.
- Deterministic pagination and retry behavior.
- No implicit network calls beyond the configured endpoints.
Related references
- docs/sdks/overview.md
- docs/sdks/go.md
- docs/sdks/java.md
- docs/sdks/python.md
- docs/sdks/typescript.md

View File

@@ -0,0 +1,33 @@
# Forensics and evidence locker
The evidence locker is a WORM friendly store for audit and forensic artifacts
such as bundles, logs, and attestations.
Storage model
- Object storage with immutable retention and versioning.
- PostgreSQL index with metadata and retention fields.
Ingest rules
- Append only, content addressed paths.
- Require tenant, hash, size, and provenance.
- Reject partial uploads or missing signatures.
Retention and legal hold
- Default retention per tenant.
- Legal hold blocks deletion until cleared by approval.
- Daily retention job emits audit logs.
Access and verification
- RBAC scopes for read, write, and legal hold.
- Verify hashes and DSSE signatures on demand.
- Background sampling emits failure events.
Minimum bundle layout
- manifest.json with hashes and provenance
- data/ payloads
- signatures/ for DSSE or sigstore bundles
Related references
- docs/forensics/evidence-locker.md
- docs/forensics/provenance-attestation.md
- docs/evidence-locker/evidence-pack-schema.md

View File

@@ -0,0 +1,35 @@
# Risk model and scoring
Risk scoring turns evidence into a normalized score and severity band. The
model is deterministic and explainable.
Core concepts
- Signals become evidence after validation.
- Evidence is normalized into factors.
- Profiles define weights, thresholds, and overrides.
- Formulas aggregate factors into scores and severity.
Lifecycle
1. Job submit with tenant, profile, and findings.
2. Evidence ingestion from scanners, reachability, and VEX.
3. Normalization and dedupe by provenance hash.
4. Profile evaluation with gates and overrides.
5. Severity assignment and explainability output.
6. Export to Findings Ledger and Export Center.
Artifacts
- Profile schema: signals, weights, overrides, provenance.
- Job and result schema: score, severity, contributions.
- Explainability payloads for UI and CLI.
Determinism rules
- Stable ordering for factors and signals.
- Fixed precision math and UTC timestamps.
- Hashes and provenance recorded for every input.
Related references
- docs/risk/overview.md
- docs/risk/factors.md
- docs/risk/formulas.md
- docs/risk/profiles.md
- docs/risk/api.md

30
docs2/task-packs.md Normal file
View File

@@ -0,0 +1,30 @@
# Task packs
Task packs are deterministic, auditable workflows executed by Task Runner.
They are distributed as signed bundles and can run online or offline.
Pack structure
- pack.yaml manifest
- assets, schemas, docs
- provenance and signatures
Key features
- Deterministic plan and execution graph
- Approval gates and policy gates
- Evidence bundles with plan hashes and artifacts
- RBAC scopes for discover, run, and approve
Determinism and validation
- Canonical plan hash and inputs lock file
- Stable ordering and fixed timestamps
- Fail closed if approvals or hashes are missing
Publishing
- Validate, build, sign, and push to registry or OCI
- Offline bundles must satisfy packs offline schema
Related references
- docs/task-packs/spec.md
- docs/task-packs/authoring-guide.md
- docs/task-packs/runbook.md
- docs/task-packs/registry.md

View File

@@ -6,7 +6,7 @@ rather than every single file.
Product and positioning
- Sources: docs/README.md, docs/overview.md, docs/key-features.md, docs/03_VISION.md,
docs/04_FEATURE_MATRIX.md, docs/05_SYSTEM_REQUIREMENTS_SPEC.md, docs/05_ROADMAP.md
- Docs2: product/overview.md
- Docs2: product/overview.md, product/roadmap-and-requirements.md
Architecture and system model
- Sources: docs/07_HIGH_LEVEL_ARCHITECTURE.md, docs/high-level-architecture.md,
@@ -37,19 +37,52 @@ Air-gap and offline kit
- Sources: docs/24_OFFLINE_KIT.md, docs/10_OFFLINE_KIT.md, docs/airgap/*
- Docs2: operations/airgap.md
Replay and determinism
- Sources: docs/replay/*, docs/runbooks/replay_ops.md, docs/release/promotion-attestations.md
- Docs2: operations/replay-and-determinism.md
Runbooks and incident response
- Sources: docs/runbooks/*, docs/operations/*
- Docs2: operations/runbooks.md
Release engineering and CI/DevOps
- Sources: docs/13_RELEASE_ENGINEERING_PLAYBOOK.md, docs/ci/*, docs/devops/*,
docs/release/*, docs/releases/*
- Docs2: release/release-engineering.md
API and contracts
- Sources: docs/09_API_CLI_REFERENCE.md, docs/api/*, docs/schemas/*,
docs/contracts/*
- Docs2: api/overview.md, api/auth-and-tokens.md, data-and-schemas.md
Contracts and interfaces
- Sources: docs/contracts/*, docs/adr/*, docs/specs/*
- Docs2: contracts-and-interfaces.md
Security, governance, compliance
- Sources: docs/13_SECURITY_POLICY.md, docs/17_SECURITY_HARDENING_GUIDE.md,
docs/11_GOVERNANCE.md, docs/12_CODE_OF_CONDUCT.md, docs/28_LEGAL_COMPLIANCE.md,
docs/29_LEGAL_FAQ_QUOTA.md, docs/33_333_QUOTA_OVERVIEW.md
- Docs2: security-and-governance.md
Risk model and scoring
- Sources: docs/risk/*, docs/contracts/risk-scoring.md
- Docs2: security/risk-model.md
Forensics and evidence locker
- Sources: docs/forensics/*, docs/evidence-locker/*
- Docs2: security/forensics-and-evidence-locker.md
Database and persistence
- Sources: docs/db/*, docs/adr/0001-postgresql-for-control-plane.md
- Docs2: data/persistence.md
Events and messaging
- Sources: docs/events/*, docs/samples/*
- Docs2: data/events.md
CLI and UI
- Sources: docs/15_UI_GUIDE.md, docs/cli/*, docs/ui/*, docs/console/*
- Sources: docs/15_UI_GUIDE.md, docs/cli/*, docs/ui/*, docs/console/*, docs/ux/*
- Docs2: cli-ui.md
Developer and contribution
@@ -57,6 +90,14 @@ Developer and contribution
docs/18_CODING_STANDARDS.md, docs/contributing/*
- Docs2: developer/onboarding.md, developer/plugin-sdk.md
SDKs and clients
- Sources: docs/sdks/*
- Docs2: sdk/overview.md
Task packs and automation
- Sources: docs/task-packs/*
- Docs2: task-packs.md
Testing and quality
- Sources: docs/19_TEST_SUITE_OVERVIEW.md, docs/testing/*
- Docs2: testing-and-quality.md
@@ -70,6 +111,10 @@ Benchmarks and performance
- Sources: docs/benchmarks/*, docs/12_PERFORMANCE_WORKBOOK.md
- Docs2: benchmarks.md
Training and adoption
- Sources: docs/training/*, docs/evaluate/*, docs/faq/*
- Docs2: training-and-adoption.md
Glossary
- Sources: docs/14_GLOSSARY_OF_TERMS.md
- Docs2: glossary.md

View File

@@ -0,0 +1,22 @@
# Training and adoption
This material helps teams evaluate and adopt StellaOps safely.
Evaluation checklist
- Day 0 to 1: run quickstart, verify quotas, capture replay bundle.
- Day 2 to 7: test airgap kit, crypto profile, and policy simulation.
- Day 8 to 14: integrate CI, notifications, and advisory feeds.
- Day 15 to 30: harden security, enable observability, run performance checks.
Concept guides and FAQ
- Score proofs and reachability concepts
- Unknowns management
- Troubleshooting and FAQ for common issues
Related references
- docs/evaluate/checklist.md
- docs/training/reachability-concept-guide.md
- docs/training/score-proofs-concept-guide.md
- docs/training/unknowns-management-guide.md
- docs/training/troubleshooting-guide.md
- docs/training/faq.md