Elysia Tools
Mobile Navigation
Workflow Playbook
Fixieren Sie das Inventar eines Node.js-Releases, prüfen Sie eine externe SBOM anhand einer genehmigten Lizenzrichtlinie und übergeben Sie nachvollziehbare Befunde und Freigaben.
Themen
Dieser Ablauf hilft Node.js-Verantwortlichen, vor einer Veröffentlichung belastbare Prüfnachweise zu übergeben. Beginnen Sie mit exaktem Artefakt, Quellrevision, package.json, Lockdatei und extern erzeugter SBOM. Erfassen Sie Generator, Einstellungen, Einbezug von Entwicklungsabhängigkeiten und Build-Kennung. Berechnen Sie Prüfsummen aller Originale. Eine Lockdatei beschreibt die Auflösung; Bündelung, ausgelassene sowie optionale oder plattformspezifische Pakete können das ausgelieferte Ergebnis verändern. Eine fehlende Zuordnung zum Build bleibt eine Abdeckungslücke.
Klären Sie die Berechtigung vor dem Hochladen privater Paketnamen oder interner Adressen. Zugangstoken gehören nicht in die Eingabe. Geschwärzte Arbeitskopien benötigen eigene Prüfsummen und eine kontrollierte Zuordnung zum Original. Dieser Ablauf installiert keine Pakete, erzeugt keine SBOM, untersucht kein fertiges Archiv und sucht keine Schwachstellen.
Der Abhängigkeitsprüfer untersucht package.json und bietet einen optionalen Baum für npm package-lock.json oder Yarn v1 yarn.lock. pnpm- und Bun-Lockdateien benötigen einen externen Leser. Eine Konvertierung für das Formular beweist keine gleichwertige Abdeckung. Ohne nutzbare Lockdatei betreffen Aussagen nur Deklarationen. Halten Sie Baumquelle, Tiefenbegrenzung und Parserwarnungen fest. Ein leerer Baum nach einem Lesefehler bedeutet nicht, dass keine Abhängigkeiten existieren.
Beispielsweise ist ^2.4.0 ein deklarierter Bereich, 2.4.3 hingegen eine konkrete aufgelöste Version. Prüfen Sie Letztere mit SemVer und behandeln Sie Git-, Workspace-Verweise und Tags gesondert. Zur JSON-Strukturprüfung müssen Sie ein passendes Schema mit unterstütztem Dialekt bereitstellen. Struktur sagt nichts über Vollständigkeit oder Wahrheit der Lizenzangaben. Der Richtlinienprüfer akzeptiert SPDX 2.3 JSON und CycloneDX 1.5 JSON/XML. Die JSON-Schema- und Vergleichsschritte gelten nicht für XML; erhalten Sie das Original und nutzen Sie geeignete externe Prüfungen.
Speichern Sie tatsächliche Einstellungen für Profil, Copyleft-Toleranz, Erlaubnis- und Sperrlisten sowie unbekannte Lizenzen. Der Profilname allein kann nach Versionswechseln mehrdeutig sein. Sichern Sie den Markdown- oder SARIF-Bericht. Für beide Formate führen Sie die Prüfung mit identischen Daten und Einstellungen jeweils aus. Bewahren Sie vollständige Lizenzausdrücke einschließlich AND, OR und WITH auf und lassen Sie Texte und Pflichten angemessen prüfen. Ein günstiger Teilausdruck darf nicht die gesamte Lizenzangabe ersetzen.
Prüfen Sie markierte Komponenten und verfügbare Abhängigkeitspfade. Fehlende Pfade können auf unvollständige SBOM-Beziehungen zurückgehen und beweisen keine Isolation. Vergleichen Sie JSON mit der genehmigten Basis und gleichen Sie Identität, Version und Ausdruck manuell ab. Arrayreihenfolge, generierte Kennungen und Zeitstempel verursachen Vergleichsrauschen; das Werkzeug gleicht Pakete nicht semantisch ab. Erklären Sie Zugänge, Abgänge und unerwartete Lizenzänderungen. Ausnahmen brauchen Verantwortlichen, Begründung, betroffenes Release, Umfang und Ablaufdatum statt stiller Erweiterung einer Erlaubnisliste.
Führen Sie ein separates Markdown-Protokoll mit Release-Kennung, Artefakt- und SBOM-Prüfsummen, Richtlinienrevision, Komponentenkennung, Version, vollständigem Ausdruck, Pfad oder dessen Fehlen, Beleg, Entscheidung und Verantwortlichem. Dies sind empfohlene Prüffelder, nicht zugesicherte automatische Berichtsfelder. Unbelegte Punkte bleiben offen oder sperrend. Wiederholen Sie betroffene Prüfungen nach Eingabe- oder Richtlinienänderungen und bewahren Sie frühere Ergebnisse auf.
Die Markdown-Prüfung verbessert Lesbarkeit, nicht Rechtsrichtigkeit. Kontrollieren Sie beim optionalen PDF Tabellen, Warnungen, lange Kennungen und Pfade auf abgeschnittene Inhalte. Bewahren Sie vollständige Quelle und maschinenlesbare Berichte auf. Archivieren Sie lokale Dateien mit finalen Prüfsummen, nicht nur temporäre Downloadlinks. SARIF allein richtet keine CI-Sperre ein. Dockerfile und Umgebung gehören zum verwandten Container-Ablauf, umfassendere Dateivergleiche zum Vergleichsablauf. Für Urheberschaft statt bloßer Bytegleichheit verwenden Sie den Signaturprüfungsablauf.
Workflow-Leitfaden
Erfassen Sie Prüfsummen, Quellrevision und Einstellungen des SBOM-Generators. Trennen Sie deklarierte Abhängigkeiten von tatsächlich ausgelieferten Paketen.
Prüfen Sie Manifest und unterstützte Lockdatei, konkrete aufgelöste Versionen sowie JSON mit passendem Schema. Behalten Sie Warnungen und Abdeckungslücken bei.
Prüfen Sie die externe SBOM mit dokumentierten Einstellungen. Sichern Sie Markdown oder SARIF und prüfen Sie unbekannte Lizenzen, vollständige Ausdrücke und fehlende Pfade.
Vergleichen Sie aktuelle und genehmigte JSON-Dateien und ordnen Sie Komponenten manuell zu. Wiederholen Sie Prüfungen nach Korrekturen; Ausnahmen brauchen Zuständigkeit, Umfang und Ablaufdatum.
Der optionale Baum unterstützt npm package-lock.json und Yarn v1 yarn.lock. Für pnpm oder Bun sind ein externer Leser und ein dokumentierter Abdeckungsvermerk nötig; ein leerer oder fehlerhafter Baum beweist keine Abhängigkeitsfreiheit.
Prüfen Sie JSON mit einem bereitgestellten kompatiblen Schema und vergleichen Sie JSON-Dateien. Unterstütztes CycloneDX XML ist im Richtlinienprüfer möglich; XML-Prüfung und Vergleich brauchen jedoch einen eigenen Weg statt einer vermeintlich verlustfreien Konvertierung.
Unbekannte Lizenzen, fehlende Herkunftsnachweise und Richtlinienfehler bleiben offen, bis ein benannter Prüfer Belege oder eine begrenzte Ausnahme genehmigt. Automatischer Erfolg ist weder Rechtsprüfung noch Schwachstellenfreigabe.
Prüfen Sie Markdown und gegebenenfalls PDF auf vollständige Tabellen und lange Pfade. Berechnen Sie finale Prüfsummen und archivieren Sie Berichte, Warnungen und Entscheidung.