Eine Version dieses Artikels wurde veröffentlicht in Infosecurity Magazin. Er wurde aktualisiert und hier syndiziert.

‍

Die letzten zwei Jahre waren eine Art Feuertaufe für alle, aber das Konzept der Cybersicherheit für die meisten Unternehmen wurde auf die Probe gestellt, da viele von uns praktisch über Nacht auf ein Modell der Telearbeit umgestellt wurden. Wir mussten wirklich den Einsatz erhöhen und uns als Branche anpassen, vor allem als Folge der verzweifelten Bedrohungsakteure, die seit Beginn der Pandemie einen 300-prozentigen Anstieg der gemeldeten Cyberkriminalität verursachten.

Wir haben alle ein paar Lektionen gelernt, und mich tröstet die Tatsache, dass nicht nur die allgemeine Cybersicherheit ernster genommen wird, sondern auch die Software-Sicherheit und -Qualität auf Code-Ebene. Bidens Durchführungsverordnung zur Sicherung der Software-Lieferkette hat kritische Fragen ans Licht gebracht, insbesondere nach dem Masseneinbruch bei SolarWinds. Der Gedanke, dass wir uns alle mehr um die Sicherheit kümmern und daran arbeiten müssen, Schwachstellen durch ein messbares Sicherheitsbewusstsein zu verringern, ist definitiv ein größerer Teil der Diskussion.

Wenn es um den Kampf gegen Cyberkriminelle geht, müssen wir ihnen jedoch so weit wie möglich folgen und ihre Spielplätze mit einer präventiven Denkweise verhindern. 

Ich denke, dass sie im kommenden Jahr Wellen schlagen werden:

Das Metaversum ist eine neue Angriffsfläche

Das Metaverse mag die nächste Evolution des Internets sein, aber ein ähnlicher Wandel in der Art und Weise, wie die meisten Branchen die Sicherung von Software und digitalen Umgebungen angehen, steht noch aus. 

Während allgemeine Cybersecurity-Fallen wie Phishing-Betrügereien unvermeidlich sind (und wahrscheinlich zahlreich auftreten werden, während jeder mit dem Metaversum zurechtkommt), müssen die eigentliche Infrastruktur und die Geräte, die diese immersive virtuelle Welt ermöglichen, sicher sein. Ähnlich wie die Smartphones uns geholfen haben, online zu leben, sind Peripheriegeräte wie VR-Headsets das neue Tor zu Bergen von Benutzerdaten. Immer komplexere eingebettete Systeme sind erforderlich, um IoT-Gadgets sicher zu machen, und die schöne neue Welt von VR/AR ist da keine Ausnahme. Wie wir mit dem Log4Shell-Exploit gesehen haben, können sich einfache Fehler auf der Code-Ebene zu einem Backstage-Pass für Bedrohungsakteure entwickeln, und in einer simulierten Realität erzeugt jede Bewegung Daten, die gestohlen werden können.  

Ein erfolgreiches Metaverse, das noch in den Kinderschuhen steckt, erfordert die praktische Anwendung von Kryptowährungen (und nicht nur das willkürliche Horten des neuesten Meme-Coins) und Wertgegenständen wie NFTs, was bedeutet, dass unser reales Vermögen, unsere Identität, unsere Daten und unser Lebensunterhalt potenziell einem neuen "Wilden Westen" ausgesetzt sind, der die Menschen gefährden kann. Bevor wir Ingenieure uns mit epischen Funktionen und Erweiterungen überschlagen, sollte die Minimierung dieser neuen, riesigen Angriffsfläche von Grund auf Priorität haben.

Gesetzgebung im Gefolge von Log4Shell

Für die zahlreichen Entwickler, die im Chaos versinken mussten, um herauszufinden, ob es eine ausnutzbare Version des weit verbreiteten Log4j-Protokollierungswerkzeugs gibt oder ob Abhängigkeiten bestehen, waren die Feiertage sicher keine schöne Zeit. 

Dieser Zero-Day-Angriff gehört zu den schlimmsten in der Geschichte. Es wurden Vergleiche zwischen Log4Shell und der verheerenden Heartbleed-OpenSSL-Schwachstelle gezogen, die auch über sechs Jahre später noch ausgenutzt wird. Wenn es nach dieser Zeitachse geht, werden wir noch lange mit einem Log4Shell-Kater zu kämpfen haben. Es ist klar, dass trotz der Lehren, die aus Heartbleed gezogen wurden - zumindest in Bezug auf die Notwendigkeit, Patches so schnell wie möglich bereitzustellen und zu implementieren - viele Unternehmen einfach nicht schnell genug handeln, um sich zu schützen. Je nach Größe des Unternehmens kann das Patchen unglaublich schwierig und bürokratisch sein und eine abteilungsübergreifende Dokumentation und Implementierung erfordern. Häufig verfügen IT-Abteilungen und Entwickler nicht über ein enzyklopädisches Wissen über alle verwendeten Bibliotheken, Komponenten und Tools und werden durch strenge Zeitpläne für die Bereitstellung behindert, um Störungen und Ausfallzeiten von Anwendungen zu minimieren. Es gibt triftige Gründe für diese Arbeitsweise (niemand will einen Fehler machen und etwas kaputt machen), aber wer zu langsam patcht, ist eine leichte Beute.

So wie der SolarWinds-Angriff die Software-Lieferkette verändert hat, sage ich voraus, dass Ähnliches im Gefolge von Log4Shell passieren wird. Während es in einigen kritischen Branchen bereits Patch-Management-Mandate und -Empfehlungen gibt, ist eine weit verbreitete Gesetzgebung eine andere Geschichte. Vorbeugende Softwaresicherheit wird immer die beste Möglichkeit sein, dringende Sicherheits-Patches ganz zu vermeiden, aber bewährte Sicherheitsverfahren schreiben vor, dass Patches eine nicht verhandelbare Prioritätsmaßnahme sind. Ich denke, dies wird ein heißes Thema sein und zu nicht ganz so subtilen Empfehlungen führen, schnell und oft zu patchen. 

Mehr Gewicht auf architektonische Sicherheit (und die Entwickler sind nicht bereit)

Die neue OWASP Top 10 2021 enthielt einige wichtige Neuzugänge sowie eine Überraschung: Injection-Schwachstellen fielen von der Spitzenposition auf einen bescheidenen dritten Platz. Diese Neuzugänge deuten auf eine Art "zweite Stufe" der Reise eines Entwicklers in Bezug auf sichere Kodierung und bewährte Sicherheitspraktiken hin, und leider sind die meisten nicht in der Lage, hier einen positiven Einfluss auf die Risikominderung zu nehmen, wenn sie nicht entsprechend geschult sind.

Wir wissen schon seit einiger Zeit, dass Entwickler über Sicherheitskenntnisse verfügen müssen, wenn wir häufige Sicherheitsfehler im Code bekämpfen wollen, und die Unternehmen reagieren immer besser auf die Prämisse der entwicklergesteuerten Prävention. Da Insecure Design jedoch einen Platz in den OWASP Top 10 beansprucht und eher eine Kategorie von architektonischen Sicherheitsproblemen als eine einzelne Art von Sicherheitsfehlern ist, müssen Entwickler über die Grundlagen hinaus gefördert werden, sobald sie diese beherrschen. Lernumgebungen, die die Modellierung von Bedrohungen abdecken - idealerweise mit Unterstützung des Sicherheitsteams - nehmen den Druck von den Entwicklern, sobald sie sich erfolgreich fortgebildet haben, aber so wie es aussieht, ist es für die meisten Softwareingenieure eine erhebliche Wissenslücke.

Um dem entgegenzuwirken, braucht es ein Dorf", und das Unternehmen kann eine Rolle bei der Schaffung einer positiven Sicherheitskultur für Entwickler spielen, indem es ihre Neugierde weckt, ohne ihre Arbeitsabläufe wesentlich zu stören.

Eine Version dieses Artikels erschien in SC-Magazin. Er wurde hier geändert und syndiziert.
Wenn

Sie schon einmal einen Einbruch erlebt haben, kennen Sie das Gefühl, dass etwas nicht stimmt, gefolgt von der Erkenntnis, dass Sie tatsächlich bestohlen wurden. Das führt in der Regel zu dauerhaftem Unbehagen, ganz zu schweigen davon, dass man Sicherheitsmaßnahmen ergreift, die es mit Fort Knox aufnehmen könnten.

Stellen Sie sich nun vor, dass in Ihr Haus eingebrochen wird, weil die Diebe sich einen Schlüssel gemacht haben. Sie schleichen herum, kommen und gehen, wie es ihnen gefällt, aber sie achten darauf, unentdeckt zu bleiben. Eines Tages bemerken Sie zu spät, dass der Schmuck, den Sie in der Gefriertruhe versteckt haben, verschwunden ist, dass Ihr Tresor geleert wurde und dass Ihre persönlichen Gegenstände durchwühlt worden sind. Dies ist die gleiche Realität, mit der ein Unternehmen konfrontiert wird, wenn es Opfer eines Zero-Day-Cyberangriffs wird. Im Jahr 2020 ergab eine Studie des Ponemon Institute, dass 80 % der erfolgreichen Datenschutzverletzungen das Ergebnis von Zero-Day-Angriffen waren, und leider sind die meisten Unternehmen nach wie vor nicht in der Lage, diese Statistik deutlich zu verbessern.

Bei Zero-Day-Angriffen bleibt den Entwicklern definitionsgemäß keine Zeit, vorhandene Schwachstellen zu finden und zu beheben, da der Bedrohungsakteur zuerst eingedrungen ist. Der Schaden ist angerichtet, und dann ist es ein verrücktes Gedränge, um sowohl die Software als auch den Imageschaden für das Unternehmen zu beheben. Angreifer sind immer im Vorteil, und es ist von entscheidender Bedeutung, diese Lücke so weit wie möglich zu schließen. 

