Get best of the week

(S) SDLC oder Wie man die Entwicklung sicherer macht. Teil 1

Bild

Jedes Jahr wächst die Entwicklungskultur, es erscheinen neue Tools zur Sicherstellung der Codequalität und neue Ideen zur Verwendung dieser Tools. Wir haben bereits über das statische Analysegerät geschrieben , darüber, auf welche Aspekte von Analysegeräten Sie achten müssen und schließlich, wie Sie aus organisatorischer Sicht einen auf statischer Analyse basierenden Prozess erstellen können .

Basierend auf den häufig auftretenden Problemen haben wir den gesamten Prozess der Einführung eines Codescanners in einen sicheren Entwicklungsprozess beschrieben. Heute werden wir darüber sprechen, wie Sie den für Sie geeigneten Analysator auswählen können.

Auf die eine oder andere Weise werden alle Entwickler mit statischen Analysen konfrontiert (Code-Analyse ohne Ausführung). Wenn der Compiler beispielsweise basierend auf den Ergebnissen der Assembly einige Fehler oder Warnungen generiert, sind dies die Ergebnisse der statischen Analyse. Wir verwenden oft Linters - dies ist auch eine statische Analyse, obwohl oft sehr einfach. Es gibt interessantere Beispiele - Spotbugs (früher Findbugs), mit denen Sie interessante Schwachstellen im Java-Bytecode finden können, oder den bekannten SonarQube - eine Plattform zur Überwachung der Codequalität.

Vollwertige SAST-Tools sind jedoch noch selten anzutreffen. Zunächst geht es um Tools, die komplexe Schwachstellen finden können. Wie sich in der Praxis herausstellt, können bekannte offene Tools diese Aufgabe nicht bewältigen, zumindest weil sie sich auf einen anderen Bereich konzentrieren (Fehler und einfache Schwachstellen). Ein gutes SAST-Tool implementiert eine interprozedurale Datenflussanalyse. Die Analyse sollte nicht am Programmtext erfolgen, sondern an der internen Präsentation - CFG, AST usw. Lesen Sie mehr dazu im vorherigen Artikel .

SAST


Hier ist ein Beispiel - die bekannte SQL-Injection. In diesem Beispiel fallen Daten des Benutzers aus der Abfrage in die abgeschlossene Funktion, werden an die injizierbare Query-Funktion übergeben, und bereits dort fallen sie in die SQL-Abfrage, wodurch die Anwendung für die SQL-Injektion anfällig wird.



Um eine solche Sicherheitsanfälligkeit zu finden, muss man verstehen, woher die „schlechten“ Daten stammen können, wie solche Daten validiert werden können und wo sie nicht verwendet werden können. Und was am wichtigsten ist: Sie müssen die Datenübertragung in der gesamten Anwendung überwachen. Dies ist eine Datenflussanalyse. Das Beispiel ist sehr einfach. In einer realen Anwendung können Daten viele Funktionen und Module, Zuweisungen und Synonyme durchlaufen.

Es ist klar, dass die Textsuche eine solche Sicherheitsanfälligkeit nicht findet. Eine intraprozedurale Analyse wird ebenfalls nicht gefunden, und in einigen offenen Tools wird nur diese implementiert. Um solche Schwachstellen zu finden (und dies ist normalerweise die kritischste Schwachstelle, dh das Hauptziel des SAST-Tools), benötigen wir gut entwickelte Algorithmen für die prozedurale Analyse des Datenflusses mit großen Regelbasen.

Aufgrund der algorithmischen Komplexität treten eine Reihe technischer Probleme auf, die die Implementierung des SAST-Tools von anderen statischen Analysatoren, beispielsweise SonarQube, unterscheiden. Wir werden diese Themen in einer Reihe von Artikeln diskutieren. Spoiler: Ressourcenverbrauch, Analysedauer, False Positives.

