For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Hauptnavigation
Codex

Codex use case

Abhängigkeitsvorfälle prüfen

Erstelle aus einem öffentlichen Sicherheitshinweis zu einem Paket einen sicheren Plan für ein Repository-Audit.

Difficulty Fortgeschritten
Time horizon 1 h

Nutze Codex, um anhand eines öffentlichen Sicherheitshinweises zu einem Paket oder zur Softwarelieferkette ein Audit ohne Schreibzugriff durchzuführen. Prüfe dabei Manifeste, Lockfiles, CI-Arbeitsabläufe und Skripte, ohne nicht vertrauenswürdigen Code auszuführen.

Am besten geeignet für

  • Entwicklungs- und Sicherheitsteams, die auf öffentliche Sicherheitshinweise zu Paketen oder zur Softwarelieferkette reagieren.
  • Verantwortliche, die Lockfiles, Skripte, CI-Berechtigungen und Caches prüfen müssen, bevor sie Abhängigkeiten ändern.
  • Vorfallanalysen, bei denen Codex Belege zusammentragen soll, ohne Pakete zu installieren oder nicht vertrauenswürdigen Code auszuführen.

Contents

    ← Alle Anwendungsfälle

    Abhängigkeitsvorfälle prüfen

    Erstelle aus einem öffentlichen Sicherheitshinweis zu einem Paket einen sicheren Plan für ein Repository-Audit.

    Nutze Codex, um anhand eines öffentlichen Sicherheitshinweises zu einem Paket oder zur Softwarelieferkette ein Audit ohne Schreibzugriff durchzuführen. Prüfe dabei Manifeste, Lockfiles, CI-Arbeitsabläufe und Skripte, ohne nicht vertrauenswürdigen Code auszuführen.

    Fortgeschritten
    1 h

    Nutze Codex, um anhand eines öffentlichen Sicherheitshinweises zu einem Paket oder zur Softwarelieferkette ein Audit ohne Schreibzugriff durchzuführen. Prüfe dabei Manifeste, Lockfiles, CI-Arbeitsabläufe und Skripte, ohne nicht vertrauenswürdigen Code auszuführen.

    Fortgeschritten
    1 h

    Am besten geeignet für

    • Entwicklungs- und Sicherheitsteams, die auf öffentliche Sicherheitshinweise zu Paketen oder zur Softwarelieferkette reagieren.
    • Verantwortliche, die Lockfiles, Skripte, CI-Berechtigungen und Caches prüfen müssen, bevor sie Abhängigkeiten ändern.
    • Vorfallanalysen, bei denen Codex Belege zusammentragen soll, ohne Pakete zu installieren oder nicht vertrauenswürdigen Code auszuführen.

    Skills und Plug-ins

    • Prüfe Repository-Dateien, Pull Requests, Arbeitsabläufe und den sicherheitsrelevanten Repository-Verlauf.
    Skill Why use it
    GitHub Prüfe Repository-Dateien, Pull Requests, Arbeitsabläufe und den sicherheitsrelevanten Repository-Verlauf.

    Einstiegs-Prompt

    Hilf mir zu prüfen, ob dieses Repository von diesem öffentlichen Sicherheitshinweis zu einem Paket betroffen ist: [advisory URL]. Arbeite ohne Schreibzugriff, es sei denn, ich genehmige einen Schritt zur Behebung ausdrücklich. Fasse zuerst Folgendes zusammen: - betroffene Pakete und Versionsbereiche - maßgebliche Quellen im Vergleich zu allgemeineren Berichten - welche Belege nachweisen würden, dass dieses Repository betroffen ist - welche Belege dies ausschließen würden Untersuche anschließend: - Paketmanifeste und Lockfiles - CI-Arbeitsabläufe und -Berechtigungen - Installations-, Build- und postinstall-Skripte - in das Repository übernommene Artefakte, Container oder generierte Bundles, falls relevant - Wege, über die Caches oder Tokens offengelegt werden könnten, falls der Sicherheitshinweis CI oder Veröffentlichungsprozesse betrifft Berichte: - Status der Belege: Betroffenheit bestätigt, Überprüfung erforderlich oder ausgeschlossen - Hinweise zu Schweregrad und Tragweite - Dateiverweise für jede Repository-spezifische Aussage - Einschränkungen und empfohlene nächste Schritte Installiere keine Pakete, führe keine Lifecycle-Skripte aus, erstelle keinen Build des Projekts, führe keinen nicht vertrauenswürdigen Code aus, rotiere keine Zugangsdaten und bereinige keine Dateien, es sei denn, ich genehmige den jeweiligen Schritt ausdrücklich.
    Hilf mir zu prüfen, ob dieses Repository von diesem öffentlichen Sicherheitshinweis zu einem Paket betroffen ist: [advisory URL]. Arbeite ohne Schreibzugriff, es sei denn, ich genehmige einen Schritt zur Behebung ausdrücklich. Fasse zuerst Folgendes zusammen: - betroffene Pakete und Versionsbereiche - maßgebliche Quellen im Vergleich zu allgemeineren Berichten - welche Belege nachweisen würden, dass dieses Repository betroffen ist - welche Belege dies ausschließen würden Untersuche anschließend: - Paketmanifeste und Lockfiles - CI-Arbeitsabläufe und -Berechtigungen - Installations-, Build- und postinstall-Skripte - in das Repository übernommene Artefakte, Container oder generierte Bundles, falls relevant - Wege, über die Caches oder Tokens offengelegt werden könnten, falls der Sicherheitshinweis CI oder Veröffentlichungsprozesse betrifft Berichte: - Status der Belege: Betroffenheit bestätigt, Überprüfung erforderlich oder ausgeschlossen - Hinweise zu Schweregrad und Tragweite - Dateiverweise für jede Repository-spezifische Aussage - Einschränkungen und empfohlene nächste Schritte Installiere keine Pakete, führe keine Lifecycle-Skripte aus, erstelle keinen Build des Projekts, führe keinen nicht vertrauenswürdigen Code aus, rotiere keine Zugangsdaten und bereinige keine Dateien, es sei denn, ich genehmige den jeweiligen Schritt ausdrücklich.

    Mit einem sicheren Auditplan beginnen

    Wenn sich ein Vorfall im Zusammenhang mit Abhängigkeiten oder der Softwarelieferkette schnell entwickelt, hilft dir ein übereilter Patch zunächst nicht. Du brauchst einen klaren Auditplan: Was hat sich geändert, welche Pakete oder Arbeitsabläufe könnten betroffen sein und welche Belege würden nachweisen, dass dein Repository betroffen ist?

    Nutze Codex, um aus dem Sicherheitshinweis eine Checkliste für ein bewusst vorsichtiges Vorgehen ohne Schreibzugriff zu erstellen, bevor du mit Installationen, Builds oder Tests beginnst oder etwas ausführst.

    Erste Prüfung ohne Schreibzugriff durchführen

    1. Stelle Codex den öffentlichen Sicherheitshinweis, den Vorfallbericht oder die Liste der betroffenen Pakete bereit.
    2. Bitte Codex, maßgebliche Quellen von allgemeinen Kommentaren und Einschätzungen zu trennen.
    3. Lass Codex festlegen, welche Belege eine Betroffenheit nachweisen oder ausschließen würden.
    4. Lass Codex Manifeste, Lockfiles, CI-Arbeitsabläufe, Skripte und relevante Dateien im Repository prüfen.
    5. Bitte Codex, die Ergebnisse nach dem Status der Belege, dem Schweregrad und dem empfohlenen nächsten Schritt zu gruppieren.

    Führe bei Vorfällen mit Paketen keine Installations-, Build-, Test-, Import- oder Lifecycle-Befehle aus, bis du weißt, welche Komponenten laut dem Sicherheitshinweis betroffen sind. Codex kann Lockfiles und Arbeitsabläufe durchsuchen, ohne nicht vertrauenswürdigen Code auszuführen.

    Status der Belege getrennt vom Schweregrad angeben

    Ein hilfreiches Auditergebnis sollte sowohl zeigen, wie schwerwiegend ein Befund wäre, als auch, wie belastbar die Belege sind:

    Codex

    Betroffenheit bestätigt: Das Lockfile enthält eine betroffene Paketversion in einem produktiv genutzten Abhängigkeitspfad.

    Überprüfung erforderlich: Ein CI-Job hat Berechtigungen zum Veröffentlichen, aber der Arbeitsablauf scheint das betroffene Paket nicht direkt zu installieren.

    Ausgeschlossen: Der Paketname kommt nur in der Dokumentation vor und ist nicht in Manifesten oder Lockfiles enthalten.

    Nächster Schritt: Prüfe die vorgeschlagene Aktualisierung der Abhängigkeiten und den Plan, Tokens zu rotieren, bevor du eine destruktive Maßnahme ergreifst.

    Sobald die Prüfung ohne Schreibzugriff abgeschlossen ist, kannst du Codex bitten, einen Pull Request zur Behebung vorzubereiten, die CI-Berechtigungen zu aktualisieren oder eine Notiz zur Nachbereitung des Vorfalls zu verfassen. Führe diese Schritte getrennt vom anfänglichen Audit aus.

    Erstelle aus den bestätigten Befunden dieses Audits einen Plan zur Behebung. Führe für jeden Befund Folgendes auf: - vorgeschlagene Änderung - zu aktualisierende Dateien oder Einstellungen - Test- oder Prüfschritt - Rollback-Plan - ob ich Zugangsdaten rotieren oder ein externes System prüfen muss Nimm noch keine Änderungen vor. Nimm Befehle, die nicht vertrauenswürdigen Code ausführen könnten, nur dann in den Plan auf, wenn du erklärst, warum sie sicher sind.

    Verwandte Anwendungsfälle