Das Weihnachtsgeschenk, das sich niemand gewünscht hat - Log4Shell - macht derzeit das Internet unsicher, da über eine Milliarde Geräte von dieser katastrophalen Java-Schwachstelle betroffen sein sollen. Es zeichnet sich ab, dass dies der schlimmste 0day-Angriff aller Zeiten sein wird, und wir stehen erst am Anfang. Obwohl in einigen Berichten behauptet wird, dass die Angriffe bereits einige Tage vor der Veröffentlichung begonnen haben, deutet eine Präsentation auf der Black Hat Conference 2016 darauf hin, dass dieses Problem schon seit einiger Zeit bekannt ist. Autsch. Noch schlimmer ist, dass es schmerzhaft einfach auszunutzen ist und jeder Skript-Kiddie und Bedrohungsakteur auf dem Planeten hinter dieser Sicherheitslücke her ist.

Was ist also der beste Weg, um sich gegen eine schlüpfrige, unheimliche Bedrohung zu verteidigen, ganz zu schweigen von Schwachstellen, die bei der Softwareentwicklung übersehen wurden? Werfen wir einen Blick darauf. 

Zero-Day-Angriffe auf große Ziele sind selten (und teuer)

Es gibt einen riesigen Markt für Exploits im Dark Web, und Zero-Days werden oft für viel Geld verkauft. Ein Beispiel in diesem Artikel wird zum Zeitpunkt der Erstellung dieses Artikels für 2,5 Millionen Dollar angeboten. Berichten zufolge handelt es sich um ein Exploit für Apple iOS. Es überrascht daher nicht, dass der Preis für den Sicherheitsforscher so hoch ist, schließlich könnte dies das Tor sein, um Millionen von Geräten zu kompromittieren und Milliarden von sensiblen Datensätzen abzugreifen, und das so lange wie möglich, bevor es entdeckt und gepatcht wird.

Aber wer hat schon so viel Geld? Normalerweise bringen organisierte Cyberkriminelle das Geld auf, wenn sie es für lohnenswert halten, insbesondere bei den beliebten Ransomware-Angriffen. Aber auch Regierungen und Verteidigungsministerien weltweit gehören zu den Abnehmern von Exploits, die sie für Bedrohungsanalysen nutzen können, und in positiveren Szenarien können die Unternehmen selbst Käufer ihrer eigenen potenziellen Zero-Day-Exploits sein, um eine Katastrophe zu verhindern. 

ImJahr 2021 wurden Rekorde bei der Entdeckung von Zero-Day-Exploitsgebrochen, und es sind große Organisationen, Regierungsstellen und Infrastrukturen, die am meisten gefährdet sind, auf Schwachstellen untersucht zu werden. Es gibt keine Möglichkeit, sich völlig vor der Möglichkeit eines Zero-Day-Angriffs zu schützen, aber Sie können das Spiel ein wenig "mitspielen", indem Sie ein großzügiges und gut strukturiertes Bug-Bounty-Programm anbieten. Anstatt zu warten, bis jemand die Schlüssel zu Ihrem Software-Schloss auf einem Dark-Web-Marktplatz anbietet, sollten Sie legitime Sicherheitsexperten auf Ihre Seite ziehen und ihnen eine anständige Belohnung für die ethische Offenlegung und mögliche Fehlerbehebung anbieten.

Und wenn es sich zufällig um eine haarsträubende Zero-Day-Bedrohung handelt, können Sie davon ausgehen, dass Sie mehr als einen Amazon-Gutschein ausgeben müssen (und es wird sich lohnen).

Ihre Werkzeuge könnten eine Belastung für Ihr Sicherheitspersonal darstellen

Schwerfällige Sicherheitstools sind schon seit langem ein Problem. Der durchschnittliche CISO verwaltet zwischen 55 und 75 Tools in seinem Sicherheitsarsenal. Abgesehen davon, dass es sich dabei um das verwirrendste (metaphorische) Schweizer Taschenmesser der Welt handelt, sind 53 % der Unternehmen laut einer Studie des Ponemon Institute nicht einmal davon überzeugt, dass sie effektiv arbeiten. Eine andere Studie ergab, dass nur 17 % der CISOs der Meinung sind, dass ihr Sicherheits-Paket "vollkommen effektiv" ist.

In einem Bereich, der für sein Burnout, den Mangel an Sicherheitsfachkräften und den Bedarf an Flexibilität bekannt ist, ist es sehr belastend, wenn Sicherheitsexperten gezwungen sind, mit einer Informationsflut in Form von Daten, Berichten und der Überwachung riesiger Toolsets zu arbeiten. Dies ist genau die Art von Szenario, die dazu führen kann, dass sie einen kritischen Alarm übersehen, was durchaus der Fall gewesen sein kann, als es darum ging, die Schwachstellen von Log4j richtig zu bewerten. 

Vorbeugende Sicherheit sollte eine entwicklergesteuerte Bedrohungsmodellierung beinhalten

Schwachstellen auf Code-Ebene werden häufig von Entwicklern eingebracht, und sie benötigen eine genaue Anleitung und regelmäßige Lernwege, um sichere Programmierfähigkeiten aufzubauen. Sichere Entwickler der nächsten Stufe haben jedoch die Möglichkeit, die Modellierung von Bedrohungen als Teil ihres Softwareentwicklungsprozesses zu erlernen und zu üben.

Es sollte nicht überraschen, dass die Leute, die ihre Software am besten kennen, die Entwickler sind, die sie selbst entwickelt haben. Sie verfügen über ein umfassendes Wissen darüber, wie die Benutzer mit der Software interagieren, wo die Funktionen verwendet werden und - bei ausreichendem Sicherheitsbewusstsein - über mögliche Szenarien, in denen die Software versagen oder ausgenutzt werden könnte.

Wenn wir dies auf den Log4Shell-Exploit zurückführen, sehen wir leider ein Szenario, in dem eine katastrophale Schwachstelle der Erkennung durch Experten und komplexe Tools entgangen ist, die jedoch möglicherweise gar nicht aufgetreten wäre, wenn die Bibliothek so konfiguriert gewesen wäre, dass Benutzereingaben sanitized wurden. Die Entscheidung, dies nicht zu tun, scheint eine obskure Funktion gewesen zu sein, die der Bequemlichkeit diente, es aber schmerzhaft einfach machte, die Schwachstelle auszunutzen (man denke an SQL-Injection-Level, sicherlich keine geniale Sache). Wenn die Bedrohungsmodellierung von einer Gruppe scharfsinniger, sicherheitsbewusster Entwickler durchgeführt worden wäre, hätte man dieses Szenario höchstwahrscheinlich durchdacht und berücksichtigt.

Ein großartiges Sicherheitsprogramm hat eine emotionale Komponente, wobei menschliches Eingreifen und Nuancen im Mittelpunkt der Lösung von Problemen stehen, die von Menschen geschaffen wurden. Die Modellierung von Bedrohungen erfordert Einfühlungsvermögen und Erfahrung, um effektiv zu sein, ebenso wie die sichere Kodierung und Konfiguration auf der Architekturebene von Software und Anwendungen. Entwickler sollten nicht von heute auf morgen in diese Aufgabe hineingeworfen werden, aber ein klarer Weg, sie auf ein Niveau zu bringen, auf dem sie das Sicherheitsteam bei dieser wichtigen Aufgabe entlasten können, ist ideal (und es ist eine großartige Möglichkeit, eine Beziehung zwischen beiden Teams aufzubauen). 

Null-Tage führen zu n-Tagen

Der nächste Teil des Umgangs mit einem Zero-Day besteht darin, Patches so schnell wie möglich zu veröffentlichen und zu hoffen, dass jeder Benutzer der verwundbaren Software sie so schnell wie möglich anwendet, und zwar bevor ein Angreifer sie als erster findet. Log4Shell könnte Heartbleed in puncto Ausdauer und Wirksamkeit in den Schatten stellen, da es in Millionen von Geräten eingebettet ist und komplexe Abhängigkeiten innerhalb eines Software-Builds schafft.

Realistisch betrachtet gibt es keine Möglichkeit, diese Art von heimtückischen Angriffen vollständig zu verhindern. Wenn wir uns jedoch dazu verpflichten, alle Möglichkeiten zu nutzen, um qualitativ hochwertige und sichere Software zu entwickeln, und die Entwicklung mit der gleichen Einstellung angehen wie kritische Infrastrukturen, können wir alle eine Chance haben.

Entwickler erstellen und testen ihren eigenen Code mit verschiedenen Methoden. Eine dieser Methoden sind Unit-Tests - eine sehr beliebte Methode zum Testen der kleinsten Teile des eigenen Codes. Wenn sie gut geschrieben sind, können Unit-Tests dazu beitragen, die Qualität Ihres Codes zu verbessern sowie Kosten und Entwicklungszeit zu reduzieren. Unabhängig davon, ob sie im Rahmen der testgetriebenen Entwicklung (TDD) durchgeführt werden oder nicht, sind Unit-Tests ein wichtiger Bestandteil der modernen Entwicklungspraktiken, und ihre Bedeutung hat zur Schaffung zahlreicher Test-Frameworks geführt.

Ohne ein geeignetes Test-Framework und eine entsprechende Anleitung können Unit-Tests jedoch komplex und unleserlich werden, da der Schwerpunkt eher auf Abdeckung und Quantität als auf Qualität und Lesbarkeit liegt. Dies gilt insbesondere für eine große und aktive Codebasis mit vielen Unit-Tests.

Ein gutes Test-Framework hilft bei der Erstellung gut lesbarer Tests, die einfach sind und sich auf Qualitätstests konzentrieren. Sie helfen auch dabei, die Art und Weise zu dokumentieren, wie Ihr Code zu verwenden ist. Ein solches Framework ist AssertJ.

AssertJ ist eine fließende API zum Schreiben von Unit-Tests in Java. Mit ihr können Sie Testbehauptungen schreiben, die sich wie Englisch lesen, mit kontextabhängiger Autovervollständigung. Wenn Sie eine große Anzahl von Tests haben und deren Lesbarkeit verbessern müssen, möchten Sie vielleicht alle zu AssertJ migrieren und sicherstellen, dass alle zukünftigen Tests die Vorteile von AssertJ nutzen.

