DevSecOps und Lieferkettensicherheit
Viele Unternehmen haben einen DevOps-Prozess etabliert, aber die Sicherheit liegt grundsätzlich außerhalb des Prozesses und wurde nicht in den traditionellen DevOps-Prozess integriert. Daher war Sicherheit schon immer der Engpass bei der agilen Bereitstellung. In diesem Artikel werden wir über Sicherheitsprobleme im F&E-Prozess aus der Perspektive von DvSecOps und der Sicherheit der Software-Lieferkette sprechen.
01 DevSecOps – der Eckpfeiler der Supply Chain Security Governance
Im Kontext vieler Unternehmen, die nach DevSecOps-Lösungen suchen, wird das Konzept der Verlagerung der Sicherheit nach links immer wichtiger. Im Weißbuch des US-Verteidigungsministeriums wurde auch erwähnt, dass der Kern der DevSecOps-Implementierung die Verschiebung der Sicherheit nach links ist. Die darin betonte Verschiebung der Sicherheit nach links besteht jedoch darin, Sicherheitstests in der Forschungs- und Entwicklungsphase durchzuführen. Eine solche Verschiebung nach links ist nicht gründlich . Es ist das SDLC-Konzept von Microsoft, das die Verschiebung der Sicherheit nach links wirklich gründlicher umsetzt und betont, dass Sicherheit in einer früheren Phase einbezogen werden sollte .
Nach kontinuierlicher Praxis in den letzten Jahren hat DevSecOps eine relativ tiefgreifende Sicherheitsverschiebung nach links erreicht: Es führt nicht nur Sicherheitstests in der Forschungs- und Entwicklungsphase durch, sondern berücksichtigt die Sicherheit in der Nachfragephase und greift sogar bei der Projektgenehmigung in die Sicherheit ein Phase.
Der Wert der Sicherheitsverschiebung nach links kann nicht ignoriert werden. Wir wissen, dass die Kosten für die Suche und Behebung von Problemen in verschiedenen Phasen geometrisch steigen. Wenn die Kosten für die Suche und Behebung eines Problems in der F&E-Phase „1“ betragen, betragen die Kosten für die Behebung des Problems in der Testphase „2“, die Kosten für die Behebung des Problems in der Release-Phase betragen „10“ und die Die Kosten für das Finden und Beheben des Problems in der laufenden Phase betragen „10“. Die Kosten betragen „100“ und die Auswirkungen auf den Geschäftsbetrieb sind sogar unkalkulierbar, da einige Sicherheitsprobleme die Lebensader eines Unternehmens sind.
02 Schwierigkeiten bei der Umsetzung der Supply Chain Security Governance
Die Governance der Lieferkettensicherheit ist dezentralisiert . Bei der Codierung, Kompilierung, Bereitstellung und anderen Verknüpfungen können häufig Probleme auftreten.
Die Kosten für Forschung, Entwicklung und Reparatur sind hoch, die Behebung von Sicherheitsproblemen hinkt hinterher und es kommt häufig zu Rückschritten .
Die Governance der Supply-Chain-Sicherheit basiert auf Multi-Tool-Funktionen . Für ein einzelnes Tool ist es schwierig, alle Governance-Objekte der Lieferkettensicherheit abzudecken. Nun wird erwähnt, dass die Supply-Chain-Governance-Tools im Wesentlichen SCA sind, das Betriebssystem und die Middleware jedoch allesamt Governance-Objekte sind, die bei der Bereitstellung berücksichtigt werden müssen Chain-Governance-Prozess.
Sicherheit besteht aus Silos, nicht aus Prozessen . Die Sicherheitstools werden unabhängig voneinander verwendet, und Sicherheitslücken bestehen nur in den Sicherheitstools, die nicht mit den F&E-, Test-, Sicherheits- sowie Betriebs- und Wartungsprozessen verbunden sind und nicht in den Prozess integriert sind, was zum Eingriff der Sicherheit führt arbeiten nur in Etappen und beeinflussen den Geburtsrhythmus und -zyklus.
Mangelnde Erfahrung in der Governance des gesamten Prozesses . Basierend auf der Theorie der Sicherheitsfässer hängt der Ausgleich von Sicherheitsmängeln und die Erzielung einer umfassenden Steuerung der Sicherheit der Lieferkette auch von der Sicherheitserfahrung ab
Es gibt kein Supply-Chain-Asset-Management . Dieses Stück ist hauptsächlich für die SBOM-Lösung gedacht. SBOM ist nur eine statische Software-Stückliste. Wenn ein 0-Tage-Sicherheitsproblem festgestellt wird, ist die Effizienz beim Scannen aller Code-Warehouses offensichtlich zu gering und ob die problematische Software nach dem Scannen schnell angezeigt werden kann ist ebenfalls ein Bedarf. Aus Sicht der Vermögensverwaltung und Obduktionsinspektionen zu berücksichtigen.
03 Lieferpipeline
Die CI/CD-Bereitstellungspipeline, also die Pipeline, und die aktuellen Sicherheitstools sind grundsätzlich in Form einer Orchestrierung mit der Pipeline verbunden. Da es viele Arten von Sicherheitstools gibt, ist es unmöglich, sich anzumelden, um für jedes einzelne einen Scanplan zu erstellen. Darüber hinaus haben viele Kernsysteme eine serviceorientierte Transformation realisiert. Der Arbeitsaufwand für die Erstellung von Erkennungsaufgaben für jede Dienstanwendung auf jedem Tool Es stellt eine große Belastung für das Sicherheitsteam dar. Es ist fast unmöglich, es abzuschließen, daher sind die aktuellen Sicherheitserkennungstools auf die Dimension der Orchestrierung gestiegen.
Es ist erwähnenswert, dass zwar mehrere Erkennungstools gleichzeitig zur Erkennung in der Pipeline gestartet werden können, die Pipeline jedoch in tatsächlichen Situationen nicht auf diese Weise organisiert ist. Wenn es sich um das Fließband der F&E-Testumgebung handelt, bleiben normalerweise alle Sicherheitsinspektionen zurück, da zu diesem Zeitpunkt die Anwendung schnell für die Bereitstellung erstellt und dann die Funktionen durch F&E und Tests überprüft werden müssen. Schauen Sie sich nach der Überprüfung der Funktion die vom Sicherheitserkennungstool erkannten Schwachstellen an, da das Sicherheitserkennungstool nach der Bereitstellung gleichzeitig mit der Erkennung beginnt und der Funktionstest und die Sicherheitserkennung fast gleichzeitig abgeschlossen werden können.
Wenn es sich um eine Online-Pipeline handelt, werden alle Sicherheitserkennungstools so früh wie möglich eingerichtet. Zu diesem Zeitpunkt müssen die Sicherheitserkennungstools in der Lage sein, in Sicherheit zu bleiben, dh in jedem Tool einen Sicherheitsschwellenwert festzulegen Definieren Sie beispielsweise für SCA-Tools: Es darf nicht mehr als eine kritische Komponente haben, andernfalls dürfen nachfolgende Pipelines nicht ausgeführt werden. Auf diese Weise kann der Qualitätskonsistenzgarantiekanal realisiert werden. Die sogenannte Qualitätskonsistenzgarantie bedeutet, dass die über das Fließband gelieferten Produkte unabhängig von der Art des geschäftlichen Forschungs- und Entwicklungshintergrunds jederzeit den Qualitätsanforderungen entsprechen. Dies kann eine Kultur bilden, das heißt, wenn Entwickler Code einreichen, denken sie darüber nach, ob sie den Sicherheitskontrollpunkt bestehen können, sodass die Denkweise über Sicherheitsprobleme geändert werden kann.
Darüber hinaus bestehen viele aktuelle Lösungen für Sicherheitstools darin, ein Skript in die Pipeline zu schreiben, den Code zum Scannen an das White-Box-Erkennungstool zu senden und dann die Erkennungsergebnisse abzurufen. Viele Microservice-Anwendungen reichen mittlerweile jedoch von Dutzenden bis zu Hunderten von Tausenden. Angesichts der Tausenden von Anwendungen wird der Code einmal täglich zum Testen an die Pipeline übermittelt und kann von keinem White-Box-Tool unterstützt werden. Wenn Sicherheitstools ans Fließband kommen, haben sich daher auch die technischen Anforderungen für eine normalisierte und automatisierte Ausführung von Sicherheitstools grundlegend geändert. Es geht nicht einfach darum, ein Skript in die Pipeline zu schreiben, um die Erkennungsschnittstelle des Erkennungstools aufzurufen und dann Daten abzurufen, sondern zu berücksichtigen, dass die Erkennungsfunktionen jedes Erkennungstools verteilt sind.
Daher kann es in der DevSecOps-Pipeline viele Stellen geben, die sich von den aktuellen Implementierungsideen des Unternehmens unterscheiden. Möglicherweise müssen wir bewerten, ob die aktuelle Pipeline die zukünftige Geschäftsentwicklung des Kernsystems unterstützen kann und ob die Effizienz des gesamten Systems gewährleistet ist Die Sicherheitsimplementierung erfüllt die Anforderungen . Unabhängig vom Zustand muss die Softwarequalität dem akzeptablen Risikobereich entsprechen.
Aufbau des DevSecOps-Sicherheitsfähigkeitssystems
DevSecOps hat zwei Entwicklungsrichtungen, eine ist One by One und die andere ist All in One.
One by one ist eine Lösung auf Basis von Jira, Jenkins und GitLab, die zu einem automatisierten Prozess kombiniert werden. All in one ist eine integrierte Plattform. Sie integriert Tools nicht einfach, sondern entwickelt sie auf der Plattform neu.
01 Integrierte DevSecOps-Plattform
DevSecOps ist ein Synonym für Effizienz. Viele Unternehmen befürworten es aufgrund der Komplexität der Supply Chain Governance. Neben der Supply Chain Governance müssen auch Cloud-native Sicherheit, Anwendungssicherheit, Datensicherheit und Compliance-Sicherheit berücksichtigt werden . Es ist schwieriger, diese Sicherheitsaufgaben gut zu erledigen. Im Jahr 2021 veröffentlichte die White-Hat-Organisation einen Sicherheitsforschungsbericht zu den Internetanwendungen des öffentlichen Sektors in den Vereinigten Staaten. Der Bericht zeigt, dass mehr als 60 % der Unternehmen in der Fertigungsindustrie ausnutzbare Schwachstellen aufweisen und der Zeitraum des Gefährdungsfensters beträgt mehr als 365 Tage. 40 % der Finanzbranche Die oben genannten Unternehmen haben solche Probleme . Es ist ersichtlich, dass die Sicherheitslage des inländischen Online-Betriebssystems nicht optimistisch ist. In diesem Fall wird eine integrierte Plattform ein unvermeidlicher Entwicklungstrend sein.
Laut den offiziellen Websites von GitLab und Jenkins heißt die Konfigurationsdatei von GitLab gitlab-ci.yml, was das Problem der kontinuierlichen Integration löst; die Konfigurationsdatei von Jenkins ist Jenkinsfile, eine Lösung für die kontinuierliche Bereitstellung. CI/CD-Pipelines im Ausland sind relativ streng und die Funktionen von CI und CD sind klarer, aber das einfache Hinzufügen von GitLab und Jenkins ist nicht gleichbedeutend mit CI/CD, daher muss sich bei der Durchführung von CI/CD ein integrierter Trend entwickeln .
Im Rahmen der integrierten Plattform kann eine große Menge an Data Mining durchgeführt werden. Die Anforderungen werden über die Mailingliste eingereicht, gelangen in das Nachfragezentrum, gehen in die Produktions- und Forschungsumgebung und dann in die Vorabversionsumgebung und gehen dann online. Das Datenobjekt der Anforderungen durchläuft viele Tools, und die Zeit, in der jedes Tool stagniert, wird durch die Arbeit verschiedener Rollen bestimmt. DevOps achtet auf eine effiziente End-to-End-Wertstrombereitstellung. Wenn jedoch Indikatoren wie der durchschnittliche Nachfragebereitstellungszyklus, die Nachfragestromauslastung sowie der Produktions- und Forschungszyklus nicht gezählt werden können, kann es nicht als echtes DevOps betrachtet werden. Es handelt sich lediglich um eine Automatisierung Prozess, der auch das Ziel vieler Unternehmen ist. Status quo. Daher wird integriertes DevOps auch der Entwicklungstrend der zukünftigen F&E-Effizienz sein.
02 DevSecOps-Sicherheitssystem
Das DevSecOps-Sicherheitsfähigkeitssystem dient der Abstraktion von Sicherheitsfähigkeiten für den gesamten Forschungs- und Betriebsprozess. Beispielsweise wird die Bedrohungsmodellierung in der Entwurfsphase durchgeführt, aber es gibt derzeit nicht viele Unternehmen, die eine Bedrohungsmodellierung durchführen, da die Implementierung stark von der umfangreichen Erfahrung der verantwortlichen Person abhängt. Zusätzlich zum Verständnis der Sicherheit müssen Sie auch verstehen Penetration, Angriff, Forschung und Entwicklung, Architektur, Unternehmen usw. können überlegen, wie diese Risiken gelöst werden können.
In der Lieferkette müssen viele Tests durchgeführt werden, und die meisten Methoden beziehen sich direkt auf Komponenten von Drittanbietern. Wir beziehen uns häufig auf Open-Source-Software in der Lieferkette, dh auf Open-Source-Komponenten oder Komponenten von Drittanbietern Komponenten, weil der Anwendungsbereich von Open-Source-Software zu groß ist. Beispielsweise besteht der Redis-Cache aus der Sicht von Komponenten von Drittanbietern darin, eine Redis-Aufrufkomponente in den Code einzuführen. Diese Komponente kann Probleme haben, aber die von Redis bereitgestellten Dienste können ebenfalls Probleme haben. Daher ist der Umfang von Open Source Software-Governance reicht von Komponenten bis hin zu Software. Aus zwei Perspektiven gibt es zwei verschiedene Dimensionen, die verwaltet werden müssen.
Die Redis-Umgebung erfordert grundsätzlich grundlegende Scans und sogar manuelle Sicherheitskonfigurationsprüfungen, daher sollte sich die Sicherheit nicht nur auf die Einführung von Tools und deren Verwendung konzentrieren, sondern auch darauf, welche Probleme dieses Tool lösen kann und wie es als nächstes implementiert wird Prozess wird Automatisierung etabliert.
Wenn Sie als Nächstes eine Supply-Chain-Sicherheits-Governance durchführen möchten, müssen Sie nur eine Ansicht erstellen und können dann unter allen Anwendungsressourcen Informationen zu Komponentenschwachstellen sowie Informationen zu jeder Bereitstellungsumgebung finden. Alle Erkennungsaufgaben oder Schwachstellenbehebungen können dabei nur abgeschlossen werden.
DevSecOps-Übungslandung
Übung 1: IDE-Sicherheitsselbsttest
Sobald der Prozess etabliert ist, muss sichergestellt werden, dass F&E über einen effizienten Prozess verfügt, der im Voraus wahrgenommen werden kann, da F&E davon ausgeht, dass der übermittelte Code den Sicherheitskontrollpunkt bestehen muss, da er sonst die KPI-Bewertung beeinträchtigt. Darüber hinaus ist es zeitaufwändig, den CI-Prozess auszulösen, nachdem der Code online übermittelt wurde. Wenn auf IDE-Ebene ein Erkennungs-Plug-in vorhanden ist, kann R&D schnell einen Selbsttest durchführen, wissen, welche problematischen Pakete Sie eingeführt haben, und diese hochladen Code nach der Änderung und Erkennung korrekt sind.
Übung 2: Erstellen Sie einen sicheren privaten Server
Wenn Sie einen privaten Server eines Drittanbieters verwenden oder keine Sicherheitskontrolle auf dem internen privaten Server durchführen, müssen Sie sich nach der Erstellung der Software auf zahlreiche Inspektionen verlassen. Wie bereits erwähnt, sind die Kosten für die Behebung von Schwachstellen, die in der Testphase gefunden werden, doppelt so hoch wie in der Forschungs- und Entwicklungsphase. Um zu vermeiden, dass noch mehr Kosten in die Forschungs- und Entwicklungsphase investiert werden, kann daher ein Sicherheitsaudit durchgeführt werden, wenn alle Drittanbieter Parteikomponenten betreten den privaten Server. Geben Sie den privaten Server ein. Tatsächlich ist dies auch eine Funktion des SCA-Tools. Es öffnet einen Netzwerk-Proxy. Wenn wir zum öffentlichen Komponentenlager gehen, um Komponenten herunterzuladen, werden die Komponenten vom Proxy überprüft. Nachdem die Prüfung bestanden wurde, werden sie abgelegt in das Lager; Es gibt verschiedene Verarbeitungsstrategien, z. B. das Ablegen in eine Cache-Warteschlange zur Auswertung oder das direkte Ablehnen. In der spezifischen Implementierung können Sie den externen privaten Server konfigurieren und dann dynamisch Speichererkennungs- und Konstruktionsaktionen durchführen.
Übung 3: Etablieren Sie einen konsistenten internen Qualitätszyklus
CI/CD ist ein zweistufiger Prozess, aber nicht viele Unternehmen können CD jetzt durchführen, da CD unterschiedliche Verständnisse hat, eines ist Continuous Delivery und das andere ist Continuous Deployment. Continuous Deployment ist ein technisches Verhalten, ähnlich wie CI, aber Continuous Delivery erfordert viele Fähigkeiten, um es zu unterstützen. Der CI-Link ist kein Prozess, da es in verschiedenen Links unterschiedliche Montagelinien für die Sicherheitsarbeit gibt. Die gesamte Sicherheitsarbeit hat eine normalisierte Automatisierung erreicht. Inkrementelle Schwachstellen werden nicht nur zur Behebung überkritischer Schwachstellen definiert, sondern auch Schwachstellen mit geringem Risiko müssen auch gemeinsam repariert werden. Dies ist ein relativ guter Zustand. Die Einrichtung des internen Qualitätszyklus wird sehr effizient sein und die Qualitätskontrolle der Softwaresicherheit wird effizienter sein.
Übung 4: Richten Sie einen Sicherheitsmanagement- und Kontrollmechanismus ein
Der Sicherheitsverwaltungs- und Kontrollmechanismus ist der oben erwähnte Stuckpoint des Sicherheitstools. Heutzutage verfügt fast kein Sicherheitstool über die Stuckpoint-Funktion. Im Allgemeinen schreiben Sie bei der Durchführung von Sicherheitskontrollpunkten selbst Skripte und beurteilen dann die aktuelle Situation der Sicherheitslückendaten. Die aktuellen Tools können so konfiguriert werden, dass unterschiedliche Schwellenwertanforderungen für feststeckende Punkte hinzugefügt werden. Anschließend können Sie eine Ausführungsstrategie auswählen, z. B. Beendigung oder Fortsetzung, und die entsprechende verantwortliche Person schnell benachrichtigen.