Woher kommen SBOMs? Als jemand, der ein paar Mal um den (sagen wir mal) Block herumgelaufen ist, habe ich mich oft mit etwas „Neuem“ konfrontiert gefühlt, das sehr nach etwas aussieht, das ich zuvor gesehen habe. Als direkte Antwort auf die Frage denke ich, dass US.gov keine Ahnung hatte, als das Weiße Haus eine Durchführungsverordnung zur Verbesserung der Cybersicherheit im Jahr 2021 herausgab. Hier, Abschnitt (4) (e) (vii): „Solche Richtlinien müssen Standards, Verfahren oder Kriterien enthalten … indem dem Käufer für jedes Produkt direkt oder durch Veröffentlichung auf a öffentliche Website.”
Der Beweggrund dieses speziellen Edikts, Cybersicherheit, ist klar genug, da es heutzutage sehr schwierig sein kann, genau zu sagen, was in einem Softwarepaket enthalten ist, mit Open-Source-Komponenten, öffentlich verfügbaren Bibliotheken, Website-Scripting-Paketen und mehr. Wenn Sie nicht sagen können, was drin ist, können Sie nicht sicher sagen, dass es sicher ist; und wenn es nicht passiert, werden Sie sich der Schwäche oder der Lösung nicht bewusst sein.
Aber mehr als das. Zu verstehen, was sich in Ihrer App befindet, kann wie ein Abstieg in die Minen von Moria sein: Ebene um Ebene von Tunneln und Verbindungen, Ratten von Daten, Abgründe, die in die Leere hinabsteigen, Löcher, die digitale Dämpfe in die Luft senden. Wenn Sie die Bedeutung hinter dem Begriff „Angriffsfläche“ verstehen wollen, müssen Sie sich nur an die Szene im Peter-Jackson-Film erinnern, in der die monströsen Schrecken aus den längst vergessenen Spalten auftauchen … Ja, die Chancen stehen gut, dass es Ihnen ähnlich geht , einst glorreiche, basierte Software . aber jetzt abgelehnte Architektur.
Es ist nur fair, dass die US-Regierung einen Index wie den SBOM vorschreibt. Tatsächlich könnte man berechtigterweise fragen, warum sie so lange gebraucht haben; oder warum haben andere Organisationen solche Anforderungen nicht an ihre Aufforderungen zur Einreichung von Vorschlägen gestellt? Denken Sie daran, dass ich weit davon entfernt bin, dieses Bedürfnis zynisch zu sehen, obwohl ich gesund bleibe, weil es in der Alltagssprache auftaucht, als ob es schon immer da gewesen wäre.
Gehen wir ein paar Schritte zurück. Ich erinnere mich, dass ich in den 1980er Jahren in der Softwareverteilung und Bibliotheksverwaltung tätig war. Wir hatten einige Vorteile gegenüber heute: Früher wurde die gesamte Software, zumindest oberhalb des Betriebssystems, von Hand erstellt, in Pascal, C und C++ geschrieben, kompiliert, gebaut und als eine Einheit ausgeliefert. Ach, diese dunklen Tage! Auch ein paar Jahre später, als ich Softwarepakete von einem Entwicklungszentrum in Berlin abholte, war die Lieferumfangliste ein fester Bestandteil der Lieferung.
Was sich geändert hat, ist einfach: Die Prozesse, die wir hatten (immer noch manuell), waren zu langsam, um mit dem Innovationstempo Schritt zu halten. In den späten 1990er Jahren, als der E-Commerce zu wachsen begann, wurden Best Practices aufgegeben: Im Zeitalter von GSD gab es keine Belohnung dafür, Dinge kaputt zu machen und es richtig zu machen. Das ist übrigens kein Kritikpunkt: Es funktioniert alles sehr gut nach Vorschrift, aber nicht, wenn Sie Buchhandlungen um sich herum schließen, weil es nicht im gleichen Tempo wie Innovatoren innoviert.
Bruch oder Bruch, in der Tat, aber die Folgen eines schnellen und lockeren Handelns liegen heute vor uns. Nebenbei erinnere ich mich, dass ich meine erste Ukulele bei Forsyths gekauft habe, einem 150 Jahre alten Musikgeschäft in Manchester. “Billiger ist nicht unbedingt schlechter”, sagte der Typ, der mir bei der Auswahl half. “Außerdem ist die Qualitätssicherung nicht gut, daher gibt es keine Garantie dafür, dass das, was Sie kaufen, gut gebaut ist.” In dieser Situation wurde die Qualitätssicherung auf die Spitze getrieben, was bedeutete, dass der Verkäufer und ich uns durch mehrere Instrumente arbeiten mussten, bevor wir einen mittleren Bereich mit vernünftigem Aufbau und Ton fanden.
Wie Ukulelen, Gebrauchtwagen und eben auch Software. Die Notwendigkeit eines Qualitätsmanagements ist nicht unbedingt erforderlich, da die Dinge nicht unbedingt schief gehen, wenn dies nicht der Fall ist. Ihre Abwesenheit erhöht jedoch das Risikoniveau bei der Softwarebereitstellung, dem Betrieb und tatsächlich dem Sicherheitsmanagement. Cybersicherheit ist ein Risiko, und der Versuch, eine Anwendung ohne SBOM zu sichern, birgt ein eigenes Risiko: Es ist, als würde man in ein Gebäude einbrechen, ohne einen Satz architektonischer Blaupausen.
Aber wie wir sehen können, geht die Notwendigkeit einer besseren Aufsicht über die Softwarebereitstellung (eine Aufsicht, die SBOM standardmäßig bieten würde) über die Cybersicherheit hinaus. Vor langer Zeit sprach ich mit Tracey Regan von DeployHub über Servicekataloge, die Verzeichnisse von Anwendungselementen sind und wo jedes einzelne verwendet wird. Das Gespräch stimmt ziemlich genau mit dem überein, was ich hier schreibe, nämlich dass, solange Software modular aufgebaut ist, es notwendig war, Module aufzulisten und diese Liste irgendwie zu verwalten. Diese Vorstellung einer “Stückliste” geht wahrscheinlich auf die Römer zurück, wenn nicht sogar früher.
Die Fähigkeit (die Bildung einer Anwendung zu erkennen) hat viele Verwendungen. Beispielsweise kann eine Anwendung bei Bedarf von Grund auf neu erstellt werden. In Best Practices für das Softwarekonfigurationsmanagement sollten Sie sagen: „Lassen Sie uns die Version der Anwendung erstellen, die wir letzten August eingeführt haben.“ In diesen softwaredefinierten Zeiten können Sie (virtualisierte) Hardware als Code dokumentieren und (um GitOps zu bringen) vergleichen, was derzeit läuft, mit dem, was Ihrer Meinung nach läuft, mit nicht verwalteten Konfigurationsoptimierungen.
Dies ist eindeutig keine bürokratische Notwendigkeit, alles in einem Register zu erfassen. Einfach ausgedrückt, und ähnlich wie bei den Theorien hinter der (Ledger-basierten) Blockchain, ermöglicht Ihnen die Aufzeichnung aller Daten, die Herkunft und Verantwortlichkeit sicherzustellen, Probleme besser zu diagnostizieren, Änderungen zu erkennen und vor allem ein auf Komplexität basierendes Schutzniveau zu schaffen. die Gefahr Ein Großteil der heutigen Technologiediskussion dreht sich um Sichtbarkeit: In Betriebskreisen sprechen wir beispielsweise über Beobachtbarkeit und AIOps; In Situationen mit Kundenkontakt geht es darum, eine kohärente Vision zu schaffen.
Wenn es jemals so war, dass wir dem nachgehen mussten, was wir geben, hat sich der Hauptunterschied von der Notwendigkeit der Geschwindigkeit (die in den letzten Jahrzehnten die Tagesordnung bestimmt hat) zu den Herausforderungen verlagert, mit den Folgen dieser Vorgehensweise umzugehen. Dinge schnell Während es in den frühen Tagen der Softwarebereitstellung Komplexität gab – der Artikel von Yourdon und Constantine aus dem Jahr 1975 über strukturiertes Design gab es, um sich damit zu befassen – ist die heutige Komplexität anders und erfordert eine andere Art von Reaktion.
Früher ging es darum, geschäftliche Anforderungen zu verstehen und zu erfüllen. Das Verständnis der Anforderungen war an sich schon eine Herausforderung, da Unternehmen versuchten, alle möglichen Funktionen in ihre proprietären Systeme einzubauen, wobei der Umfang unvermeidlich war. Mehr Diskussion war, wie man gibt; Im Allgemeinen vertrauten die Benutzer den Softwareteams nicht, was benötigt wurde, und alles ging langsamer als erwartet. Die Projekte waren abgeschlossen, für die Ewigkeit gebaut und stark wie Plumpudding.
Heute geht es um Betrieb, Management und Sicherheit. Der Bedarf an SBOMs war immer da; denn wissen zu müssen, was geliefert wird, und dann zurückgehen, wenn es falsch ist, bleibt gleich. Aber die Probleme, die durch Nichtwissen verursacht werden, sind um eine Größenordnung größer (oder mehr). Das entdecken Unternehmen, wenn sie sich von veralteten Ansätzen befreien und sich in das Cloud-native Unbekannte wagen.
In vielen der heutigen Gespräche geht es darum, mit den Problemen umzugehen, die wir geschaffen haben. Wir können über Shift-Left-Tests oder Security-by-Design sprechen, die jeweils früher im Prozess besser verstanden werden, indem man sich umsieht, bevor man springt. Wir sind von der Feldverfolgung zur erweiterten Lieferung übergegangen, weil alles geliefert wird, ob es Ihnen gefällt oder nicht. Der Trichter hat sich umgedreht, oder besser gesagt, er ist zu einem Feuerwehrschlauch geworden.
Anstatt uns selbst dazu zu verpflichten, Bedürfnisse auszublenden, müssen wir jetzt Ventile ausblenden. Aus diesem Grund sind SBOMs so wichtig, nicht weil jeder eine Liste mag, sondern weil unsere Fähigkeit, eine SBOM effektiv zu erstellen, ein so guter Test ist wie jeder andere, basierend auf dem Stand unserer Softwarebereitstellungspraktiken und dem daraus resultierenden Risikoniveau.
Lassen Sie uns also SBOMs erstellen. Lassen Sie uns auf diese Weise verstehen, wie tief das Kaninchenloch in Bezug auf unseren Software-Stack und die darin enthaltenen Schwachstellen ist, und dieses Verständnis als Hebel nutzen, um wichtige Entscheidungsträger davon zu überzeugen, dass sich die Situation ändern muss. Lassen Sie uns unsere Softwarearchitekturen bewerten, unsere Augen dafür öffnen, wie wir externe Bibliotheken, Open-Source-Module und Skriptsprachen verwenden. Lasst uns nichts Schlechtes sehen, außer unserer Unfähigkeit zu wissen, was wir haben und worauf wir bauen.
Jede Organisation, die gebeten wird, einen SBOM bereitzustellen, könnte dies als langweilige Ablenkung von der Erledigung von Aufgaben oder als taktische Art der Reaktion auf eine Anfrage ansehen. Aber diese Haltung einzunehmen, schafft eine verpasste Gelegenheit, zusammen mit einem Risiko: Ich kann keine genaue Zahl nennen, aber die Chancen stehen gut, dass der Aufwand, der erforderlich ist, um eine SBOM zu erstellen, nicht viel anders sein wird, als die Prozesse voranzutreiben, die sie ermöglichen. immer wieder neu erstellt, mit allen Zusatznutzen, die es mit sich bringt.
Das ist kein Plädoyer dafür, „wieder so zu werden, wie die Dinge waren“, sondern eine einfache Feststellung. Es gibt Softwarequalitätsprozesse, um die Effizienz zu steigern und das Risiko zu reduzieren, was beides mit Kosten verbunden ist. Richten Sie die Prozesse richtig ein, und SBOM wird zu einem Nebeneffekt. Wenn sie falsch liegen, wird das Unternehmen als Ganzes unter den Folgen leiden.