Eine vollständige Migration kann jedoch einen enormen Aufwand und viel Zeit in Anspruch nehmen und wird daher oft übersprungen oder zugunsten anderer Entwicklungsaufgaben aufgeschoben. Deshalb haben wir Sensei entwickelt - ein hochgradig anpassbares IntelliJ-Plugin, das Ihnen helfen kann, Ihre aktuellen Unit-Tests auf AssertJ zu migrieren und alle zukünftigen Tests auf die richtige Weise zu schreiben. Dies geschieht mit einer Reihe von Rezepten (Regeln), die das Entwicklungsteam von Senseibereits für Sie erstellt hat. Sensei macht es einfach, eine einmalige Migration durchzuführen oder den Ansatz einer schrittweisen Migration zu AssertJ zu wählen, einen Test nach dem anderen. Nach der Umstellung auf AssertJ helfen die Rezepte den Entwicklern weiterhin bei der Anwendung von Schnellkorrekturen, während sie Unit-Tests schreiben, so dass Ihre Unit-Tests weiterhin einheitlich, standardisiert und konsistent über die gesamte Codebasis sind.

‍

Über Sensei

Sensei ist ein hochgradig anpassbares IntelliJ-Plugin zum Scannen und Korrigieren von unerwünschtem Code während der Eingabe - mit Hunderten von herunterladbaren Code-Transformationen und Migrationsrezepten (Regeln) sowie einer eingebauten Möglichkeit, eigene zu erstellen. Mit Sensei können Entwickler schlechte Codemuster während der Eingabe korrigieren, so dass sie qualitativ hochwertigen Code schneller liefern und ihn letztlich in einer konsistenten und standardisierten Art und Weise über Teams und Projekte hinweg schreiben können.

Hier ist ein Beispiel für eine Migration, die Ihnen zeigen könnte, wie Sensei die Migration Ihrer Unit-Tests zur Verwendung von AssertJ vereinfacht.

Warum ist AssertJ ein großartiges Framework zum Schreiben von Unit-Tests

Anstatt einen Test wie diese JUnit-Assertion zu schreiben:

können Sie dies mit AssertJ schreiben:

Das bedeutet, dass Sie die Behauptung wie einen englischen Satz von links nach rechts lesen können, und es ist klar, was die Erwartung ist (in diesem Fall die Größe 3). Wie oft haben Sie schon eine Behauptung falsch herum geschrieben, so wie hier?

Dies sind nur einfache Beispiele. Je komplexer Ihre Prüfungen und Assertions sind, desto mehr hilft Ihnen AssertJ, Ihre Tests einfach und lesbar zu gestalten. Es arbeitet sehr gut mit der Autovervollständigung Ihrer IDE zusammen. Sobald Sie eingeben:

wird je nach Typ von myResult eine Liste mit allen Dingen angezeigt, die Sie überprüfen können. Handelt es sich um eine Auflistung, können Sie den Inhalt, die Größe, den Inhalt bestimmter Werte oder Typen usw. überprüfen.

AssertJ unterstützt von Haus aus Primitive und ihre Boxed Types, Atomic Types, Collections, Arrays, Maps, Dates, java.time, Futures, Files/Paths, InputStreams, Throwables und URLs. Und wenn Sie einen bevorzugten benutzerdefinierten Matcher für Hamcrest haben, können Sie ihn mit AssertJ über HamcrestCondition verwenden.

Lesbare Unit-Tests erleichtern es Entwicklern, den Code in normalem Englisch zu lesen und machen es daher einfach, Fehler zu erkennen und die Abdeckung zu erhöhen - was AssertJ zu einem unverzichtbaren Framework für gute Java Unit-Tests macht.

Rezepte zum Verschieben von Legacy-Unit-Tests nach AssertJ

Wir haben ein Kochbuch geschrieben , um Ihnen zu helfen, konsistenten Code mit AssertJ zu schreiben. Es kann Ihnen helfen, Ihre Assertions von einem der folgenden Frameworks zu AssertJ zu migrieren: JUnit 3, JUnit 4, JUnit 5 und FEST-Assert.

Dieses Kochbuch kann in Sensei zur sofortigen Verwendung konfiguriert werden. Eine Installationsanleitung für Sensei finden Siehier.

Bessere Unit-Tests beim Programmieren schreiben - JUnit-Qualität schrittweise verbessern

Das Sensei Kochbuch für AssertJ hilft Ihnen nicht nur bei der Migration von anderen Frameworks. Es enthält einige Rezepte, die Ihnen helfen können, Ihre Tests zu verbessern, mit alten Gewohnheiten zu brechen und mehr idiomatische AssertJ-Tests zu schreiben.

Nehmen wir zum Beispiel an, Sie haben einen Test geschrieben, der wie folgt aussieht:

Vielleicht haben Sie es sogar mit einem der oben genannten Migrationsrezepte aus dieser JUnit-ähnlichen Assertion migriert:

Das Sensei Kochbuch für AssertJ hat ein Rezept, das auch diese alte Art von Assertion erkennen kann, und bietet an, sie in diese zu konvertieren:

Ein anderes Rezept kann das folgende umwandeln:

dazu:

Eine einmalige Migration und einheitliche Kodierungspraktiken in allen Teams - mit Sensei

Wie wir aus den obigen Beispielen ersehen können, kann die manuelle Migration von Unit-Tests zu AssertJ viel Aufwand und Zeit kosten, die man besser in das Schreiben besserer Tests investieren sollte. Mit Sensei können Sie Ihre Unit-Tests einfach und sicher nach AssertJ migrieren. Sie können eine einmalige Migration durchführen oder einzelne Tests nach und nach auf AssertJ migrieren. Sensei bietet diese Art von Flexibilität, die Code-Migrationen weniger schmerzhaft macht.

Die Migration von Unit-Tests ist nur ein Beispiel für die vielen Möglichkeiten, die Sensei bietet, um konsistenten Code in Ihren Projekten zu schreiben. Sie können immer nach Anti-Patterns oder bestimmten manuellen Code-Transformationen Ausschau halten, auf die Sie häufig in Pull-Requests oder beim Coding selbst stoßen. Wenn Sie über eine Reihe von Codierungsrichtlinien verfügen, die von den Entwicklern häufig nicht beachtet werden, können Sie diese Richtlinien in Rezepte umwandeln, damit die Entwickler bewährte Codetransformationen sicher anwenden können.

Wenn Sie Fragen haben, würden wir uns freuen, von Ihnen zu hören! Treten Sie uns auf Slack bei: sensei-scw.slack.com

Die Migration von Code (sprich: Legacy-Code) ist kein Vergnügen. Es erfordert eine enorme Menge an Planung und Aufwand, um ihn über die Linie zu bringen. Es ist zwar nicht die aufregendste oder motivierendste Arbeit für Entwickler, aber es erfordert Entschlossenheit und die richtige Erfahrung, um Legacy-Code auf neue Bibliotheksversionen zu migrieren. Joda-Time zu java.time ist eine solche Migration, die eine sorgfältige Planung und Ausführung erfordert.

Wenn Ihr Java-Projekt vor Java SE 8 begonnen hat und Datums- und Zeitverarbeitung verwendet, dann hat es wahrscheinlich Joda-Time verwendet - eine ausgezeichnete Bibliothek und ein De-facto-Standard für die Handhabung von Datums- und Zeitfunktionen vor SE 8. Wenn Ihr Projekt immer noch Joda-Time verwendet, aber auf java.time migrieren möchte, dann lesen Sie weiter.

Mit der Veröffentlichung von Java SE 8 wurde eine neue und verbesserte Standard-API für Datum und Uhrzeit eingeführt, die gemeinhin als java.time (JSR-310) bezeichnet wird. Das Joda-Time-Projekt empfiehlt nun die Migration auf java.time (JSR-310).

Obwohl java.time (JSR-310) stark von Joda-Time inspiriert wurde, ist es nicht rückwärtskompatibel und Konzepte und Terminologien haben sich geändert. Deshalb erfordert die Migration von Joda-Time zu java.time eine sorgfältige Prüfung jeder einzelnen Codezeile, die Sie ändern. Dies kann zeitaufwändig sein und man würde sich fast wünschen, dass es einen einfacheren und automatisierten Weg zur Migration gäbe.

Es gibt einen besseren Weg zu migrieren, und wir haben ihn mit Sensei entwickelt - ein IntelliJ-Plugin, das automatisch Code-Transformationen nach den von Ihnen definierten Rezepten (Regeln) durchführt. Verbringen Sie Ihre Zeit damit, wiederverwendbare Rezepte zu definieren, anstatt sich wiederholende Migrationsaufgaben durchzuführen. Die Automatisierung wird nicht nur Ihren alten Joda-Time-Code transformieren, sondern auch den Teams helfen, die Richtlinien direkt in der IDE zu befolgen, wenn sie neuen Code schreiben.

Um Ihnen einen Vorsprung zu verschaffen, haben wir ein öffentliches Sensei Kochbuch Standardization on java.time (JSR-310) erstellt, das Rezepte für die Migration von Joda-Time zu java.time auf eine weniger schmerzhafte Weise enthält. Dies ist ein wachsender Satz von Rezepten, den wir weiter ausbauen werden, um die Abdeckung mit weiteren Rezepten zu erhöhen.

Hier ist ein Beispiel für eine Migration, das Ihnen zeigt, wie Sensei die Migration von Legacy-Code vereinfacht.

Von der sich wiederholenden manuellen Migration zu automatisierten Codeumwandlungen

Schauen wir uns ein Beispiel für die Erstellung einer neuen DateTime an, das ein paar versteckte Fallen bei der Migration einer einzigen Codezeile von Joda-Time zu java.time aufzeigt. Wir werden uns dann eines unserer Sensei Rezepte aus unserem Standardization on java.time (JSR-310) Kochbuch ansehen und zeigen, wie es all diese Informationen erfasst, so dass dieselbe Migration von jedem Entwickler wieder und wieder verwendet werden kann.

