git.stella-ops.org/docs/product-advisories/23-Dec-2026 - Proof‑Driven Moats Stella Ops Can Ship.md

Here’s a compact blueprint for two high‑leverage Stella Ops capabilities that cut false positives and make audits portable across jurisdictions.

1) Patch‑aware backport detector (no humans in loop)

Goal: Stop flagging CVEs when a distro backported the fix but kept the old version string.

How it works—in plain terms

• Compile equivalence maps per distro:

  • BuildID → symbol ranges → hunk hashes for core libraries/kernels.
  • For each upstream CVE fix, store the minimal “hunk signature” (function, file path, before/after diff hash).

• Auto‑diff at scan time:

  • From a container/VM, collect ELF BuildIDs and symbol tables (or BTF for kernels).
  • Match against the equivalence map; if patched hunks are present, mark the artifact “fixed‑by‑backport”.

• Emit proof‑carrying VEX:

  • Generate a signed VEX entry with status:not_affected, justification: patched-backport, and attach a proof blob: (artifact BuildIDs, matched hunk IDs, upstream commit refs, deterministic diff snippet).

• Release‑gate policy:

  • Gate only passes if (a) VEX is signed by an approved issuer, (b) proof blob verifies against our equivalence map, (c) CVE scoring policy is met.

Minimal data model

• EquivalenceMap{ distro, package, version_like, build_id, [HunkSig{file,func, pre_hash, post_hash, upstream_commit}] }
• ProofBlob{ artifact_build_ids, matched_hunks[], verifier_log }
• VEX{ subject=digest/ref, cve, status, justification, issued_by, dsse_sig, proof_ref }

Pipeline sketch (where to run what)

• Feedser: pulls upstream CVE patches → extracts HunkSig.
• Sbomer: captures BuildIDs for binaries in SBOM.
• Vexer: matches hunks → emits VEX + proof.
• Authority/Attestor: DSSE‑signs; stores in OCI referrers.
• Policy Engine: enforces “accept only if proof verifies”.

Testing targets (fast ROI)

• glibc, openssl, zlib, curl, libxml2, Linux kernel LTS (common backports).

Why it’s a moat

• Precision jump without humans; reproducible proof beats “trust me” advisories.

---

2) Regional crypto & offline audit packs

Goal: Hand an auditor a single, sealed bundle that replays identically anywhere—while satisfying local crypto regimes.

What’s inside the bundle

• Evidence: SBOM (CycloneDX 1.6/SPDX 3.0.1), VEX set, reachability subgraph (source+post‑build), policy ledger with decisions.
• Attestations: DSSE/in‑toto for each step.
• Replay manifest: feed snapshots + rule versions + hashing seeds so a third party can re‑execute and get the same verdicts.

Dual‑stack signing profiles

• eIDAS / ETSI (EU), FIPS (US), GOST/SM (RU/CN regional), plus optional PQC (Dilithium/Falcon) profile.
• Same content; different signature suites → auditor picks the locally valid one.

Operating modes

• Connected: push to an OCI registry with referrers and timestamping (Rekor‑compatible mirror).
• Air‑gapped: tar+CAR archive with embedded TUF root, CRLs, and time‑stamped notary receipts.

Verification UX (auditor‑friendly)

• One command: stella verify --bundle bundle.car → prints (1) signature set validated, (2) replay hash match, (3) policy outcomes, (4) exceptions trail.

---

Lightweight implementation plan (90‑day cut)

• Weeks 1–3:

  • Extract HunkSig from upstream patches (git diff parser + normalizer).
  • Build ELF symbol/BuildID collector; store per‑distro maps.

• Weeks 4–6:

  • VEXer: matching engine + not_affected: patched-backport schema + ProofBlob.
  • DSSE signing with pluggable crypto providers; start with eIDAS+FIPS.

• Weeks 7–9:

  • Offline bundle format (CAR/TAR) + replay manifest + verifier CLI.
  • Policy gate: “accept if backport proof verifies”.

