Angst und Abscheu vor DevSecOps

Wir hatten 2 Code-Analysatoren, 4 Tools für dynamische Tests, unser eigenes Handwerk und 250 Skripte. Nicht, dass dies alles im aktuellen Prozess notwendig gewesen wäre, aber seit ich mit der Implementierung von DevSecOps begonnen habe, müssen wir bis zum Ende gehen.



Quelle Charakterautoren: Justin Royland und Dan Harmon.

Was ist SecDevOps? Was ist mit DevSecOps? Was sind die Unterschiede? Anwendungssicherheit - worum geht es? Warum funktioniert der klassische Ansatz nicht mehr? Yury Shabalin von Swordfish Security kennt die Antwort auf all diese Fragen . Yuri wird alles im Detail beantworten und die Probleme beim Wechsel vom klassischen Anwendungssicherheitsmodell zum DevSecOps-Prozess analysieren: wie man die Integration des sicheren Entwicklungsprozesses in den DevOps-Prozess angeht und nichts unterbricht, wie man die Hauptphasen der Sicherheitstests durchläuft, welche Tools verwendet werden können, was Sie unterscheiden sich und wie man sie richtig konfiguriert, um Fallstricke zu vermeiden.


Über den Sprecher: Yuri Shabalin - Chief Security Architect bei Swordfish Security . Er ist verantwortlich für die Implementierung von SSDL und für die allgemeine Integration von Anwendungsanalyse-Tools in ein einziges Entwicklungs- und Test-Ökosystem. 7 Jahre Erfahrung in der Informationssicherheit. Er arbeitete bei Alfa Bank, Sberbank und Positive Technologies, die Software entwickeln und Dienstleistungen erbringen. Sprecher internationaler Konferenzen ZerONights, PHDays, RISSPA, OWASP.

Anwendungssicherheit: Worum geht es?

Anwendungssicherheit ist der Sicherheitsbereich, der für die Anwendungssicherheit verantwortlich ist. Dies gilt nicht für die Infrastruktur- oder Netzwerksicherheit, dh was wir schreiben und woran Entwickler arbeiten - dies sind die Fehler und Schwachstellen der Anwendung selbst.

Die Richtung von SDL oder SDLC - Security Development Lifecycle - wurde von Microsoft entwickelt. Das Diagramm zeigt das kanonische SDLC-Modell, dessen Hauptaufgabe die Beteiligung der Sicherheit in jeder Entwicklungsphase von den Anforderungen bis zur Freigabe und Freigabe in die Produktion ist. Microsoft erkannte, dass der Abschlussball zu viele Fehler enthielt, dass mehr davon vorhanden waren und dass etwas getan werden musste, und schlug diesen Ansatz vor, der kanonisch wurde.



Anwendungssicherheit und SSDL zielen nicht darauf ab, Schwachstellen zu erkennen, wie allgemein angenommen wird, sondern deren Auftreten zu verhindern. Im Laufe der Zeit wurde der kanonische Ansatz von Microsoft verbessert, weiterentwickelt und ein tieferes detailliertes Eintauchen in ihn gezeigt.



Canonical SDLC ist in verschiedenen Methoden sehr detailliert - OpenSAMM, BSIMM, OWASP. Die Methoden sind unterschiedlich, aber im Allgemeinen ähnlich.

Gebäudesicherheit im Reifegradmodell

Ich mag BSIMM am meisten - Building Security In Maturity Model . Die Grundlage der Methodik ist die Aufteilung des Anwendungssicherheitsprozesses in vier Bereiche: Governance, Intelligence, SSDL-Touchpoints und Bereitstellung. Jede Domäne verfügt über 12 Praktiken, die als 112 Aktivitäten dargestellt werden.



Jede der 112 Aktivitäten hat drei Reifegrade : Grundstufe, Mittelstufe und Fortgeschrittene. Alle 12 Praktiken können in Abschnitten studiert werden, wichtige Dinge für Sie auswählen, verstehen, wie sie implementiert werden, und schrittweise Elemente hinzufügen, z. B. statische und dynamische Code-Analyse oder Code-Überprüfung. Sie malen den Plan und arbeiten im Rahmen der Umsetzung der ausgewählten Aktivitäten ruhig daran.