In diesem Beispiel konstruieren wir eine Joda-Time DateTime aus 7 int-Argumenten, die Werte der DateTime-Felder darstellen.

Wie können wir dies in ein java.time-Äquivalent migrieren?

Die Javadoc in Joda-Time für diesen Konstruktor sagt:

Konstruiert eine Instanz aus Datetime-Feldwerten unter Verwendung von ISOChronology in der Standardzeitzone.

Zunächst könnte man annehmen, dass es eine DateTime-Klasse in java.time gibt, aber das ist nicht der Fall. Wenn Sie nach "Migration von Joda-Time zu Java-Time" googeln, werden Sie höchstwahrscheinlich Stephen Colebournes Blogbeitrag Converting from Joda-Time to java.time finden.

Dies ist ein guter Anfang und weist uns den Weg zur Verwendung von java.time.ZonedDateTime oder java.time.OffsetDateTime. Hier stellt sich die erste Frage: Welche soll ich verwenden? Wahrscheinlich ZonedDateTime, basierend auf Stephens Kommentaren.

Wenn wir im Javadoc von ZonedDateTime nachsehen, können wir überhaupt keine Konstruktoren finden. Wir kehren zu Stephens Blogbeitrag zurück und lesen weiter unten:

Konstruktion. Joda-Time hat einen Konstruktor, der ein Objekt akzeptiert und eine Typkonvertierung durchführt. java.time hat nur Factory-Methoden, so dass die Konvertierung ein Benutzerproblem ist, obwohl eine parse()-Methode für Strings zur Verfügung steht.

Es muss also eine statische Fabrikmethode geben, und beim Durchsuchen der statischen Methoden finden wir eine, die ziemlich ähnlich aussieht, aber nicht genau dieselbe ist.

Er hat 7 int-Parameter wie unser ursprünglicher Joda-Time DateTime-Konstruktor, aber wenn Sie nicht aufpassen, werden Sie ein wichtiges Detail übersehen. Der 7. Parameter steht nicht mehr für Millisekunden, sondern für Nanosekunden. Das liegt daran, dass java.time die Genauigkeit gegenüber Joda-Time erhöht hat und Instanten auf die Nanosekunde genau misst. Ein wichtiges Detail, das Sie leicht hätten übersehen können. Außerdem erwartet diese Methode eine ZoneId, so dass man sich fragt, warum man vorher keine brauchte und warum man sie jetzt braucht.

Erinnern Sie sich an die Javadoc unserer ursprünglichen Konstruktor, die es würde die Standard-Zeitzone verwenden erwähnt, vielleicht gibt es eine Möglichkeit, die Standard-ZoneId zu erhalten?

In der Javadoc für ZoneId sind keine Konstruktoren aufgeführt, aber wenn wir uns die statischen Methoden ansehen, sehen wir, dass wir systemDefault()verwenden können

Nun, da wir die ZoneId geklärt haben, was sollen wir mit der Konvertierung von Millisekunden in NanoSekunden tun? Vielleicht können wir java.util.concurrent.TimeUnit verwenden, um die Umwandlung durchzuführen.

Diese Methode gibt einen long zurück, und unsere Methode erwartet einen int, so dass wir jetzt auch ein Konvertierungsproblem zu lösen haben. Vielleicht können wir etwas Einfaches versuchen. Eine Multiplikation?

Das funktioniert zwar, sieht aber ein wenig deplatziert aus. Falls Sie es noch nicht bemerkt haben: Wir haben viel Zeit und Mühe investiert, um eine einzige Codezeile zu migrieren. Aber wie Sie sich vorstellen können, müssen wir viele solcher Bearbeitungen von Hand vornehmen, und es wird nicht besser.

Wenn wir uns jedoch die java.time API etwas genauer ansehen, können wir eine Lösung entdecken, die etwas flüssiger aussieht.

Obwohl ZonedDateTime keine offensichtliche Möglichkeit bietet, die Millisekunden zu setzen, kann dies mit der Methode with(TemporalField field, long newValue) erfolgen, wobei ChronoField.MILLI_OF_SECOND als TemporalField verwendet wird.

Und in der Java-Doku wird erwähnt, dass es die Konvertierung in Nanosekunden für uns durchführt:

Wenn dieses Feld zur Einstellung eines Wertes verwendet wird, sollte es sich genauso verhalten wie die Einstellung von NANO_OF_SECOND, wobei der Wert mit 1.000.000 multipliziert wird.

Wir können also einfach 0 für unsere Nanosekunden in der Factory-Methode angeben und dann die With-Methode verwenden, um eine ZonedDateTime zu erstellen, die alle ursprünglichen Werte sowie die Millisekunden enthält.

Wenn man sich unser Endergebnis ansieht, sieht es so aus, als hätten wir nur eine einzige Codezeile geändert. Das zeigt nicht wirklich den Aufwand, der mit der Erforschung einer einzigen Migration verbunden war!

‍

Erstellen Sie ein Rezept, um schneller und einfacher zu migrieren

Sensei bietet uns die Möglichkeit, diese hart erarbeiteten Informationen mit anderen Entwicklern zu teilen. Durch die Erstellung eines Rezepts, in dem all diese Anforderungen erfasst sind, können die Benutzer von Sensei diese Migration mit einem Mausklick durchführen.

Ein Sensei Rezept besteht aus 3 Hauptteilen:

• Metadaten
• Suche
• AvailableFixes

Schauen wir uns ein Sensei Rezept an (kann auch als YAML-Rezept betrachtet werden), das uns hilft, diesen Aufruf in sein java.time-Äquivalent zu migrieren.

DateTime foo = new DateTime(year, monthOfYear, dayOfMonth, hourOfDay, minuteOfHour, secondOfMinute, millisOfSecond);

Abschnitt Metadaten

Der Abschnitt Metadaten enthält Informationen über das Rezept und seine Verwendung.

Bereich Suche

Der Suchabschnitt eines Sensei Rezepts gibt an, auf welche Code-Elemente dieses Rezept angewendet werden soll.

search:
instanceCreation:
args:
1:
type: int
2:
type: int
3:
type: int
4:
type: int
5:
type: int
6:
type: int
7:
type: int
argCount: 7
type: org.joda.time.DateTime

‍

In diesem Suchabschnitt sehen wir, dass wir es sind:

• Suche nach einer instanceCreation, d.h. einer Verwendung eines Constructors. Hinweis: Es sind viele andere Suchziele verfügbar
• Der Konstruktor sollte 7 Argumente haben, dies wird durch die Eigenschaft argCount angegeben
• args 1-7 sollten vom Typ int sein
• Wir suchen nach Konstruktoren vom Typ org.joda.time.DateTime

‍

Abschnitt Verfügbare Korrekturen

Im Abschnitt availableFixes können eine oder mehrere Korrekturen angegeben werden, die auf das entsprechende Codeelement angewendet werden können. Jede Korrektur kann mehrere Aktionen haben, und in unserem Fall haben wir eine einzige Korrektur, die 2 Aktionen ausführt.

‍

• Der Name des Fixes wird dem Benutzer im Menü "Quickfixes" angezeigt und beschreibt, was passiert, wenn der Benutzer diesen Quickfix anwendet
• Die Liste der Aktionen zeigt, welche Aktionen durch diesen Quickfix ausgeführt werden
• Die Rewrite-Aktion schreibt das Code-Element unter Verwendung einer Mustache-Vorlage um. Dabei können Variablen und Funktionen zur Ersetzung von Zeichenketten verwendet werden.
• Die Aktion modifyAssignedVariable prüft, ob dieser Konstruktor verwendet wird, um einer Variablen einen Wert zuzuweisen. Wenn dies der Fall ist, ändert diese Aktion die Variable so, dass sie als der Typ deklariert wird, der durch type

‍

Verwendung des Rezepts für die Codeumwandlung

Wenn unser Rezept geschrieben und aktiviert ist, scannt es unseren Code und markiert die Segmente, auf die es angewendet werden kann.

Im folgenden Screenshot sehen wir, dass der Zielkonstruktor mit Sensei markiert wurde. Wenn wir den Mauszeiger über den markierten Konstruktor bewegen, sehen wir die Recipe shortDescription und die Quickfix-Option Migrate to java.time.ZonedDateTime

‍

Nachdem wir den Quickfix Migrate to java.time.ZonedDateTime ausgewählt haben, wird der Code entsprechend den im Rezept angegebenen Aktionen umgewandelt.

‍

Eine einmalige Migration und einheitliche Kodierungspraktiken in allen Teams - mit Sensei

Wie wir an unserem obigen Beispiel sehen, kann die Migration einer einzigen Codezeile hart erarbeitetes Wissen beinhalten. Sensei kann dieses Wissen in umsetzbare Rezepte oder Kochbücher umwandeln, die innerhalb von Teams geteilt werden können. Sie können einen einmaligen Migrations-Sprint planen oder den Ansatz verfolgen, inkrementelle, sofortige Transformationen zu java.time durchzuführen, sobald Sie auf Joda-Time-Code stoßen. Sie können Rezepte aktivieren/deaktivieren, um Migrationen in logischen Phasen oder Schritten durchzuführen und sogar den Umfang der von Sensei gescannten Dateien zu erweitern oder zu reduzieren - die Flexibilität, die Code-Migrationen weniger schmerzhaft macht.

Die Migration von Bibliotheken ist nur ein Beispiel für die vielen Möglichkeiten, die Sensei bietet, um Ihre Projekte zu standardisieren. Sie können immer nach Anti-Patterns oder bestimmten manuellen Code-Transformationen Ausschau halten, auf die Sie häufig in Pull-Requests oder beim Coding selbst stoßen. Wenn Sie über eine Reihe von Codierungsrichtlinien verfügen, die von den Entwicklern häufig übersehen werden, können Sie diese Richtlinien in Rezepte umwandeln, so dass die Entwickler bewährte Codeumwandlungen sicher anwenden können.