• Weeks 10–12:

  • Reachability subgraph export/import; deterministic re‑execution harness.
  • Docs + sample audits (openssl CVEs across Debian/Ubuntu/RHEL).

---

UI hooks (keep it simple)

• Finding: “Backport Proofs” tab on a CVE detail → shows matched hunks and upstream commit links.
• Deciding: Release diff view lists CVEs → green badges “Patched via Backport (proof‑verified)”.
• Auditing: “Export Audit Pack” button at run level; pick signature profile(s); download bundle.

If you want, I can draft:

• the HunkSig extractor spec (inputs/outputs),
• the VEX schema extension and DSSE envelopes,
• the verifier CLI contract and sample CAR layout,
• or the policy snippets to wire this into your release gates. Below is a developer-grade implementation guide for patch-aware backport handling across Alpine, Red Hat, Fedora, Debian, SUSE, Astra Linux, and “all other Linux used as Docker bases”. It is written as if you are building this inside Stella Ops (Feedser/Vexer/Sbomer/Scanner.Webservice, DSSE attestations, deterministic replay, Postgres+Valkey).

The key principle: do not rely on upstream version strings. For distros, “fixed” often means “patch backported with same NEVRA/version”. You must determine fix status by distro patch metadata plus binary/source proof.

---

0) What you are building

Outputs (what must exist after implementation)

1. DistroFix DB (authoritative normalized knowledge)

   • For each distro release + package + CVE:

     • status: affected / fixed / not_affected / under_investigation / unknown
     • fixed range expressed in distro terms (epoch/version/release or deb version) and/or advisory IDs
     • proof pointers (errata, patch commit(s), SRPM/deb source, file hashes, build IDs)

2. Backport Proof Engine

   • Given an image and its installed packages, produce a deterministic VEX:

     • status=not_affected with justification=patched-backport
     • proof blob: advisory id, package build provenance, patch signatures matched

3. Policy integration

   • Gating rules treat “backport proof verified” as first-class evidence.

4. Replayable scans

   • Same inputs (feed snapshots + rules + image digest) → same verdicts.

---

1) High-level approach (two-layer truth)

Layer A — Distro intelligence (fast and usually sufficient)

For each distro, ingest its authoritative vulnerability metadata:

• advisory/errata streams
• distro CVE trackers
• security databases (Alpine secdb)
• OVAL / CPE / CSAF if available
• package repositories metadata

This provides “fixed in release X” at distro level.

Layer B — Proof (needed for precision and audits)

When Layer A says “fixed” but the version looks “old”, prove it:

• Source proof: patch set present in source package (SRPM, debian patches, apkbuild git)
• Binary proof: vulnerable function/hunk signature is patched in shipped binary (BuildID + symbol/hunk signature match)
• Build proof: build metadata ties the binary to the source + patch set deterministically

You will use Layer B to:

• override false positives
• produce auditor-grade evidence
• operate offline with sealed snapshots

---

2) Core data model (Postgres schema guidance)

2.1 Canonical keys

You must normalize these identifiers:

• Distro key: distro_family + distro_name + release + arch

  • e.g. debian:12, rhel:9, alpine:3.19, sles:15sp5, astra:??

• Package key: canonical package name plus ecosystem type

  • apk, rpm, deb

• CVE key: CVE-YYYY-NNNN

2.2 Tables (minimum)

• distro_release(id, family, name, version, codename, arch, eol_at, source)

• pkg_name(id, ecosystem, name, normalized_name)

• pkg_version(id, ecosystem, version_raw, version_norm, epoch, upstream_ver, release_ver)

• advisory(id, distro_release_id, advisory_type, advisory_id, published_at, url, raw_json_hash, snapshot_id)

• advisory_pkg(advisory_id, pkg_name_id, fixed_version_id NULL, fixed_range_json NULL, status, notes)