Warum DevSecOps

DevOps ist ein allgemeiner großer Prozess, bei dem Sie sich um die Sicherheit kümmern müssen.

Zu Beginn umfasste DevOps Sicherheitsüberprüfungen. In der Praxis war die Anzahl der Sicherheitsteams viel geringer als jetzt und sie fungierten nicht als Teilnehmer am Prozess, sondern als Kontroll- und Aufsichtsbehörde, die Anforderungen an sie stellt und die Qualität des Produkts am Ende der Veröffentlichung überprüft. Dies ist ein klassischer Ansatz, bei dem Sicherheitsteams von der Entwicklung an hinter der Mauer standen und nicht in den Prozess involviert waren.



Das Hauptproblem besteht darin, dass die Informationssicherheit von der Entwicklung getrennt ist. Normalerweise ist dies eine Art IB-Schaltung, die 2-3 große und teure Werkzeuge enthält. Einmal alle sechs Monate kommt der Quellcode oder die Anwendung an, die überprüft werden muss, und einmal im Jahr werden Pentests erstellt. Dies alles führt dazu, dass die Fristen für die Teilnahme am Abschlussball verschoben werden und eine große Anzahl von Schwachstellen durch automatisierte Tools auf den Entwickler fallen. All dies kann nicht zerlegt und repariert werden, da die Ergebnisse der letzten sechs Monate nicht aussortiert wurden und hier eine neue Charge ist.

Im Verlauf unseres Unternehmens sehen wir, dass die Sicherheit in allen Bereichen und Branchen versteht, dass es Zeit ist, sich selbst zu ziehen und mit der Entwicklung in einem Rad zu drehen - in Agile . Das DevSecOps-Paradigma passt gut zur agilen Entwicklungsmethodik, zur Implementierung, zum Support und zur Teilnahme an jeder Version und Iteration.

Übergang zu DevSecOps

Das wichtigste Wort im Sicherheitsentwicklungszyklus ist „Prozess“. Sie müssen dies verstehen, bevor Sie über den Kauf von Werkzeugen nachdenken.

Es reicht nicht aus, nur Tools in den DevOps-Prozess einzubeziehen - die Interaktion und das Verständnis zwischen den Prozessbeteiligten sind wichtig.

Wichtiger als Menschen, keine Werkzeuge

Häufig beginnt die Planung eines sicheren Entwicklungsprozesses mit der Auswahl und dem Kauf eines Tools und endet mit Versuchen, das Tool in den aktuellen Prozess zu integrieren. Dies bleiben Versuche. Dies führt zu traurigen Konsequenzen, da alle Werkzeuge ihre eigenen Eigenschaften und Einschränkungen haben.

Ein häufiger Fall, in dem die Sicherheitsabteilung ein gutes, teures Tool mit großartigen Funktionen auswählte und zu den Entwicklern kam, um es in den Prozess einzubetten. Aber es funktioniert nicht - der Prozess ist so strukturiert, dass die Einschränkungen des bereits gekauften Tools nicht in das aktuelle Paradigma passen.

Beschreiben Sie zunächst, welches Ergebnis Sie möchten und wie der Prozess aussehen wird. Dies hilft, die Rollen des Werkzeugs und die Sicherheit im Prozess zu verstehen.

Beginnen Sie mit dem, was bereits verwendet wird

Sehen Sie sich vor dem Kauf teurer Werkzeuge an, was Sie bereits haben. Jedes Unternehmen hat Sicherheitsanforderungen für die Entwicklung, es gibt Kontrollen, Pentests - warum nicht all dies in eine verständliche und bequeme Form für alle verwandeln?

Typischerweise ist ein Papier-Talmud erforderlich, der in einem Regal liegt. Es gab einen Fall, in dem wir zum Unternehmen kamen, um die Prozesse zu sehen und nach den Sicherheitsanforderungen für die Software zu fragen. Der Spezialist, der dies tat, suchte lange:

