Seien Sie nicht das schwächste Glied: Die Rolle der Entwickler bei der Sicherung der Software-Lieferkette

Alle Beiträge

Wenn drei US-Regierungsbehörden zusammenkommen, um Entwickler „nachdrücklich zu ermutigen“, bestimmte Praktiken einzuführen, sollten Sie aufmerksam sein. CISA, NSA und ODNI gaben angesichts der Bedrohung durch Cyber-Hacker und im Anschluss an den SolarWinds-Angriff bekannt, dass sie gemeinsam eine Sammlung von Empfehlungen zur Sicherung der Software-Lieferkette veröffentlichen werden, um solche Schwachstellen in Zukunft zu verhindern . In der Ankündigung wurde deutlich gemacht, dass der Zweck des Dokuments darin besteht, Entwickler zur Übernahme bewährter Praktiken zu ermutigen, und es heißt: „Zu diesen Grundsätzen gehören die Planung von Sicherheitsanforderungen, das Entwerfen von Softwarearchitekturen unter Sicherheitsgesichtspunkten, das Hinzufügen von Sicherheitsfunktionen und die Aufrechterhaltung der Sicherheit von Software und der zugrunde liegenden Infrastruktur."

Dieser Leitfaden ist als dreiteilige Reihe organisiert und wird zeitgleich mit dem Lebenszyklus der Software-Lieferkette veröffentlicht. Teil 1 der Serie, das sich auf Empfehlungen für Softwareentwickler konzentriert, wurde im August 2022 veröffentlicht. Die verbleibenden zwei Teile werden in naher Zukunft veröffentlicht: Teil 2 wird sich auf die Softwarelieferanten konzentrieren und Teil 3 wird sich auf die Kunden konzentrieren, die die Software erhalten. Das ultimative Ziel besteht darin, dass diese Reihe dazu beiträgt, die Kommunikation zwischen diesen drei Hauptakteuren und unter Cybersicherheitsexperten zu fördern, um die Ausfallsicherheit zu erhöhen und insgesamt zu verbessern Sicherheit der Software-Lieferkette.

Obwohl nicht immer klar ist, wer für die Gewährleistung der Softwaresicherheit verantwortlich ist, ist dies unabhängig davon, wer in Ihrer spezifischen Organisation die Gesamtverantwortung trägt neue Anleitung macht deutlich, dass sich alle Entwickler mit diesen neuen Best Practices vertraut machen sollten und dass sie alle eine Rolle bei der Sicherung der Software-Lieferkette spielen. Oder, wenn ich es deutlicher formulieren darf: Entwickler, Sie spielen eine entscheidende Rolle bei der Sicherung der Software-Lieferkette Ihres Unternehmens! Aus diesem Grund dachten wir, dass es für Sie hilfreich sein könnte, eine (relativ) kurze Zusammenfassung dieses ersten Teils des Leitfadens nur für Sie zu lesen. Hier kommt es. 

Der Leitfaden in Kürze:

Unter den umfangreichen Listen potenzieller Bedrohungen, auf die in diesem praktischen Leitfaden für Entwickler verwiesen wird, wurden einige wichtige Schwachstellen identifiziert, die Sie unbedingt beheben und sich darauf vorbereiten sollten:

  • Funktionen, die nicht ordnungsgemäß dokumentiert wurden oder riskante Funktionen implementieren
  • Verdeckte Verschiebungen der zentralen Sicherheitsannahmen zwischen dem Zeitpunkt der Sicherheitsbewertung und der Codebereitstellung 
  • Unternehmensveränderungen bei den Stakeholdern der Lieferkette
  • Minderwertige Codierungs- oder Sicherheitspraktiken

