Interview mit Johannes Nicolai

Themenkomplex Security: „Auf einen Sicherheitsforscher kommen momentan durchschnittlich 570 Programmierer“
Keine Kommentare

Die moderne IT-Welt ist ein gefährliches Pflaster. Von der Entwicklung über das Deployment bis hin zur Nutzung fertiger Anwendungen gibt es quasi an jeder Ecke potentielle Schwachstellen. Kein Wunder also, dass „Security“ ein zentraler Bereich der Softwareentwicklung ist. Im Interview spricht Johannes Nicolai, Principal Solutions Engineer bei GitHub, über die aktuelle Sicherheitslage in der IT.

Entwickler: Hallo Johannes! Sicherheit ist in der Welt der IT schon immer ein Thema. Kannst du vielleicht kurz umreißen, wie sich die Sicherheitslage in den letzten Jahren verändert hat?

Johannes Nicolai: Viele ehemals komplett analoge Geschäfte bieten ihre Dienstleistungen zunehmend auch im Internet an, sei es das Restaurant oder Tanzstudio um die Ecke, oder große Unternehmen in der Automobil- oder Versicherungsbranche. In der gegenwärtigen Krise hat sich dieser Trend zur Digitalisierung weiter verschärft – ohne eine Möglichkeit virtuell an ein Unternehmen oder eine Behörde heranzutreten, funktioniert nur noch wenig. Beim Digitalisierungstrend dürfen wir aber nie vergessen, dass dies für die meisten Unternehmen und Freiberufler nur Mittel zum Zweck ist und nicht ihr Kerngeschäft. Ein tiefergehendes Wissen zu Sicherheitslücken in verwendeter Software – beispielsweise ihren Online-Shops – ist in vielen Fällen nicht gegeben und kann auch realistischerweise ohne Programmierkenntnisse nicht gegeben sein.

80 Prozent aller kommerziellen Softwareprojekte, die von alten Library-Versionen abhängen, beheben bekannte Sicherheitslücken auch nach über einem Monat nicht.

Der 2019 Data Breach Investigations Report von Verizon schätzt, dass 53 Prozent aller Sicherheits-Problematiken sich auf fehlerhaften Applikations-Code zurückführen lassen. Dieser Applikations-Code wird durch die gestiegenen Kundenerwartungen immer komplexer – unsere Untersuchungen zeigen, dass das durchschnittliche npm/Javascript-Projekt ganze 742 weitere Bibliotheken direkt und indirekt einbindet. Bei Ruby-, C#-, PHP-, Java- und Python-Projekten sieht es ähnlich aus – programmiersprachenübergreifend kommen wir auf durchschnittlich 200 Abhängigkeiten zu externen Bausteinen.

So verwundert es nicht, dass heutzutage kommerzielle Softwareprojekte zu mehr als 60 Prozent aus Abhängigkeiten zu Open-Source-Komponenten bestehen. Leider benutzen diese Projekte nicht unbedingt die aktuellsten Versionen dieser Bausteine. Wir gehen davon aus, dass 80 Prozent aller kommerziellen Softwareprojekte, die von alten Versionen dieser Bibliotheken abhängen, bekannte Sicherheitslücken auch nach über einem Monat nicht durch Updates beheben.

GitHub als größte Softwareplattform für Open Source und kommerzielle Softwareprojekte sieht sich in der Verantwortung, die Konsumenten und Produzenten dieser Softwarebausteine mit den benötigten Werkzeugen, Prozessen und Erfahrungen für sichere Softwareentwicklung und Nutzung zu unterstützen. Das spüren auch die Sicherheitsforscher bereits: Seit GitHub im November 2019 die Möglichkeit anbietet, Sicherheitslücken über GitHub Security Advisories direkt an die betreffenden Projekte zu melden, werden mehr als 60 Prozent aller weltweiten CVEs direkt über GitHub registriert. Von den aktiv entwickelten Open-Source-Projekten werden 98 Prozent der von GitHub gemeldeten Sicherheitslücken innerhalb von zwei Wochen adressiert, bei den meisten Open-Source-Konsumenten ist diese DevSecOps-Mentalität leider noch nicht so stark ausgeprägt.

Entwickler: Im DevOps-Bereich gibt es viele Ansätze, Anwendungen und deren Deployment sicherer zu machen: Das Stichwort hier heißt „DevSecOps“. Kannst du uns zu dessen Definition vielleicht ein paar Worte sagen?