Es sollte beachtet werden, dass ein gutes Tool zusätzlich zu den Algorithmen die gesamte Mathematik in einer praktischen Schnittstellen-Shell zusammenfasst, sodass Sie SAST ohne ernsthafte Vorbereitung verwenden können. Solche Tools werden auch mithilfe von Plugins und APIs in das CI / CD eingebettet, wodurch die Suche nach Schwachstellen automatisiert und Sie sichere Entwicklungsprozesse erstellen können.



Im ersten Artikel haben wir versucht, die Hauptprobleme zu klassifizieren, die während des Studiums von SAST sowie nach der Entscheidung zur Implementierung des Tools auftreten. Wir werden hier über einige Probleme sprechen, andere werden in den folgenden Artikeln behandelt.

Lasst uns beginnen


Warum SAST, wenn Sie bereits kostenlose statische Analysegeräte haben?


Wir haben diese Frage im vorherigen Teil teilweise angesprochen. Natürlich mindern wir in keiner Weise die Vorzüge offener Werkzeuge. Jeder weiß, dass SonarQube ein großartiges Tool zur Automatisierung der Bewertung der Codequalität ist, mit einer großen Anzahl unterstützter Sprachen, Integrationen und Plugins. SonarQube eignet sich gut zum Einbetten in den Entwicklungsprozess, ist jedoch eher zum Zählen verschiedener Codemetriken und zum Suchen nach relativ einfachen Fehlern oder Schwachstellen gedacht. Es implementiert keine interprozedurale Analyse des Datenstroms und kann dementsprechend nicht zur Suche nach komplexen Schwachstellen verwendet werden. Normalerweise empfehlen wir die Verwendung von SonarQube und eines guten SAST-Tools (dies kann hier hilfreich sein, wenn das SAST-Tool in SonarQube integriert werden kann).

Es gibt andere gute offene statische Analysatoren. Sie können Spotbugs (Findbugs) für den JVM-Bytecode mit dem Plugin find-sec-bugs aufrufen, das eine In-Process-Analyse des Datenstroms mit einem kleinen Satz von Regeln implementiert. Es gibt einen bekannten Banditenanalysator für Python. Man kann nur den in clang eingebauten statischen Analysator erwähnen, der eine gute Analyse-Engine und eine gute Regelbasis hat.



Die Probleme solcher Tools bestehen darin, dass sie normalerweise sehr eng spezialisiert sind (z. B. für eine Sprache geeignet), einfache Algorithmen implementieren (dh keine komplexen Schwachstellen finden können) und viel kleinere Regelgrundlagen haben als kommerzielle Tools. Darüber hinaus verfügen sie über eine kleinere Reihe von Funktionen, sowohl für die Benutzeroberfläche als auch für die Integration. Nun, wir können den Mangel an Unterstützung erwähnen.

Auf der anderen Seite implementieren gute kommerzielle SAST-Tools (und es gibt auch schlechte) komplexe spezifische Algorithmen und verfügen über umfangreiche Regelbasen, die Tausende von Datensätzen enthalten können. Normalerweise unterstützen sie viele Programmiersprachen, verfügen über umfangreiche Schnittstellen- und Integrationsfunktionen (Plugins, APIs). Im Folgenden gebe ich ein Beispiel dafür, um welche Art von Integrationen es sich handelt.



Schauen Sie sich ein Beispiel für ein Integrationsschema an, das auf der Basis eines SAST-Tools erstellt werden kann. Im Allgemeinen unterscheidet sich das Schema nicht von der Einführung anderer Tools zur Codequalitätskontrolle. Entwickler schreiben Code und können sofort eine SAST-Prüfung durchführen. Der Code gelangt in das Repository und von dort aus gelangen verschiedene Trigger mit CI / CD in SAST. Scanergebnisse können entweder in der SAST-Oberfläche angezeigt werden oder in Tools landen, die den Entwicklungsprozess unterstützen (Bug-Tracker, E-Mail usw.).



Welches SAST-Tool soll ich wählen?