• cve(id, cve_id, severity, cwe, description_hash)

• cve_pkg_status(id, cve_id, distro_release_id, pkg_name_id, status, fixed_version_id NULL, advisory_id NULL, confidence, last_seen_snapshot_id)

• source_artifact(id, type, url, sha256, size, fetched_in_snapshot_id)

  • SRPM, .dsc, .orig.tar, apkbuild, patch files

• patch_signature(id, cve_id, upstream_commit, file_path, function, pre_hash, post_hash, algo_version)

• build_provenance(id, distro_release_id, pkg_nevra_or_debver, build_id, source_artifact_id, buildinfo_artifact_id, signer, signed_at)

• binary_fingerprint(id, artifact_digest, path, elf_build_id, sha256, debuglink, arch)

• proof_blob(id, subject_digest, cve_id, pkg_name_id, distro_release_id, proof_type, proof_json, sha256)

2.3 Version comparison engines

Implement three comparators:

• rpmvercmp (RPM EVR rules)
• dpkg --compare-versions equivalent (Debian version algorithm)
• Alpine apk version rules (similar to semver-ish but not semver; implement per apk-tools logic)

Do not “approximate”. Implement exact comparators or call system libraries inside controlled container images.

---

3) Feed ingestion per distro (Layer A)

3.1 Alpine (apk)

Primary data

• Alpine secdb repository (per branch) mapping CVEs ↔ packages, fixed versions.

Ingestion

• Pull secdb for each supported Alpine branch (3.x).
• Parse entries into cve_pkg_status with fixed_version.

Package metadata

• Pull APKINDEX.tar.gz for each repo (main/community) and arch.
• Store package version + checksum.

Notes

• Alpine often explicitly lists fixed versions; backports are less “opaque” than enterprise distros, but still validate.

3.2 Red Hat Enterprise Linux (rhel) & UBI

Primary data

• Red Hat Security Data: CVE ↔ packages, errata, states.
• Errata stream provides authoritative “fixed in RHSA-…”.

Ingestion

• For each RHEL major/minor you support (8, 9; optionally 7), pull:

  • CVE objects + affected products + package states
  • Errata (RHSA) objects and their fixed package NEVRAs

• Populate advisory + advisory_pkg.

• Derive cve_pkg_status from errata.

Package metadata

• Use repository metadata (repomd.xml + primary.xml.gz) for BaseOS/AppStream/CRB, etc.
• Record NEVRA and checksums.

Enterprise backport reality

• RHEL frequently backports fixes while keeping old upstream version. Your engine must prefer errata fixed NEVRA over upstream version meaning.

3.3 Fedora (rpm)

Fedora is closer to upstream; still ingest advisories. Primary data

• Fedora security advisories / updateinfo (often via repository updateinfo.xml.gz)
• OVAL may exist for some streams.

Ingestion

• Parse updateinfo to map CVE → fixed NEVRA.
• For Fedora rawhide/rolling, treat as high churn; snapshots must be time-bounded.

3.4 Debian (deb)

Primary data

• Debian Security Tracker (CVE status per release + package, fixed versions)
• DSA advisories.

Ingestion

• Pull Debian security tracker data, parse per release (stable, oldstable).
• Normalize Debian versions exactly.
• Store “fixed in” version.

Package metadata

• Parse Packages.gz from security + main repos.
• Optionally Sources.gz for source package mapping.

3.5 SUSE (SLES / openSUSE) (rpm)

Primary data

• SUSE security advisories (often published as CSAF; also SUSE OVAL historically)
• Updateinfo in repos.

Ingestion

• Prefer CSAF/official advisory feed when available; otherwise parse updateinfo.xml.gz.
• Map CVE → fixed packages.

3.6 Astra Linux (deb-family, often)

Astra is niche and may have bespoke advisories/mirrors. Primary data

• Astra security bulletins and repository metadata.