Wenn Sie Fragen haben, würden wir uns freuen, von Ihnen zu hören! Treten Sie uns auf Slack bei: sensei-scw.slack.com

Wenn Sie in irgendeiner Weise mit Software zu tun haben, sei es als Entwickler, QA, technischer Leiter oder AppSec-Experte, gehört Sicherheit zu Ihrem Job. Es ist die Aufgabe des Sicherheitsteams, auf Software-Schwachstellen hinzuweisen, und es ist die Aufgabe des Entwicklers, sein Bestes zu tun, um Code zu schreiben, der von vornherein keine Schwachstellen aufweist. Aber um diese Aufgaben so effizient und effektiv wie möglich zu erledigen, ist es wichtig, dass alle Parteien gemeinsam gegen Sicherheitsbedrohungen vorgehen, angefangen beim Code, auf dem Ihre Anwendungen laufen. 

Das effektive Erlernen von sicherem Kodieren und das Behalten dieses Wissens kann jedoch den Anschein erwecken, dass es von Natur aus schwierig ist. Mit den richtigen Tools muss das nicht sein. Es ist jedoch nicht immer einfach, Interessengruppen und Vorgesetzte davon zu überzeugen, in die richtige Art von Schulung zu investieren. Zu oft werden Schulungen mit dem alleinigen Ziel ausgewählt, die Einhaltung von Vorschriften zu erfüllen, und oft sind sie für die tägliche Arbeit der Entwickler irrelevant. Aber was wäre, wenn Entwickler in Echtzeit etwas über Sicherheit lernen könnten, und zwar in der Sprache:Framework, in der sie täglich arbeiten, und dabei auch noch Spaß haben? Und um das Ganze abzurunden? Ihr Unternehmen hält gleichzeitig die Industriestandards ein.

Wir halten Ihnen den Rücken frei. Hier finden Sie einige Strategien, mit denen Sie Ihre Kollegen, Führungskräfte und Entscheidungsträger in Ihrem Unternehmen für ein auf Entwickler ausgerichtetes Schulungsprogramm zur Sicherheitsprogrammierung gewinnen können.   

Die Vermeidung von Software-Schwachstellen von Anfang an spart unermessliche Mengen an Zeit und Geld

Verbringen Sie zu viel Zeit damit, Sicherheitsprobleme zu finden, zu melden oder zu beheben? Da sind Sie nicht allein. 

Stellen Sie sich das folgende Szenario vor: Sobald AppSec eine Schwachstelle findet und an die Entwicklung meldet, nehmen die Entwickler an einer entsprechenden Schulung teil und lernen nicht nur, wie sie diese Schwachstelle beheben können, sondern auch, wie sie denselben Fehler in Zukunft vermeiden können. Was glauben Sie, was das Ergebnis wäre? Der Entwickler würde sich höchstwahrscheinlich an die Lektion erinnern, weil sie relevant ist, und es wäre weniger wahrscheinlich, dass er denselben Fehler noch einmal macht. Wenn Sie also in einem Sicherheitsteam arbeiten, ist es für einen Entwickler weniger wahrscheinlich, dass er diese Schwachstelle unwissentlich noch einmal schafft, und es ist weniger wahrscheinlich, dass derselbe Entwickler noch einmal zurückgehen und den Fehler beheben muss.

Sehen Sie sich dieses Video unseres Kunden Contrast Security an und erfahren Sie, wie leistungsfähig Echtzeit-Schulungen für sein Entwicklungsteam sind.

Wenn alle Entwickler regelmäßig an Schulungen zu sicherem Code teilnehmen würden und ihnen die Tools zur Verfügung stünden, mit denen sie sich in Echtzeit über Sicherheitsprobleme informieren könnten, wäre die Zeit, die sie für die Entwicklung großartiger Software und die Arbeit an Sicherheitsprogrammen zurückgewinnen, unermesslich. Klingt nach einem ziemlich guten Argument für Ihr Unternehmen, in ein solches Tool zu investieren, oder? 

Wenn Sie ein großartiges Tool gefunden haben, mit dem Sie sich im Bereich der Sicherheit weiterbilden möchten, etwas wie (hust) Secure Code Warriorist dies ein gutes Argument, um es dem CISO oder CTO Ihres Unternehmens vorzustellen. 

Befähigte Entwickler liefern bessere Ergebnisse und sind zufriedener

Zeit und Geld sind natürlich sehr wichtig für Ihr Managementteam, aber auch Ihre Arbeitszufriedenheit. Zufriedene Mitarbeiter liefern bessere Ergebnisse, bleiben länger an ihrem Arbeitsplatz und tragen zu einem positiven Arbeitsumfeld bei. Deshalb sind berufliche Weiterbildung und Training eine Investition und keine Kosten. Und wenn diese Schulungen auch noch Spaß machen und etwas Relevantes vermitteln? Dann ist das ein goldenes Ticket zum Erfolg. 

Die gute Nachricht ist, dass Entwickler in der Regel hoch motiviert sind, Sicherheit zu lernen, weil sie wissen, wie wichtig sie für ihre Arbeit ist. In einer Studie mit Evans Data Corporation haben wir Entwickler aus der ganzen Welt befragt und herausgefunden, dass Entwickler Sicherheit lernen wollen, weil: 

1. Es erhöht die Produktivität und Effizienz
2. Sie sind neugierig und persönlich daran interessiert, mehr darüber zu erfahren.
3. Sie wollen die Probleme vermeiden, die mit unsicherem Code verbunden sind
4. Sie wissen, dass sie die Möglichkeit zum beruflichen Aufstieg bietet.
5. Es ist eine effizientere Nutzung der Humanressourcen
   

(Laden Sie das vollständige Whitepaper hierherunter .)

Das Problem ist nur, dass die meisten Schulungen zur sicheren Kodierung sie im Stich lassen. Es ist nicht relevant für ihre tägliche Arbeit und, seien wir ehrlich, es ist schlichtweg langweilig. Das sind Eigenschaften, die in der Regel keine guten Ergebnisse liefern, wenn es darum geht, Informationen zu behalten und tatsächlich zu lernen. Wenn die learning platform jedoch auf die Entwickler ausgerichtet ist, Spaß macht, sie anspricht und für ihre Arbeit relevant ist, kann sie echte Ergebnisse liefern und Menschen dazu bringen, sicheren Code schreiben zu wollen. Und warum sollte Ihr Chef, sei es ein Entwicklungsleiter oder ein CISO oder CTO, nicht wollen, dass die Entwickler an sicherer Programmierung interessiert sind und die entsprechenden Fähigkeiten besitzen?

Sicherheitsverständnis macht insgesamt bessere Ingenieure 

Wenn Ingenieure verstehen, wie Software für Angriffe anfällig sein kann, können sie ihre Arbeit in diesem Sinne erledigen. Je mehr jemand versteht, was schief gehen kann, desto mehr arbeitet er mit einem präventiven Ansatz.

Und nicht nur das: Bei minderwertigem Code ist es wahrscheinlicher, dass er Software-Schwachstellen enthält, und es ist für einen Entwickler leichter, unwissentlich eine Schwachstelle in diesen Code einzubauen. Und warum? Weil ein großer Teil der Arbeit darin besteht, Code zu lesen und zu ändern. Wenn dieser Code schlecht organisiert ist und eine schlechte Logik verwendet, dauert es länger, diese Aufgaben auszuführen, und es wird einfacher, etwas zu ändern und versehentlich einen kritischen Sicherheitsfehler einzubringen.

Wenn man weiß, was Sicherheit bedeutet und wie man Probleme vermeiden kann, macht man sich auch mehr Gedanken über die Gesamtqualität des Codes und darüber, wie man ihn so schreiben kann, dass ein Fehler nicht einfach aus Versehen eingeschleust werden kann. Sicherheitsschulungen sind eine Win-Win-Situation. Die Entwickler lernen nicht nur etwas über sichere Programmierung, sondern werden in der Zwischenzeit auch zu besseren Ingenieuren. 

In Zahlen liegt die Kraft

Eine weitere gute Taktik, um Ihre Führungskräfte für die Einführung eines sicheren Codes learning platform zu gewinnen, besteht darin, Ihre Kollegen mit ins Boot zu holen. Je mehr Entwickler daran interessiert sind, ihre Sicherheitskenntnisse zu verbessern, desto leichter wird es sein, die Geschäftsleitung oder den Vorstand davon zu überzeugen, in dieses Thema zu investieren.

Wie kann man das also machen? In Anbetracht der Tatsache, dass die meisten Entwickler die Notwendigkeit verstehen, sich in Sachen Sicherheit zu verbessern und lernen wollen, sollte das nicht allzu schwer sein. Sie können sie auch einen Blick auf diesen secure code warrior developer showcase werfen lassen, um einen kleinen Einblick in unser Produkt zu bekommen und ihre Fähigkeiten im sicheren Programmieren zu testen. Sobald sie die Auswirkungen von unsicherem Code sehen und erfahren, dass das Lernen über Sicherheit Spaß machen kann, werden sie sich ermutigt fühlen, mehr zu lernen.

Sobald Sie das richtige Tool ausgewählt haben, können Sie Ihre Entwickler mit einem gesunden Wettbewerb anspornen. Starten Sie Ihr Schulungsprogramm mit einem tournament. 

Sehen Sie sich an, wie Nelnet mit tournaments wirklich kreativ wurde, um eine Sicherheitskultur in ihrem Unternehmen aufzubauen.

Kontinuierliche Sicherheitsschulungen fördern eine wünschenswerte Unternehmenskultur