- Irgendwo in den Notizen gab es einen Weg, wo dieses Dokument liegt.

Infolgedessen erhielten wir das Dokument eine Woche später.

Erstellen Sie für Anforderungen, Überprüfungen und andere Dinge eine Seite, z. B. zu Confluence - dies ist für alle praktisch.

Es ist einfacher, das bereits Vorhandene neu zu formatieren und damit zu beginnen.

Verwenden Sie Security Champions

In einem mittelständischen Unternehmen für 100 bis 200 Entwickler arbeitet normalerweise ein Sicherheitsbeauftragter, der mehrere Funktionen ausführt und physisch nicht die Zeit hat, alles zu überprüfen. Selbst wenn er sein Bestes versucht, wird er allein nicht den gesamten Code überprüfen, den die Entwicklung generiert. Für solche Fälle wurde ein Konzept entwickelt - Security Champions .

Security Champions ist eine Person im Entwicklungsteam, die an der Sicherheit Ihres Produkts interessiert ist.

Security Champion ist der Einstiegspunkt für das Entwicklungsteam und den Sicherheitsevangelisten in einem.

Wenn ein Safe zum Entwicklungsteam kommt und einen Fehler im Code anzeigt, erhält er normalerweise eine überraschte Antwort:

- Wer sind Sie? Ich sehe dich zum ersten Mal. Mir geht es gut - mein älterer Freund vom Code-Überprüfungssatz "Übernehmen", wir gehen noch weiter!

Dies ist eine typische Situation, da viel mehr Vertrauen in ältere oder nur Teamkollegen besteht, mit denen der Entwickler bei der Arbeit und bei der Codeüberprüfung ständig interagiert. Wenn der Sicherheitschampion anstelle des Sicherheitsbeamten den Fehler und die Konsequenzen anzeigt, hat sein Wort mehr Gewicht.

Außerdem kennen Entwickler ihren Code besser als jeder Sicherheitsanbieter. Für eine Person, die mindestens 5 Projekte in einem statischen Analysewerkzeug hat, ist es normalerweise schwierig, sich alle Nuancen zu merken. Sicherheitschampions kennen ihr Produkt: Was interagiert mit was und was ist überhaupt zu beachten - sie sind effektiver.

Denken Sie also daran, Security Champions zu implementieren und den Einfluss des Sicherheitsteams zu erweitern. Für den Champion selbst ist dies ebenfalls nützlich: berufliche Entwicklung in einem neuen Bereich, Erweiterung des technischen Horizonts, Verbesserung der technischen Fähigkeiten, Management- und Führungsqualitäten, Steigerung des Marktwerts. Dies ist ein Element des Social Engineering, Ihre „Augen“ im Entwicklungsteam.

Testschritte

Das 20 bis 80-Paradigma besagt, dass 20% des Aufwands 80% des Ergebnisses produzieren. Diese 20% sind Methoden zur Anwendungsanalyse, die automatisiert werden können und sollten. Beispiele für solche Aktivitäten sind statische Analyse - SAST , dynamische Analyse - DAST und Open Source-Steuerung . Ich werde Ihnen mehr über Aktivitäten sowie über Tools erzählen, auf welche Funktionen wir normalerweise stoßen, wenn sie in den Prozess eingeführt werden, und wie man sie richtig macht.

Die Hauptprobleme von Werkzeugen

Ich werde die Probleme hervorheben, die für alle Tools relevant sind, die Aufmerksamkeit erfordern. Ich werde sie genauer analysieren, um sie nicht weiter zu wiederholen.

Langzeitanalyse. Wenn es 30 Minuten dauert, bis alle Tests und die Montage vom Commit bis zum Produkt abgeschlossen sind, dauert die Überprüfung der Informationssicherheit einen Tag. So wird niemand den Prozess verlangsamen. Betrachten Sie diese Funktion und ziehen Sie Schlussfolgerungen.