Ich werde mich ein wenig mit der Auswahl eines Werkzeugs befassen. Es gibt viele SAST-Tools, normalerweise werden mehrere Teile auf dem Markt angeboten (3-4). Es stellt sich die Frage, wie man das richtige Werkzeug auswählt und wonach man sucht. Hier werde ich nicht überraschen, ich werde mich auf drei Punkte konzentrieren: Funktionsvergleich, Qualitätsvergleich und Lizenzierung. Es ist wichtig, dass Sie das Testtool (Pilot) in Ihrem lokalen Schaltkreis verwenden und Ihren Code in Ihrer Infrastruktur überprüfen.

Es wäre schön, alle Funktionen der Benutzeroberfläche auszuprobieren, um zu verstehen, wie sie auf Ihren Fall anwendbar sind und wie bequem sie zu verwenden sind. Ich verweise auf einen der vorherigen Artikel . Hier sind einige nützliche Funktionen:

  • der am meisten automatisierte Start des Scannens (idealerweise können Sie ohne unnötige Einstellungen in zwei Schaltflächen einen Scan ausführen);
  • — , , ;
  • ;
  • ;
  • ;
  • (, );
  • ;
  • , “”;
  • “ , ”;
  • ;
  • .

Die Integrationsfunktionen sind sehr wichtig - mit CI / CD, Bugtrackern, Repositorys und Active Directory. Es wäre schön zu versuchen, eine einfache Aktion mithilfe der API zu automatisieren, falls vorhanden.

Um die Qualität zu überprüfen, müssen Sie Ihren Code scannen. Es ist gut, mehrere verschiedene Beispiele in verschiedenen Sprachen auszuwählen, damit die Stichprobe repräsentativ ist. Unter dem Gesichtspunkt der Qualität müssen Sie sich Fehlalarme (bei denen es eindeutig keine Sicherheitsanfälligkeit gibt, das Tool jedoch anzeigt) und Auslassungen ansehen (im Idealfall müssen Sie wissen, wo sich die Sicherheitsanfälligkeiten befinden, oder die in verschiedenen Tools gefundenen Sicherheitsanfälligkeiten vergleichen). Ich würde falsch positiven Ergebnissen etwas weniger Aufmerksamkeit schenken, da es normalerweise ausreicht, die Scanergebnisse einmal durchzugehen, falsche zu markieren, und dann werden sie Sie nicht stören.

Ich werde mich auf zwei wichtige Punkte konzentrieren. Zunächst ist es sehr wichtig, dies alles in der Anwendung auf Ihre Situation zu betrachten. Überprüfen Sie genau Ihren Code (SAST funktioniert möglicherweise bei verschiedenen Arten von Anwendungen unterschiedlich). Suchen Sie nach den Funktionen, die Sie benötigen, um das Tool in den Entwicklungsprozess einzubetten. Überprüfen Sie die Integration mit den vorhandenen Systemen.

Zweitens ist es während des Pilotprojekts sehr wichtig, mit dem Anbieter zu kommunizieren. SAST ist nicht die einfachste Sache, und oft reicht es aus, den üblichen Rat des Anbieters einzuholen, um die Leistungsfähigkeit des Tools voll zu nutzen.

Ab wann scannen Sie?


Je früher eine Sicherheitslücke gefunden wird, desto billiger ist sie. Es gibt abgedroschene Zeitpläne, die von Präsentation zu Präsentation wandern. Ich werde sie hier nicht einmal hinzufügen. Aber die Aussage ist ziemlich offensichtlich. Es ist eine Sache, die Sicherheitsanfälligkeit am Tag nach ihrer Herstellung zu beheben, eine andere Sache, eine Änderung am Kampfserver vorzunehmen, wenn dieser bereits gehackt wurde. Dementsprechend ist es notwendig, die Verwendung von SAST auf die frühen Entwicklungsstadien zu übertragen. Hier kann argumentiert werden, dass die Einführung von SAST in der Entwicklung an sich ein teures Ereignis ist und sich möglicherweise nicht auszahlt. Hier werde ich argumentieren: Normalerweise deckt das Auffinden mehrerer kritischer Schwachstellen die gesamte Implementierung ab (Sie können sogar eine Bewertung innerhalb des Piloten durchführen).

