Connect(); 2016

Band 31, Nummer 12

Dieser Artikel wurde maschinell übersetzt.

ALM und DevOps: Schutz und Übermittlung mit Rugged DevOps

Durch Jean-Marc Prieur, Sam Guckenheimer; 2016

Sicherheit kann ein schwieriges Thema sein. Gemäß der Microsoft Security Intelligence Report (bit.ly/2drid6a), letztes Jahr 17,9 Prozent Computern Sicherheitsrisiken gefunden. Und die Dringlichkeit geschützt ist größer als je zuvor. Manipulieren ist fast immer Tage oder weniger, wenn nicht Minuten oder weniger, sucht Verizon in "Report seine 2016 Daten verletzen Untersuchungen" (vz.to/2dnpNk8).

Es ist häufig erkannten Konflikten zwischen DevOps-Methoden, die Geschwindigkeit ab, und Sicherheitsmethoden, die Gründlichkeit hervorzuheben. Der Konflikt muss nicht vorhanden. In der Tat wurde eine Anzahl von Anbietern arbeiten um DevOps-Pipelines sicherer zu machen. Und dies ist Teil einer Verschiebung in Richtung robust DevOps. Dieser Artikel beschreibt vier Erweiterungen neu mit dem Visual Studio Team Services (VSTS) Marketplace verfügbar.

Beginnen wir mit einer Übersicht über eine robuste DevOps-Pipeline (finden Sie unter Abbildung 1).

Die robuste DevOps-Workflow
Abbildung 1: die robuste DevOps-Workflow

Das Ziel einer robusten DevOps-Pipeline werden Entwicklungsteams schnell ohne wichtige Dinge durch die Einführung von unerwünschter Sicherheitsrisiken wechseln können. Fallstudien implementieren robust DevOps Teams finden Sie in Kapitel 22 "Der DevOps Handbook" (IT Revolution Press 2016) von Gene Kim, Jez Humble, Patrick Debois und John Willis (bit.ly/2dUXJW3).

Paketverwaltung

Genau wie ein Team Versionskontrolle als die einzige Informationsquelle für den aktuellen Quellcode verwendet wird, können sie in einem Paketmanager als eindeutige Quelle Binärkomponenten verlassen. Mithilfe von binären Pakets Management ein Entwicklungsteam nicht nur einen lokalen Cache genehmigten Komponenten erstellen, aber auch einen vertrauenswürdigen Feed für die fortlaufende Integration (CI) Pipeline machen. Management-Paket – jetzt in VSTS und Herkunft zu Team Foundation Server (TFS) – ist ein integraler Bestandteil der Komponenten-Workflow. Die Paket-Erweiterung aus dem Visual Studio-Marketplace verfügbar ist (bit.ly/1VLXIzG).

Die Rolle des OSS-Komponenten

Heute sind die Entwickler viel produktiver als je zuvor, aufgrund der breiten Verfügbarkeit von wieder verwendbaren open-Source-Software (OSS)-Komponenten. Es gibt jetzt eine praktische Anleitung für die Wiederverwendung mit Laufzeiten, die unter Windows und Linux wie .NET Core und Node.js verfügbar. Gleichzeitig enthält die Produktivität der Wiederverwendung von OSS das Risiko, dass wiederverwendeten Abhängigkeiten Sicherheitsrisiken bringen. Z. B. Ansprüche thesnyk.io Dienst 76 Prozent der Benutzer von Sicherheitsrisiken in ihrer Anwendung aufgrund der Versionen von Node.js-Pakete finden, die sie belegen. 

In der Welt von OSS, besteht ein neues Konzept, bezeichnet Software Komposition Analysis (SCA), die in dargestellt wird Abbildung 2. Dies beinhaltet Szenarien wie folgt:

Als Entwickler oder Entwicklungsleiter, beim Verarbeiten einer OSS-Komponente, erstellen Sie eine Abhängigkeit oder Abhängigkeiten nutzen, möchte: Start mit der richtigen neueste Version verwenden, um alle alten Sicherheitsrisiken zu vermeiden oder Missbrauch;-Lizenz Überprüfen Sie, dass sie tatsächlich die richtigen Binärdateien für diese Version sind; Überprüfen Sie in der versionspipeline Binärdateien, um sicherzustellen, dass sie korrekt sind und eine nachweisbare Stückliste zu halten; im Falle einer Sicherheitslücke sofort benachrichtigt werden und in der Lage, zu korrigieren und erneut bereitstellen, um zu verhindern, dass Sicherheitslücke oder Lizenz Missbrauch von wiederverwendete Software automatisch.

Open-Source-Abhängigkeiten erstellen sicheren
Abbildung 2: Erstellen problemlos öffnen Source Abhängigkeiten

Zwei Anbietern, die jetzt für die Verwaltung von OSS mit VSTS und TFS Dienstleistungen sind WhiteSource und Veracode. Beide haben Erweiterungen zur Verfügung stehen, auf dem Visual Studio-Markt. 

Projektmappen-Dienstprogramme: WhiteSource-Erweiterung für VSTS und TFS

Die Erweiterung WhiteSource Adressen für ein Team, externe Pakete nutzen speziell die Fragen der Sicherheit, Qualität und Lizenz open-Source-Kompatibilität. In einer Welt, in denen meisten Verstöße gegen Schwachstellen in bekannten Komponenten abzielen, ist dies wichtig Hygiene für die Nutzung von open-Source. Erläutert einige seiner Funktionen.

Fortlaufend erkennt alle öffnen Quellkomponenten in Ihre Software der WhiteSource-Erweiterung (bit.ly/2dEMCC0) erkennt automatisch alle open-Source-Komponenten – einschließlich kompilierbar transitiv – jedes Mal, wenn Sie einen Build ausführen. Dies bedeutet, Sie können einen umfassenden Bericht generieren, innerhalb von wenigen Minuten basierend auf dem letzten Build ausführen (siehe Abbildung 3). Darüber hinaus haben die Sicherheit, DevOps und rechtlichen Teams Einsicht in Ihrer Organisation Softwareentwicklungsprozess.

WhiteSource Komponente Inventur
Abbildung 3 WhiteSource Komponente Inventur

Warnungen auf Open Source-Sicherheitsrisiken und deren behebt wenn eine neue Sicherheitslücke entdeckt wird, WhiteSource automatisch generiert eine Warnung, und bietet gezielte Abhilfemaßnahmen (finden Sie unter Abbildung 4). Dies kann Links zu Patches, Updates, entsprechenden Quelldateien und sogar Empfohlene Systemkonfiguration, um eventuellen Ausnutzung vorzubeugen ändern kann. 

WhiteSource-Erkennung von Sicherheitslücken Komponenten
Abbildung 4 WhiteSource Erkennung von Sicherheitslücken Komponenten

Automatisch erzwingt öffnen Quelle Sicherheits- und Lizenz-Compliance-Richtlinien laut den Richtlinien des Unternehmens WhiteSource automatisch eine genehmigt, abgelehnt aus oder löst einen Prozess für die manuelle Genehmigung jedes Mal, wenn ein Build eine neue open-Source-Komponente hinzugefügt wird. Entwickler können Richtlinien basierend auf Parametern wie Sicherheitsrisiko Schweregrad einrichten, Typ oder Bibliothek Alter Lizenz. Sobald ein Entwickler versucht, eine problematische open-Source-Komponente hinzufügen, wird der Dienst eine Benachrichtigung senden und den Build fehlschlagen.

Zum Suchen von online-Repositorys, z. B. GitHub und Maven Central, bietet WhiteSource auch eine innovative Browsererweiterung. Ein Entwickler kann sogar, bevor Sie eine neue Komponente auswählen, sehen, die Sicherheitsrisiken, die Qualität und den Problemen, und gibt an, ob es sich um eine Unternehmensrichtlinie einfügt.