Management-, Finanz- und Programmmanager haben alle die Verantwortung, sich um die Sicherheit der Software-Lieferkette zu kümmern, aber auch um deren Integrität Sicherheit der Software-Lieferkette hängt oft von der Wachsamkeit der Softwareentwickler und dem Bewusstsein aller Beteiligten in der Lieferkette ab. Teil 1 des Leitfadens konzentriert sich auf die Rolle von Entwicklern und die Bedrohungen, die jeder Phase des Entwicklungsprozesses innewohnen, und bietet Empfehlungen für Risikominderungsstrategien, die zu Standardpraktiken werden sollten. 

Stufe Nr. 1: Sichere Produktkriterien und -verwaltung

Eine sichere Entwicklung beginnt mit der Anerkennung der Bedeutung der Sicherheit der Software-Lieferkette durch alle wichtigen Beteiligten in den Produkt- und Entwicklungsteams. Die Bedrohungsszenarien sind häufig und dürften jedem klar sein; Die Herausforderung besteht darin, alle hinsichtlich der beschlossenen Klimaschutzmaßnahmen auf den gleichen Stand zu bringen. Diese Richtlinien müssen den gesamten Prozess abdecken: das Design und die Architektur, die Bedrohungsmodellierung, die Codierung, die Sicherheitstestpläne, die Freigabekriterien und den Umgang mit Schwachstellen in der Zukunft. Dazu gehört auch die Bewertung der Fähigkeiten der Teams und die Sicherstellung, dass sie für ihre Aufgaben ordnungsgemäß geschult wurden. Anschließend werden Dokumentationspraktiken sowie regelmäßige Sicherheitsüberprüfungen und Bedrohungsbewertungen festgelegt.

Stufe Nr. 2: Sichere Codeentwicklung

Wenn es um die Codeentwicklung geht, wurden die richtigen Vorgehensweisen für sicheres Codieren bereits im dargelegt SSDF. Aus diesem Grund sollten, soweit die Programmiersprache nicht vorgegeben ist, auch Sicherheitsaspekte in die Entscheidung einbezogen werden. Der Führer liefert nützliche Hinweise für Entwickler, die sich mit einem breiten Spektrum von Szenarien befassen, wie z. B. dem Einfügen schädlichen Quellcodes durch „Insider“ (z. B. Entwickler), Open-Source-Software und den Best Practices für den Umgang damit. So erstellen Sie eine sichere Umgebung für die Codierung (einschließlich sicherer Build-Konfigurationen und Softwaretools von Drittanbietern) und testen anschließend die Sicherheit eines integrierten Produkts. Da es wahrscheinlich ist, dass Schwachstellen auch nach der Auslieferung auftreten, gibt es auch Empfehlungen zum Umgang mit gemeldeten Schwachstellen und zur Sicherstellung, dass zukünftige externe Softwareerweiterungen die Sicherheitsintegrität des Produkts nicht gefährden.

Stufe Nr. 3: Härten Sie die Build-Umgebung

Sobald der Code sicher entwickelt wurde, erfordert die Sicherheit der Software-Lieferkette, dass die Build-Umgebung nach denselben Standards gehärtet wird wie die Software selbst. Die Kompromittierung des Build-Systems ist eine attraktive Möglichkeit, in den Code einzudringen, da sie in einer Phase des Entwicklungsprozesses erfolgt, die von Entwicklern naturgemäß weniger genau unter die Lupe genommen wird. 

Stufe Nr. 4: Code-Lieferung

Die letzte im Leitfaden behandelte Schwachstelle betrifft die letzte Phase der Software-Lieferkette – die Codebereitstellung. Selbst wenn der Code bis zu diesem Zeitpunkt ordnungsgemäß gesichert wurde, gibt es immer noch zwei wichtige Schwachstellen in der Lieferkette, die behoben werden müssen. Die erste ist die endgültige Paketvalidierung, die beispielsweise durch die unbeabsichtigte Offenlegung von Metadaten, Entwickleranmeldeinformationen oder dem Open-Source-Bestand ausgenutzt werden kann. Der andere Schritt, der häufig auf Schwachstellen untersucht wird, ist das Verteilungssystem, das durch einen Man-in-the-Middle-Angriff kompromittiert werden könnte, der eine oder mehrere Phasen der Bereitstellung übernehmen kann.