Hoch Falsch Negativ oder Falsch Positiv. Alle Produkte sind unterschiedlich, jeder verwendet unterschiedliche Frameworks und seinen eigenen Schreibstil. Auf verschiedenen Codebasen und Technologien können Tools unterschiedliche Ebenen von False Negative und False Positive anzeigen. Sehen Sie daher genau, was in Ihrem Unternehmen und für Ihre Anwendungen ein gutes und zuverlässiges Ergebnis liefert.

Keine Integration in vorhandene Tools . Sehen Sie sich die Tools im Hinblick auf Integrationen an, damit Sie sie bereits verwenden. Wenn Sie beispielsweise über Jenkins oder TeamCity verfügen, überprüfen Sie die Integration von Tools in diese Software und nicht in GitLab CI, das Sie nicht verwenden.

Das Fehlen oder die übermäßige Komplexität der Anpassung. Wenn das Tool keine API hat, warum wird es dann benötigt? Alles, was in der Schnittstelle getan werden kann, sollte über die API zugänglich sein. Idealerweise sollte das Tool die Möglichkeit haben, Prüfungen anzupassen.

Keine Roadmap-Produktentwicklung. Die Entwicklung steht nicht still, wir verwenden immer neue Frameworks und Funktionen, schreiben alten Code in neue Sprachen um. Wir möchten sicher sein, dass das von uns gekaufte Tool neue Frameworks und Technologien unterstützt. Daher ist es wichtig zu wissen, dass das Produkt eine echte und ordnungsgemäße Entwicklungs- Roadmap hat .

Prozessfunktionen

Berücksichtigen Sie zusätzlich zu den Funktionen von Tools die Funktionen des Entwicklungsprozesses. Ein Eingriff in die Entwicklung ist beispielsweise ein typischer Fehler. Mal sehen, welche anderen Funktionen berücksichtigt werden sollten und worauf das Sicherheitsteam achten sollte.

Um die Entwicklungs- und Veröffentlichungsdaten nicht zu stören, erstellen Sie unterschiedliche Regeln und unterschiedliche Show-Stopper - Kriterien zum Stoppen des Erstellungsprozesses bei Vorhandensein von Sicherheitslücken - für verschiedene Umgebungen . Zum Beispiel verstehen wir, dass der aktuelle Zweig zum Entwicklungsstand oder zur UAT geht, also hören wir nicht auf und sagen nicht:

- Sie haben hier Schwachstellen, Sie werden nirgendwo weiter gehen!

An dieser Stelle ist es wichtig, den Entwicklern mitzuteilen, dass es Sicherheitsprobleme gibt, die es wert sind, beachtet zu werden.

Das Vorhandensein von Sicherheitslücken ist kein Hindernis für weitere Tests : manuell, integriert oder manuell. Auf der anderen Seite müssen wir die Sicherheit des Produkts irgendwie erhöhen, damit die Entwickler nicht vergessen, was sie für Sicherheit halten. Deshalb tun wir dies manchmal: Am Stand, wenn es auf die Entwicklungsumgebung übertragen wird, benachrichtigen wir einfach die Entwicklung:

- Leute, ihr habt Probleme, bitte beachtet sie.

In der UAT-Phase zeigen wir erneut Warnungen vor Sicherheitslücken und in der Exit-Phase des Abschlussballs sagen wir:

- Leute, wir haben mehrmals gewarnt, Sie haben nichts getan - wir werden Sie damit nicht rauslassen.

Wenn wir über Code und Dynamik sprechen, müssen nur die Funktionen und der Code, die gerade in dieser Funktion geschrieben wurden, angezeigt und vor Schwachstellen gewarnt werden. Wenn der Entwickler die Schaltfläche um 3 Pixel verschoben hat und wir ihm mitteilen, dass er dort eine SQL-Injection hat und daher dringend behoben werden muss, ist dies falsch. Schauen Sie sich nur an, was jetzt geschrieben steht und welche Änderungen an der Anwendung vorgenommen werden.