Johannes Nicolai: Es gibt so viele Definitionen von DevSecOps, dass ich mich nicht noch mit einer weiteren anschließen möchte. Die Kernidee ist jedoch bei allen Definitionen dieselbe: Mache das Softwareentwicklungsteam so früh wie möglich darauf aufmerksam, wenn ihre Anwendung eine bekannte Sicherheitslücke inkludiert oder eigener Applikations-Code gerade im Begriff ist, einen Fehler zu begehen, den in ähnlicher Form schon viele andere Teams begangen haben. Ein potenzielles Sicherheitsproblem bereits in dem Moment zu beheben, wo es im Pull-Request angezeigt wird, ist oft um Faktor 1000 oder mehr günstiger, als einen kostspieligen Vergleich oder eine Strafe der EU-Kommission auf Grund eines Datenlecks zahlen zu müssen. Das verlorene Kundenvertrauen und der Reputationsschaden lassen sich dabei oft nicht einmal mehr beziffern.

Es ist leider immer noch oft gängige Praxis, dass geschriebener Code erst Wochen oder Monate nach der Erstellung von einem Sicherheitsteam manuell durchgesehen und abgenickt wird.

Es ist leider immer noch oft gängige Praxis, dass geschriebener Code erst Wochen oder Monate nach der Erstellung von einem Sicherheitsteam manuell durchgesehen und „abgenickt“ wird. Abgenickt deswegen, weil durch die gewachsene Komplexität und Abhängigkeit zu externen Bibliotheken oft keine realistische Chance besteht, eine Sicherheitslücke zu identifizieren. Im Durchschnitt kommt ein Security-Reviewer auf 570 Programmierer – wie soll das mehr als nur ein Abnicken sein?

DevSecOps ändert diesen Ansatz, indem das Wissen der internen Sicherheitsteams mit dem Wissen der Sicherheitsforscher in der Open-Source-Community kombiniert wird und automatisiert jede Code-Änderung darauf überprüft – ob jemand gerade im Begriff ist, einen ähnlichen Fehler zu begehen, den so viele Programmierer schon einmal begangen haben.

Entwickler: Wie genau sichert man eine CI/CD-Pipeline am besten ab? Irgendwelche Best Practices?

