{"id":3945,"date":"2020-03-01T05:52:00","date_gmt":"2020-03-01T03:52:00","guid":{"rendered":"https:\/\/astarios.com\/zuerich-devsecops-meetup\/"},"modified":"2025-02-03T14:50:32","modified_gmt":"2025-02-03T12:50:32","slug":"zuerich-devsecops-meetup","status":"publish","type":"post","link":"https:\/\/astarios.com\/de\/zuerich-devsecops-meetup\/","title":{"rendered":"Z\u00fcrich DevSecOps Meetup"},"content":{"rendered":" \n

Vielen Dank, Jan, dass du das mit uns geteilt hast\u00a0https:\/\/www.linkedin.com\/pulse \/z%25C3%25BCrich-devsecops-meetup-jan-jambor<\/a><\/p> \n \n

Das zweite\u00a0Z\u00fcrich DevSecOps Meetup<\/a>\u00a0organisiert von\u00a0< a href=“https:\/\/www.linkedin.com\/in\/retokaeser\/“ target=“_blank“ rel=“noreferrer noopener“>Reto\u00a0und\u00a0Ken<\/a> von\u00a0Astarios<\/a>\u00a0mit Unterst\u00fctzung des \u201eDevOPS\u201c-Unternehmens\u00a0VSHN<\/a>\u00a0und gehostet von Swisscom.<\/p> \n

\"\"<\/p> \n \n

DEVSECOPS-AUTOMATISIERUNG MIT OPEN-SOURCE-TOOLS<\/h2> \n \n

Der erste Teil war eine Pr\u00e4sentation mit einigen Demos von Ken. Er hat an der Automatisierung bestimmter Aspekte seines Entwicklungsprozesses gearbeitet und einige Erfahrungen und Tools mit uns geteilt.<\/p> \n \n

Detecting secrets in your code <\/strong><\/h3> \n \n

Github hat vor kurzem damit begonnen, Repos nach API-Schl\u00fcsseln und Passw\u00f6rtern zu durchsuchen und warnt die Besitzer. Einige haben auch berichtet, dass AWS API-Schl\u00fcssel widerruft, die in \u00f6ffentlichen Repositories gefunden werden. Shhgit<\/a>\u00a0erregte k\u00fcrzlich einige Aufmerksamkeit, da es Informationen \u00fcber \u00f6ffentlich geteilte Geheimnisse sammelt.<\/p> \n \n

W\u00e4re es nicht klug, wenn ein Tool Ihnen dabei helfen w\u00fcrde, Geheimnisse in Ihren Commits zu erkennen, bevor Sie sie an Github & Co.? Und das hat Ken uns in seiner ersten Demo gezeigt:\u00a0Talisman<\/a>. Als Pre-Commit-Hook installiert, pr\u00fcft es auf Passw\u00f6rter und andere Geheimnisse und bricht den Commit ab, wenn etwas gefunden wird.<\/p> \n \n

F\u00fcr diese Aufgaben stehen auch andere Tools wie\u00a0<a href=“https:\/\/www.sonarqube.org\/“ target=“_blank“ rel=“noreferrer noopener“>SonarQube<\/a> zur Verf\u00fcgung, die ebenfalls mehr Funktionen bieten.<\/p> \n \n

Where to store secrets <\/strong><\/h3> \n \n

Da wir bereits \u00fcber Geheimnisse gesprochen haben, haben wir dar\u00fcber gesprochen, wie man richtig mit ihnen umgeht. Und hier hat Ken einige Tresorl\u00f6sungen gezeigt. HashiCorp Vault<\/a>\u00a0ist eine der bekannteren L\u00f6sungen, aber auch alle gro\u00dfen Cloud-Anbieter bieten eigene L\u00f6sungen an \u2013 wie Azure Key Vault \u2013 die auch gut sind. Der Punkt, den Sie ber\u00fccksichtigen m\u00fcssen, ist die Portabilit\u00e4t Ihrer L\u00f6sung. Es gibt also keine Ausreden mehr f\u00fcr hartcodierte Passw\u00f6rter, auch nicht zum Testen. Tun Sie das nicht, es wird schnell und hart auf Sie zur\u00fcckkommen.<\/p> \n \n

Package managers and dependencies <\/strong><\/h3> \n \n

Die Kurzfassung dieses Teils der Demo lautet: Alle Paketmanager sind grunds\u00e4tzlich kaputt. Wir haben nicht nur eine Menge Abh\u00e4ngigkeiten f\u00fcr einfache \u201eHallo Welt\u201c-Apps, es gibt auch unbekannte, potenziell unsichere Pakete, die nicht gut aktualisiert sind. Ein Beispiel f\u00fcr SQL-Injections ist im Bild unten dargestellt (Quelle:\u00a0https:\/\/snyk.io\/blog<\/a>).<\/p> \n

\"SQL<\/p> \n \n

Die gro\u00dfen SaaS-Quellcode-Repository-L\u00f6sungen wie Github haben Sicherheits\u00fcberpr\u00fcfungen f\u00fcr Paketmanager und Abh\u00e4ngigkeiten Ihrer App eingef\u00fchrt. Aber auch On-Prem-L\u00f6sungen k\u00f6nnen durch entsprechende Pr\u00fcfungen in der Build-Pipeline erweitert werden.<\/p> \n \n

Dynamic analysis scanning <\/strong><\/h3> \n \n

Wir haben auch schnell die OWASP-Top-10 besprochen, die sich \u00fcberraschenderweise (oder nicht \u00fcberraschend?) \u00dcber Jahrzehnte hinweg nicht so sehr ver\u00e4ndert haben. Es gibt viele kommerzielle und Open-Source-Tools, die Sie bei der dynamischen Analyse unterst\u00fctzen. OWASP selbst hat eine riesige Liste von Tools auf seiner Website.<\/p> \n \n

Infrastructure as code <\/strong><\/h3> \n \n

Auch Infrastructure as Code ist ein gro\u00dfes Thema. Meistens ist es stark auf Komponenten und Bilder angewiesen, die aus \u00f6ffentlichen Ressourcen stammen. Genau wie die oben erw\u00e4hnten Paketmanager verf\u00fcgen wir \u00fcber unbekannte und m\u00f6glicherweise unsichere Quellen dieser Komponenten. Hier kommen statische Analyseger\u00e4te wie\u00a0Clair<\/a>\u00a0f\u00fcr Docker-Images ins Spiel und helfen bei der Identifizierung potenzieller Probleme.<\/p> \n \n

Update<\/strong>: Ich habe gerade\u00a0vulnerablecontainers.org<\/a> gefunden, eine riesige Sammlung von Wenn Sie \u00f6ffentlich verf\u00fcgbare Container-Images (z. B. Docker Hub) mit Scan-Ergebnissen verwenden, sollte dies ziemlich alarmierend sein, wenn Sie diese Images sofort in der Produktion verwenden.<\/p> \n \n

Keeping track <\/strong><\/h3> \n \n

Mittlerweile haben wir im Tagesgesch\u00e4ft eines Sicherheitsbeamten viele verschiedene Werkzeuge und \u201eL\u00e4rmquellen\u201c gesehen. Was wir brauchen, ist eine M\u00f6glichkeit, den \u00dcberblick \u00fcber die wichtigen Dinge zu behalten, im Grunde ist ein \u201eNagios\u201c f\u00fcr DevSecOPS erforderlich. Ken hat uns\u00a0Bogenschie\u00dfen<\/a>\u00a0gezeigt, das genau das tut. Es hilft Ihnen, alle Informationen aus den verschiedenen Quellen zu sammeln und in all dem Chaos die wirklich wichtigen Punkte zu identifizieren.<\/p> \n \n

PROJEKT SYN VON VSHN<\/h2> \n \n

Der zweite Teil des Treffens wurde von Adrian Kosmaczewski, verantwortlich f\u00fcr Developer Relations bei VSHN, moderiert, der uns das sehr coole kommende\u00a0Projekt SYN<\/a>\u00a0das dabei helfen soll, die 5 gro\u00dfen Punkte von DevSecOPS abzudecken: GitOPS, Wartung, Protokollierung, vertrauensw\u00fcrdige Quellen und Richtlinienverwaltung.<\/p> \n \n

Einige gro\u00dfe Pluspunkte sind in meinen Augen:<\/p> \n \n

Erstens<\/strong>: Alles wird Open Source sein, nicht nur der Code, sondern auch der\u00a0ganze Diskussion \u00fcber die Spezifikationen und vor allem die Organisation<\/a>\u00a0was einen gro\u00dfen Unterschied macht. Nur ein Projekt auf Github zu stellen, ist in meinen Augen nicht einmal ann\u00e4hernd die vollst\u00e4ndige Aufgabe. Versuchen Sie, eines der Apache-Projekte wie Superset in weniger als einem Tag in einem PoC zum Laufen zu bringen, und Sie werden sehen, wovon ich spreche.<\/p> \n \n

Zweitens<\/strong>: Adrian beschrieb es als \u201eniedrig h\u00e4ngende\u201c Fr\u00fcchte, als er sagte, dass das Projekt SYN in die drei gro\u00dfen Cloud-Anbieter (AKS, EKS und GKE) und auch in bestehende Cluster integriert werden wird. Das ist in meinen Augen ein riesiges Plus. Ich habe nach \u00e4hnlichen L\u00f6sungen wie dem neuen Controller v3.0 von nginx gesucht, der nur vollst\u00e4ndig neu erstellte Cluster auf Bare-Metal oder VMs unterst\u00fctzt, was aus meiner Sicht ein gro\u00dfes Problem darstellt. Wenn Projekt SYN also auch nur ann\u00e4hernd h\u00e4lt, was hier versprochen wurde: riesig!<\/p> \n \n

Drittens<\/strong>: VSHN isst sein eigenes Hundefutter! Und sie haben mit Abstand die gr\u00f6\u00dfte Erfahrung, wenn es um Cloud-native-Infrastruktur, Kubernetes und Open Shift geht. Was wir hier also sehen werden, ist, was VSHN jeden Tag antreibt. Und das kann nicht schlecht sein.<\/p> \n \n

Einige Einblicke, die Adrian uns gezeigt hat:<\/p> \n \n

Ein gro\u00dfer Punkt ist die enge Zusammenarbeit mit\u00a0crossplane<\/a>. Diese recht neue L\u00f6sung hilft bei der Verwaltung von Cloud-nativen Apps und VSHN, indem sie sie nutzt und im Gegenzug dazu beitr\u00e4gt, ist f\u00fcr beide ein gro\u00dfes Plus. Einige weitere verwendete Tools sind unten aufgef\u00fchrt (keine vollst\u00e4ndige Liste).<\/p> \n \n

GitOPS<\/p> \n \n