Zunächst allgemein über das Projekt. Wir haben einen sicheren Entwicklungsprozess in einem großen Handelsunternehmen aufgebaut, in dem die IT-Abteilung über ein großes Personal verfügt und in viele Bereiche unterteilt ist, die nur minimal miteinander korrelieren. Herkömmlicherweise können diese Bereiche in drei Hauptgruppen unterteilt werden. Die erste, eine sehr große Gruppe, ist Registrierkassensoftware, die hauptsächlich in Java geschrieben ist (90% der Projekte). Die zweite, hinsichtlich der Codemenge umfangreichste Systemgruppe sind SAP-Anwendungen. Und schließlich war der dritte Block ein "Durcheinander" von Portalen und mobilen Anwendungen: verschiedene externe Sites für die Kunden des Unternehmens, mobile Anwendungen für diese Sites sowie interne Ressourcen - mobile Anwendungen und Webportale für die Mitarbeiter des Einzelhändlers.
Der Kunde des Projekts - die Abteilung für Informationssicherheit - formulierte die allgemeine Aufgabe für alle drei Gruppen auf ziemlich übliche Weise: „Wir wollen weniger Schwachstellen und eine sichere Entwicklung aller im Unternehmen erstellten Systeme“. In der Praxis sah in jeder Abteilung alles ganz anders aus als bei anderen Kollegen, da wir bei jedem Schritt der Implementierung einer sicheren Entwicklung eine Million verschiedener Kompromisse eingehen mussten. Einige Nuancen halfen, den Prozess aufzubauen, während andere im Gegenteil störten. Am Ende ist es uns dennoch gelungen, für die meisten Projekte einen mehr oder weniger allgemeinen Ansatz zu entwickeln.
Wir haben diesen Ansatz so einfach wie möglich formuliert: Der für alle Entwickler relevanteste Code wird gescannt. Wenn wir in Bezug auf Gitflow sprechen und alle Projektgruppen mit Ausnahme von SAP Entwicklungszweige in Gitflow hatten, wird der Hauptentwicklungszweig nach einem Zeitplan gescannt.
Aber wie immer gibt es Ausnahmen von jeder Regel: Der allgemeine Ansatz kann aus einer Reihe von Gründen nicht überall so angewendet werden, wie er ist. Erstens weist unser Tool (Code Analyzer) einige Einschränkungen auf, da wir in der Lage sein möchten, bei Bedarf die gründlichste Analyse einiger Programmiersprachen durchzuführen. Im Fall von Java ist der Analyse-Bytecode also viel tiefer als der des Quellcodes. Dementsprechend erforderte das Scannen von Java-Projekten die vorläufige Zusammenstellung des Bytecodes und das erstmalige Senden zur Analyse. Bei C ++ -, Objective C- und iOS-Anwendungen wurde der Analysator bereits in der Erstellungsphase in den Prozess integriert. Wir mussten auch die verschiedenen individuellen Anforderungen der Entwickler aller Projekte berücksichtigen. Im Folgenden wird beschrieben, wie wir den Prozess für Portale und mobile Anwendungen erstellt haben.
Portale und mobile Anwendungen
Es scheint, dass alle diese Anwendungen in einer logischen Gruppe zusammengefasst sind, aber tatsächlich waren sie ein schreckliches Durcheinander. Es gab mehr als 120 Portale (!). Das Unternehmen ist sehr groß, mit vielen geschäftlichen, administrativen und technischen Abteilungen, und von Zeit zu Zeit entscheidet jeder von ihnen, dass er sein eigenes Portal und seine eigene mobile Anwendung benötigt. Dieses Portal und diese Anwendung werden erstellt, für einige Zeit verwendet und dann sicher aufgegeben. Infolgedessen mussten wir in der Anfangsphase eine Bestandsaufnahme für den Kunden durchführen, da selbst die Entwickler dieser Anwendungen keine einzige Liste von Codebasen hatten. Um beispielsweise die Repositorys in dieser Gruppe zu verwalten, verwendeten die Entwickler zwei GitLabs mit unterschiedlichen Administratoren. Darüber hinaus wurde bei Portalen und mobilen Anwendungen ein erheblicher Teil der Projekte mithilfe externer Entwicklung umgesetzt.Wenn sich die Veröffentlichungszeit näherte, übertrugen die Auftragnehmer die Quellcodes der neuen Version häufig fast auf einem USB-Stick an das Unternehmen. Infolgedessen hatte das Unternehmen einen Zoo mit verschiedenen Anwendungen und ein komplettes Durcheinander im Code. Wir mussten eine Liste aller Projekte erstellen, alle Verantwortlichen finden - technische Eigentümer, Teamleiter - und uns dann mit dem Hauptkunden - der Abteilung für Informationssicherheit - einverstanden erklären, welche von ihnen wir analysieren werden.
Aus diesem Grund haben wir Produktionssysteme und unterstützte Software für die Analyse ausgewählt und die Archivierungssysteme überhaupt nicht berührt. Eine Reihe interner Anwendungen wurde als unkritisch angesehen, da sie dem Unternehmen keinen finanziellen Schaden zufügen konnten und nicht für die Analyse ausgewählt wurden. Zum Beispiel ein Managementsystem für Packer innerhalb eines Lagers oder von Ladern. Es gibt nichts, was für externe Kunden des Unternehmens in ihnen anfällig ist, und das Hacken durch einen der internen Mitarbeiter führt nur zu geringfügigen internen Unannehmlichkeiten für eine Reihe von Abteilungen.
Der IS-Dienst hat die Einführung der Codeanalyse für Schwachstellen als vorrangige Aufgabe für diese Softwaregruppe und die Entwickler formuliert, um einen praktischen Verifizierungsprozess aufzubauen, der in die Entwicklungszyklen integriert ist.
Integration nach dem Standardschema
GitLab mit zwei verschiedenen Versionen wurde als Versionskontrollsystem in der Gruppe der Portale und mobilen Anwendungen verwendet.
Einrichten der Integration mit GitLab
Nicht alle Anwendungen verwendeten CI / CD, und wo dies nicht der Fall war, mussten wir darauf bestehen, es zu verwenden. Wenn Sie den Prozess der Überprüfung des Codes auf Schwachstellen wirklich automatisieren möchten (und nicht nur manuell einen Link zur Analyse hochladen möchten), damit das System ihn selbst in das Repository herunterlädt und die Ergebnisse an die erforderlichen Spezialisten weitergibt, können Sie nicht auf die Installation von Läufern verzichten. Läufer sind in diesem Fall Agenten, die sich automatisch an Versionskontrollsysteme wenden, den Quellcode herunterladen und zur Analyse an Solar appScreener senden.
Die Entwickler des Portals und der Gruppe für mobile Anwendungen wollten die sichere Entwicklung als halbautomatischen Prozess organisieren, damit der Code ohne deren Beteiligung auf Schwachstellen gescannt wurde. Damit der Sicherheitsbeauftragte die Ergebnisse der Analyse auf Schwachstellen überprüfen und den Entwicklern in Jira Aufgaben zuweisen kann, wenn er die Schwachstellen als kritisch erachtet, oder sie zur Klärung an die Entwickler sendet. Die Entwickler würden entscheiden, ob sie die Sicherheitsanfälligkeit dringend beheben müssen oder nicht. Und falls erforderlich, würden wir planen, in welcher Version sie die Korrekturen enthalten können.
Jira wurde hauptsächlich als Bug-Tracker verwendet, in den der Code-Analysator automatisch Informationen zu den gefundenen Sicherheitslücken lieferte.
Jira-Integrationssetup
In seltenen Fällen haben sich die Teamleiter die Crawlergebnisse selbst angesehen und die Aufgaben in Jira manuell gestartet.
Erstellen einer Aufgabe in Jira
Wir haben solche Fälle auch als separate Funktion in den Vorschriften registriert. In einigen Projekten wurden im Allgemeinen alle Korrekturen in Slack oder Telegram besprochen und Aufgaben in Echtzeit festgelegt.
Infolgedessen sah der Prozess der sicheren Entwicklung nach der Implementierung von Solar appScreener folgendermaßen aus: Die Portale werden täglich auf Änderungen im Code des Hauptentwicklungszweigs überprüft. Wenn der wichtigste Zweig nicht innerhalb von 24 Stunden aktualisiert wurde, geschieht nichts. Wenn es aktualisiert wurde, wird dieser Zweig zur Analyse an das entsprechende Projekt für dieses Repository gesendet. Das Repository in GitLab entsprach einem bestimmten Projekt im Code Analyzer, und in diesem Projekt wurde der Hauptzweig gescannt. Danach überprüfte der Sicherheitsbeauftragte die Analyseergebnisse, verifizierte sie und startete Aufgaben für Korrekturen in Jira.
In Jira erstellte Analyseergebnisse und Aufgaben zur Behebung von Sicherheitslücken
Wir haben begonnen, Schwachstellen in der Regel von kritischen zu beheben, die dringend beseitigt werden mussten. Nach dem Ende dieser Sicherheitsanfälligkeiten hat das Team neue Fehler im Code behoben. Und bereits in der dritten Phase, zum Beispiel im Rahmen der Schließung einiger technischer Schulden, wurden auch die alten verbleibenden Schwachstellen beseitigt.
Nicht standardmäßig
Dieser auf den ersten Blick nicht so komplizierte Prozess hatte zwei schwerwiegende Einschränkungen. Um Android-Anwendungen (d. H. In Java geschrieben) zu analysieren, benötigten wir zunächst eine Assembly. Und zweitens benötigte iOS MacOS-Maschinen, auf denen unser Agent installiert sein würde, und es würde eine Umgebung geben, in der wir Anwendungen erstellen könnten. Wir haben uns ganz einfach mit Android-Anwendungen befasst: Wir haben unsere Teile in die Skripte geschrieben, die den Entwicklern bereits zur Verfügung standen und die ebenfalls planmäßig gestartet wurden. Unsere Teile der Skripte haben den Build des Projekts in der breitesten Konfiguration vorab gestartet, der zur Analyse an Solar appScreener gesendet wurde. Um iOS-Anwendungen zu überprüfen, haben wir unseren MacOS-Agenten auf einem Mac-Computer installiert, der den Code zusammengestellt und den Code zum Scannen über GitLab CI an den Analysator gesendet hat. Ferner, wie im Fall bei anderen Arten von Software,Der Sicherheitsbeauftragte überprüfte die Analyseergebnisse, verifizierte sie und übermittelte Jira Fehlerbehebungen.
Wir haben Portale und mobile Anwendungen auch als in Java geschriebene Projekte bezeichnet - wir haben sie auf ähnliche Weise gesammelt und analysiert.
In Projekten, in denen es kein CI / CD gab, was für uns eine Voraussetzung war, sagten wir einfach: „Leute, wenn Sie analysieren möchten, sammeln Sie es manuell und laden Sie es selbst in den Scanner. Wenn Sie keine Java- oder JVM-ähnlichen Sprachen haben - Scala, Kotlin und andere -, können Sie den Code einfach über den Link in das Repository hochladen, und alles wird gut. "
Komplexität des Projekts
Wie Sie oben sehen können, war das Hauptproblem in diesem Anwendungsstapel das Fehlen von CI / CD in vielen Projekten. Entwickler haben oft von Hand gebaut. Wir haben begonnen, unseren Analysator in Sharepoint-Portale in C # zu integrieren. Jetzt hat C # mehr oder weniger auf Linux-Systeme umgestellt, obwohl es nicht ganz vollwertig ist. Und als das Projekt in vollem Gange war, funktionierte diese Sprache noch unter Windows, und wir mussten einen Agenten unter Windows für GitLab installieren. Dies war eine echte Herausforderung, da unsere Spezialisten an die Verwendung von Linux-Befehlen gewöhnt sind. Es waren spezielle Lösungen erforderlich, zum Beispiel war es in einigen Fällen erforderlich, den vollständigen Pfad zur exe-Datei anzugeben, in einigen Fällen musste etwas maskiert werden usw. Und nach der Implementierung der Integration mit Sharepoint sagte das Team des Projekts für mobile Anwendungen in PHP:dass sie auch keinen Läufer haben und C # -ovskiy verwenden möchten. Ich musste die Operationen für sie wiederholen.
Zusammenfassung
Trotz eines solch heterogenen Parks von Technologien, Teams und Prozessen ist es uns gelungen, die Hauptfälle dieses Falls in mehrere Pipelines zu gruppieren, ihre Ausführung gegebenenfalls zu automatisieren und sie zu implementieren. In unserem Beispiel konnten wir Folgendes sicherstellen:
- Die von uns implementierte Lösung ist alt genug, um flexibel genug zu sein, um DevSecOps-Prozesse in radikal unterschiedlichen Bereitstellungsumgebungen zu erstellen. Flexibilität wird durch eine Vielzahl integrierter und benutzerdefinierter Integrationen erreicht, ohne die sich die Arbeitskosten für die Implementierung erheblich erhöhen oder unmöglich machen würden.
- . 3-4 ;
- DevSecOps DevOps , , . win-win - .
Rückruf: Dies ist der erste Teil einer Reihe von Artikeln zum Aufbau eines sicheren Entwicklungsprozesses in einem großen Einzelhändler. Im nächsten Beitrag werden wir die Details der Implementierung dieses Projekts in der Anwendungsgruppe der SAP-Familie offenlegen.
Haben Sie eigene Erfahrungen mit der Umsetzung ähnlicher Projekte gemacht? Wir freuen uns, wenn Sie uns Ihre Fälle der Implementierung sicherer Entwicklungspraktiken in den Kommentaren mitteilen!
Autor: Ivan Staroselsky, Leiter der Abteilung Betrieb und Automatisierung von Informationssystemen