Angenommen, wir haben einen bestimmten Funktionsfehler - die Art und Weise, wie die Anwendung nicht funktionieren sollte: Geld wird nicht überwiesen, wenn Sie auf die Schaltfläche klicken, erfolgt kein Übergang zur nächsten Seite oder die Ware wird nicht geladen. Sicherheitsmängel sind die gleichen Mängel, jedoch nicht im Zusammenhang mit der Anwendung, sondern Sicherheit.

Nicht alle Probleme mit der Softwarequalität sind Sicherheitsprobleme. Alle Sicherheitsprobleme hängen jedoch mit der Softwarequalität zusammen. Sherif Mansour, Expedia.

Da es sich bei allen Schwachstellen um dieselben Fehler handelt, sollten sie sich an derselben Stelle befinden wie alle Entwicklungsfehler. Vergessen Sie also Berichte und beängstigende PDFs, die niemand liest.



Als ich für eine Entwicklungsfirma arbeitete, bekam ich einen Bericht von statischen Analysetools. Ich öffnete es, war entsetzt, kochte Kaffee, blätterte 350 Seiten durch, schloss es und arbeitete weiter. Große Berichte sind tote Berichte . Normalerweise gehen sie nirgendwo hin, Briefe werden gelöscht, vergessen, gehen verloren oder das Unternehmen sagt, dass es Risiken eingeht.

Was zu tun ist? Wir wandeln nur die bestätigten Mängel, die wir gefunden haben, in ein für die Entwicklung geeignetes Formular um, indem wir sie beispielsweise dem Rückstand in Jira hinzufügen. Wir priorisieren und beseitigen Fehler in der Reihenfolge ihrer Priorität sowie Funktionsfehler und Testfehler.

Statische Analyse - SAST

Dies ist eine Codeanalyse für Schwachstellen , die jedoch nicht mit SonarQube identisch ist. Wir prüfen nicht nur nach Mustern oder Stil. Bei der Analyse werden verschiedene Ansätze verwendet: im Schwachstellenbaum, in DataFlow , bei der Analyse von Konfigurationsdateien. Dies hängt alles direkt mit dem Code zusammen.

Vorteile des Ansatzes : Erkennen von Schwachstellen im Code in einem frühen Stadium der Entwicklung , wenn keine Stände und ein fertiges Tool vorhanden sind, und die Möglichkeit des inkrementellen Scannens : Scannen eines Codeabschnitts, der sich geändert hat, und nur der Funktion, die wir jetzt ausführen, wodurch die Scanzeit verkürzt wird.

Nachteile - dies ist der Mangel an Unterstützung für die erforderlichen Sprachen.

Die notwendigen Integrationen , die meiner subjektiven Meinung nach in den Tools enthalten sein sollten:

• Integrationstool: Jenkins, TeamCity und Gitlab CI.
  
• Entwicklungsumgebung: Intellij IDEA, Visual Studio. Für den Entwickler ist es bequemer, nicht in eine unverständliche Oberfläche zu gelangen, an die man sich noch erinnern muss, sondern direkt am Arbeitsplatz in seiner eigenen Entwicklungsumgebung, um alle erforderlichen Integrationen und Schwachstellen zu erkennen, die er gefunden hat.
  
• Codeüberprüfung: SonarQube und manuelle Überprüfung.
  
• Defekt-Tracker: Jira und Bugzilla.
  

Das Bild zeigt einige der besten Vertreter der statischen Analyse.



Es sind nicht die Tools, die wichtig sind, sondern der Prozess. Daher gibt es Open Source-Lösungen, die sich auch gut zum Ausführen des Prozesses eignen.



SAST Open Source findet keine große Anzahl von Schwachstellen oder komplexen DataFlow, aber Sie können und sollten diese beim Erstellen eines Prozesses verwenden. Sie helfen zu verstehen, wie der Prozess aufgebaut wird, wer auf Fehler reagiert, wer zu melden ist, wer zu melden ist. Verwenden Sie Open Source-Lösungen, wenn Sie die erste Phase des Aufbaus der Sicherheit Ihres Codes durchführen möchten.

Wie kann dies integriert werden, wenn Sie am Anfang der Straße stehen und nichts haben: weder CI noch Jenkins noch TeamCity? Betrachten Sie die Integration in den Prozess.