Schulungen müssen nicht langweilig sein, und das sollten sie auch nicht. Wir wissen, dass Vorträge teuer und schwer zu organisieren sind - vor allem bei verteilten Teams - und dass Sie wahrscheinlich nicht viel davon mitnehmen werden. Aber Unternehmen bieten Entwicklern immer noch Schulungen zur sicheren Programmierung an, die kaum mehr bewirken, als jedes Jahr ein Kästchen für die Einhaltung der Vorschriften anzukreuzen. Es reicht nicht mehr aus, einfach den Status quo beizubehalten. Es ist an der Zeit, dass Entwicklungsleiter und AppSec gemeinsam an der Implementierung eines Schulungsinstruments arbeiten, das kontinuierliches und ansprechendes Lernen fördert. Und das beginnt damit, die Entscheidungsträger zu überzeugen.

Kontinuierliche, praxisnahe Schulungen sind aus mehreren Gründen notwendig. Die Bedrohungen für die Cybersicherheit entwickeln sich ständig weiter, daher ist es nur natürlich, dass auch die Schulungen zur Bekämpfung dieser Bedrohungen kontinuierlich stattfinden. Und nicht nur das: Wie bereits erwähnt, ist es viel wahrscheinlicher, dass wir das Gelernte behalten, wenn wir in Echtzeit lernen. Eine sicherheitsorientierte Programmierung ist schwer umzusetzen, denn es ist unrealistisch, von einem Entwickler zu erwarten, dass er sich an etwas erinnert, das er vielleicht vor fast einem Jahr in einer Diashow gelernt hat. Wenn sie aber lernen, wie man eine bestimmte Software-Schwachstelle in dem Moment vermeidet, in dem sie ihnen gemeldet wird, und gleichzeitig das Gefühl haben, ein Spiel zu spielen, ist das eine ganz andere Sache. 

Sobald eine praxisnahe, relevante Schulung durchgeführt wird, wird die Sicherheit Teil der Unternehmenskultur und wird nicht mehr als nachträglicher Gedanke behandelt. Sie wird vom Beginn des Softwareentwicklungszyklus an in den Entwicklungsprozess integriert. 

Worauf warten Sie also noch? Machen Sie sich auf den Weg, die Sicherheit in Ihrem Unternehmen zu verbessern und wichtige Unternehmens- und Kundendaten zu schützen. Holen Sie Ihre Entwickler und Chefs ins Boot, um die sichere Programmierung in Ihrem Unternehmen auf die nächste Stufe zu heben. Hören Sie ein für alle Mal auf, immer wieder dieselben Schwachstellen zu erleben, indem Sie von Anfang an an die Sicherheit denken. 

Brauchen Sie mehr Ressourcen?

Laden Sie das vollständige "Convince your CISO / CTO kit" herunter

Anfang Oktober veröffentlichte Apache die Version 2.4.49, um eine Schwachstelle in Bezug auf Path Traversal und Remote Code Execution zu beheben, und anschließend die Version 2.4.50, um die Tatsache zu beheben, dass die Behebung der Schwachstelle in 2.4.49 unvollständig war. Vielleicht haben Sie in den sozialen Medien gelesen, wie wichtig es ist, auf die neueste Version zu aktualisieren, um diese Risiken zu vermeiden, da Apache nach einigen Schätzungen 25 % des Internets betreibt. Aber worum geht es hier eigentlich? Wie groß ist das Risiko hier?

Warum probieren Sie es nicht selbst aus? 

Wir haben eine Mission erstellt, um die Risiken in einer realen Umgebung zu demonstrieren, und haben sie für jeden zum Ausprobieren freigegeben. In dieser Mission zeigen wir Ihnen, wie sich die Path Traversal Vulnerability auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie unten, um direkt einzusteigen, oder lesen Sie weiter, um mehr über die Sicherheitslücke im Detail zu erfahren.

Über die Path Traversal-Schwachstelle 

Die Schwachstelle wurde in der Version 2.4.49 eingeführt(aufgrund einer Änderung der URL-Normalisierungsfunktion), wo eine neue Pfadnormalisierungsfunktion eingeführt wurde. Leider konnte sie URL-kodierte Pfade nicht korrekt normalisieren. Dadurch ist es möglich, einen Path-Traversal-Angriff durchzuführen, wenn die folgende Konfiguration nicht vorhanden ist:

Und wenn mod_cgi aktiviert ist, kann dies auch zu einer Schwachstelle bei der Remote-Code-Ausführung führen. Aber lassen Sie uns zuerst die URL-Kodierung untersuchen, um besser zu verstehen, was schief gelaufen ist.

URL-Kodierung

Die Schwachstelle ist im Wesentlichen auf die fehlende Berücksichtigung von URLs mit URL-Kodierung zurückzuführen. Die neu eingeführte Pfadnormalisierungsfunktion behandelte Fälle, in denen Punkte URL-kodiert waren, nicht vollständig. 

Denken Sie daran, dass Sie, um einen Pfadüberquerungsangriff durchzuführen, mit der Sequenz ../ überqueren müssen. Die Normalisierungsfunktion ist jedoch intelligent genug, um dies zu entfernen. Was können Sie also tun? Sie können die URL mit einem .(Punkt) bis zu %2e kodieren und eine Sequenz wie .%2e/ verwenden. Das würde in vielen Fällen gegen Apache 2.4.40 funktionieren. Sie können aber auch einen Schritt weiter gehen und es doppelt kodieren. Die URL-kodierte Version von .%2e/ ist .%252e/. Damit konnte die versuchte Normalisierung durch Apache umgangen werden.

Aber es gibt einen Haken

Wenn jemand versuchen würde, diese Schwachstelle direkt in seinem Browser auszunutzen, wäre er nicht erfolgreich. Das liegt daran, dass Browser auch versuchen, URLs, die an Server gesendet werden, zu normalisieren. Das bedeutet, dass sogar unsere doppelt kodierte Sequenz entfernt wird. Das bedeutet auch, dass wir nicht einfach einen Browser verwenden können, um dies zu demonstrieren.

Sie können cURL verwenden, um dies zu demonstrieren, indem Sie das Flag --path-as-is verwenden, das verhindert, dass die URL vor dem Senden normalisiert wird:

Prävention und Schadensbegrenzung

Um das Problem vollständig zu vermeiden, ist es wichtig, die neuesten Patches von Apache zu verwenden. Insbesondere sollten Sie mindestens ein Upgrade auf 2.4.51 durchführen. Es ist jedoch eine gute Praxis, regelmäßig zu aktualisieren, um auf dem neuesten Stand zu bleiben.

Um dieses Problem abzuschwächen, wenn Sie 2.4.49 verwenden, stellen Sie sicher, dass Sie Folgendes in Ihre Apache-Konfiguration aufgenommen haben:

Und um Remote Code Execution zu verhindern, deaktivieren Sie mod_cgi , wenn Sie es nicht verwenden.

Erleben Sie die Auswirkungen selbst

Möchten Sie herausfinden, was genau passiert ist und es selbst ausprobieren? 

‍

Micha Martinez ist Cybersicherheitsanalytiker und Kameramann bei Nelnet, einem US-Konglomerat, das sich mit der Verwaltung und Rückzahlung von Studentenkrediten und Finanzdienstleistungen für die Bildung beschäftigt. Als er mit der Erstellung eines Schulungsprogramms für Entwickler zum Thema sicheres Coding beauftragt wurde, ging er kreative Wege, um sein Team einzubinden. Wir waren so beeindruckt davon, wie er sein Schulungsprogramm für sicheren Code durchführt, dass wir uns mit ihm zusammensetzten, um mehr zu erfahren. 

Die Quintessenz? 

Schaffen Sie eine Sicherheitskultur und fördern Sie Ihre internen Sicherheitschampions in Ihren Entwicklungsteams, damit sie "die Kraft des Guten" sind. 

"Indem wir uns auf sicheren Code konzentrieren, haben wir dazu beigetragen, das Unternehmen stärker und sicherer zu machen." 

Bei Nelnet haben Micha und sein Sicherheitsteam verstanden, wie wichtig es ist, von Anfang an sicheren Code zu entwickeln. Sie wollten dies auf eine ansprechende, relevante und lohnende Weise erreichen. Er entdeckte, dass durch die Identifizierung von Entwicklern mit starkem Interesse an sicherem Code und deren Förderung zu Sicherheits-Champions diese Champions zum Katalysator für eine Änderung der Denkweise in Bezug auf Sicherheitsschulungen als Ganzes wurden. Diese Personen betreuen ihre Kollegen, die mehr Hilfe benötigen, auf einer Peer-to-Peer-Ebene und werden zu Vorreitern bei der Umsetzung von Änderungen in der sicheren Codepraxis innerhalb der Organisation. 

Im Folgenden erzählt Micha, wie er und sein Team die Denkweise und die Kultur in Bezug auf die Sicherheitsprävention verändert haben, was ihr Unternehmen "stärker und sicherer" gemacht hat.

Es geht um das Recht zu prahlen... und um die Reduzierung von Schwachstellen

Micha führt kein gewöhnliches Sicherheitstrainingsprogramm durch. Er nutzt den Wettbewerb und seine filmischen Talente, um tournaments zu einem äußerst ansprechenden und erfolgreichen Programm zu machen. Die Entwickler erhalten hochrelevantes, praktisches Wissen, das zu einem sichereren Code führt. 

Auch das Unternehmen profitiert, da seine Produkte sicherer werden und ein höheres Maß an Schutz vor Software-Schwachstellen bieten. Das Erlernen von Softwaresicherheit muss keine typische und langweilige Lernerfahrung sein, bei der man nur ein Kästchen ankreuzt. Entwickler wünschen sich Schulungserfahrungen, die sie mitreißen und herausfordern und die für ihre tägliche Arbeit relevant sind. 

Micha erzählt, wie er das Training für sicheres Programmieren zum Vergnügen macht: tournaments mit physischen Meisterschaftsgürteln a la Wrestle Mania als Preis. Alles, was es braucht, ist ein kleiner, gesunder Wettbewerb, um die Sicherheit für sein Team ganz oben zu halten. 

Wer liebt es nicht, mit sich selbst zu prahlen? 