Projektmappen-Dienstprogramme: Erweiterung für VSTS: Die statische Codeanalyse (SCA) verstärken

HPE Sicherheit verstärken SCA bietet statischen Analyse für die Sicherheit der Anwendung durch VSTS und TFS testen (bit.ly/2dEWEOW). Dies macht Software nahtlos in die Codierung Prozess befähigen Entwickler Sicherheitsrisiken finden Sie weiter oben in der DevOps-Lebenszyklus.

Verstärken Sie SCA bietet einen umfassenden Satz von Software Security Analyzer, die für Verstöße gegen sicherheitsspezifische Codierungsregeln und Richtlinien zu suchen. Entwicklungsgruppen und Sicherheitsexperten Anwendungsquellcode für Sicherheitsprobleme analysieren verwenden (siehe Abbildung 5). Verstärken Sie SCA identifiziert die Ursachen von Software-Sicherheitsrisiken und präzise, Risiko-Rank Ergebnisse mit Line-of-Code Abhilfemaßnahmen bietet.

Visual Studio Team Services Buildaufgaben HPE Sicherheit verstärken SCA
Abbildung 5 Visual Studio Team Services Buildaufgaben HPE Sicherheit verstärken SCA

Rüsten Sie auf Anforderung bietet auch Anwendung Security as a Service (SaaS). Verstärken Sie bei Bedarf Absenden der Tasks automatisch statische und dynamische überprüfungsanforderungen an die Anwendung SaaS-Plattform (siehe Abbildung 6). Für statische Bewertungen wird das Projekt auf Fortify bei Bedarf geladen. Für dynamische Bewertungen verwendet Fortify auf Anforderung die URL der Anwendung vorkonfiguriert.

HPE Sicherheit verstärken bedarfsgesteuerte Erkennung von Sicherheitsrisiken
Abbildung 6 HPE Sicherheit verstärken bedarfsgesteuerte Erkennung von Sicherheitsrisiken

Geschwindigkeit und Tiefe

In der Vergangenheit war das Security-Überprüfung in der Regel eine "Over-the-Wand"-Aktivität, z. B. nur einmal pro Version durchgeführt. Dies erstellt eine durchdachte Muster in der Spezialisten große Batches von Probleme genau die Zeit finden Sie unter Wenn Entwickler, unter dem größten Druck sind zu ignorieren und freizugeben. Robuste DevOps ist bestrebt, die alle Qualität Aktivitäten, einschließlich Sicherheit – kontinuierlicher und automatisierter.

Alle hier beschriebenen Erweiterungen kann das Team Quellcode vollständig scannen. Es gibt mehrere Punkte Scannen in der Team-Workflow integrieren.

Pull-Anforderungen (PRs) werden DevOps Übermitteln von Änderungen teams. Vor der PR muss ein Entwickler in der Lage, finden Sie unter die Auswirkung von Änderungen am Code und gewinnen sie ordnungsgemäß zusammenzuführen und keine neue Problemen eingeführt werden. In einem Prozess DevOps jeder Kurs ist in der Regel kleine und Zusammenführungen sind kontinuierlicher, sodass die hauptverzweigung Code neue bleiben kann. Im Idealfall kann Entwickler auf Sicherheitsprobleme vor der Pr. Überprüfen WhiteSource erleichtert dies zum Überprüfen von Abhängigkeiten mit den binären Fingerabdruck; Wie etwa Checkmarx bietet eine inkrementelle Suche geändert. und Veracode wurde das Konzept einer Developer-Sandbox. Diese Ansätze können Entwickler mit Änderungen experimentieren, vor dem einreichen.

Auf ähnliche Weise muss CI Geschwindigkeit Development Team unmittelbar Feedback von Buildunterbrechungen geben optimiert werden. Ebenso wie in den Datenfluss PR bei schnell genug, die Überprüfung ist kann und integriert die CI-Builddefinition. Einem Überprüfungsfehler im Build verursachen kann, und Sicherheitsprobleme des Builds in Grün wiederherstellen sofort behoben werden können.