Mit diesem Ansatz erhalten wir auch einen Bonus: Wenn Entwickler „jeden Tag“ SAST-Ergebnisse sehen, erweitern sie ihre Kenntnisse über sichere Programmierung, sodass im Allgemeinen die Kultur der sicheren Entwicklung verbessert und der Code besser wird.

Wenn Sie SAST im Entwicklungsprozess implementieren, müssen Sie natürlich in CI / CD implementieren und DevSecOps erstellen. Der Trend, SAST von Kontrollprüfungen vor der Freigabe in den Entwicklungsprozess zu übertragen, ist seit langem sichtbar und hat in den letzten 2-3 Jahren unseren Markt eingeholt. Jetzt besteht kein Pilot mehr, ohne die Integrationsfähigkeiten zu testen.

Gleichzeitig würde ich Kontrollprüfungen vor der Veröffentlichung idealerweise für binäre Assemblys belassen (dies ist auch möglich). So können Sie sicherstellen, dass beim Zusammenstellen und Übertragen der Anwendung auf das Produkt keine neuen Schwachstellen hinzugefügt wurden.

Technische Probleme


Und dann werde ich Ihnen sofort 4 Fragen stellen.

  1. Verbinden Sie SAST als SonarQube. Was ist die Schwierigkeit?
  2. SAST funktioniert schon lange, wie konfiguriert man DevSecOps?
  3. SAST gibt falsch positive Ergebnisse aus. Wie konfiguriere ich Quality Gate?
  4. Und ohne Fehlalarme im Bericht, mehrere tausend Sicherheitslücken, was tun mit ihnen?

Dies sind die wichtigsten technischen Probleme, die bei der Implementierung von SAST auftreten. Sie entstehen aus folgenden Gründen.

  1. Aufgrund der exponentiellen Natur der Algorithmen kann SAST lange laufen und viele Ressourcen verbrauchen - viel mehr als ein Linter oder SonarQube.
  2. Aus dem gleichen Grund kann SAST viele Fehlalarme liefern - es ist unwahrscheinlich, dass Entwickler jeden Tag nach dem nächsten Scan eine Reihe von Stürzen analysieren möchten.
  3. Normalerweise wird SAST zum ersten Mal auf der Codebasis gestartet, und der erste Lauf kann viele Vorgänge anzeigen, insbesondere wenn viel Code vorhanden ist und die Datenbank nicht sehr neu ist.

Alle Probleme sind lösbar. Im nächsten Artikel der Reihe werden wir anhand eines konkreten Beispiels aus unserer Erfahrung untersuchen, wie SAST so implementiert werden kann, dass alle technischen Funktionen ausgeglichen werden und alle glücklich werden.

Organisatorische Angelegenheiten


Ich würde organisatorische Fragen nicht vergessen. In großen Unternehmen entstehen viele von ihnen aus dem Implementierungsprozess selbst, der Zuweisung von Ressourcen zur Erstellung von Vorschriften und der Replikation von Prozessen.

Organisatorische Probleme entstehen durch dieselben technischen Merkmale, die wir im vorherigen Absatz erörtert haben. Abgesehen davon sind die historisch begründete Trennung und Konfrontation zwischen Entwicklung und Sicherheit noch nicht verschwunden. Ich verweise auch auf unseren vorherigen Artikel.

Fortsetzung folgt


Implementieren Sie SAST - es ist notwendig, es ist normalerweise gerechtfertigt. Aber wenn Sie mit der Implementierung beginnen, wäre es schön, sich mit all den Fallstricken vertraut zu machen, die auf Ihrem Weg auftreten. In diesem Artikel haben wir begonnen, sie zu zerlegen. Wir werden im Folgenden mit technischen Aspekten fortfahren.

More articles:


All Articles