Durch die Anwendung dieser Risikominderungspraktiken auf der Ebene der Softwareentwicklung können Softwareanbieter Schwachstellen vermeiden, die beispielsweise zum Einschleusen von Updates, zur Manipulation von Codesignaturen und zu im Open-Source-Code versteckten „Überraschungen“ führen können.

So etwas wie ein kostenloses Mittagessen gibt es nicht: Die versteckten Kosten für Software von Drittanbietern

über GIPHY

Ein Schlüssel Beitrag zur Entwicklergeschwindigkeit ist die Fähigkeit geworden, Software von Drittanbietern effektiv zu integrieren. Dies hat es Entwicklern ermöglicht, sich beispielsweise auf Innovation oder Funktion zu konzentrieren, während sie für Skalierbarkeit oder Schnittstellen auf vorgefertigte Komponenten zurückgreifen. Dieser zunehmende Einsatz von Software von Drittanbietern stellt die Sicherheit der Software-Lieferkette vor große Herausforderungen. Zusätzlich zur Durchführung einer Bewertung dieses Codes gemäß den gleichen Standards, die auch zur Bewertung Ihres eigenen Codes verwendet werden, empfiehlt der Leitfaden, die Binärdateien auf etwaige Schwachstellen zu scannen und die daraus resultierenden Risiken zu bewerten. Die Ergebnisse dieser Bewertung sollten in die Entscheidung einfließen, eine bestimmte Softwarekomponente zu verwenden oder nicht. Bei der Auswahl einer Softwarekomponente muss auch deren Quelle berücksichtigt werden; Die Integration von Komponenten von Drittanbietern in Ihren Quellcode ist der Beginn einer langen Beziehung und Sie sollten danach streben, mit Partnern zusammenzuarbeiten, denen Sie vertrauen können. Codebesitz, Codierungspraktiken und Versionsverwaltungsrichtlinien sind nur einige Punkte, die bei der Auswahl einer vertrauenswürdigen Quelle zu berücksichtigen sind. Denken Sie nur an alle zukünftigen Updates, Releases und Wartungsarbeiten für jede Komponente, wenn neue Bedrohungen entdeckt werden. Die Herausforderung wird darin bestehen, alle Änderungen von Drittanbietern zu überwachen, auf Schwachstellen zu prüfen und entsprechend zu reagieren, manchmal unter großem Zeitdruck. 

Steigern Sie die Sicherheit Ihrer Software-Lieferkette mit einer SBOM

Eine wichtige Vorgehensweise zur Sicherstellung der langfristigen Integrität Ihrer Software-Lieferkette ist die Aufrechterhaltung einer aktuellen Aktualisierung Software-Stückliste (SBOM). Die SBOM ist eine detaillierte Bestandsaufnahme der Softwarekomponenten, aus denen eine bestimmte Lösung besteht. 

Dadurch sparen Sie Zeit und Aufwand und – was am wichtigsten ist – reduzieren Sie Ihre Gefährdung durch anhaltende Bedrohungen. Jede in Ihr Produkt integrierte Softwarekomponente sollte über eine eigene SBOM verfügen, die validiert und zu einer einzigen „Master“-SBOM für das Produkt zusammengeführt werden muss. Wenn Sie beabsichtigen, Komponenten zu integrieren, die nicht mit einer SBOM geliefert werden, müssen Sie Ihre eigene Analyse mithilfe von SCA-Tools (Software Composition Analysis) durchführen.

Je genauer und beschreibender die SBOM ist, desto einfacher ist sie zu pflegen und zu referenzieren. Angesichts der schwindelerregenden Geschwindigkeit, mit der Softwarekomponenten aktualisiert werden, a gut strukturierte SBOM wird sich auszahlen, wenn es an der Zeit ist, jedes Update, jeden Patch oder jede Veröffentlichung aufzuspüren und aufzuzeichnen. Noch wichtiger: Sobald eine Sicherheitsbedrohung entdeckt wird, ist jeder Moment entscheidend. Merken: Das Sicherheit Ihrer Software-Lieferkette wird immer so stark sein wie Ihr schwächstes Glied. Wenn Dutzende Softwarekomponenten gefährdet sind, werden Sie für eine SBOM dankbar sein, die alle Antworten bereithält.