Kontinuierliche Bereitstellung (CD) soll gleichzeitig gründlich. In VSTS CD wird in der Regel durch verwaltet, entweder versionsdefinitionen, die Status die Buildausgabe in Umgebungen oder über zusätzliche Builddefinitionen, die geplant werden können – z. B. täglich – anstatt mit jedem Commit ausgelöst. In beiden Fällen kann die Definition eine längere statische Analyse Überprüfung durchführen (siehe Abbildung 7). Das vollständige Codeprojekt gescannt werden kann, und Fehler oder Warnungen überprüft offline ohne Blockierung des CI-Fluss.

Die Builddefinition kann eine Überprüfung der statischen Analyse des Quellcodes auslösen.
Abbildung 7 der Builddefinition kann eine Überprüfung der statischen Analyse des Quellcodes auslösen.

Projektmappen-Dienstprogramme: Wie etwa Checkmarx-Erweiterung für VSTS

Die Erweiterung wie etwa Checkmarx für VSTS (bit.ly/2dVyuDg) ermöglicht es Entwicklern, die nicht nur alle Quellcode überprüfen, sondern auch zu neuen oder geänderten Code einfach zu scannen. Diese inkrementelle Scan-Funktion ist eine wichtige Grundlage für Entwickler in CI-Umgebungen Scanzeiten Stunden auf nur wenige Minuten verringert wird.

Wenn die Analyse abgeschlossen ist, bietet wie etwa Checkmarx Kurzbericht über den Sicherheitsstatus des gescannten Codes auf der VSTS-Projekt Zusammenfassungsseite ermöglichen es Entwicklern, Adresse und Minderung von Sicherheitsrisiken (finden Sie unter Abbildung 8).

Visual Studio Team Services Buildbericht mit wie etwa Checkmarx Überprüfungsergebnisse
Abbildung 8 Visual Studio Team Services Buildbericht mit wie etwa Checkmarx Überprüfungsergebnisse

Wie etwa Checkmarx bietet zudem Entwicklern den "besten beheben Ort" um die Zeit zum Wiederherstellen zu minimieren. Dies schließt ein Diagramm mit visuellen Daten-Flussdiagramm, der den idealen Ort im Code innerhalb des Datenflusses in eine einzige Zeile Code mehrere Schwachstellen angibt (siehe Abbildung 9).

Wie etwa Checkmarx am besten beheben Position im Daten-Flussdiagramm
Abbildung 9 wie etwa Checkmarx am besten beheben Speicherort im Daten-Flussdiagramm

Mit Regel Anpassung Entwicklungsteams können außerdem ändern vorhandene Schwachstelle Erkennung vordefinierte Abfragen, um die Erkennung und die Genauigkeit zu verbessern. Wie etwa Checkmarx beschreibt die Regeln in einer einfachen C#-Syntax.

Sicherer Code ist nur ein Teil der Grafik

Sicherer Code ist erforderlich, aber nicht ausreichend, um die robuste DevOps zu erreichen. Das Verizon "2016 Daten verletzen Intelligence Report" hat viele Angriffsvektoren erfahrenen Kriminelle verwenden, ihre Ziele zu kompromittieren. Zusätzlich zum Schutz von Code, ist es unerlässlich, Anmeldeinformationen und geheime Schlüssel schützen. Insbesondere Phishing wird immer mehr immer komplexer.

Es gibt mehrere Betriebsverfahren, die ein Team, um sich selbst schützen jetzt besprochen angewendet sollte.

Authentifizierung und Autorisierung mehrstufige Authentifizierung verwenden, sogar über interne Domänen und just-in-Time-Verwaltung, z. B. den PowerShell einfach genug Administration (JEA), zum Schutz der Ausweitung von Berechtigungen (aka.ms/jea). Unterschiedliche Kennwörter für verschiedene Benutzerkonten werden den Schaden zu begrenzen, wenn ein Satz von Anmeldeinformationen gestohlen wird.