‍

Umfassen Sie eine Kultur, die auf sichere Programmierung ausgerichtet ist... das Tool ist nicht genug

Micha ließ uns mit einem letzten Gedanken darüber zurück, warum er Secure Code Warrior empfiehlt. Die Plattform war das Mittel, das ihn dazu brachte, eine präventive Kultur und proaktives Lernen zu schaffen. Es hat Zeit gekostet, das Schulungsprogramm aufzubauen und auch in die Entwickler zu investieren, die gut schulen und arbeiten. Es braucht eine transformative Kultur, um bei jedem Entwickler die Fähigkeiten zu entwickeln, einen präventiven Ansatz zur sicheren Programmierung zu verfolgen. 

Hier erfahren Sie mehr von Micha, warum eine Kultur der sicheren Programmierung den Unterschied ausmacht: Secure Code Warrior.

Secure Code Warrior bietet eine fesselnde und sichere Codierung learning platform für Entwickler. Interessiert an einer Demo? Buchen Sie unten eine. 

In dieser zunehmend chaotischen Welt gab es schon immer ein paar Konstanten, auf die man sich zuverlässig verlassen konnte: Die Sonne wird morgens aufgehen und abends wieder untergehen, Mario wird immer cooler sein als Sonic the Hedgehog, und Injektionsangriffe werden immer den ersten Platz auf der Liste des Open Web Application Security Project (OWASP) der zehn häufigsten und gefährlichsten Schwachstellen einnehmen, die Angreifer aktiv ausnutzen.

Nun, die Sonne wird morgen aufgehen, und Mario hat immer noch einen Vorsprung vor Sonic, aber Injektionsangriffe sind auf der berüchtigten OWASP-Liste, die 2021 aktualisiert wird, vom ersten Platz gefallen. Injektionsschwachstellen, eine der ältesten Angriffsformen, gibt es schon fast so lange wie Computernetzwerke. Die pauschale Schwachstelle ist für ein breites Spektrum von Angriffen verantwortlich, das von traditionellen SQL-Injektionen bis zu Exploits gegen Object Graph Navigation Libraries (OGNL) reicht. Sie umfasst sogar direkte Angriffe auf Server unter Verwendung von OS-Befehlsinjektionstechniken. Die Vielseitigkeit der Injektionsschwachstellen für Angreifer - ganz zu schweigen von der Anzahl der potenziell angreifbaren Stellen - hat dazu geführt, dass diese Kategorie seit vielen Jahren an der Spitze steht.

Aber der Injektionskönig ist gefallen. Lang lebe der König. 

Bedeutet das, dass wir das Problem der Injektionsschwachstellen endlich gelöst haben? Keineswegs. Es ist nicht weit von seiner Position als Sicherheitsfeind Nummer eins entfernt und nur auf Platz drei der OWASP-Liste abgerutscht. Es wäre ein Fehler, die anhaltende Gefahr von Injektionsangriffen zu unterschätzen, aber die Tatsache, dass eine andere Schwachstellenkategorie sie übertreffen konnte, ist bedeutsam, denn sie zeigt, wie weit verbreitet der neue OWASP-Platzhirsch tatsächlich ist, und warum Entwickler ihm in Zukunft große Aufmerksamkeit schenken müssen.

Das vielleicht Interessanteste ist jedoch, dass die OWASP Top 10 2021 eine deutliche Überarbeitung erfahren haben, mit brandneuen Kategorien, die ihr Debüt feiern: Unsicheres Design, Software- und Datenintegritätsfehler und ein Eintrag, der auf den Ergebnissen einer Community-Umfrage basiert: Server-Side Request Forgery. Dies deutet darauf hin, dass der Schwerpunkt zunehmend auf architektonischen Schwachstellen liegt und der Maßstab für die Softwaresicherheit nicht mehr nur auf Oberflächenfehlern beruht.

Kaputte Zugangskontrolle setzt sich die Krone auf (und zeigt einen Trend)

Die unzureichende Zugriffskontrolle hat sich vom fünften Platz der OWASP-Liste der zehn größten Schwachstellen bis auf den ersten Platz hochgearbeitet. Wie bei Injection und neuen Einträgen wie Insecure Design umfasst die Sicherheitslücke "Broken Access" ein breites Spektrum an Programmierfehlern, was zu ihrer zweifelhaften Popularität beiträgt, da sie zusammengenommen Schaden an mehreren Fronten verursachen können. Die Kategorie umfasst alle Fälle, in denen Zugriffskontrollrichtlinien verletzt werden können, so dass Benutzer außerhalb ihrer vorgesehenen Berechtigungen handeln können. 

Zu den von OWASP angeführten Beispielen für eine lückenhafte Zugriffskontrolle, die die Familie der Schwachstellen auf den ersten Platz heben, gehören solche, die es Angreifern ermöglichen, eine URL, den internen Status einer Anwendung oder einen Teil einer HTML-Seite zu ändern. Sie können es Benutzern auch ermöglichen, ihren primären Zugriffsschlüssel zu ändern, so dass eine Anwendung, Website oder API glaubt, sie seien jemand anderes, z. B. ein Administrator mit höheren Berechtigungen. Es gibt sogar Schwachstellen, bei denen Angreifer nicht auf die Änderung von Metadaten beschränkt sind, so dass sie Dinge wie JSON-Web-Token, Cookies oder Zugriffskontroll-Token ändern können.

Einmal ausgenutzt, kann diese Familie von Schwachstellen von Angreifern genutzt werden, um Datei- oder Objektautorisierungen zu umgehen, was ihnen ermöglicht, Daten zu stehlen oder sogar zerstörerische Funktionen auf Administratorebene wie das Löschen von Datenbanken durchzuführen. Dies macht eine unterbrochene Zugriffskontrolle nicht nur immer häufiger, sondern auch besonders gefährlich.

Es ist ziemlich überzeugend - und doch nicht überraschend -, dass Schwachstellen in der Authentifizierung und Zugangskontrolle für Angreifer zum fruchtbarsten Boden werden, den sie ausnutzen können. Der jüngste Data Breach Investigations Report von Verizon zeigt, dass Probleme bei der Zugangskontrolle in fast allen Branchen, insbesondere im IT- und Gesundheitswesen, weit verbreitet sind und dass bei satten 85 % aller Sicherheitsverletzungen ein menschliches Element eine Rolle spielt. Der Begriff "menschliches Element" umfasst Vorfälle wie Phishing-Angriffe, die kein technisches Problem darstellen, aber 3 % der Sicherheitsverletzungen betrafen ausnutzbare Schwachstellen und waren dem Bericht zufolge überwiegend ältere Schwachstellen und auf menschliches Versagen zurückzuführen, wie z. B. falsche Sicherheitskonfiguration.

Während diese altersschwachen Sicherheitsprobleme wie XSS und SQL-Injection den Entwicklern nach wie vor zu schaffen machen, wird zunehmend deutlich, dass das grundlegende Sicherheitsdesign versagt und architektonischen Schwachstellen Platz macht, die für Bedrohungsakteure sehr vorteilhaft sein können, vor allem wenn sie nicht behoben werden, nachdem die Sicherheitslücke in einer bestimmten Version einer Anwendung bekannt gemacht wurde. 

Das Problem ist, dass nur wenige Ingenieure eine Ausbildung und Kompetenzentwicklung erhalten, die über die Grundlagen hinausgeht, und noch weniger erhalten ihr Wissen und ihre praktische Anwendung über lokalisierte Fehler auf Code-Ebene hinaus, die in der Regel von den Entwicklern selbst verursacht werden.

Verhinderung von Fehlern, die Roboter selten finden

Die neu gruppierte Familie der Sicherheitslücken in der Zugangskontrolle ist ziemlich vielfältig. Auf unserem YouTube-Kanal und in unserem Blog finden Sie einige konkrete Beispiele für Schwachstellen in der Zugriffskontrolle und wie man sie beheben kann.

Ich denke jedoch, dass es wichtig ist, diese neue OWASP Top 10 zu feiern; sie ist in der Tat vielfältiger und umfasst ein breiteres Spektrum an Angriffsvektoren, darunter auch solche, die von Scannern nicht unbedingt erkannt werden. Für jede gefundene Schwachstelle auf Code-Ebene werden komplexere Architekturfehler von den meisten Sicherheitstechnologien unbemerkt bleiben, egal wie viele automatische Schutzschilde und Waffen im Arsenal vorhanden sind. Während der Löwenanteil der OWASP Top 10-Liste nach wie vor auf der Grundlage von Scandaten erstellt wird, zeigen die neuen Einträge, die unter anderem unsicheres Design und Datenintegritätsfehler abdecken, dass der Schulungshorizont für Entwickler schnell erweitert werden muss, um zu erreichen, was Roboter nicht können.

Einfach ausgedrückt: Sicherheitsscanner sind keine großartigen Bedrohungsmodellierer, aber ein Team von sicherheitskompetenten Entwicklern kann dem AppSec-Team unermesslich helfen, indem es seinen Sicherheits-IQ in Übereinstimmung mit den Best Practices und den Anforderungen des Unternehmens steigert. Dies muss in einem guten Sicherheitsprogramm berücksichtigt werden, wobei man sich darüber im Klaren sein muss, dass die OWASP Top 10 zwar eine hervorragende Grundlage darstellen, die Bedrohungslandschaft aber so schnelllebig ist (ganz zu schweigen von den Anforderungen interner Entwicklungsziele), dass es einen Plan geben muss, um die Weiterbildung der Entwickler im Bereich Sicherheit zu vertiefen und zu präzisieren. Andernfalls werden unweigerlich Gelegenheiten zur frühzeitigen Behebung von Sicherheitslücken verpasst und ein erfolgreicher, ganzheitlicher Ansatz zur präventiven, von Menschen geleiteten Cybersicherheit wird behindert.

‍

Wir sind bereit für die OWASP Top 10 2021, und das ist erst der Anfang! Bringen Sie Ihre Entwickler auf einen erweiterten Sicherheitsfähigkeiten noch heute.

