e91da22836
- Introduced attestation inventory and subject-rekor mapping files for tracking Docker packages. - Added a comprehensive crypto registry decision document outlining defaults and required follow-ups. - Created an offline feeds manifest for bundling air-gap resources. - Implemented a script to generate and update binary manifests for curated binaries. - Added a verification script to ensure binary artefacts are located in approved directories. - Defined new schemas for AdvisoryEvidenceBundle, OrchestratorEnvelope, ScannerReportReadyPayload, and ScannerScanCompletedPayload. - Established project files for StellaOps.Orchestrator.Schemas and StellaOps.PolicyAuthoritySignals.Contracts. - Updated vendor manifest to track pinned binaries for integrity.
65 lines
6.5 KiB
Markdown
Executable File
65 lines
6.5 KiB
Markdown
Executable File
# Stella Ops
|
||
|
||
> Stella Ops is the sovereign, SBOM‑first security platform that proves every container decision with deterministic scans, explainable policy verdicts, and offline‑ready provenance.
|
||
|
||
- **Sovereign by design** – bring your own trust roots, vulnerability advisory sources, VEX sources, regional crypto, and Offline Update Kits that never phone home.
|
||
- **Deterministic + replayable** – every scan can be reproduced bit‑for‑bit with DSSE + OpenVEX evidence.
|
||
- **Actionable signal** – lattice logic ranks exploitability, and the policy engine lets you tailor VEX handling, muting, and expiration rules for your environment.
|
||
|
||
**Proof points:** SBOM dependency and vulnerability dependency cartographing work, deterministic replay manifests, lattice policy UI with OpenVEX, and post‑quantum trust packs ready for regulated sectors.
|
||
|
||
## Choose Your Path
|
||
|
||
| If you want to… | Open this | Read time |
|
||
|-----------------|-----------|-----------|
|
||
| Understand the promise and pain we solve | `overview.md` | ≈ 2 min |
|
||
| Run a first scan and see the CLI | `quickstart.md` | ≈ 5 min |
|
||
| Browse key capabilities at a glance | `key-features.md` | ≈ 3 min |
|
||
| Check architecture, road to production, or evaluate fit | See “Dig deeper” below | ≤ 30 min curated set |
|
||
|
||
## Explore the Essentials
|
||
|
||
1. **Value in context** – [Overview](overview.md) compresses the “Why” + “What” stories and shows how Stella Ops stands apart.
|
||
2. **Try it fast** – [Quickstart](quickstart.md) walks through fetching the signed bundles, configuring `.env`, and verifying the first scan.
|
||
3. **Feature confidence** – [Key Features](key-features.md) gives five capability cards covering Delta SBOM, VEX‑first policy, Sovereign crypto, Deterministic replay, and Transparent quotas.
|
||
4. **Up-next checkpoints** – [Evaluation checklist](evaluate/checklist.md) helps teams plan Day‑0 to Day‑30 adoption milestones.
|
||
|
||
## Key capabilities that define Stella Ops
|
||
|
||
| Capability | What ships | Why it matters |
|
||
|------------|------------|----------------|
|
||
| **Deterministic Δ‑SBOM & replay bundles** | Layer-aware cache + replay manifests keep scans reproducible even months later. | Auditors can re-run any verdict with identical inputs, proving integrity without SaaS dependencies. |
|
||
| **Pristine advisory mirrors** | OSV, GHSA, NVD, CNVD, CNNVD, ENISA, JVN, BDU, etc. are mirrored as immutable, per-source snapshots—never merged. | Policy (via `scanner.*` / `SCANNER__*`) can trust, down-rank, or ignore sources without rewriting upstream data. |
|
||
| **Lattice VEX engine** | OpenVEX, waivers, mitigations, and configs flow through deterministic lattice logic. | Every block/allow decision is explainable, replayable, and environment-specific. |
|
||
| **Context fabric** | Static reachability now, optional runtime/eBPF probes at GA so build + runtime signals share one verdict. | Prioritisation spans first-party code, base images, and live telemetry. |
|
||
| **Transparency log + trust credits** | Cosign/DSSE bundles push to a Rekor-compatible log; the trust-credit ledger records who accepted a risk. | Compliance teams get provenance plus accountable ownership trails. |
|
||
| **Sovereign crypto profiles** | Swap in FIPS, eIDAS, GOST, SM, or PQ-ready providers without code changes. | Meets regional crypto rules while keeping attestations verifiable. |
|
||
| **Offline-first operations** | Offline Kit packages the pristine feeds, plug-ins, and configs; import CLI verifies everything locally. | Air-gapped clouds get the same security posture as connected sites. |
|
||
| **Enterprise readiness** | Transparent quotas, LDAP/AD SSO, restart-time plug-in SDK, generous free tier. | Large teams keep their workflows without surrendering control to SaaS platforms. |
|
||
|
||
## Where Stella Ops differs from incumbents
|
||
|
||
| Vendor | Where they stop | Stella Ops difference |
|
||
|--------|-----------------|-----------------------|
|
||
| **Trivy / Syft** | SBOM generation as a CLI add-on; policy left to other products. | SBOM + VEX are the system of record with deterministic replay and signed evidence. |
|
||
| **Snyk Container** | Static reachability bounded to first-party code. | Lattice links code, base images, cluster policies, and optional runtime probes so the entire stack shares one score. |
|
||
| **JFrog Xray** | Contextual scoring lives behind a closed service. | Policies, DSSE bundles, and transparency logs are open, auditable, and portable. |
|
||
| **Docker Scout** | Provenance remains inside Docker’s ecosystem. | Any OCI provenance is ingested, signed with your crypto profile, and replayed offline. |
|
||
| **Wiz / runtime sensors** | Runtime telemetry is separate from build-time SBOM/VEX evidence. | Optional runtime probes feed the same deterministic lattice so build- and run-time context stay consistent. |
|
||
|
||
## Dig Deeper (curated reading)
|
||
|
||
- **Install & operations:** [Installation guide](21_INSTALL_GUIDE.md), [Offline Update Kit](24_OFFLINE_KIT.md), [Security hardening](17_SECURITY_HARDENING_GUIDE.md).
|
||
- **Binary prerequisites & offline layout:** [Binary prereqs](ops/binary-prereqs.md) covering curated NuGet feed, manifests, and CI guards.
|
||
- **Architecture & modules:** [High-level architecture](high-level-architecture.md), [Module dossiers](modules/platform/architecture-overview.md), [Strategic differentiators](moat.md).
|
||
- **Policy & governance:** [Policy templates](60_POLICY_TEMPLATES.md), [Legal & quota FAQ](29_LEGAL_FAQ_QUOTA.md), [Governance charter](11_GOVERNANCE.md).
|
||
- **UI & glossary:** [Console guide](15_UI_GUIDE.md), [Accessibility](accessibility.md), [Glossary](14_GLOSSARY_OF_TERMS.md).
|
||
- **Technical documentation:** [Full technical index](technical/README.md) for architecture, APIs, module dossiers, and operations playbooks.
|
||
- **FAQs & readiness:** [FAQ matrix](23_FAQ_MATRIX.md), [Roadmap (external)](https://stella-ops.org/roadmap/), [Release engineering playbook](13_RELEASE_ENGINEERING_PLAYBOOK.md).
|
||
|
||
Need more? The full documentation tree – ADRs, per‑module operations, schemas, developer references – stays untouched under the existing directories (`modules/`, `api/`, `dev/`, `ops/`), ready when you are.
|
||
|
||
> **Configuration note:** Feature exposure stays governed by `StellaOps.Scanner.WebService` (`scanner.*` / `SCANNER__*`) settings. See [modules/scanner/architecture.md](modules/scanner/architecture.md) and [modules/scanner/design/surface-env.md](modules/scanner/design/surface-env.md) for the authoritative schema; the docs remain pristine while configuration decides what surfaces for each deployment.
|
||
|
||
© 2025 Stella Ops contributors – AGPL‑3.0‑or‑later
|