Verwenden die Version CI/CD-Pipeline dies tun, um die Infrastruktur neu erstellen, damit der releasepipeline und Trittfrequenz auch Schäden enthalten können. Wenn die Infrastruktur als Code mit Azure-Ressourcen-Manager oder mithilfe von Azure-PaaS oder einem anderen Dienst, und klicken Sie dann Ihre Pipeline automatisch neue Instanzen erstellen und zerstören, sodass Angreifer keine Möglichkeit, die innerhalb Ihrer Infrastruktur ausblenden (bit.ly/2dEY5wR). VSTS verschlüsselt die Daten in der Pipeline, und Sie sollten die Kennwörter drehen, ebenso wie andere Anmeldeinformationen aus.

Berechtigungen verwalten dies tun, um eine Pipeline mit rollenbasierte Zugriffskontrolle sichern, wie Sie Ihren Quellcode. Sie möchten steuern, wer auf den Build bearbeiten kann und Release-Definitionen, die Sie für die Produktion verwenden.

Dynamisches Scannen Dies ist die ausgeführte Anwendung mit bekannten Angriffsmuster testen. Z. B. OWASP Zed (bit.ly/1fjloVy) ist ein gängiger open Source dynamische Scanner gegen die primären Schwachstellen, owasp.orgtracks überprüfen. Zwei Partner erläutert in diesem Artikel HPE Sicherheits- und Veracode, dynamische Scan Dienste bereitstellen, auch.

Überwachung Produktion Dies ist eine wichtige DevOps Vorgehensweise. Die spezialisierte Dienste zum Erkennen von Anomalien, die im Zusammenhang mit Eindringversuchen werden als Sicherheitsinformationen und Ereignismanagement bezeichnet. Azure Security Center konzentriert sich auf die Sicherheitsvorfälle im Zusammenhang mit der Azure-Cloud (bit.ly/2dzcj5r).

Projektmappen-Dienstprogramme: Veracode-Erweiterung für VSTS

Die Veracode Application Security-Plattform ist eine SaaS, die Entwicklern ermöglicht, eine Anwendung für Sicherheitslücken automatisch überprüft. Veracode bietet statische Sicherheitstests (SAST), dynamische Sicherheit Anwendungstests (DAST) und SCA, ermöglicht Entwicklungsteams die Erstanbieter-Code und Drittanbieter-Komponenten Sicherheitsrisiken bewerten (finden Sie unter Abbildung 10).

Visual Studio Team Services Buildbericht mit Veracode Überprüfungsergebnisse
Abbildung 10 Visual Studio Team Services Buildbericht mit Veracode Überprüfungsergebnisse

Die Veracode VSTS-Erweiterung (bit.ly/2dme4Vr) ermöglicht es Teams kontinuierlicher und automatisierter Bewertung ihrer Programme als ein Build oder Release Schritt in ihrer CI/CD-Pipeline zu konfigurieren. Der Build oder Release Schritt kann auch konfiguriert werden, um automatisch einen Build oder eine Veröffentlichung auf Grundlage der Anwendungssicherheitsrichtlinie, die es Entwicklern ermöglicht, Sicherheitstests in eine vollständig automatische CD-Pipeline integrieren zu beenden. Darüber hinaus bietet Veracode "Developer Sandkasten" ausgeführt wird, um Ergebnisse auf eine einzelne Entwickler Änderungen vor der Übermittlung bereitzustellen. 

Warum sollte eine Integration in Ihre Pipeline DevOps Security-Überprüfung?

Da dies nun möglich ist. Mit den neuen Erweiterungen in VSTS Marketplace können Sie die Security-Überprüfung fortlaufende Teil Ihres Teams versionspipeline vornehmen. Im Gegensatz zu können in der Vergangenheit bei Überprüfungen wurden selten und generiert eine Wand Probleme direkt vor der Veröffentlichung, Sie Warnungen und Fehler adressieren, sobald sie auftreten. Durch die Sicherheitswarnungen in kleinen Batches Adressierung – entweder mit einzelnen PR oder sogar täglich – Sie können die Arbeit kontinuierlich Komponente und Code für den Prozess und die Adresse Sicherheit verringern.

