Erreichbarkeit als Beweis

Was die Freigabe blockiert – zuerst erreichbare, nicht behobene, richtlinienrelevante Expositionen.

Der lange Rest ist nur einen Filter entfernt.

~85 % der kritischen Container-Schwachstellen liegen in inaktivem Code (Sysdig 2024 Container Security Report). Die Erreichbarkeitsanalyse fragt, ob ein Pfad in Ihrem Image die verwundbare Funktion erreicht, und signiert einen Nachweis für jedes Urteil – unabhängig davon, ob der Befund beibehalten oder herausgefiltert wird.

Der Arbeitssatz

In der folgenden Ansicht gelangen sieben Befunde in den Arbeitssatz. Einer blockiert: Er ist erreichbar und nicht behoben. Die anderen sechs sind ebenfalls nicht behoben, wurden aber nicht als erreichbar beobachtet – sie bleiben im Satz, werden niedriger priorisiert und niemals ausgeblendet.

blocking = reachable × unfixed × policy-relevant

Stella Ops-Expositionsansicht: ein Arbeitssatz aus sieben Befunden, davon einer als blockierend und REACHABLE markiert; die übrigen tragen den Status NOT OBSERVED
Expositionsansicht, v1.0-RC1-Konsole mit Beispiel-Bestand. NOT OBSERVED bedeutet nicht „nicht verwundbar“ – Unbekannte bleiben sichtbar, bis Nachweise etwas anderes belegen.

REACHABLE

Ein ausführbarer Pfad von einem Einstiegspunkt zum anfälligen Symbol wird nachgewiesen – durch ein statisches Aufrufdiagramm, eine binäre Symbolübereinstimmung oder einen Laufzeit-Probe-Treffer.

NOT OBSERVED

Mit den bisher gesammelten Beweisen konnte kein ausführbarer Pfad gefunden werden. Das ist eine Aussage über die Beweise, nicht über die Verwundbarkeit. Der Befund behält seinen Platz im Arbeitssatz.

Zwei Rankings, ein Datensatz

Derselbe Arbeitssatz bedient zwei Aufgaben. Wenn man zwischen ihnen wechselt, ändert sich die Sortierung nach oben – nichts kommt rein oder raus.

Freigeben

Sortiert danach, was dieses Release blockiert: erreichbare, nicht behobene, richtlinienrelevante Exposition zuerst.

Absichern

Sortiert nach Gesamtexposition in der gesamten Systemlandschaft, einschließlich Befunden, die niemals Teil eines Release werden.

Es ändert die Rangfolge und den Schwerpunkt, niemals die Daten.

Woher der Nachweis kommt

Die statische Analyse erzeugt das Urteil bei jedem Scan. Binärsymbole und Laufzeitfakten liefern zusätzliche Tiefe, wenn Sie sie wollen. CVECommon Vulnerabilities and Exposures – eine eindeutige Kennung für eine öffentlich bekannte Sicherheitslücke

Layer 1

Statische Aufrufdiagrammanalyse

Baut einen Aufrufgraphen aus kompiliertem Bytecode und aus Quellcode und verfolgt Pfade von Ihren Einsprungpunkten zu den Funktionen, die eine Meldung benennt.

  • • Sprachen mit Aufrufgraph: Go, Java, C#/.NET, JavaScript und TypeScript, Python, Rust, PHP, Ruby. Pro Image wird eine Sprache analysiert. Andere Ökosysteme landen im Unknown-Bereich – bewertet, nicht übersprungen.
  • • Die Offline-Extraktion ist eingeschränkter: Ein Aufrufgraph aus einem Quellbaum wird in der CLI nur für Go und Rust erstellt, und zwar in der lexikalischen Stufe – die SSA-Toolchain steckt im Scanner-Worker. Andere Sprachen analysiert die Scan-Pipeline, deren vorab extrahierten Aufrufgraphen die CLI übernimmt.
  • • Python, JavaScript/TypeScript, Rust, PHP und Ruby werden aus dem Quelltext analysiert, und jede Kante trägt ihre Konfidenz – so sehen Sie, welche Stufe ein Urteil erzeugt hat
  • • Reflection, dynamische Aufrufe und virtueller Dispatch über bekannte Implementierungen hinaus werden nicht modelliert – jedes Ergebnis nennt diese Grenze
Layer 2

Binärsymbolanalyse

Eine CLI-Spur für nativen Code ohne lesbare Quellen: ELF-Symboltabellen und DWARF-Funktionsnamen, x86, x64 und ARM64. Die Befunde stehen für sich, getrennt vom Scan-Urteil.

  • • ELF-Symboltabellen und DWARF-Funktionsnamen
  • • Disassemblierung für x86, x64 und ARM64. Debug-Informationen werden nur aus DWARF gelesen – kein PDB
Layer 3

