Prüfen, was in die Veröffentlichung gelangt

Fragen Sie, ob die Abhängigkeit nötig ist

Ein Agent kann ein Paket vorschlagen, das ein Problem scheinbar löst. Der Vorschlag ist kein Nachweis dafür, dass das Paket existiert oder geeignet ist. Prüfen Sie vor der Installation die genaue Registry, den Herausgeber, Paketnamen und Version.

Für einen fiktiven CSV-Export stellt die Laufzeit das erforderliche Verhalten möglicherweise bereits bereit. Ein neues Paket kann dennoch angemessen sein. Es ergänzt aber Wartungsaufwand und Ausführungspfade. Vergleichen Sie den Implementierungsaufwand mit den dauerhaften Aufgaben, die diese Abhängigkeit mit sich bringt.

Prüfen Sie Lizenz und unterstützte Laufzeit. Untersuchen Sie Wartungsaktivität und relevante Sicherheitshinweise. Ein vertrauter Name kann in einer anderen Registry ein anderes Paket bezeichnen. Eine erfolgreiche Installation zeigt nur, dass die Installation abgeschlossen wurde.

Prüfen Sie Installations- und Build-Verhalten

Abhängigkeiten können während Installation oder Build Code ausführen. Begrenzen Sie Zugangsdaten und Netzwerkzugriff in diesen Umgebungen. Geben Sie einem Job, der einen nicht vertrauenswürdigen Pull Request verarbeitet, keine Produktionssecrets.

Nutzen Sie eine eingecheckte Lockdatei, sofern das Ökosystem dies unterstützt. Verlangen Sie, dass der Build diese Datei beachtet. Prüfen Sie Lockdateiänderungen zusammen mit der Quellcodeänderung, einschließlich unerwarteter transitiver Pakete. Feste Versionen verbessern die Reproduzierbarkeit, machen eine verwundbare Version aber nicht sicher.

Das NIST SSDF behandelt den Schutz von Software und Entwicklungspraktiken über den gesamten Lebenszyklus. Nutzen Sie diese breitere Perspektive beim Entwurf der Build-Umgebung. Lesen Sie das Framework.

Unterscheiden Sie Inventar und Herkunftsnachweis

Eine Software Bill of Materials, kurz SBOM, erfasst Komponenten einer Software. Sie hilft, betroffene Veröffentlichungen zu finden, wenn eine Komponente Probleme aufwirft. Sie belegt nicht eigenständig, dass die Komponenten sicher sind.

Provenance beschreibt, wie ein Artefakt erzeugt wurde. SLSA definiert dafür ein Format mit Informationen über Build und Eingaben. Die Prüfung muss diese Informationen mit einem vertrauenswürdigen Ersteller und dem vorgesehenen Artefakt verbinden. Eine Datei namens „Provenance“ reicht nicht aus. SLSA-Provenance.

Dokumentieren Sie für den Exportdienst eine prüfbare Kette:

1. Der geprüfte Commit identifiziert den angenommenen Quellcode.
2. Der Build benennt seine Eingaben und Ausführungsumgebung.
3. Das Artefakt besitzt einen stabilen Hash.
4. Die Prüfungen benennen das untersuchte Artefakt oder den Quellcode.
5. Das Deployment erfasst das in der Zielumgebung bereitgestellte Artefakt.

Erzeugen Sie nach der Genehmigung keinen abweichenden Neubuild ohne definierten Prüfprozess. Ein veränderlicher Tag wie latest kann später auf ein anderes Image zeigen.

Entscheiden Sie, was ein Befund bedeutet

Ein Schwachstellenbefund braucht Kontext: betroffene Version, erreichbares Verhalten, Exposition, verfügbare Korrektur und Folgen. Dokumentieren Sie die Nachweise hinter jeder vorübergehenden Ausnahme. Geben Sie ihr einen Verantwortlichen, ein Ablaufdatum und einen Prüfauslöser.

Schalten Sie nicht einen ganzen Scanner stumm, weil ein Befund nicht zutrifft. Behaupten Sie kein sauberes Ergebnis, wenn der Scan nicht abgeschlossen wurde. Ein Timeout, ein nicht unterstütztes Paket oder ein nicht verfügbarer Hinweisfeed bedeutet fehlende Nachweise.

Planen Sie schließlich Aktualisierungen nach der Veröffentlichung. Neue Sicherheitshinweise können das gestern angenommene Artefakt betreffen. Der Dienstverantwortliche braucht ein Inventar, einen Reaktionsprozess und die Kapazität für eine korrigierte Veröffentlichung.

Lesen Sie weiter über kontinuierliches Schwachstellenmanagement, um wiederholte Scans mit geprüften Produktionskorrekturen zu verbinden.