CVS-Integration

Wenn Sie über Bitbucket oder GitLab verfügen, können Sie die Integration auf der Ebene des Concurrent Versions-Systems durchführen .

Durch Ereignis - Pull-Anforderung, Festschreiben. Sie scannen den Code und zeigen im Build-Status an, dass die Sicherheitsprüfung bestanden wurde oder fehlgeschlagen ist.

Rückkopplung. Natürlich ist immer Feedback erforderlich. Wenn Sie nur auf der Sicherheitsseite aufgetreten sind, haben Sie es in eine Schachtel gelegt und niemandem davon erzählt und dann Ende des Monats eine Reihe von Fehlern beseitigt - das ist weder richtig noch gut.

Integration in die Codeüberprüfung

Einmal haben wir in einer Reihe wichtiger Projekte den Standardprüfer des technischen AppSec-Benutzers festgelegt. Abhängig davon, ob im neuen Code Fehler festgestellt wurden oder ob keine Fehler vorliegen, setzt der Prüfer den Status für die Pull-Anforderung auf "Akzeptieren" oder "Arbeit benötigen" - entweder ist alles in Ordnung, oder Sie müssen genau festlegen, was finalisiert werden soll, und Links erstellen. Für die Integration mit der Version, die zum Produkt gehört, wurde das Zusammenführungsverbot aktiviert, wenn der IB-Test nicht bestanden wurde. Wir haben dies in eine manuelle Codeüberprüfung aufgenommen, und andere Teilnehmer des Prozesses haben den Sicherheitsstatus für diesen bestimmten Prozess festgestellt.

SonarQube-Integration

Viele haben ein Qualitätsgatter für die Codequalität. Das Gleiche gilt hier - Sie können dieselben Gates nur für SAST-Tools erstellen. Es wird dieselbe Schnittstelle geben, dasselbe Gate, nur wird es als Sicherheitstor bezeichnet . Wenn Sie einen Prozess mit SonarQube haben, können Sie dort problemlos alles integrieren.

CI-Integration

Auch hier ist alles ganz einfach:

• Auf dem gleichen Niveau wie bei Autotests , Unit-Tests.
  
• Trennung nach Entwicklungsstadien : dev, test, prod. Es können verschiedene Regelsätze oder unterschiedliche Fehlerbedingungen enthalten sein: Beenden Sie die Assembly, stoppen Sie die Assembly nicht.
  
• Synchroner / asynchroner Start . Wir warten auf das Ende des Sicherheitstests oder warten nicht. Das heißt, wir haben sie gerade gestartet und gehen weiter, und dann erhalten wir den Status, dass alles gut oder schlecht ist.
  

Es ist alles in einer perfekten rosa Welt. Im wirklichen Leben ist dies nicht der Fall, aber wir bemühen uns. Das Ergebnis von Sicherheitsüberprüfungen sollte den Ergebnissen von Komponententests ähneln.

Zum Beispiel haben wir ein großes Projekt aufgenommen und beschlossen, es jetzt mit SAST'om - OK zu scannen. Wir haben dieses Projekt in SAST verschoben, es hat uns 20.000 Sicherheitslücken gegeben, und mit einer willensstarken Entscheidung haben wir akzeptiert, dass alles in Ordnung ist. 20.000 Schwachstellen sind unsere technische Pflicht. Wir werden die Schulden in eine Schachtel legen, und wir werden langsam Fehler in den Defekt-Trackern machen. Wir stellen ein Unternehmen ein, erledigen alles selbst oder Security Champions helfen uns - und unsere technischen Schulden werden sinken.