Zur Optimierung der Geschwindigkeit fördert DevOps die Idee, nach links verschieben. In anderen Worten, ist was lohnt, lohnt kontinuierlich als Teil des DevOps-Workflow. Wenn Sie geändert haben, stellen Sie sie und Version mit Code. Dies erstellt eine Informationsquelle: Ihre Quell-Repositorys und vertrauenswürdigen Management-Paketspeicher. Wenn Sie aktualisieren, aktualisieren Sie die einzelnen Informationsquelle.

Gemäß den 2016 "Status der DevOps Report" (bit.ly/28NI32i) von Puppet, hohe Ausführende, neben der höheren Flexibilität und Zuverlässigkeit Ergebnissen verfügte über bessere Sicherheit Ergebnisse. Durch die Integration (InfoSec) Sicherheitsziele in die tägliche Arbeit von Entwicklungs- und Ops, Zeit sie 50 Prozent weniger Sicherheitsprobleme beheben. Wenn Sie die Sicherheit in der DevOps-Pipeline integrieren, müssen Sie ein automatisches Verfahren zum Erstellen, testen und Bereitstellen von Updates. Dies verkürzt die Zeit zum Wiederherstellen, wenn neue Sicherheitslücken entdeckt werden. Sicherheitsupdates werden genau wie andere Updates und die gleichen automatisierten Fluss folgen.

Die Methoden stellen die Wiederverwendung sicher. Wenn Sie kontinuierlich Pakete scannen, können von diesen abhängig und wissen, dass Sie deren Sicherheitslücken werden nicht übernommen. Darüber hinaus können in der Praxis neue Sicherheitslücken entdeckt werden, Sie sofort benachrichtigt werden, wenn damit Sicherheitsintelligenz umsetzbare zu. Können heben Sie die neuen Paketversionen, ändern Sie den Code nach Bedarf, testen und freigeben, ohne warten Angreifer die Anfälligkeit zu ermitteln.

DevOps gestartet, indem die Aufschlüsselung von Informationssilos zwischen Entwicklung und Betrieb. Jetzt können Sie die nächste Wand, zwischen DevOps und InfoSec aufteilen. Anstelle von Sicherheit Schulden erstellen, die zu spät behandelt werden muss, können Sie dies verhindern, dass Chaos in der Pipeline.

Die Kombination dieser Vorteile hilft Ihnen dabei, schnell. Durch die Integration von Sicherheit Automatisierung in der Pipeline, können Sie sie als Zugriffstaste verwenden. Schließlich wechselt Einbrecher nach leichten Zielen. Und wie der alte Witz, wenn Sie sich an eine camping Partei in die Wälder und eine Herausforderung angezeigt wird, Sie outrun müssen, Bären ist nicht, aber Bären der anderen potenziellen Beute.


Sam Guckenheimer in Visual Studio-Cloud-Diensten funktioniert.  Er ist Autor von drei Bücher über agile Entwicklungsverfahren und einem e-Book auf der Visual Studio Team Services Weg in der cloud ausgeführt. Sie erreichen ihn unter samgu@microsoft.com oder auf Twitter: @samguckenheimer.


Jean-Marc Prieur ist senior Programmmanager bei Microsoft Zielsetzung und fördern die Bereitstellung von Funktionen in Visual Studio und Visual Studio Team Services konzentriert sich technischen Schulden, einschließlich Architektur Analysetools steuern.  Sie erreichen ihn unter jmprieur@microsoft.com oder auf Twitter: @jm_prieur.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Amit Ashbel, Michael rechts, Joanna Rosenberg und Maya Rotenberg
Verstärken Sie am HPE Sicherheit Joanna Rosenberg, Amit Ashbel, Director of Produktmarketing bei wie etwa Checkmarx, Michael rechten Senior Product Manager - Lösung Marketing bei Veracode und Maya Rotenberg, Head Marketing bei WhiteSource.