Laufzeit-eBPFExtended Berkeley Packet Filter — eine Linux-Kernel-Technologie, die sandboxed Programme für hochperformante Beobachtbarkeit und Laufzeitanalyse ohne Kernelmodule ausführt-Probes

Speisen Sie echte Ausführungsdaten ein – Stella Ops prüft sie und versiegelt sie als den stärksten Erreichbarkeitsnachweis überhaupt. Die Probes betreiben Sie; RC1 liefert den Ingest-Pfad.

  • • Tetragon-basierte eBPFExtended Berkeley Packet Filter — eine Linux-Kernel-Technologie, die sandboxed Programme für hochperformante Beobachtbarkeit und Laufzeitanalyse ohne Kernelmodule ausführt-Instrumentierung
  • • Zeichnet symbol_id, code_id, hit_count, loader_base auf
  • • Datenschutz: Keine Argumentwerte erfasst

Jedes Urteil wird als DSSE-signierter Nachweis verpackt, der das Ergebnis an den ausführbaren Pfad bindet, anhand dessen es bewertet wurde. Konnte kein Pfad analysiert werden, wird der Befund als unbekannt gemeldet und nicht freigegeben. DSSEDead Simple Signing Envelope – ein einfacher, flexibler Standard zum Signieren beliebiger Daten mit kryptographischen Signaturen

Unbekannte als First-Class-Status

Wenn die Analyse die Erreichbarkeit nicht ermitteln kann, wird die Unsicherheit explizit nachverfolgt – nicht versteckt oder stillschweigend als sicher angenommen.

Erreichbarkeits-BucketStandardgewichtung
reachable:proven1.0
reachable:likely0.85
not-observed0.0

Höher bedeutet mehr Risiko, nicht mehr Vertrauen: das Gewicht skaliert den Risikowert eines Befundes. Laufzeitbestätigung ersetzt den Pfadnachweis nicht — sie erhöht die Konfidenz des Urteils. Wo der Analyzer überhaupt keinen Pfad beobachtet hat, meldet Stella Ops nicht beobachtet mit einer signierten Abdeckungsaussage, niemals „nicht erreichbar“: keinen Pfad zu beobachten ist kein Beweis, dass keiner existiert.

Richtlinienempfehlung: Behandeln Sie unknown als erstklassiges Urteil, legen Sie explizite Schwellenwerte pro Schweregrad fest und überschreiben Sie Gründe für den Protokollprüfer im Beweisbündel.

Wo VEX-Aussagen einfließen

VEX-Aussagen von Herausgebern werden demselben Nachweisgraphen hinzugefügt und auf fünf Status normalisiert — not_affected, affected, fixed, under_investigation, unknown. „In Untersuchung“ ist damit ein Zustand mit Konsequenzen, keine Fußnote. VEXVulnerability Exploitability eXchange – maschinenlesbare Aussagen darüber, ob Schwachstellen in Ihrem Kontext tatsächlich ausnutzbar sind

not_affected affected fixed under_investigation unknown

Mehrere Emittenten können über dieselbe Komponente sprechen. Wenn sie nicht einverstanden sind, erfasst die Konfliktlösung die Meinungsverschiedenheit als Konflikt – nichts wird gemittelt und kein Emittent gewinnt stillschweigend.

Wie SBOM- und VEX-Beweise zusammengeführt werden →

KEV und EPSS nehmen teil – sie entscheiden nicht

Einträge in CISA KEV und EPSS-Scores sind Ausnutzungssignale auf Advisory-Ebene. Sie erhöhen Rang und Dringlichkeit eines Befunds innerhalb des Arbeitssatzes. KEVKnown Exploited Vulnerabilities – CISAs Katalog aktiv ausgenutzter Schwachstellen EPSSExploit Prediction Scoring System – ein Wahrscheinlichkeitswert (0–100 %), der vorhersagt, wie wahrscheinlich eine Schwachstelle ausgenutzt wird

Exploit signals attach at the advisory level, not at the finding level. Open a CVECommon Vulnerabilities and Exposures – eine eindeutige Kennung für eine öffentlich bekannte Sicherheitslücke to read its advisory-level exploit data: the KEVKnown Exploited Vulnerabilities – CISAs Katalog aktiv ausgenutzter Schwachstellen listing and the EPSSExploit Prediction Scoring System – ein Wahrscheinlichkeitswert (0–100 %), der vorhersagt, wie wahrscheinlich eine Schwachstelle ausgenutzt wird score belong to the advisory, and they read the same for every service that carries the affected component.

