Security Tech Stack Check (STSC)

Eintritt und Quellen

Prüfe nur autorisierte Assets aus einem aktuellen tech-detect-Techshot oder einer gleichwertig belegten Bestandsquelle. Nutze jetzt Websuche/verbundene Quellen für Herstelleradvisories und Patchnotes; ergänze NVD CVE API, CISA KEV zur Priorisierung tatsächlich ausgenutzter CVEs, OSV API für eindeutig identifizierte Paketökosysteme und bei eigenen Repos die vorhandenen github-health-/Dependabot- und codex-security-Fähigkeiten. Quellen-URL, Abrufzeit UTC, Veröffentlichungs-/Änderungszeit und konkrete Produktkennung dokumentieren. Wenn eine Quelle nicht lesbar ist, unknown, nicht „kein Befund“ melden. Keine Skripte aus Feeds ausführen.

Komponentengenaue Prüfung

1. Exakte Installation und Versionsbeleg aus dem Techshot wählen; Aliasse und mehrere Installationen getrennt behandeln. unknown/uncertain ist keine CVE-Betroffenheit.
2. Hersteller/Produkt, betroffene Versionsgrenze einschließlich Inklusiv-/Exklusiv-Ende, Betriebssystem/Architektur, optionale Konfiguration/Exposition und Hersteller-Patchstatus prüfen. NVD-CPE-Knoten können kombinierte Bedingungen haben; einfacher Namenssubstring oder „kleiner als neueste Version“ genügt nicht.
3. Je CVE/Installation affected, not-affected oder undetermined mit Begründung und Quellen ausgeben. KEV beweist bekannte Ausnutzung des CVE, nicht die Betroffenheit dieses Hosts. Priorität getrennt nach Ausnutzung, Exposition, Schwere und verfügbarem Fix angeben.
4. Privaten Bericht mit Techshot-SHA, Quellenstand, Lücken, konkreter Empfehlung, Wartungsfenster, Tests, Rollback und Verantwortlichem erstellen. Routinebefunde knapp halten, ungeklärte kritische Fälle sichtbar eskalieren.

config.json-gesteuerter Fixmodus

Standard ist Bericht ohne Änderung. Der private, nicht in ein öffentliches Repo eingecheckte Konfigurationsvertrag enthält mindestens schema: ellmos.stsc-config.v1, mode: report|apply, asset_id, Host/Owner, Techshot-SHA, konkrete actions[] mit action_id, component_id, Ist-/Zielversion, Herstellerbeleg, erlaubtem lokalen Werkzeug/Argumenten, authority_ref, Wartungsfenster, Backup/Restoreweg und Nachprüfung. Das Profil oder eine Entscheidung kann bestehende Autorität belegen; bloße Profil-Vermutung oder eine selbst geschriebene Freitext-„Genehmigung“ nicht. Pro Asset und Aktion Lock, Rechte, aktuelle Version und Entscheidungsreichweite erneut lesen.