• If they publish a tracker or advisories in a machine-readable format, ingest it; otherwise:

  • treat repo metadata + changelogs as the canonical signal.

Ingestion strategy

• Implement a generic “Debian-family fallback”:

  • ingest Packages.gz and Sources.gz from Astra repos
  • ingest available security bulletin feed (HTML/JSON); parse with a deterministic extractor
  • if advisories are sparse, rely on Layer B proof more heavily (source patch presence + binary proof)

3.7 “All other Linux used on docker repositories”

Handle this by distro families plus a plugin pattern:

• Debian family (Ubuntu, Kali, Astra, Mint): use Debian comparator + Packages/Sources + their security tracker if exists
• RPM family (RHEL clones: Rocky/Alma/Oracle; Amazon Linux): rpm comparator + updateinfo/OVAL/errata equivalents
• Alpine family (Wolfi/apko-like): their own secdb or APKINDEX equivalents
• Distroless/scratch: no package manager; you must fall back to binary scanning only (Layer B).

Developer action

• Create an interface IDistroProvider with:

  • EnumerateReleases()
  • FetchAdvisories(snapshot)
  • FetchRepoMetadata(snapshot)
  • NormalizePackageName(...)
  • CompareVersions(a,b)
  • ParseInstalledPackages(image) (if package manager exists)

• Implement providers: AlpineProvider, DebianProvider, RpmProvider, SuseProvider, AstraProvider, plus “GenericDebianFamilyProvider”, “GenericRpmFamilyProvider”.

---

4) Installed package extraction (inside scan)

4.1 Determine OS identity

From image filesystem:

• /etc/os-release (ID, VERSION_ID)

• distro-specific markers:

  • Alpine: /etc/alpine-release
  • Debian: /etc/debian_version
  • RHEL: /etc/redhat-release

Write a deterministic resolver:

• if /etc/os-release missing, fall back to:

  • package DB presence: /lib/apk/db/installed, /var/lib/dpkg/status, rpmdb paths
  • ELF libc fingerprint heuristics (last resort)

4.2 Extract installed packages deterministically

• Alpine: parse /lib/apk/db/installed
• Debian: parse /var/lib/dpkg/status
• RPM: parse rpmdb (use rpm tooling in a controlled helper container, or implement rpmdb reader; prefer tooling for correctness)

Store:

• package name
• version string (raw)
• arch
• source package mapping if available (Debian’s Source: fields; RPM’s Sourcerpm)

---

5) The backport proof engine (Layer B)

This is the “precision jump”. It has three proof modes; implement all three and choose best available.

Proof mode 1 — Advisory fixed NEVRA/version match (fast)

If the distro’s errata/DSA/updateinfo says fixed in X, and installed package version compares ≥ X (using correct comparator):

• mark fixed with confidence=high
• attach advisory reference only

This already addresses many cases.

Proof mode 2 — Source patch presence (best for distros with source repos)

Prove the patch is in the source package even if version looks old.

Debian-family

• Determine source package:

  • from dpkg status “Source:” if present; otherwise map binary→source via Sources.gz