Johannes Nicolai: GitHub bietet mit CodeQL und Dependabot Werkzeuge an, die sowohl Probleme im eigenen Quellcode als auch in den konsumierten Abhängigkeiten zu Open-Source-Bibliotheken (Bausteinen) aufzeigen und beheben können. Diese Werkzeuge sind für Open-Source-Projekte kostenlos und werden bereits von über 130.000 Projekten (Javascript/Typescript, Java, C#, Python, Javascript, C/C++, Go) in Produktion eingesetzt. Wer sich davon selbst ein Bild machen möchte, dem sei lgtm und https://github.com/features/security empfohlen.

Mittels auf CodeQL basierender statischer Code-Analyse wurden allein in den letzten drei Monaten über 50 CVEs gefunden und mehr als 100.000 Pull Request analysiert, sodass gefundene Sicherheitslücken gar nicht erst in ein Release gemerged wurden – man könnte lgtm wahrscheinlich als den größten DevSecOps-Showcase auf dem Planeten bezeichnen. Die dafür benutzten Security-Queries werden nicht nur von Sicherheitsforschern bei GitHub, sondern auch von einer großen Community mit Mitwirkung von Firmen wie Google, Uber, Google, Microsoft, HackerOne und OWASP beigesteuert. Jedes Mal, wenn eine Sicherheitslücke gefunden wird, versucht die CodeQL-Community das Problem so im Kern zu beschreiben, dass auch andere Varianten der Lücke gefunden werden können. Auf diese Weise sind schon über 1.700 CodeQL-Community-Queries zusammengekommen – Tendenz rapide steigend. Jeder, der sich gerne beim Schreiben von CodeQL-Queries beteiligen möchte, kann dies unter https://securitylab.github.com/ tun.

Die Wahrscheinlichkeit der Behebung einer Sicherheitslücke ist schon nach 48 Stunden mehr als doppelt so hoch, wenn ein automatisierter Fix zur Verfügung steht.

Während CodeQL potenzielle Sicherheitslücken im eigenen Quellcode als Teil des DevSecOps-Lifecycle automatisch aufzeigt, sorgt sich Dependabot darum, bereits bekannte Sicherheitslücken in benutzten Bausteinen – auch Abhängigkeiten genannt – automatisch zu beheben, indem Pull Requests zum Update auf neuere, sichere Versionen der benutzten Bibliotheken erzeugt werden. Unsere Analysen zeigen, dass die Wahrscheinlichkeit der Behebung einer Sicherheitslücke schon nach 48 Stunden mehr als doppelt so hoch ist, wenn ein automatisierter Fix zur Verfügung steht.

Nicht jedes Versions-Upgrade funktioniert ja ohne weiteres – manchmal haben sich neue Fehler eingeschlichen oder Interfaces sich geändert. Deswegen überprüft Dependabot in mehr als 6 Millionen Open-Source-Repositories, ob die von ihm generierten Pull Requests erfolgreich gemerged wurden, oder ob Testfälle oder andere automatisierte Checks fehlschlugen. Aus dem Community-Feedback ermittelt Dependabot den Community Compatibility Score, damit auch GitHubs kommerzielle Kunden in der Cloud und in den eigenen Rechenzentrum eine gute Indikation haben, ob ein automatisches Sicherheitsupdate problemlos merge-bar ist.

Allein im letzten Monat (März 2020) wurden mehr als 100.000 Pull Requests von Dependabot in Open-Source- und kommerziellen Software-Projekten erzeugt und 87% davon auch erfolgreich gemerged.

Entwickler: Die Cloud ist für viele Unternehmen ein Segen, müssen sie doch nicht mehr selbst Hand anlegen, was die Server und die Konfiguration angeht. Dennoch gibt es, da alles irgendwo halb-öffentlich in der Cloud lagert, ganz andere Sicherheitsprobleme. Wie sichert man Cloud-basierten Anwendungen richtig ab?

Johannes Nicolai: Um mit Kunden vernünftig und zeitnah interagieren zu können, sind die elastischen Kapazitäten und Komfortdienste einer Cloud heutzutage fast unabdingbar. Alle großen Cloud-Anbieter haben mittlerweile verstanden, dass Datenschutz und Sicherheit dabei mindestens in dem Maßstab garantiert werden müssen, wie man es im eigenen Rechenzentrum (on-prem) gewohnt ist.

Richtig ist, dass man bei sensiblen Informationen wie Passwörtern und Cloud-Zugangsschlüsseln sehr schnell handeln muss, falls diese versehentlich publik werden sollten. Auf GitHub entdecken wir in öffentlichen Repositories täglich über 1.800 noch gültige Cloud-Credentials für Dienste wie AWS, GCP und Azure. Manche auf Token Leakage spezialisierte Scripts probieren bereits 20 Sekunden nach dem Auftauchen, diese zu nutzen. Daher haben wir uns entschlossen, mit mehr als 20 Cloud-Diensten zusammenzuarbeiten und diese sekundenschnell zu informieren, sollten ihre Tokens an die Öffentlichkeit gelangen.

Auf diese Weise haben wir schon mehr als 50 Millionen Tokens analysiert und gegebenenfalls invalidiert. Erstaunlicherweise waren viele dieser Tokens nicht einmal für öffentlich exponierte Netzwerke sondern Private-Cloud- bzw. on-prem-Installationen bestimmt – mit Cloud-Sicherheit muss man sich also auch auseinandersetzen, wenn man selbst kaum Nutzer dieser Technologien ist. Die GitHub-Token-Scanning-Technologie ist für alle Open-Source-Projekte kostenfrei und wird auch unseren kommerziellen Kunden für GitHub.com und GitHub-Installationen in der private cloud oder on-prem zur Verfügung gestellt.

Entwickler: Auch das maschinelle Lernen oder Machine Learning ist in den letzten Jahren ordentlich vorangeschritten. Wie wirkt sich das auf die Sicherheit von Anwendungen aus? Immerhin können solche Technologien auch zum Knacken von Passwörtern und Firewalls genutzt werden.

Machine Learning hat ein großes Potenzial, um sowohl existierende Schwachstellen auszunutzen, als auch diese zu identifizieren und im Rahmen des DevSecOps-Zyklus frühzeitig an die Entwicklerteams zu melden.

Johannes Nicolai: Maschinelles Lernen hat wie jedes Werkzeug ein großes Potenzial, um sowohl existierende Schwachstellen auszunutzen, als auch diese zu identifizieren und im Rahmen des DevSecOps-Zyklus frühzeitig an die Entwicklerteams zu melden. GitHub setzt Machine Learning im Sicherheitskontext bereits konkret ein. Ein gutes Beispiel ist wieder lgtm, wo neue CodeQL-Queries zunächst an über 130.000 Open-Source-Projekten verprobt werden. Werden die neuen Alerts ignoriert, als invalid geschlossen oder aber sofort angesehen und behoben, wirkt sich dies auf die Gewichtung und das Ranking unseres Algorithmus aus und ermöglicht uns einen sehr kurzen Feedback-Loop um die Queries und deren Dokumentation zu verbessern.

Auch die Nutzer von CodeQL freut dies, da sie nicht durch Tausende von größtenteils belanglosen Findings gehen müssen, sondern eine kurze Liste von Alerts gezielt von oben nach unten abarbeiten können.

Bei der Identifizierung von Sicherheitslücken in Open-Source-Abhängigkeiten gehen wir nach einem ähnlichen Schema vor – sollten wir beobachten, dass viele Projekte plötzlich die Abhängigkeiten zu einer Bibliothek upgraden und die assoziierten Pull Requests sicherheitsrelevante Schlüsselwörter enthalten, wird dies automatisch ein guter Kandidat für Dependabot. Die endgültige Entscheidung fällt bei uns jedoch immer noch das Sicherheitsteam – künstliche und menschliche Intelligenz gehen Hand in Hand.

Entwickler: Was ist deine Sicherheitsprognose für die kommenden Monate und Jahre – welche Entwicklungen wird es in Sachen Anwendungssicherheit geben?

Johannes Nicolai: Wie bereits erwähnt, kommen auf einen Sicherheitsforscher momentan durchschnittlich 570 Programmierer – dieser Trend wird sich fortsetzen, allerdings wird das Wissen der weltweiten Security-Research-Community mehr und mehr in Form von virtuellen, intelligenten Assistenten verfügbar sein.

In meiner W-JAX-Keynote „The future of software development“ (siehe unten) habe ich das Thema künstliche Intelligenz im Rahmen sicherer Softwareentwicklung genauer beleuchtet. Künstliche Intelligenz wird definitiv nicht den Softwareentwickler von morgen ersetzen, aber die Softwareentwickler von morgen werden sich künstlicher Intelligenz – eingebaut in ihren Entwicklungswerkzeugen – bedienen, um nicht dieselben Programmierfehler zu begehen, wie Generationen von Programmierern vor ihnen. Potenzielle Sicherheitslücken werden in der IDE ähnlich wie Rechtschreib- oder Syntaxfehler rot unterkringelt werden. Beispiele, wie der angreifbare Code ausgenutzt werden kann, können automatisch generiert und CodeQL-Queries, die neue Arten von Sicherheitslücken aufzeigen, automatisch an die Data Sanitization Layer der im Unternehmen eingesetzten Frameworks angepasst werden. Security Alerts werden nicht mehr nur pauschal für eine genutzte Version einer riesengroßen Bibliothek aufgezeigt werden, sondern direkt mit einer Analyse, ob die konkrete Schwachstelle überhaupt etwas mit der Funktionalität zu tun hat, die man von dieser Bibliothek nutzt.

2019 wurden nur 1 Prozent der gefundenen Sicherheitslücken durch statische Code-Analyse automatisch identifiziert und eine Lösung vorgeschlagen. Wir wollen den automatisierten Lösungsanteil wesentlich erhöhen – wenn nicht zur Norm machen, da eine Behebung nach unseren Analysen dann mehr als doppelt so wahrscheinlich ist. Dabei wird der Anteil von False Positives hoffentlich auf ein solches Niveau fallen, dass Entwicklerteams nicht mehr frustriert nach 100 sogenannten Findings aufgeben, sondern jede automatisch gemeldete Sicherheitslücke auch ernst nehmen können und werden.

Bis jetzt skalierten nur die Anzahl der Sicherheitsprobleme mit der Komplexität des Anwendungs-Codes und der eingebundenen Komponenten – GitHubs Ziel ist, das Wissen der weltweiten Security-Communitys ebenfalls skalierbar für Open-Source- und kommerzielle Softwareentwicklung zur Verfügung zu stellen – damit sich Entwickler wieder darauf konzentrieren können, was sie von künstlicher Intelligenz unterscheidet: das kreative Lösen von Geschäftsproblemen und das Meistern der digitalen Herausforderungen unserer Gesellschaft.

Entwickler: Vielen Dank für das Gespräch!


Johannes Nicolai ist ein langjähriger Open Source-Enthusiast und Contributor. In seiner Position als Enterprise Solutions Engineer bei GitHub unterstützt er Unternehmen wie BMW, Continental, Daimler, Deutsche Börse und SAP bei technischen und kulturellen Herausforderungen rund um Software Entwicklung und Open/Inner- Source. Vor GitHub war Johannes bei CollabNet als Europaleiter R&D für die Weiterentwicklung von Subversion, SourceForge, TeamForge und Gerrit zuständig.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -