de.wedoany.com-Bericht: Die US-amerikanische Cybersecurity and Infrastructure Security Agency (CISA) hat den Leitfaden „Open-Source-Software: Sicherheitsprinzipien und -praktiken" veröffentlicht, der Bundesbehörden bei der Verwaltung der Sicherheit von Open-Source-Software, der Beteiligung an Open-Source-Projekten und der Bewertung von Open-Source-KI-Systemen unterstützt.
Der Leitfaden weist darauf hin, dass der Quellcode von Open-Source-Software unabhängig geprüft werden kann, wodurch die Abhängigkeit von Herstellerangaben verringert und das Risiko einer Bindung an einen einzelnen Anbieter reduziert wird; die Befreiung von Lizenzgebühren und die gemeinsame Verteilung der Entwicklungsarbeit können Kosten senken, und die öffentliche Bereitstellung öffentlich finanzierter Software kann unter geeigneten Umständen die Transparenz erhöhen.
CISA empfiehlt den Behörden, Open-Source-Software wie normale Software-Assets zu behandeln, ihre Sicherheit vor der Einführung zu bewerten und sie über den gesamten Lebenszyklus hinweg zu überwachen. Bevorzugt sollten aktiv gepflegte Projekte ausgewählt, Lizenzbedingungen verstanden und eine Liste der verwendeten Open-Source-Komponenten geführt werden.
Der Leitfaden empfiehlt, Software-Abhängigkeiten zu verfolgen, neu bekannt gewordene Schwachstellen zu überwachen und regelmäßig zu bewerten, ob Projekte weiterhin vertrauenswürdig sind. Eine Software-Stückliste (SBOM) hilft dabei, bei der Offenlegung von Schwachstellen betroffene Komponenten zu identifizieren. Die Behörden sollten Sicherheitspatches so schnell wie möglich anwenden; wenn für kundenspezifische Software oder Open-Source-Projekte noch keine Updates verfügbar sind, sollten sie sich darauf vorbereiten, Korrekturprogramme beizusteuern. Wenn ein Projekt das Ende des Supports erreicht hat oder Sicherheitsprobleme ungelöst bleiben, sollte es durch unterstützte Alternativen ersetzt werden. Werkzeuge, einschließlich solcher mit künstlicher Intelligenz, erhöhen die Anzahl der entdeckten Schwachstellen und beschleunigen die Patch-Entwicklung. CISA ermutigt dazu, Abhängigkeitsverwaltung, Patch-Bereitstellung und Sicherheitstests so weit wie möglich zu automatisieren.
CISA ermutigt die Behörden, Verbesserungen zu den von ihnen verwendeten Open-Source-Projekten beizutragen, einschließlich Sicherheitskorrekturen, Fehlerberichten, Dokumentation und technischen Diskussionen, und Änderungen mit der Gemeinschaft zu teilen, um Doppelarbeit zu reduzieren, Software zu verbessern und staatlich finanzierte Ergebnisse öffentlich zu machen. Vor einem Beitrag sollte bestätigt werden, dass die Projektlizenz eine Teilnahme erlaubt, und Quellcode, Dokumentations- und Konfigurationsdateien sollten überprüft werden, um die Offenlegung von Geheimnissen wie Passwörtern, Verschlüsselungsschlüsseln und internen Systemdetails zu verhindern.
Für Behörden, die selbst Software entwickeln, empfiehlt CISA, von Anfang an eine Veröffentlichung als Open Source in Betracht zu ziehen, sofern nicht rechtliche, sicherheitsbezogene oder betriebliche Gründe dagegen sprechen. Ein Inventar der intern entwickelten Software sollte kennzeichnen, ob ein Projekt öffentlich veröffentlicht, innerhalb der Bundesregierung geteilt oder zurückbehalten wird. Vor der Veröffentlichung sollten sensible Informationen geprüft, sichere Entwicklungspraktiken befolgt, eine geeignete Lizenz gewählt und Dokumentation, Beitragsrichtlinien, Richtlinien zur Offenlegung von Schwachstellen und SBOM im öffentlichen Code-Repository veröffentlicht werden. Nach der Veröffentlichung müssen Updates weiterhin veröffentlicht, Sicherheitsprobleme behoben und klar festgelegt werden, wann die Software nicht mehr unterstützt wird. Wenn Software von Auftragnehmern kundenspezifisch entwickelt wird, sollte die Regierung das Recht behalten, sie wiederzuverwenden, zu modifizieren und unter geeigneten Bedingungen als Open Source zu veröffentlichen.
CISA betont, dass bei der Bewertung sogenannter „Open-Source"-KI-Systeme eine Unterscheidung von Open-Source-Software erforderlich ist: KI-Modelle können unter Open-Source-Lizenzen veröffentlicht werden, ohne dass Trainingsdaten öffentlich zugänglich gemacht werden müssen. Ohne Zugang zu Trainingsdaten und Trainingsprozessen ist es für Organisationen schwierig, die Herkunft des Modells zu bestimmen und zu bewerten, ob der Entwicklungsprozess oder Komponenten manipuliert wurden. Vor der Bereitstellung sollte sichergestellt werden, dass ausreichende Transparenz über die Entwicklungsweise (einschließlich Trainingsdaten und Trainingsprozess) besteht; wenn Informationen nicht verfügbar sind, sollte das System als proprietäre Software mit unvollständiger Herkunft betrachtet und strengeren Risikomanagementmaßnahmen unterzogen werden.