• Fetch source:

  • .dsc + referenced tarballs + debian/patches/* (or debian/patches/series)

• Patch signature verification:

  • For CVE, you maintain patch_signature derived from upstream fix commits:

    • identify file/function/hunk; store normalized diff hashes (ignore whitespace/context drift)

  • Apply:

    • check if any distro patch file contains the “post” signature (or the vulnerable code is absent)

• Record in proof_blob:

  • source artifact SHA256
  • patch file names
  • matching signature IDs
  • deterministic verifier log

RPM-family (RHEL/Fedora/SUSE)

• Determine SRPM from installed RPM metadata (Sourcerpm field).
• Fetch SRPM from source repo (or debug/source channel).
• Extract patches from SRPM spec + sources.
• Verify patch signatures as above.

Alpine

• Determine apkbuild and patches for the package version (Alpine aports)
• Verify patch signature.

Proof mode 3 — Binary hunk/signature match (works even without source repos)

This is your universal fallback (also for distroless).

Build fingerprints

• For each ELF binary in the package or image:

  • compute sha256
  • read ELF BuildID if present
  • capture .gnu_debuglink if present
  • capture symbols (when available)

Signature strategy

For each CVE fix, create one or more binary-checkable predicates:

• vulnerable function contains a known byte sequence that disappears after fix
• or patched function includes a new basic block pattern
• or a string constant changes (weak, but sometimes useful)
• or the compile-time feature toggles

Implement as BinaryPredicate objects:

• type: bytepattern | cfghash | symbolrangehash | rodata-string
• scope: file path patterns / package name constraints
• arch: x86_64/aarch64 etc.
• algo_version: so you can evolve without breaking replay

Evaluation:

• locate candidate binaries (package manifest, common library paths)

• apply predicate in a stable order

• if “fixed predicate” matches and “vulnerable predicate” does not:

  • produce proof

Evidence quality

Binary proof must include:

• file path + sha256
• BuildID if available
• predicate ID + algorithm version
• extractor/verifier version hashes

---

6) Building the patch signature corpus (no humans)

6.1 Upstream patch harvesting (Feedser)

For each CVE:

• find upstream fix commits (NVD references, project advisories, distro patch references)

• fetch git diffs

• normalize to patch_signature:

  • (file path, function name if detectable, pre hash, post hash)
  • store multiple signatures per CVE if multiple upstream branches

You will not always find perfect fix commits. When missing:

• fall back to distro-specific patch extraction (learn signatures from distro patch itself)
• mark signature_origin=distro-learned but keep it auditable

6.2 Deterministic normalization rules

• strip diff metadata that varies

• normalize whitespace

• compute hashes over:

  • token stream (C/C++ tokens; for others line-based)
  • include hunk context windows

• store algo_version and never change semantics without bumping

---

7) Decision algorithm (deterministic, ordered, explainable)

For each (image_digest, distro_release, pkg, cve):

1. If distro provider has explicit status “not affected” (e.g., vulnerable code not present in that distro build):

   • emit VEX not_affected with advisory proof

2. Else if advisory says fixed in version/NEVRA and installed compares as fixed:

   • emit VEX fixed with advisory proof

3. Else if source proof succeeds:

   • emit VEX not_affected / fixed (depending on semantics) with justification=patched-backport

4. Else if binary proof succeeds:

   • emit VEX not_affected / fixed with binary proof

5. Else:

   • affected/unknown depending on policy, but always attach “why unknown” in evidence.

This order is critical to keep runtime reasonable and proofs consistent.

---

8) Engineering constraints for Docker base images

8.1 Multi-stage images and removed package DBs

Many production images delete package databases to slim. Your scan must handle:

• no dpkg status, no rpmdb, no apk db In this case:

• try SBOM from build provenance (if you have it)

• otherwise treat as binary-only:

  • scan ELF binaries + shared libs
  • map to known package/binary fingerprints where possible
  • rely on Proof mode 3

8.2 Minimal images (distroless, scratch)

• There is no OS metadata; don’t pretend.
• Mark distro as unknown, skip Layer A, go straight to binary proof.
• Policy should treat unknowns explicitly (your existing “unknown budget” moat).

---

9) Implementation structure in .NET 10 (practical module map)

9.1 Services and boundaries

• Feedser

  • pulls distro advisories/trackers/repo metadata
  • produces normalized DistroFix snapshots

• Sbomer

  • produces SBOM + captures file fingerprints, BuildIDs

• Scanner.Webservice

  • runs the deterministic evaluation and lattice/policy logic (per your standing rule)
  • does proof verification + emits signed verdicts

• Vexer

  • aggregates VEX claims + attaches proof blobs (but evaluation logic stays in Scanner.Webservice)

• Authority/Attestor

  • DSSE signing, OCI referrers, audit pack exports

9.2 Core libraries

Create a library StellaOps.Security.Distro:

• IDistroProvider
• IVersionComparator
• IInstalledPackageExtractor
• IAdvisoryParser
• ISourceProofVerifier
• IBinaryProofVerifier

Each provider implements:

• parsing
• comparator
• extraction for its ecosystem

9.3 Determinism rules (must be enforced)

• Every scan references a specific snapshot_id for feeds.

• Proof computations are pure functions of:

  • image digest
  • extracted artifacts
  • snapshot content hashes
  • algorithm version hashes

• Logs included in proof blobs must be stable (no timestamps unless separately recorded).

---

10) Test strategy (non-negotiable)

10.1 Golden corpus images

Build a repo of fixtures:

• alpine:3.18, alpine:3.19
• debian:11, debian:12
• ubuntu:22.04, ubuntu:24.04
• ubi9, ubi8 (or rhel-like equivalents you can legally test)
• fedora:40+
• opensuse/leap, sles if accessible
• Astra base images if you use them internally

For each fixture:

• pick 10 known CVEs across openssl, curl, zlib, glibc, libxml2

• store expected decisions:

  • vulnerable vs fixed, including backported cases

• run in CI with locked snapshots

10.2 Comparator test suites

For RPM and Debian version compare:

• ingest official comparator test vectors (or recreate known tricky cases)

• unit tests must include:

  • epoch handling
  • tilde ordering in Debian versions
  • rpm release ordering

10.3 Proof verifier tests

• source proof: patch signature detection on extracted SRPM/deb sources
• binary proof: fixed/vulnerable predicate detection on controlled binaries

---

11) Practical rollout plan (how developers should implement)

Phase 1 — Layer A for all major distros (fast coverage)

1. Implement comparators: rpm, deb, apk.

2. Implement providers:

   • Alpine secdb + APKINDEX
   • Debian security tracker + Packages/Sources
   • RHEL errata/CVE feed + repo metadata
   • Fedora updateinfo + repo metadata
   • SUSE advisory/updateinfo
   • Generic Debian/RPM fallback providers

3. Produce cve_pkg_status snapshots and basic VEX results using only Layer A.

Phase 2 — Source proof (removes most false positives)

1. Implement upstream patch harvesting → patch_signature.
2. Implement Debian source fetch + verification.
3. Implement SRPM fetch + verification.
4. Wire into decision algorithm, emit proof blobs.

Phase 3 — Binary proof (covers stripped/minimal images)

1. Implement ELF fingerprint extraction + BuildID store.
2. Implement predicate framework + initial predicates for top libraries.
3. Add caching (Valkey) for predicate results keyed by (file sha256, predicate_id, algo_version).

Phase 4 — Astra and niche distros hardening

1. Implement Astra provider:

   • repo metadata ingestion
   • advisory parsing if available
   • otherwise rely on source/binary proof

2. Add distro onboarding kit:

   • define endpoints for repo metadata
   • define advisory parsing rules
   • define comparator family

---

12) What “done” means (acceptance criteria)

A developer story is “complete” only if:

• For each supported distro family, you can:

  • identify distro release
  • extract installed packages OR fall back to binary-only
  • compute fix status for at least top 50 packages
  • produce VEX with either advisory or proof

• At least 100 backport scenarios across RHEL/Debian/SUSE pass golden tests.

• Scan is replayable:

  • freeze snapshot, rerun, identical verdict hash.

---

If you want this converted into your internal sprintable format (epics/stories/tasks + acceptance tests + file/module layout in a .NET 10 repo), I can output it as:

• SPECS.md section “Patch-aware Backport Handling”
• CONTRACTS.md (provider interfaces, proof blob schema, DSSE envelopes)
• DB_REPOSITORIES.md migrations outline
• IMPLEMENTATION.md with step-by-step task breakdown per distro.