Die Cyber-Bedrohungslandschaft wird von Tag zu Tag komplexer. Angreifer suchen ständig in Netzwerken nach anfälligen Anwendungen, Programmen und Cloud-Instanzen. Der neueste Schrei sind APIs, die dank ihrer oft laxen Sicherheitskontrollen als leichte Beute gelten. Sie sind so hartnäckig, dass neue Anwendungen manchmal innerhalb weniger Stunden nach der Bereitstellung kompromittiert und ausgenutzt werden können. Der Verizon 2021 Data Breach Investigations Report macht deutlich, dass die Bedrohungen für Unternehmen und Organisationen heute gefährlicher sind als je zuvor in der Geschichte.

Es wird immer deutlicher, dass die einzige Möglichkeit, die erstellte Software wirklich zu schützen, darin besteht, sicherzustellen, dass sie auf sicherem Code aufbaut. Mit anderen Worten: Der beste Weg, die Invasion der Bedrohungsakteure zu stoppen, besteht darin, ihnen von vornherein den Zugang zu Ihren Anwendungen zu verwehren. Wenn man erst einmal angefangen hat, diesen Krieg zu führen, liegen die meisten Vorteile auf der Seite der Angreifer.

Aus dieser Situation heraus entstanden zunächst die agile Entwicklung und DevOps und später die gesamte DevSecOps-Bewegung, bei der die Sicherheit eine gemeinsame Verantwortung aller am Prozess der Softwareerstellung von der Entwicklung bis zur Bereitstellung Beteiligten ist. Die Basis dieser Pyramide, und damit der wohl wichtigste Teil, sind jedoch die Entwickler. Während die meisten Entwickler ihren Teil dazu beitragen und sicheren Code schreiben wollen, unterstützen viele der Unternehmen, für die sie arbeiten, die Änderungen, die eine solch umfassende Verschiebung der Prioritäten erfordert, weniger.

Niederlage nach Plan

Viele Jahre lang wurde den Entwicklern gesagt, dass ihre Hauptaufgabe in ihren Unternehmen darin besteht, in einer schnelllebigen Umgebung, in der das Geschäft nie stillsteht und die Kunden nie schlafen, schnell Anwendungen zu entwickeln und bereitzustellen. Je schneller die Entwickler programmieren und je mehr Funktionen sie bereitstellen konnten, desto wertvoller wurden sie in ihren Leistungsbewertungen eingestuft.

Die Sicherheit war ein nachträglicher Gedanke, wenn sie überhaupt berücksichtigt wurde. Stattdessen wurde all dies den Teams für Anwendungssicherheit (AppSec) überlassen. AppSec-Teams waren bei den meisten Entwicklern unbeliebt, weil sie fertige Anwendungen oft zurück in die Entwicklung schickten, um Sicherheits-Patches anzuwenden oder Code umzuschreiben, um Schwachstellen zu beheben. Und jede Stunde, die ein Entwickler mit der Arbeit an einer bereits "fertigen" Anwendung verbrachte, war eine Stunde, die er nicht mit der Entwicklung neuer Anwendungen und Funktionen verbrachte, wodurch seine Leistung (und sein Wert in den Augen eines besonders strafenden Unternehmens) sank.

Und dann veränderte die Bedrohungslage die Bedeutung und Priorisierung der Sicherheit für die meisten Unternehmen. Laut dem jüngsten Bericht "Cost of a Data Breach Report" von IBM und dem Ponemon Institute kostet eine Verletzung der Cybersicherheit im Durchschnitt etwa 3,8 Millionen Dollar pro Vorfall, wobei dies kaum die Obergrenze darstellt. Allein ein Unternehmen erlitt nach einem Einbruch in sein Netzwerk Verluste in Höhe von 1,3 Milliarden Dollar. Die Unternehmen von heute wollen die Sicherheit, die DevSecOps bietet, belohnen aber leider nur langsam die Entwickler, die diesem Ruf folgen.

Den Entwicklungsteams einfach zu sagen, dass sie die Sicherheit berücksichtigen sollen, wird nicht funktionieren, vor allem, wenn sie immer noch Anreize allein aufgrund der Geschwindigkeit erhalten. In einem solchen System könnten Entwickler, die sich die Zeit nehmen, etwas über Sicherheit zu lernen und ihren Code zu sichern, tatsächlich bessere Leistungsbewertungen und lukrative Boni verlieren, die ihre weniger sicherheitsbewussten Kollegen weiterhin erhalten. Es ist fast so, als ob Unternehmen unwissentlich das System für ihre eigenen Sicherheitsmängel manipulieren, und das hängt mit ihrer Wahrnehmung des Entwicklungsteams zusammen. Wenn sie sie nicht als die Sicherheitsfront sehen, ist es sehr unwahrscheinlich, dass ein praktikabler Plan zur Nutzung ihrer Arbeitskräfte zum Tragen kommt.

Und dabei ist noch nicht einmal die mangelnde Ausbildung berücksichtigt. Einige sehr fähige Entwickler haben jahrzehntelange Erfahrung im Programmieren, aber sehr wenig, wenn es um Sicherheit geht... schließlich wurde das nie von ihnen verlangt. Wenn ein Unternehmen seinen qualifizierten Programmierern kein gutes Schulungsprogramm anbietet, kann es kaum erwarten, dass seine Entwickler plötzlich neue Fähigkeiten erwerben und diese sinnvoll einsetzen, um Sicherheitslücken aktiv zu verringern.

Belohnung von Entwicklern für gute Sicherheitspraktiken

Die gute Nachricht ist, dass die überwältigende Mehrheit der Entwickler ihren Job macht, weil sie ihn sowohl herausfordernd als auch lohnend finden, und weil sie den Respekt genießen, den ihre Position mit sich bringt. Michael Shpilt, der sein Leben lang professionell programmiert hat, schrieb kürzlich über all die Dinge, die ihn und seine Programmierkollegen bei ihrer Entwicklungsarbeit motivieren. Ja, er zählt die monetäre Vergütung zu diesen Anreizen, aber sie steht überraschend weit unten auf der Liste. Stattdessen gibt er dem Nervenkitzel bei der Entwicklung von etwas Neuem, dem Erlernen neuer Fähigkeiten und der Genugtuung darüber, dass seine Arbeit anderen direkt zugute kommt, den Vorrang. Er spricht auch davon, dass er sich in seinem Unternehmen und in der Gemeinschaft wertgeschätzt fühlen möchte. Kurz gesagt, Entwickler sind wie viele andere gute Menschen, die stolz auf ihre Arbeit sind.

Entwickler wie Shpilt und andere wollen nicht, dass Bedrohungsakteure ihren Code kompromittieren und ihn nutzen, um ihrem Unternehmen oder den Nutzern, denen sie eigentlich helfen wollen, zu schaden. Aber sie können ihre Prioritäten nicht plötzlich ohne Unterstützung auf die Sicherheit verlagern. Andernfalls ist es fast so, als ob das System gegen sie arbeiten würde.

Um Entwicklungsteams bei der Verbesserung ihrer Cybersicherheitsfähigkeiten zu unterstützen, müssen ihnen zunächst die erforderlichen Fähigkeiten vermittelt werden. Der Einsatz von gerüstgestütztem Lernen und Tools wie Just-in-Time (JiT)-Schulungen kann diesen Prozess sehr viel weniger schmerzhaft machen und hilft dabei, auf vorhandenem Wissen im richtigen Kontext aufzubauen. 

Das Prinzip von JiT besteht darin, dass Entwicklern das richtige Wissen zum richtigen Zeitpunkt zur Verfügung gestellt wird. Wenn ein JiT-Entwicklerschulungstool beispielsweise feststellt, dass ein Programmierer einen unsicheren Code erstellt oder versehentlich eine Schwachstelle in seine Anwendung einführt, kann es den Entwickler aktivieren und ihm zeigen, wie er das Problem beheben kann und wie er einen sichereren Code schreiben kann, um dieselbe Funktion in Zukunft auszuführen.

Wenn die Verpflichtung zur Weiterbildung besteht, müssen die alten Methoden der Bewertung von Entwicklern allein auf der Grundlage der Geschwindigkeit abgeschafft werden. Stattdessen sollten Programmierer auf der Grundlage ihrer Fähigkeit, sicheren Code zu erstellen, belohnt werden, wobei die besten Entwickler zu Sicherheits-Champions werden, die dem Rest des Teams helfen, ihre Fähigkeiten zu verbessern. Und diese Champions müssen sowohl mit Firmenprestige als auch mit einer finanziellen Entschädigung belohnt werden. Es ist auch wichtig, daran zu denken, dass Entwickler in der Regel keine positiven Erfahrungen mit Sicherheit gemacht haben. Wenn man sie mit positiven, unterhaltsamen Lernmethoden und Anreizen, die ihre Interessen ansprechen, motiviert, werden sie ihr Wissen behalten und den Wunsch verspüren, ihre Fähigkeiten weiter auszubauen.

Unternehmen können die Geschwindigkeit der Programmierung immer noch als Teil der Bewertung eines Entwicklers einbeziehen, aber mit der Erwartung, dass die Entwicklung sicherer Anwendungen etwas mehr Zeit in Anspruch nimmt, insbesondere wenn die Programmierer diese neuen Fähigkeiten erlernen.

DevSecOps kann die ultimative Verteidigung gegen die dunklen Künste einer zunehmend gefährlichen Bedrohungslandschaft sein. Vergessen Sie nur nicht, dass die Meister dieser neuen Welt, die Entwickler, die ständig neuen Code erstellen, respektiert und für ihre Arbeit entlohnt werden müssen.

Möchten Sie Ihre Sicherheitskenntnisse im Vergleich zu anderen Entwicklern auf der ganzen Welt auf die Probe stellen? Besuchen Sie Secure Code Warrior’s Devlympics 2021und du könntest einen großen Preis in unserem globalen tournaments gewinnen!