Sie sind kein Erreichbarkeitsnachweis. Ein KEV-Eintrag für Code, den Ihr Dienst niemals lädt, ändert die Priorität, nicht das Urteil – sofern Ihre Richtlinie nicht festlegt, dass nachweislich ausgenutzte Befunde trotzdem blockieren. Zwei Regelklassen können blockieren, und sie sind unabhängig: Eine CVE-Sperrliste ignoriert Reachability vollständig, während eine Reachability-Regel nur bei einem bewiesenen Pfad blockiert — reachable:likely und unknown blockieren dadurch nie, unabhängig davon, welche Zustände die Policy nennt.

A policy gate can combine both kinds of answer in one rule: reachability state together with EPSSExploit Prediction Scoring System – ein Wahrscheinlichkeitswert (0–100 %), der vorhersagt, wie wahrscheinlich eine Schwachstelle ausgenutzt wird, KEVKnown Exploited Vulnerabilities – CISAs Katalog aktiv ausgenutzter Schwachstellen, and CVSSCommon Vulnerability Scoring System – eine Schweregradbewertung von 0–10, die angibt, wie kritisch eine Schwachstelle ist thresholds. "Known-exploited and reachable" and "known-exploited regardless of reachability" are both expressible; which one you enforce is your policy, not a default we pick for you.

Im Vergleich zu einem Scanner in CI

Ein Scanner antwortet: „Was ist gerade in diesem Image?“ Notwendig – und nicht ausreichend für eine Freigabeentscheidung.

Was Ihnen ein Scannerlauf bringt

  • • Eine Befundliste pro Image, bei jedem Lauf von Grund auf neu erzeugt
  • • Der Schweregrad stammt aus dem Advisory, nicht aus Ihrem Aufrufgraphen
  • • Unterdrückungen in Ignore-Dateien ohne signierte Aufzeichnung darüber, wer was akzeptiert hat

Was Stella Ops hinzufügt

  • • Befunde aus 38 aktiven Advisory-Quellen werden zusammengeführt und anschließend nach Erreichbarkeit geordnet
  • • Ein DSSE-signierter, wiederholbarer Nachweis für jedes Urteil – auch für herausgefilterte Befunde
  • • Das Urteil speist das Release-Gate; nach der Bereitstellung vergleicht Watch den ausgeführten Digest weiterhin mit dem genehmigten Digest

Was Stella Ops nicht tut

Trivy deckt Git-Repositorys, VMs und Kubernetes-Ziele sowie Fehlkonfigurations- und Secret-Scanning ab. Stella Ops nicht. Der Umfang von Stella Ops umfasst Container-Images und Dateisystem-Snapshots mit signierten, wiederholbaren Nachweisen für jedes Urteil.

Vollständige Vergleiche: Stella Ops vs Trivy | Stella Ops vs Grype

Implementierung: Knoten-Hash-Joins

Erreichbarkeitsnachweise werden zur Deduplizierung und Überprüfung inhaltsadressiert. Knoten-Hashes ermöglichen eine effiziente Differenzierung zwischen Versionen. Knoten Hash SHA256(normalize(purl) + ":" + normalize(symbol)) Pfad-Hash SHA256(entryNodeHash + ":" + joinedIntermediateHashes + ":" + sinkNodeHash) Top-K-signifikante Pfade bleiben im Beweisbündel erhalten. Pfade werden nach Ausführungshäufigkeit (von Laufzeit) oder Aufruftiefe (von statisch) geordnet.
Read more

Erreichbarkeitsnachweise werden zur Deduplizierung und Überprüfung inhaltsadressiert. Knoten-Hashes ermöglichen eine effiziente Differenzierung zwischen Versionen.

Knoten Hash

SHA256(normalize(purl) + ":" + normalize(symbol))

Pfad-Hash

SHA256(entryNodeHash + ":" + joinedIntermediateHashes + ":" + sinkNodeHash)

Top-K-signifikante Pfade bleiben im Beweisbündel erhalten. Pfade werden nach Ausführungshäufigkeit (von Laufzeit) oder Aufruftiefe (von statisch) geordnet.

Umsetzung: unterzeichnete Nachweise

Jede Erreichbarkeitsanalyse erzeugt einen kryptografisch signierten Beweis, der im inhaltsadressierten Speicher gespeichert wird. DSSE?Dead Simple Signing Envelope – ein einfacher, flexibler Standard zum Signieren beliebiger Daten mit kryptographischen Signaturen DSSEDead Simple Signing Envelope – ein einfacher, flexibler Standard zum Signieren beliebiger Daten mit kryptographischen Signaturen-Umschlag mit in-totoEin Framework zur Absicherung der Software-Lieferkette durch Überprüfung, dass jeder Schritt wie geplant und von autorisierten Akteuren durchgeführt wurde SLSASupply-chain Levels for Software Artifacts — ein Framework zur Sicherstellung der Integrität von Software-Artefakten in der gesamten Lieferkette-Prädikatformat Von Prüfern ohne Netzwerkzugriff überprüfbar Deterministische Wiedergabe erzeugt bitidentische Ergebnisse Grafik und Traces für Offline archiviert Verifizierung Inhaltsadressierte Speicherpfade cas://reachability_graphs/<hh>/<sha>.tar.zst cas://runtime_traces/<hh>/<sha>.tar.zst
Read more

