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是效率的代名词，之所以很多企业一直在提倡它，是因为供应链治理工作的复杂性，除了供应链治理以外，还要考虑云原生安全、应用安全、数据安全、合规安全等，企业要想做好这些安全工作比较困难。White Hat组织在2021年针对全美公共事业部的互联网应用发布了一份安全调研报告，报告显示制造业有60%以上的企业存在可利用漏洞，暴露窗口期在365天以上，金融行业有40%以上的企业存在此类问题。由此可见，国内的在线运营系统，其安全状况也不容乐观，在这种情况下一体化平台将是发展的必然趋势。
根据GitLab和Jenkins的官网介绍，GitLab的配置文件叫gitlab-ci.yml，是解决持续集成的问题；Jenkins的配置文件是Jenkinsfile，是持续部署的解决方案。国外的CI/CD流水线比较严谨，CI与CD的功能更加明确，但是简单的将GitLab与Jenkins相加并不等同于CI/CD，所以真正在做CI/CD时必然是向一体化的趋势发展。
在一体化的平台框架之下，可以进行大量的数据挖掘。需求从邮件列表提出来，进入到需求中心，到产研环境，再到预发环境，然后上线。需求这一数据对象流经很多工具，每一个工具停滞的时间都由不同角色的工作来决定。DevOps讲究高效的端到端价值流交付，但是像需求平均交付周期、需求流负载、产研周期等指标都统计不出来，就不能算真正的DevOps，只是一个自动化流程而已，这也是很多企业的现状。所以一体化的DevOps，也将是未来研发效能的发展趋势。
02 DevSecOps安全能力体系
DevSecOps安全能力体系，就是针对整个研运流程去做安全能力抽象。比如在设计阶段做威胁建模，但现在做威胁建模的企业并不多，因为它的落地非常依赖于负责人丰富的经验，除了要懂安全，还要懂渗透、攻击、研发、架构、业务等等，才能考虑怎样去解决这些风险。
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.