Alle neu auftretenden Schwachstellen im neuen Code sollten behoben werden, ebenso Fehler im Gerät oder in Autotests. Relativ gesehen begann die Montage, fuhr weg, zwei Tests und zwei Sicherheitstests fielen aus. OK - sie gingen, schauten, was passiert ist, korrigierten eine Sache, korrigierten die zweite, fuhren sie das nächste Mal raus - alles war in Ordnung, es gab keine neuen Schwachstellen, die Tests schlugen fehl. Wenn diese Aufgabe tiefer geht und Sie sie gut verstehen müssen oder das Beheben von Schwachstellen große Schichten dessen betrifft, was sich unter der Haube befindet: Sie haben einen Fehler in den Defekt-Tracker gebracht, wird dieser priorisiert und behoben. Leider ist die Welt nicht perfekt und Tests scheitern manchmal.

Ein Beispiel für ein Sicherheitstor ist ein Analogon eines Qualitätstors, gemessen am Vorhandensein und der Anzahl der Schwachstellen im Code.

Wir integrieren in SonarQube - das Plugin ist installiert, alles ist sehr bequem und cool.

Integration der Entwicklungsumgebung

Integrationsmöglichkeiten:

• Starten eines Scans aus der Entwicklungsumgebung vor dem Festschreiben.
  
• Ergebnisse anzeigen.
  
• Analyse der Ergebnisse.
  
• Synchronisation mit dem Server.
  

Es sieht so aus, als würde man Ergebnisse vom Server erhalten.



Intellij IDEA , , . , Flow Graph . , — - .

Open Source

. Open Source — , , ?



, , , , , , . Application Security — Open Source .

Open Source — OSA

.

. , , - , CVE - - , . , , , .

. , , , . , . , , . , , .

, . , . — , , . , , . Open Source , , -. , , . , . .

Fähigkeiten:

• .
  
• .
  
• .
  
• .
  
• Docker-.
  

, Open Source.


— Dependency-Check OWASP. , , . , on-premise, . , , , , .

, . . , Event Central Nexus, , «» «». Nexus Firewall Lifecycle , .

CI . , - : dev, test, prod. , , , - «critical» -, .

: Nexus JFrog.

. , , . , CVS.

CD. , — . .



Public Component Repositories — , . , trusted components. , . , , . , - , — .

• build' , , .
  
• trusted components.
  
• : war, jar, DL Docker- , .
  
• , : .
  

— DAST

, . . -, , , , : , , , , .

Open Source. DAST , Open Source , «» :

— , , .

, , — .

• \ .
  
• .
  
• .
  
• .
  
• .
  

, AppScan: , 3 — - ! , , AppScan — -, , , mailform -. :

— , ?! , !

. , -, . — , .

, . 10-15 , , , , .

, .



Burp Suite — « » . , . - enterprise edition. stand alone , - , . , .

: .

mock-, — , .

• — .
  
• .
  
• — .
  

, . — , , OpenSource, - , , Waf .

.

, , , , -.

. , , . , , . , .



API, , , , — AppSec , .

, security- , , , , , . , , — Confluence , Jira -, / CI/CD.

Key Takeaways

. — . , , . — «» , — - high mega super critical, , .

— , . , , . DevSecOps, SecDevOps, .

, : , , , , . — . — .

.

, . , — . - , . , .

— Security Champions .

, , , - — . Wählen Sie Werkzeuge basierend auf den Anforderungen Ihres Prozesses . Schauen Sie sich nicht an, was die Community sagt, dass dieses Tool schlecht und dieses gut ist. Vielleicht ist es genau das Gegenteil bei Ihrem Produkt.

Werkzeuganforderungen.

• Niedrig Falsch Positiv.
  
• Angemessene Analysezeit.
  
• Benutzerfreundlichkeit.
  
• Verfügbarkeit von Integrationen.
  
• Grundlegendes zur Entwicklung von Roadmap-Produkten.
  
• Die Möglichkeit, Werkzeuge anzupassen.
  

Yuris Bericht wurde auf der DevOpsConf 2018 als einer der besten ausgewählt. Um noch interessantere Ideen und praktische Fälle kennenzulernen , kommen Sie am 27. und 28. Mai auf der DevOpsConf im Rahmen des RIT ++ - Festivals nach Skolkovo . Besser noch, wenn Sie bereit sind, Ihre Erfahrungen zu teilen, beantragen Sie bis zum 21. April einen Bericht.