Jede Erreichbarkeitsanalyse erzeugt einen kryptografisch signierten Beweis, der im inhaltsadressierten Speicher gespeichert wird. DSSEDead Simple Signing Envelope – ein einfacher, flexibler Standard zum Signieren beliebiger Daten mit kryptographischen Signaturen

  • DSSEDead Simple Signing Envelope – ein einfacher, flexibler Standard zum Signieren beliebiger Daten mit kryptographischen Signaturen-Umschlag mit in-totoEin Framework zur Absicherung der Software-Lieferkette durch Überprüfung, dass jeder Schritt wie geplant und von autorisierten Akteuren durchgeführt wurde SLSASupply-chain Levels for Software Artifacts — ein Framework zur Sicherstellung der Integrität von Software-Artefakten in der gesamten Lieferkette-Prädikatformat
  • Von Prüfern ohne Netzwerkzugriff überprüfbar
  • Deterministische Wiedergabe erzeugt bitidentische Ergebnisse
  • Grafik und Traces für Offline archiviert Verifizierung

Inhaltsadressierte Speicherpfade

cas://reachability_graphs/<hh>/<sha>.tar.zst

cas://runtime_traces/<hh>/<sha>.tar.zst

An einer veröffentlichten Ground Truth gemessen

Der Erreichbarkeits-Klassifizierer wird an einem etikettierten Korpus gemessen, der im öffentlichen Quellbaum ausgeliefert wird: acht minimale Services in Java, Node.js, Python, Go, .NET, Ruby, Rust und PHP, jeder mit einer Labels-Datei, die pro CVE die erwartete Stufe — von R0, in diesem Service nicht erreichbar, bis R4, vom Entrypoint erreichbar — und deren Begründung festhält.

Derselbe Baum enthält das Harness, das Klassifizierungen je Stufe bewertet — Precision und Recall, keine einzelne Mischzahl. Weil Korpus, Labels und Stufenvertrag öffentlich sind, müssen Sie unsere Lesart nicht übernehmen: Scannen Sie dieselbe Ground Truth mit Ihrer eigenen Installation und vergleichen Sie das Ergebnis mit den veröffentlichten erwarteten Antworten.

Wie dieser Vergleich läuft, ist Schritt 2.1 des Evaluations-Piloten →

Implementierung: eBPF-Sonden

Stella Ops nimmt Laufzeit-Ausführungsfakten über einen Streaming-Ingest-Endpunkt an und behandelt sie als den stärksten Erreichbarkeitsnachweis überhaupt. RC1 liefert den Collector nicht: die Tetragon-basierten Probes sind Instrumentierung, die Sie betreiben, und Erreichbarkeit funktioniert ohne sie über die statische und die Binärschicht. Erfasste Sondendaten symbol_id: kanonischer Symbol-Identifikator code_id: Identifikator des Code-Abschnitts hit_count: Ausführungshäufigkeit loader_base: Basisadresse im Speicher cas_uri: inhaltsadressierte Referenz Probes Senden Sie Beobachtungen stapelweise an /api/v1/observations. Jede Beobachtung enthält den CAS-URI für das zugrunde liegende Artefakt.
Read more

Stella Ops nimmt Laufzeit-Ausführungsfakten über einen Streaming-Ingest-Endpunkt an und behandelt sie als den stärksten Erreichbarkeitsnachweis überhaupt. RC1 liefert den Collector nicht: die Tetragon-basierten Probes sind Instrumentierung, die Sie betreiben, und Erreichbarkeit funktioniert ohne sie über die statische und die Binärschicht.

Erfasste Sondendaten

symbol_id: kanonischer Symbol-Identifikator

code_id: Identifikator des Code-Abschnitts

hit_count: Ausführungshäufigkeit

loader_base: Basisadresse im Speicher

cas_uri: inhaltsadressierte Referenz

Probes Senden Sie Beobachtungen stapelweise an /api/v1/observations. Jede Beobachtung enthält den CAS-URI für das zugrunde liegende Artefakt.

Beginnen Sie mit Ihrem eigenen Arbeitssatz

Verweisen Sie Stella Ops auf ein Image, das Sie heute ausliefern, und lesen Sie die signierten Urteile. Wenn die Erreichbarkeitsanalyse weniger herausfiltert als angegeben, ist auch das sichtbar – jeder herausgefilterte Befund trägt seinen Nachweis.

Kostenloses Kontingent: 3 Umgebungen und bis zu 100 Scans neuer Digests pro rollierender 24-Stunden-Periode, selbstgehostet. v1.0-RC1, Release Candidate.