Für einen effizienten Arbeitsablauf sollte eine sinnvolle SBOM mindestens diese drei Komponenten umfassen:

  1. Datenfelder – Dies sind die Deskriptoren für die Komponenten, die Sie implementiert haben. Die Möglichkeit, auch lange nach Abschluss der Entwicklung leicht zu erkennen, welche Komponenten verwendet wurden, hilft dabei, diese effektiv auf Schwachstellen zu überwachen.  
  2. Automatisierungsunterstützung – Die automatische Überwachung der SBOM erfordert, dass diese auch in einem der akzeptierten maschinenlesbaren Formate identifiziert werden. 
  3. Praktiken und Versprechen – Die Verwaltung einer SBOM erfordert ein gemeinsames Verständnis der Wartungspraktiken, wie z. B. Häufigkeit von Versionen, Abhängigkeiten, bekannte Unbekannte, Verteilung und Zustellung, Zugriffskontrolle und die Behebung von Fehlern.

Die gemeinsame Nutzung der SBOM unter den Stakeholdern eines bestimmten Produkts (dem Softwareentwickler, dem Softwarelieferanten und dem Kunden) trägt zur Förderung von Transparenz und Ausrichtung bei und erhöht die Fähigkeit einer Softwarelieferkette, das Produkt vor Sicherheitsbedrohungen zu schützen. Es muss beachtet werden, dass angesichts aller beweglichen Teile in einer Software-Lieferkette die konsistente Pflege einer solchen SBOM – eine SBOM, die leicht referenziert, überwacht und gewartet werden kann – eine komplexe Herausforderung darstellt. 

Abschließende Worte: Wie können Sie die Sicherheit Ihrer Software-Lieferkette auf die nächste Stufe heben?

Da die Sicherheit der Software-Lieferkette immer wichtiger wird, stehen Unternehmen immer wieder vor der Herausforderung, transparentes Vertrauen in die Software aufzubauen, die sie liefern oder verwenden. Da erwartet wird, dass die Akzeptanz des SBOM als Best Practice zunehmen wird, ist ein Tool, mit dem Sie diese Herausforderung meistern können, ein wichtiger Schritt zur Etablierung der Software-Lieferkettensicherheit. Aus diesem Grund haben wir kürzlich den ersten evidenzbasierten Sicherheitshub für Softwareprodukte gestartet. Es ermöglicht seinen Benutzern, team- und organisationsübergreifend Vertrauen in ihre Software aufzubauen. Diese benutzerfreundliche Plattform wird Entwicklungsteams dabei helfen, Risiken in der Software-Lieferkette zu mindern, indem sie die SBOM zugänglich, benutzerfreundlich und vor allem – macht.Machen Sie die Sicherheit von Softwareprodukten für Kunden, Käufer und Sicherheitsteams transparent

Wenn Sie als Softwareentwickler über die Bedrohungen für die Sicherheit Ihrer Software-Lieferkette besorgt sind, raten wir Ihnen dringend, dies zu tun Probieren Sie die Plattform aus; Die Nutzung ist kostenlos und an keine Bedingungen geknüpft. Durch die Implementierung unseres Workflows können Sie Ihre SBOMs in Ihrer gesamten Lieferkette teilen.  

Banner

Diese Inhalte werden Ihnen von Scribe Security zur Verfügung gestellt, einem führenden Anbieter von End-to-End-Sicherheitslösungen für die Software-Lieferkette, der modernste Sicherheit für Code-Artefakte sowie Code-Entwicklungs- und Bereitstellungsprozesse in der gesamten Software-Lieferkette bietet. Weitere Informationen.