Einblicke in sichere Codes

In dieser zunehmend chaotischen Welt gab es schon immer ein paar Konstanten, auf die sich die Menschen zuverlässig verlassen konnten: Die Sonne geht morgens auf und abends wieder unter, 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 Top Ten am häufigsten und gefährliche Sicherheitslücken, die Angreifer aktiv ausnutzen.

Nun, morgen geht die Sonne auf und Mario hat immer noch einen „Eins-Up“ auf Sonic, aber Injection-Angriffe sind von der Nummer eins auf der berüchtigten OWASP-Liste gefallen, die 2021 aktualisiert wurde. Eine der ältesten Formen von Angriffen, Sicherheitslücken durch Injektion gibt es fast so lange wie Computernetzwerke. Diese generelle Sicherheitslücke ist für eine Vielzahl von Angriffen verantwortlich, darunter auch alle herkömmlichen Angriffe SQL-Injektionen zu Exploits, die gegen Object Graph Navigation Libraries (OGNL) gestartet wurden. Es beinhaltet sogar direkte Angriffe auf Server, die Betriebssystem-Befehlsinjektionstechniken. Die Vielseitigkeit von Injection-Schwachstellen für Angreifer — ganz zu schweigen von der Anzahl der Stellen, die potenziell angegriffen werden könnten — hat diese Kategorie viele Jahre lang an der Spitze gehalten.

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

Bedeutet das, dass wir das Injection-Schwachstellenproblem endlich gelöst haben? Keine Chance. Es fiel nicht weit von seiner Position als Sicherheitsfeind Nummer eins ab, nur auf Nummer drei der OWASP-Liste. Es wäre ein Fehler, die anhaltenden Gefahren von Injection-Angriffen zu unterschätzen, aber die Tatsache, dass eine andere Schwachstellenkategorie sie übertreffen konnte, ist bedeutsam, denn sie zeigt, wie weit verbreitet der neue OWASP-Topdog tatsächlich ist und warum Entwickler ihm in Zukunft besondere Aufmerksamkeit schenken müssen.

Das vielleicht Interessanteste ist jedoch, dass die OWASP Top 10 2021 eine grundlegende Überarbeitung widerspiegeln. Brandneue Kategorien feiern ihr Debüt: Unsicheres Design, Software- und Datenintegritätsfehler, und ein Eintrag, der auf den Ergebnissen einer Community-Umfrage basiert: Serverside Request Forgery. Diese deuten darauf hin, dass der Schwerpunkt zunehmend auf architektonischen Sicherheitslücken liegt und nicht nur oberflächliche Fehler als Maßstab für Softwaresicherheit gelten.

Eine kaputte Zutrittskontrolle setzt sich durch (und zeigt einen Trend auf)

Broken Access Control stieg vom fünften Platz auf der Liste der zehn häufigsten Sicherheitslücken von OWASP rasant auf den aktuellen Platz Nummer eins. Wie bei Injection und neuen Einträgen wie Unsecure Design umfasst auch die Sicherheitslücke bei Broken Access eine Vielzahl von Codierungsfehlern, was zu ihrer zweifelhaften Beliebtheit beiträgt, da sie gemeinsam Schäden an mehreren Fronten verursachen. Diese Kategorie umfasst alle Fälle, in denen gegen Richtlinien zur Zugriffskontrolle verstoßen werden kann, sodass Benutzer außerhalb ihrer beabsichtigten Rechte handeln können.

Einige Beispiele für fehlerhafte Zugriffskontrollen, die von OWASP angeführt wurden, um die Familie der Sicherheitslücken an die Spitze zu heben, umfassen solche, die es Angreifern ermöglichen, eine URL, den internen Anwendungsstatus oder einen Teil einer HTML-Seite zu ändern. Sie können Benutzern auch ermöglichen, ihren primären Zugriffsschlüssel so zu ändern, dass eine Anwendung, Site oder API glaubt, dass sie jemand anderes sind, z. B. ein Administrator mit höheren Rechten. Es beinhaltet sogar Sicherheitslücken, bei denen Angreifer nicht daran gehindert werden, Metadaten zu ändern, sodass sie Dinge wie JSON-Web-Tokens, Cookies oder Zugriffskontroll-Token ändern können.

Einmal ausgenutzt, kann diese Familie von Sicherheitslücken von Angreifern genutzt werden, um Datei oder Objekt umgehen Autorisierungen ermöglichen es ihnen, Daten zu stehlen oder sogar zerstörerische Funktionen auf Administratorebene wie das Löschen von Datenbanken auszuführen. Das macht kaputte Zugriffskontrollen nicht nur immer häufiger, sondern auch äußerst gefährlich.

Es ist ziemlich überzeugend — aber nicht überraschend —, dass Sicherheitslücken in den Bereichen Authentifizierung und Zugriffskontrolle immer mehr zum fruchtbarsten Nährboden für Angreifer werden. Die neueste Version von Verizon Bericht zur Untersuchung von Datenschutzverletzungen zeigt, dass Probleme mit der Zugangskontrolle in fast allen Branchen, insbesondere in der IT und im Gesundheitswesen, weit verbreitet sind und dass satte 85% aller Verstöße menschliches Element betrafen. Inzwischen umfasst die „menschliche Komponente“ Vorfälle wie Phishing-Angriffe, bei denen es sich nicht um ein technisches Problem handelt, aber 3% der Sicherheitslücken betrafen ausnutzbare Sicherheitslücken. Dem Bericht zufolge handelte es sich dabei überwiegend um ältere Sicherheitslücken, die von Menschen verursacht wurden, wie z. B. eine Fehlkonfiguration der Sicherheit.

Während diese heruntergekommenen Sicherheitslücken wie XSS und SQL Injection Entwickler weiterhin verunsichern, hat sich zunehmend herausgestellt, dass das zentrale Sicherheitsdesign versagt, was architektonischen Sicherheitslücken Platz macht, die für einen Bedrohungsakteur sehr vorteilhaft sein können, insbesondere wenn sie nicht gepatcht werden, nachdem die Sicherheitslücke in einer bestimmten Version einer Anwendung veröffentlicht wurde.

Das Problem ist, dass nur wenige Ingenieure Schulungen und Fähigkeiten erhalten, die über die Grundlagen hinausgehen, und noch weniger erhalten wirklich eine Erweiterung ihres Wissens und ihrer praktischen Anwendung über lokalisierte Bugs auf Codeebene hinaus, die normalerweise von Entwicklern eingeführt werden.

Vermeidung von Bugs, die Roboter selten finden

Die neu gruppierte Familie der Sicherheitslücken bei der defekten Zugriffskontrolle ist ziemlich vielfältig. Einige konkrete Beispiele für defekte Zugriffskontrollen und wie Sie diese verhindern können, finden Sie unter unser YouTube-Kanal und unsere Blog.

Ich denke jedoch, dass es wichtig ist, diese neuen OWASP Top 10 zu feiern. Sie sind in der Tat vielfältiger und umfassen ein breiteres Spektrum an Angriffsvektoren, einschließlich solcher, die Scanner nicht unbedingt erkennen. Bei jeder entdeckten Schwachstelle auf Codeebene werden komplexere architektonische Mängel von den meisten Sicherheitstechnikern unbemerkt bleiben, unabhängig davon, wie viele automatische Schilde und Waffen sich im Arsenal befinden. Zwar basiert der Löwenanteil der OWASP-Top-10-Liste immer noch auf der Grundlage von Scandaten, doch neue Beiträge, die sich unter anderem mit unsicherem Design und Datenintegritätsfehlern befassen, zeigen, dass der Schulungshorizont für Entwickler schnell erweitert werden muss, um das zu erreichen, was Roboter nicht können.

Einfach ausgedrückt: Sicherheitsscanner sind keine großartigen Bedrohungsmodellierer, aber ein Team von sicherheitserfahrenen Entwicklern kann dem AppSec-Team unermesslich helfen, indem es seinen Sicherheits-IQ entsprechend den Best Practices und den Anforderungen des Unternehmens erhöht. Dies muss in einem guten Sicherheitsprogramm berücksichtigt werden, wobei zu berücksichtigen ist, dass die OWASP Top 10 zwar eine hervorragende Ausgangsbasis sind, die Bedrohungslandschaft jedoch so schnelllebig ist (ganz zu schweigen von den Anforderungen der internen Entwicklungsziele), dass ein Plan zur Vertiefung und Spezifizierung der Entwickler im Bereich Sicherheit vorliegen muss. Geschieht dies nicht, werden unweigerlich Gelegenheiten verpasst, frühzeitig Abhilfe zu schaffen, und ein erfolgreiches ganzheitliches Konzept für präventive, von Menschen geleitete Cybersicherheit wird behindert.

‍

Wir sind bereit für OWASP Top 10 2021, und das ist erst der Anfang! Starten Sie Ihre Entwickler auf einem Qualifizierung im Bereich Sicherheit heute.

Eine Version dieses Artikels erschien in Dunkle Lektüre. Es wurde hier aktualisiert und syndiziert.

‍

Seit dem ersten Hype um die neuesten, kulturerschütternden KI-Tools haben Entwickler und Programmierer sie gleichermaßen verwendet, um Code auf Knopfdruck zu generieren. Sicherheitsexperten wiesen schnell darauf hin, dass der erzeugte Code in vielen Fällen schlechte Qualität und anfälligund könnte in den Händen von Personen mit geringem Sicherheitsbewusstsein zu einer Lawine unsicherer Apps und Webentwicklung führen, die ahnungslose Verbraucher trifft.

Und dann gibt es diejenigen, die genug Sicherheitswissen haben, um es für, naja, das Böse zu nutzen. Für jede überwältigende KI-Leistung scheint es einen Gegenschlag zu geben, bei dem dieselbe Technologie eingesetzt wird schändliche Zwecke. Phishing, gefälschte Betrugsvideos, Malware-Erstellung, allgemeine Script-Kiddie-Spielereien... diese störenden Aktivitäten sind viel schneller und mit niedrigeren Eintrittsbarrieren realisierbar.

Es gibt sicherlich eine Menge Clickbait, die dieses Tool als revolutionär anpreisen oder sich zumindest durchsetzen, wenn es mit „durchschnittlichen“ menschlichen Fähigkeiten verglichen wird. Es scheint zwar unvermeidlich, dass KI-Technologie im LLM-Stil die Art und Weise verändern wird, wie wir an viele Aspekte der Arbeit herangehen — nicht nur an die Softwareentwicklung —, aber wir müssen einen Schritt zurücktreten und die Risiken berücksichtigen, die hinter den Schlagzeilen liegen.

Und als Begleiter beim Programmieren sind seine Fehler vielleicht das „menschlichste“ Merkmal.

Schlechte Codierungsmuster dominieren seine bevorzugten Lösungen

Da ChatGPT auf jahrzehntelangen Code- und Wissensdatenbanken trainiert wurde, ist es keine Überraschung, dass auch ChatGPT trotz all seiner Wunder und Geheimnisse unter den gleichen häufigen Fallstricken leidet, mit denen Menschen beim Navigieren im Code konfrontiert sind. Schlechte Codierungsmuster sind die erste Wahl, und es bedarf immer noch eines sicherheitsbewussten Treibers, um sichere Codierungsbeispiele zu generieren, indem er die richtigen Fragen stellt und die richtige schnelle technische Umsetzung liefert.

Selbst dann gibt es keine Garantie dafür, dass die angegebenen Codeschnipsel aus Sicherheitsgründen korrekt und funktionsfähig sind; die Technologie neigt sogar zu Halluzinationen Erstellung nicht existierender Bibliotheken wenn er gebeten wird, bestimmte JSON-Operationen auszuführen, wie von Mike Shema entdeckt. Dies könnte zu einer „Halluzination“ der Bedrohungsakteure führen, die nur allzu gerne Malware entwickeln würden, getarnt als die fabrizierte Bibliothek, die mit vollem Vertrauen von ChatGPT empfohlen wird.

Letztlich müssen wir uns der Realität stellen, dass wir im Allgemeinen nicht erwartet haben, dass Entwickler ausreichend sicherheitsbewusst sind, und dass wir sie als Branche auch nicht angemessen darauf vorbereitet haben, sicheren Code als Standardzustand zu schreiben. Dies wird sich in der enormen Menge an Trainingsdaten zeigen, die in ChatGPT eingespeist werden, und wir können zumindest anfänglich mit ähnlich schwachen Sicherheitsergebnissen rechnen. Entwickler müssten in der Lage sein, die Sicherheitslücken zu identifizieren und sie entweder selbst zu beheben oder bessere Eingabeaufforderungen zu entwerfen, um ein robusteres Ergebnis zu erzielen.

Der erste groß angelegte Nutzerstudie Die Untersuchung, wie Benutzer mit einem KI-Programmierassistenten interagieren, um eine Vielzahl von sicherheitsrelevanten Funktionen zu lösen — durchgeführt von Forschern der Stanford University — unterstützt diese Annahme, wobei eine Beobachtung zu dem Schluss kommt:

“Wir beobachteten, dass Teilnehmer, die Zugriff auf den KI-Assistenten hatten, bei den meisten Programmieraufgaben mit größerer Wahrscheinlichkeit Sicherheitslücken einführten, ihre unsicheren Antworten jedoch auch eher als sicher einstuften als diejenigen in unserer Kontrollgruppe..“

Dies spricht für ein gewisses Maß an Vertrauen in die Ergebnisse von KI-Codierungstools, da sie Code produzieren, der immer inhärent sicher ist, obwohl dies in Wirklichkeit nicht der Fall ist.

Angesichts dessen und der unvermeidlichen KI-gestützten Bedrohungen, die unsere Zukunft durchdringen werden, müssen Entwickler heute mehr denn je ihre Sicherheitsfähigkeiten verbessern und die Messlatte für die Codequalität höher legen, unabhängig von ihrer Herkunft.

Der Weg zu einer Datenschutzverletzung ist mit guten Vorsätzen gepflastert

Es sollte nicht überraschen, dass KI-Programmierbegleiter beliebt sind, zumal Entwickler mit zunehmender Verantwortung und immer engeren Fristen konfrontiert sind und die Ambitionen der Innovation eines Unternehmens auf ihren Schultern ruhen. Doch selbst mit den besten Absichten führt ein Mangel an umsetzbarem Sicherheitsbewusstsein beim Einsatz von KI zum Programmieren unweigerlich zu eklatanten Sicherheitsproblemen. Alle Entwickler mit KI/ML-Tools werden mehr Code generieren, und das Ausmaß des Sicherheitsrisikos hängt von ihrem Qualifikationsniveau ab. Unternehmen müssen sich darüber im Klaren sein, dass ungeschulte Mitarbeiter sicherlich schneller Code generieren, aber auch die Geschwindigkeit, mit der sie technische Sicherheitsschulden eingehen, erhöhen werden.

Sogar unser vorläufiger Test (April 2023) mit ChatGPT hat ergeben, dass es zu sehr grundlegenden Fehlern kommen wird, die verheerende Folgen haben könnten. Als wir es baten, eine Login-Routine in PHP mithilfe einer MySQL-Datenbank zu erstellen, wurde schnell funktionaler Code generiert. Es speicherte jedoch standardmäßig Passwörter im Klartext in einer Datenbank, speicherte die Anmeldeinformationen für die Datenbankverbindung im Code und verwendete ein Codierungsmuster, das zu einer SQL-Injektion führen konnte (obwohl es die Eingabeparameter bis zu einem gewissen Grad filterte und Datenbankfehler ausspuckte). Alles Anfängerfehler, egal in welcher Hinsicht:
‍

‍
Durch weitere Eingabeaufforderungen wurde sichergestellt, dass die Fehler behoben wurden, aber für die Kurskorrektur sind umfangreiche Sicherheitskenntnisse erforderlich. Ein unkontrollierter und weit verbreiteter Einsatz dieser Tools ist nicht besser, als Nachwuchsentwickler für Ihre Projekte zu gewinnen. Und wenn dieser Code sensible Infrastrukturen aufbaut oder personenbezogene Daten verarbeitet, haben wir es mit einer tickenden Zeitbombe zu tun.

Natürlich gehen wir davon aus, dass sich die KI/ML-Fähigkeiten verbessern werden, genau wie junge Entwickler ihre Fähigkeiten im Laufe der Zeit zweifellos verbessern werden. In einem Jahr wird es vielleicht nicht mehr so offensichtliche und einfache Sicherheitsfehler machen. Dies wird jedoch dazu führen, dass das Sicherheitswissen, das erforderlich ist, um die schwerwiegenderen, versteckten, nicht trivialen Sicherheitsfehler aufzuspüren, die immer noch zu verursachen drohen, drastisch erweitert werden.

Wir sind nach wie vor schlecht darauf vorbereitet, Sicherheitslücken zu finden und zu beheben, und KI vergrößert die Lücke

Zwar ist zu diesem Zeitpunkt seit vielen Jahren viel von einem „Linksruck“ die Rede, doch Tatsache ist, dass in den meisten Unternehmen in der Entwicklungskohorte ein erheblicher Mangel an praktischem Sicherheitswissen besteht, und wir müssen härter daran arbeiten, ihnen die richtigen Tools und Schulungen zur Verfügung zu stellen, die ihnen auf ihrem Weg helfen.

So wie es aussieht, sind wir nicht auf die Sicherheitslücken vorbereitet, an die wir gewöhnt sind, ganz zu schweigen von den neuen KI-bedingten Problemen wie Prompt Injection und Halluzination Squatting, die völlig neue Angriffsvektoren darstellen, die wie ein Lauffeuer abheben werden. KI-Programmierwerkzeuge stellen zwar die Zukunft des Programmierwaffenarsenals von Entwicklern dar, aber die Ausbildung zum sicheren Umgang mit diesen Produktivitätswaffen muss jetzt erfolgen.

‍

Im Leben ist Kommunikation im Allgemeinen eine großartige Sache. Es gibt keinen schnelleren Weg, um zu einer Einigung zu kommen, etwas Neues zu lernen oder eine Beziehung aufzubauen. Im Softwarebereich dienen APIs einem Kommunikationszweck, der es Anwendungen ermöglicht, miteinander zu kommunizieren, wodurch Funktionen und Benutzerfreundlichkeit verbessert werden. Diese Konnektivität führt oft zu einer umfassenderen Erfahrung, die Endbenutzer lieben und die sie in ihrem täglichen Leben zunehmend von der Software erwarten.

Wie im wirklichen Leben ist es jedoch ein großes Problem, wenn sie zu viel reden. Experian hat dies kürzlich auf die harte Tour herausgefunden, als eine ihrer APIs — die von einem Drittanbieter verwendet wird — möglicherweise durchgesickert die Kreditwürdigkeit von... nun ja, fast jedem amerikanischen Staatsbürger.

Das Problem wurde schnell gepatcht, aber es bleibt die Frage offen, ob diese Sicherheitslücke wirklich beseitigt wurde. Wenn ein Anbieter betroffen war, stehen die Chancen gut, dass es auch andere waren, und es besteht die Möglichkeit, dass es sich um einen systemischer Bug, was jeden betrifft, der diese unsichere API nutzt.

API-Sicherheit ist ein Thema, das den meisten Sicherheitsexperten nicht fern ist, und wir müssen uns mit dem Wissen ausstatten, um dagegen vorzugehen.

Jeder verwegene Geek kann eine schlechte API-Authentifizierung umgehen

Ein Merkmal vieler Datenlecks, Sicherheitslücken und Sicherheitsvorfälle ist, dass es selten eines Masterminds bedarf, um sie zu erreichen. Für komplexe, heimtückische und schädigende Angriffe, wie wir sie bei SolarWinds gesehen haben, müssen Teams von Cyberkriminellen ausgeführt werden, und sie sind eher die Ausnahme als die Regel.

Wenn eine API mit schwacher Authentifizierung erstellt wird, ist es ziemlich einfach, sie auszunutzen. Bill Demirkapi, der Sicherheitsforscher, der den API-Bug von Experian entdeckte, stellte fest, dass ohne Authentifizierung darauf zugegriffen werden kann. Durch Eingabe von 00/00/0000 in das Feld für das Geburtsdatum erhielt er Zugriff auf die Kreditwürdigkeit einer Person, wobei nur öffentlich zugängliche Informationen wie ein Name und die zugehörige Postanschrift verwendet wurden. Obwohl dies nicht gemeldet wurde, besteht sicherlich die Möglichkeit, dass diese Aufzeichnungen gelöscht und als kreditbezogener (und daher wertvoller) Datendump kontextualisiert werden.

Saubere und funktionale Authentifizierungsprozesse sollten vorhanden sein, egal wie klein der Anwendungsfall ist. Eine Chatterbox-API, die nicht ordnungsgemäß gesichert ist und möglicherweise den Zugriff auf mehrere Systeme eröffnet, ist eine Gefahr.

Broken Authentication ist Nummer zwei auf der Die 10 besten APIs von OWASP Liste der Sicherheitslücken. Lesen Sie hier mehr darüber, wie du diesen Bug vermeiden und deine Fähigkeiten auf unserer Plattform testen kannst, sobald du mit dem Füttern deines Gehirns fertig bist.

Schlechte API-Sicherheitskontrollen sind ein weit verbreitetes Problem, das einen kulturellen Wandel erfordert

Es ist nicht fair, mit dem Finger ausschließlich auf Organisationen wie Experian zu zeigen, aber der Mangel an Nuancen und Sorgfalt bei der Sicherheitskontrolle, der in dieser speziellen API-Exposition zum Ausdruck kommt, ist kein gutes Zeichen für die vielen Unternehmen da draußen, die APIs als Teil ihrer IT-Systeme und Endpunkte verwenden.

Im Allgemeinen haben wir noch viel mehr zu tun, um API-Schwachstellen nicht nur zu finden und zu beheben, sondern sie auch als Teil der Angriffsfläche zu verstehen, die wir schützen sollen. Der Überblick über APIs — und wie sie erstellt wurden — ist ein großes Problem und sollte als Teil der bewährten Sicherheitsmethoden verlangt werden. Selbst ein Unternehmen mit den strengsten Sicherheitsmaßnahmen kann durch eine API, die veröffentlicht wird und außerhalb der Sicherheitskontrollen des Unternehmens funktioniert, zunichte gemacht werden. Es ist wichtiger denn je, sich zu fragen, woher eine API stammt und wer sie letztlich verwaltet (handelt es sich um einen Drittanbieter? Wie streng sind sie in Bezug auf die Sicherheit?) , und auf welche Informationen es zugreift.

Injection-Schwachstellen sind nach wie vor ein Hindernis für jeden CISO.

API-Sicherheit mag wie ein relativ neues Modul erscheinen, das in ein Sicherheitsprogramm aufgenommen werden kann, aber es kann durch einige (sehr) alte Tricks ausgenutzt werden, die wir von einfacher alter Websoftware gewohnt sind.

EIN kürzlich veröffentlichter Angriff auf Accellion enthüllte, dass Angriffe mit verketteter SQL-Injektion und Ausführung von Betriebssystembefehlen es den Bedrohungsakteuren ermöglichten, APIs zu manipulieren und eine beträchtliche Menge sensibler Daten, einschließlich Sozialversicherungsnummern, zu extrahieren. Sie stellten fest, dass die Angreifer über umfassende Kenntnisse der FTA-Software von Accellion verfügen mussten, um den Überfall durchzuführen, was durch umfangreiches Reverse Engineering möglich gewesen wäre.

Da sich der Verstoß im Dezember 2020 und Januar 2021 ereignete, hatten die Diebe genügend Zeit, um Schaden anzurichten. Weitere Entdeckungen im Februar 2021 deckten eine gespeicherte XSS-Sicherheitslücke auf. Forensische Analysen ergaben, dass nur ein API-Endpunkt, der Benutzereingaben unsachgemäß bereinigt hatte, es ermöglichte, ein Argument einzufügen, wenn der admin.pl Drehbuch.

Bei über 3000 Kunden, darunter viele renommierte Bildungseinrichtungen, könnte dieser Verstoß weitreichend sein. Leider wurden diese Exploits durch die Ausnutzung gängiger Sicherheitslücken ermöglicht, von denen viele von einem sicherheitsbewussten Entwickler vor der Produktion auf Codeebene hätten behoben werden können. Wie wir immer wieder sehen, reicht ein kleines Fenster, das offen gelassen wird, um große Probleme zu verursachen. Und eine Kultur der von Menschen geleiteten Cyberabwehr muss Teil der Strategie zur Lösung eines sehr menschlichen Problems sein.

Möchten Sie Ihre API-Sicherheitsfähigkeiten jetzt testen in Java-Spring-API, Kotlin Spring API, C# (.NET) -Web-API und mehr? Probiere einige API-Herausforderungen auf unserer Lernplattform aus (sieh dir alle Sprachen:Frameworks über das Drop-down-Menü an):
‍

‍

Seien Sie ein produktiverer Java-Entwickler

Mit 9 Millionen Entwicklern weltweit* gehört Java (Oracle Corporation) zu den beliebtesten Programmiersprachen der Welt. Viele Anwendungsframeworks wurden auf Java aufgebaut, da es sich um eine sehr vielseitige Sprache handelt, mit der Programme auf vielen verschiedenen Geräten ausgeführt werden können, die Java Runtime Environment (JRE) unterstützen — eine Umgebung, in der alle Java-Programme ausgeführt werden. Die von Entwicklern geleiteten Communitys sind sehr aktiv und die umfassende Unterstützung, die neuen Programmierern zur Verfügung steht, trägt zu ihrer stetig wachsenden Beliebtheit bei.

Da es Java schon lange gibt, haben die Communities Jahre damit verbracht, Standards, Tools und Codierungsmuster zu entwickeln und häufige Fehler zu beheben, mit denen Entwickler immer wieder konfrontiert sind. Alle diese von der Community geleiteten Initiativen haben ein gemeinsames Ziel: Entwickler dabei zu unterstützen, bei der Entwicklung von Anwendungen mit Java so produktiv wie möglich zu sein. Wenn es jedoch darum geht, die besten Praktiken oder Muster im Anwendungscode anzuwenden, liegt die Verantwortung beim Entwickler. Die Durchsetzung guter Praktiken ist sehr unterschiedlich und macht es daher schwierig, einen Standardansatz für eine Programmierpraxis zu verfolgen, wenn die Meinungen innerhalb der Gemeinschaften sehr unterschiedlich sind. Die Entwickler greifen auf Hilfe in Online-Communities zurück, die Ihnen manchmal versehentlich unsichere Lösungen für Ihre Codierungsprobleme bieten können.

Um Entwicklern bei der Implementierung sicherer Lösungen für häufig auftretende Java-Codierungsprobleme zu helfen, haben wir Sensei entwickelt — ein IntelliJ-Plugin zur Korrektur fehlerhafter Codierungsmuster gemäß den von Ihnen oder Ihrer Organisation definierten Rezepten (oder Regeln) in einer professionellen Umgebung. Sensei ermöglicht es Entwicklern, häufige Java-Fehler (Fallstricke) mit einem einzigen Klick zu identifizieren und zu korrigieren.

Lesen Sie weiter, um zu erfahren, wie Sensei die Produktivität von Entwicklern steigert, indem er einige häufig auftretende Java-Codierungsfehler behebt.

Ein wiederkehrender Fehler, der Entwickler frustriert

Ein Beispiel für diese häufigen Fehler ist die falsche Gleichheitsprüfung von Wrapper-Werten. Werte von Grundkörpern in Boxen sollten mit der Equals-Methode verglichen werden, statt mit dem Referenzvergleichsoperator (= =), um unerwartete Ergebnisse zu vermeiden.

Beispielsweise verhält sich die Verwendung des Referenzvergleichsoperators für Integer-Werte im Bereich von -128 bis 127 (normalerweise) genauso wie die Methode equals. Wenn wir jedoch denselben Vergleich mit Werten außerhalb dieses Bereichs durchführen, unterscheiden sich die Ergebnisse. Dies liegt daran, dass Java einen konstanten Pool für den genannten Bereich von Integer-Werten beibehält. Die Verwendung der Equals-Methode führt immer zu den erwarteten Ergebnissen und ist daher die richtige Methode zum Vergleichen.

In diesem Beispiel verwenden wir fälschlicherweise den Operator (==), um die Gleichheit zu überprüfen.

Was zu der folgenden Ausgabe führt:

wahr

falsch

falsch

wahr

Der richtige Weg zum Vergleichen ist die Equals-Methode.

Und dann wäre die Ausgabe:

wahr

falsch

wahr

falsch

Diese bekannte bewährte Methode gibt es schon seit geraumer Zeit und dennoch wird sie oft falsch in Legacy-Code implementiert, der darauf wartet, zum ungünstigsten Zeitpunkt seinen hässlichen Kopf zu erheben. Deshalb haben wir Rezepte (oder Regeln) erstellt, die helfen, solche unerwünschten Codierungsmuster lokal zu identifizieren und mithilfe von Sensei mit einem einzigen Klick eine Korrektur vorzunehmen.

Sensei ist ein hochgradig anpassbares IDE-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 Fähigkeit, eigenen Code zu erstellen. Mit Sensei können Entwickler fehlerhafte Codemuster während der Eingabe korrigieren, sodass sie Qualitätscode schneller bereitstellen und ihn letztendlich auf konsistente und standardisierte Weise für alle Teams und Projekte schreiben können.

Wie Sensei solche häufigen Java-Probleme behebt

Da Sensei es dir ermöglicht, deine eigenen Rezepte zu kreieren, haben wir ein Rezept erstellt, um den oben genannten Fehler zu korrigieren.

In diesem Beispiel wollen wir herausfinden, wo wir den Vergleichsoperator (==) im primitiven Box-Typ verwenden.

Ein Sensei-Rezept sieht so aus (in YAML):

Das oben Genannte kann während der Eingabe nach dem wiederkehrenden fehlerhaften Muster oder der gesamten Datei, dem konfigurierten Bereich und sogar der gesamten Codebasis suchen. Sobald das Muster gefunden wurde, besteht der nächste natürliche Schritt darin, es sofort korrigieren zu können, ohne online suchen zu müssen. Mit Sensei können Sie Korrekturen erstellen, mit denen Sie Code wie angegeben hinzufügen/bearbeiten/löschen können. Sie können sogar mehrere Fixes bereitstellen, wenn Sie dies für richtig halten, sodass Entwickler den für sie am besten geeigneten Fix auswählen können.

In unserem Beispiel wollen wir den Vergleich mit der Methode equals anstelle des Operators (==) neu schreiben.

Ein verfügbarer Fix wird wie folgt beschrieben:

So funktioniert's:

Einfache Implementierung von Standard-Codierungsrichtlinien

Das Java Gotchas Cookbook enthält 22 Rezepte, mit denen Sie häufige Fehler vermeiden und Ihren Code sauber und sicher halten können. Es erkennt die falsche oder unsichere Verwendung verschiedener Funktionen und APIs der Java-Sprache, z. B. Objektgleichheit, Ausnahmebehandlung, reguläre Ausdrücke und Sammlungen. Wenn Sie Sensei und dieses Kochbuch verwenden, können Sie von Anfang an besseren Code schreiben und sogar Ihre eigenen Rezepte erstellen, die zu Ihrem einzigartigen Team, Projekt oder Ihrer Organisation passen.

Dies ist nur ein Beispiel für die vielen Möglichkeiten, wie Sensei zur Standardisierung Ihrer Projekte eingesetzt werden kann. Du kannst immer nach Anti-Patterns oder bestimmten manuellen Codetransformationen Ausschau halten, auf die du häufig in Pull-Requests stößt oder wenn du selbst codest. Wenn du eine Reihe von Codierungsrichtlinien hast, die von Entwicklern oft übersehen werden, könntest du die Richtlinien in Rezepte umwandeln, sodass Entwickler genehmigte Codetransformationen mit Zuversicht anwenden können.

Installieren Sie Sensei jetzt und aktivieren Sie Java Gotchas Cookbook für ein produktives Entwicklungserlebnis. https://sensei.securecodewarrior.com/cookbooks/scw:java

*2021, Bundesstaat der Entwicklernation, https://www.developernation.net/developer-reports/de20

‍

Lass uns über Schulden sprechen

Fast jeder weiß jetzt, dass Cyberkriminalität zu einem wichtigen Problem unserer Weltwirtschaft geworden ist. Im Jahr 2022 beliefen sich die durchschnittlichen Kosten einer Datenschutzverletzung in den Vereinigten Staaten auf 9,44 Millionen US-Dollar, gegenüber 9,05 Millionen US-Dollar im Vorjahr. Es ist wichtig, die Kosten von unsicherem Code und die damit verbundenen technischen Schulden nicht zu ignorieren. Laut 2022 Konsortium für Informations- und Softwarequalität: Die Kosten schlechter Softwarequalität Berichten zufolge sind die Kosten für schlechte Softwarequalität in den USA auf 2,41 Billionen US-Dollar gestiegen, und die kumulierten technischen Softwareschulden sind auf 1,52 Billionen US-Dollar gestiegen.

Die steigenden Kosten für den Umgang mit unsicherem Code und die damit verbundenen technischen Schulden sind zum größten Hindernis für Änderungen an bestehenden Codebasen geworden — und machen sie somit anfällig für Ausnutzung und externe Bedrohungen. Der Stand der Softwaresicherheit steckt in einer existenziellen Krise. Wir wissen, dass wir unsere Sicherheitslage verbessern und die angehäuften technischen Schulden abbauen müssen, aber die Hindernisse sind enorm:

• In den USA gibt es schätzungsweise 300.000 unbesetzte Stellen als Softwareentwickler und IT-Bereich, mit einer prognostizierten Wachstumsrate von 15%
• Es wird prognostiziert, dass bis 2025 40% der IT-Budgets einfach für die Aufrechterhaltung der Technologieverschuldung ausgegeben werden
• Durchschnittlich 1/3 der wöchentlichen Arbeitsstunden von Entwicklern werden damit verbracht, technische Schulden zu beheben

Schnelle Lösungen sind riskant — und kosten langfristig mehr

Was sind technische Schulden und warum sind sie so wichtig? Technische Schulden häufen sich an, wenn Entscheidungsträger sich für eine kurzfristige Lösung eines Softwareentwicklungsproblems entscheiden — und nicht für eine umfassendere, langfristige Lösung. Dies ist mit erheblichen versteckten Kosten verbunden, die Unternehmen später zahlen müssen. Ähnlich wie bei einer voll ausgeschöpften Kreditkarte bestehen technische Schulden aus zwei Hauptkomponenten:

• Schulleiter - bezieht sich auf die Gesamtkosten für die Überarbeitung oder Reparatur von Software, sodass sie ein gewünschtes Maß an Wartbarkeit und Sicherheit erreicht.
• Zinsen - der zusätzliche Aufwand, den Entwickler für diese Änderungen aufwenden, um allein die technischen Probleme zu beheben und nicht um neue Funktionen. Jede Minute, die für einen nicht ganz richtigen Code aufgewendet wird, erhöht die Zinsen auf die Schulden.

Irgendwann kann es zu einem „technischen Bankrott“ kommen, wenn die Kosten für neue Funktionen, Bugfixes und Wartung das Projektbudget übersteigen, wodurch der Wert der Softwareanwendung erheblich sinkt.

Eine gewisse Anhäufung von Schulden ist jedoch, genau wie im Leben, normal und in den meisten Fällen etwas zu erwarten.

Idealerweise sollten alle Softwareentwickler Fehler so weit wie möglich reduzieren, bevor sie den Code versenden. Sie stehen jedoch vor einem schwierigen Kompromiss: Um wettbewerbsfähig zu sein, möchte ein Unternehmen möglicherweise Funktionen oder Produkte schnell und zu minimalen Kosten an Kunden liefern. Infolgedessen leidet die Qualität der Anwendung, da die KPIs der Entwickler auf der Geschwindigkeit der Bereitstellung und den anfänglichen Kosten für die Erstellung der Anwendung basieren. Was auf dem Bild fehlt, sind die akkumulierten Mängel und potenziellen Sicherheitslücken, die im Code verankert sind. Das macht ihn anfällig für spätere Bugs oder Sicherheitslücken oder, schlimmer noch, für die Ausnutzung durch böswillige Akteure.

Aber da liegt das Rätsel: Gibt es eine andere Möglichkeit, Produkte schnell zu versenden, ohne eine enorme Menge an technischen Schulden anzuhäufen?

Die Kosten für das Auffinden und Beheben von Mängeln und Sicherheitslücken sind die größten Einzelkosten im Lebenszyklus der Softwareentwicklung. Je früher im Entwicklungszyklus Probleme gefunden werden, desto kostengünstiger wird die gesamte Bereitstellung sein.

Technische Schulden können sich zu Sicherheitsschulden entwickeln

Viele Entwickler versuchen, diesen Kompromiss zu umgehen, indem sie Open-Source-Code verwenden, um schnell voranzukommen, und verwenden idealerweise eine bereits geprüfte Lösung. Sie verlassen sich jedoch stark auf Open-Source-Software birgt oft eigene Risiken:

• 82% der Open-Source-Komponenten wurden als veraltet befunden (d. h. ungepatcht oder nicht gut unterstützt)
• 75% der Codebasen enthielten Sicherheitslücken (gegenüber 60% im Jahr 2018), und 49% enthielten Sicherheitslücken mit hohem Risiko
• Pro Codebasis wurden durchschnittlich 82 Sicherheitslücken identifiziert

Dadurch wächst eine Untergruppe der technischen Schulden — die Sicherheitsschulden. Sicherheitsschulden sind die Anhäufung von Sicherheitslücken in einer Softwareanwendung, die es schwieriger oder sogar unmöglich machen, Daten und Systeme vor Angriffen zu schützen.

Eines der berüchtigtsten Beispiele ist Equifax, der Kreditauskunftriese im Jahr 2017 verletzt weil es versäumt hatte, eine bekannte Sicherheitslücke in Apache Struts, einem beliebten Open-Source-Framework für Webanwendungen, zu beheben. Der Patch war seit Monaten verfügbar, aber die Sicherheitsverletzung gefährdete die wichtigen persönlichen Daten von mehr als 147 Millionen Menschen.

Daher muss sicheren Codierungspraktiken mehr Aufmerksamkeit geschenkt werden, da viele Anwendungen nicht nur aufgrund ihrer technischen Schulden, sondern auch aufgrund der Dichte an Sicherheitslücken und Sicherheitslücken in der Anwendung selbst eine kritische Masse erreicht haben.

Dies kann zu enormen Verlusten führen, die entweder greifbar oder immateriell sein können:

Rufschädigung: Der Verlust des Kundenvertrauens kann sich in der Zukunft äußerst negativ auswirken. Dazu können Schäden an der Marke, Umsatzeinbußen und kostspielige Rechtsprobleme infolge eines Verstoßes gehören.

Auswirkungen auf Vorschriften und Compliance: Wenn eine Sicherheitsverletzung dazu führen kann, dass ein Unternehmen eine Frist und/oder vertragliche Verpflichtungen verpasst. Die Nichteinhaltung eines SLA kann ein Unternehmen in Schwierigkeiten mit den Aufsichtsbehörden bringen, was zu erheblichen Bußgeldern führen kann.

Sanierungskosten: Nach einem Ausfall oder Ausfall ist häufig zusätzliche Arbeit erforderlich, um den Produktivitätsverlust auszugleichen.

Vermeidung von technischen Schulden und Sicherheitsschulden im SDLC

Viele Unternehmen ändern bereits ihr Budget, um ein stärkeres Sicherheitsniveau zu schaffen. Letztes Jahr Google hat über einen Zeitraum von 5 Jahren 10 Milliarden US-Dollar bereitgestellt um ein Programm zur Stärkung der Cybersicherheit zu finanzieren. Die Biden-Regierung forderte ebenfalls 2,1 Milliarden US-Dollar im Ermessenshaushalt 2022 für die Agentur für Cybersicherheit und Infrastruktursicherheit (CISA).

Die Bereitstellung von mehr Ressourcen und Schulungen, um das berufliche Wachstum und das Wissen Ihrer Entwickler zu fördern, kann der erste Schritt zur Festlegung von Qualitätsstandards für den gesamten Code sein, der in die Produktion geliefert wird.

Die Kosten für das Auffinden und Beheben von Sicherheitslücken oder Defekten steigen exponentiell, je später im Softwareentwicklungszyklus sie gefunden und behoben werden. Und wie wir gesehen haben, verursachen Unternehmen bei so viel Zeit, die für die Behebung von technischen und Sicherheitsschulden aufgewendet wird, ihre eigenen Verluste, indem sie auf Innovationen verzichten und auf Zeit verzichten, die für neue Funktionen oder Produkte aufgewendet wird.

Im Jahr 2022 gab eine Mehrheit der Entwicklerteams an, dass DevOps oder DevSecOps die Methode der Wahl waren, und es ist keine Überraschung, warum. DevSecOps integriert Sicherheit in jeder Phase des Softwareentwicklungszyklus, um bessere und sicherere Anwendungen bereitzustellen. Sicherheits- und Entwicklungsteams arbeiten weiterhin isoliert und stehen unter Spannungen, aber es ist klar, dass sich dies ändern muss, um Unternehmen zum Erfolg zu verhelfen. DevOps ist Teil der Art und Weise, wie Unternehmen versuchen, Barrieren abzubauen und die Kultur neu zu gestalten. Das grundlegende Ziel von DevSecOps ist es, die Zusammenarbeit zwischen AppSec/Security und Entwicklern von Beginn des Softwareentwicklungszyklus an zu verbessern.

Die Einführung einer neuen Denkweise im Umgang mit technischen Schulden und Sicherheit muss keine monumentale Leistung sein. Die Etablierung einer proaktiven Denkweise durch Schulungen ist entscheidend, wenn man versucht, das Sicherheitsbewusstsein und die Fähigkeiten der Entwickler-Community eines Unternehmens zu verbessern. Eine solide Schulung für Entwickler im Bereich sicheres Programmieren stellt sicher, dass das Lernen kontinuierlich, interaktiv, relevant und kontextabhängig ist. Bei einem wirklich ganzheitlichen Ansatz muss berücksichtigt werden, was zur Förderung einer echten, von Entwicklern geleiteten Sicherheitskultur erforderlich ist. Dies erfordert möglicherweise eine Verlagerung des Schwerpunkts von den üblichen Methoden der Verwaltung und des Aufbaus von Entwicklerteams.

Es ist nicht einfach, einen Kulturwandel herbeizuführen, aber Secure Code Warrior hilft Ihnen dabei, Ihre Sicherheitsexperten zu identifizieren und Entwickler und Unternehmen mit den richtigen Fähigkeiten auszustatten, um die sich ständig ändernden Sicherheitsherausforderungen von heute zu bewältigen.

Die Einführung eines ansprechenden und skalierbaren Sicherheitscode-Programms ist aufgrund des langfristigen präventiven Sicherheitsansatzes und nicht des reaktiven Ansatzes der Vergangenheit eine lohnende Investition. Dies trägt letztlich dazu bei, die kostspieligen Risiken einer Sicherheitsverletzung zu mindern, Entwickler darin zu schulen, wie sie Sicherheitslücken schnell finden und beheben können, und ermöglicht eine agilere Art, sich auf die Produktentwicklung zu konzentrieren und die Markteinführung zu beschleunigen.

Ein Entwickler in seinem natürlichen Lebensraum wird oft in einem Zustand hoher Konzentration beobachtet und programmiert tolle Features innerhalb knapper Fristen. Das Erstellen von Funktionen ist oft unser Lieblingsteil der Arbeit, und in Wirklichkeit ist es das grundlegende Ergebnis des Softwareentwicklungszyklus (SDLC).

Wie wir bereits besprochen haben, räumen viele von uns Funktionen jedoch immer noch den besten Sicherheitsmethoden vor. Schließlich ist es in den meisten Organisationen so eingerichtet, dass es die Aufgabe von jemand anderem ist, und angemessene Sicherheitsschulungen für uns sind begrenzt. Penetrationstests und Tools zum Scannen statischer Analysen (besser bekannt als SAST) sind nur ein Teil des Gesamtprozesses zur Minderung von Sicherheitsrisiken. Sie arbeiten ziemlich unabhängig von dem, was wir tun... bis der Code natürlich für Hotfixes zu uns zurückkommt.

Und in diesem Moment denken viele Entwickler:“Hassen mich die Pentester?“.

Diese Interaktionen definieren oft ein Team, eine Kultur. Das Besorgniserregende ist, dass der Mangel an Kommunikation, Verständnis und allgemeiner Zusammenarbeit zu Spannungen geführt hat, zumindest auf der Seite des Entwicklers. Denken Sie darüber nach: Stellen Sie sich vor, Sie haben ein paar hundert Stunden damit verbracht, eine wunderbare Statue zu formen, und dann kommt jemand mit einem Hammer und fängt an, Teile davon abzuschlagen, nachdem er Ihnen gesagt hat, dass die Fundamente nicht mehr auf dem neuesten Stand sind. Das ist die wahrgenommene Dynamik zwischen einem Tester und einem Entwickler. Letztere lassen ihre Software-Lieblinge von einem Außenstehenden abschlachten, der den Prozess nicht mit ihnen durchgearbeitet hat. Stattdessen haben sie die Arbeitsbelastung erhöht und die Erfüllung des Versandcodes verzögert.

Da ich vor langer Zeit in den Sicherheitsbereich gezogen bin, kann ich beide Seiten der Geschichte sehen. Und nein, Pentester tun das nicht Hass Entwickler. Der Pentester ist aller Wahrscheinlichkeit nach überarbeitet und steht unter großem Druck. Daher nimmt ein ständiger Strom gängiger Sicherheitslücken, die auf Codeebene recht einfach behoben werden könnten, Zeit, Ressourcen und Headspace weg von den wirklich schwerwiegenden Problemen.

Ich habe Pentester immer als Eltern gesehen. Sie wollen, dass es dir gut geht, und wenn du es nicht tust... sind sie nicht sauer, nur enttäuscht.

Nachdem ich Ihnen dieses (vielleicht etwas unfaire) Bild in den Sinn gebracht habe, lassen Sie uns das etwas genauer untersuchen. Was hat dieses Weltbild unter Entwicklern verursacht?

„Natürlich werde ich defensiv; sie sagen mir, wie ich meinen Job zu machen habe!“

Niemand mag das Gefühl, einen schlechten Job gemacht zu haben oder dass jemand seine Arbeit nicht mag. Leider kann es sich für Entwickler wie ein Zeugnis anfühlen, wenn ihnen statische Analysen und Pentest-Ergebnisse vorliegen. Sie haben schlechte Noten bekommen, aber am Ende des Tages ihr Chefs beurteilen sie nach den Funktionen, die sie entwickelt haben, und nach dem Zeitpunkt, zu dem sie sie bereitgestellt haben, und nicht danach, ob die Software anfällige Elemente enthielt oder nicht.

Für den armen Pentester ist das ein Fall von „Schieß nicht auf den Boten“. Es ist nichts Persönliches - sie haben die Aufgabe, Fehler zu finden, und sie haben sie gefunden. Zugegeben, auf persönlicher Ebene sind einige Pentester vielleicht mürrischer als andere, aber sie sind nicht darauf aus, Entwicklungsteams zu kreuzigen (oder sollten es nicht sein). Es wäre für beide Teams viel einfacher, wenn sie mit den bewährten Sicherheitsmethoden auf derselben Wellenlänge wären. Und von Entwicklern wird nicht erwartet, dass sie perfekt sind. Realistischerweise ist das Testteam dazu da, sie davor zu schützen, anfälligen Code zu versenden.

„Sie haben mir gesagt, ich solle all diese kleineren Probleme lösen, wissen sie nicht, dass es höhere Prioritäten gibt? Und warum helfen sie mir nicht, sie zu beheben, wenn sie sich so sehr darum kümmern?“

Es ist wahr — die höchste Priorität eines Entwicklers wird immer die Entwicklung von Funktionen sein, und in dieser verrückten Welt der schnellen Digitalisierung muss dies schnell geschehen. Einige Programmierer haben zwar ein persönliches Interesse an Sicherheit und sicherer Codierung, aber die allgemeine Meinung ist, dass Sicherheit „das Problem eines anderen“ ist, was unweigerlich Pentester einschließt.

Bei den häufigsten Sicherheitslücken handelt es sich in der Tat um kleinere Probleme, die behoben werden müssen — sobald sie bekannt sind, sind die Fixes für Dinge wie Cross-Site Scripting (XSS) und SQL-Injection einfach auszuführen... das Problem ist, dass viele Entwickler nicht wissen, dass sie sie überhaupt einführen, und diese scheinbar geringfügigen Probleme sind das kleine Zeitfenster, das ein Angreifer nutzt, um verheerende Probleme für ein Unternehmen zu verursachen. Laut Akamai waren zwischen November 2017 und März 2019 SQL-Injection-Schwachstellen dafür verantwortlich 65% aller webbasierten Angriffsvektoren. Für eine Sicherheitslücke, für die seit mehr als zwanzig Jahren ein Fix bekannt ist, ist das eine ernüchternde Statistik.

Einige Pentest-Teams helfen bei der Behebung von Sicherheitslücken, aber andere melden die schlechten Nachrichten und erwarten, dass Entwickler Hotfixes durcharbeiten, auch wenn sie zu diesem Zeitpunkt zu einem anderen Projekt gewechselt sind. Und in einigen Fällen kann das Entwicklungsteam mit einem Bericht konfrontiert werden, der Fehler enthält, die sie nicht beheben können (oder sollten nicht erwartet werden) — sie müssen trotzdem Teil der Ergebnisse sein und auch hier nicht persönlich genommen werden.

Die „goldene Mitte“ dafür wären Pentester, Sicherheitspersonal und Entwicklungsmanager, die eher eine Mentorenrolle spielen, um sicherzustellen, dass das Team über das verfügt, was es an effektiven Schulungen und Tools benötigt, sodass einzelne Programmierer die besten Erfolgschancen haben und von Beginn des SDLC an sicher programmieren können. Beide Teams sollten sich wirklich auf halbem Weg treffen, um sicherzustellen, dass Sicherheit im Rahmen einer gesunden DevSecOps-Praxis von Anfang an berücksichtigt wird.

„Ich habe weitaus bessere Sicherheitskenntnisse, als mir zugeschrieben wird. Diese Berichte sind meistens falsch positiv oder nicht wichtig“.

Die statische Analyse ist ein Element des Sicherheitsprozesses im SDLC, und statische Analysescanning-Tools (SAST) spielen eine grundlegende Rolle. Und ja, falsch positive Ergebnisse sind ein Problem mit diesen und anderen Scannertypen (DAST/IAST/RAST). Es ist ein Ärgernis in einem ohnehin langsamen Prozess, der eine manuelle Codeüberprüfung erfordert und sowohl Entwickler als auch Pentester unter Druck setzt. Die Mitarbeiter von Pentesting haben sich Zeit genommen, um akribisch benutzerdefinierte Regeln aufzustellen, um ungenaue Messwerte zu vermeiden, und haben unternehmensspezifische Anleitungen gegeben. Dennoch rutschen einige falsche Messwerte durch und enden vor einem Entwickler, der sich den Kopf kratzt.

Dieser Prozess ist nicht perfekt, aber das andere Problem ist, dass es vielen Entwicklern an Wissen mangelt, um viele häufig auftretende Sicherheitslücken konsistent zu beheben. Da Sicherheitsschulungen in der Hochschulbildung selten sind und die Ausbildung am Arbeitsplatz in ihrer Effektivität unterschiedlich ist, liegt es auf der Hand, dass auch eine gewisse Selbstüberschätzung im Spiel sein kann (und das ist nicht ihre Schuld — wir als Branche müssen besser darin werden, sie mit dem auszustatten, was sie benötigen).

„Ich wusste nicht, dass diese Anwendung getestet werden sollte, aber jetzt bin ich bei den Korrekturaufgaben hängen geblieben“.

Manchmal gehen überarbeitete Ingenieure davon aus, dass Pentester nur in den Startlöchern stehen und darauf warten, dass der Moment kommt, um zuzuschlagen, indem sie eine Anwendung testen und dem Entwicklungsteam einen Strich durch die Rechnung machen. Sie testen zu viel, sie sind pingelig, sie schaffen zusätzliche Arbeit.

Das einzige Problem dabei ist, dass auch sie überarbeitet sind (noch mehr — der Fachkräftemangel im Bereich Cybersicherheit ist auf einem schlimmen Niveau und es wird immer schlimmer) und haben einfach nicht die Zeit, ohne Grund zu testen. Sie sind nicht die einzigen Entscheidungsträger bei der Priorisierung von Tests. Sie könnten von der Geschäftsleitung, einem Kunden, im Rahmen einer Sicherheitsüberprüfung angefordert oder sogar als Ergebnis eines Bug-Bounty-Programms festgestellt worden sein.

Für einen Entwickler ist es ärgerlich, von aktuellen Sprints zur Feature-Erstellung abgezogen zu werden, um an Sicherheitsupdates zu arbeiten — vor allem, wenn es nicht seine Arbeit ist. Vielleicht hat ein vorheriges Team das letzte Update durchgeführt, oder ein anderer Anbieter. Sicherheit ist jedoch jedermanns Problem. Das bedeutet nicht, dass jeder Entwickler die Verantwortung für Sicherheitslücken übernehmen muss, als ob er sie alle selbst gemacht hätte, aber sie müssen zur Partei kommen, um sicherzustellen, dass Sicherheit eine gemeinsame Verantwortung ist.

Wohin geht es von hier aus?

Manchmal reicht eine Änderung der Denkweise aus, um bei der Lösung eines Problems erhebliche Fortschritte zu erzielen. Wir haben über die eher frostige Reaktion eines Entwicklers auf weniger als günstige Pentest-Ergebnisse gesprochen, aber was wäre, wenn er daraus eine Herausforderung machen könnte? Vielleicht könnten sie sich den Pentester als einen freundlichen Konkurrenten vorstellen; jemanden, den sie in ihrem eigenen Spiel schlagen können. Schließlich wird ein sicherheitsbewusster Entwickler, der häufig auftretende Fehler beim Schreiben von Code beheben kann, seine Arbeit erheblich erschweren. Im Gegensatz dazu wird ein Entwickler, der sich nicht auf Sicherheit konzentriert, von seinen Pentester-Kollegen umfassend übertroffen, wenn sie ihre Software leicht kaputt machen können.

Pentester und Entwickler sind vielleicht nicht immer zu 100% harmonisch miteinander verbunden, aber ihre Beziehung kann erheblich verbessert werden, wenn ein Unternehmen Sicherheit als oberste Priorität betrachtet und Teams mit den richtigen Kenntnissen und Tools ausstattet, um erfolgreich zu sein — insbesondere Entwickler. Es kommt darauf an, ob eine unternehmensweite, positive Sicherheitskultur Priorität hat, und wenn wir den (derzeit) verlorenen Kampf gegen häufig auftretende Sicherheitslücken führen wollen, sollte dies unbedingt der Fall sein.

Migrating code (read: legacy code) is not fun. It takes an enormous amount of planning and effort to get it across the line. While not the most exciting or motivating piece of work for developers, it does require determination and the right experience to migrate legacy code to new library versions. Joda-Time to java.time is one such migration that requires meticulous planning and execution.

If your Java project started its life out prior to Java SE 8, and uses date/time processing, then it probably used Joda-Time - an excellent library and a de-facto standard to handle date and time functions prior to SE 8. If your project still uses Joda-Time but would like to migrate to java.time then read on.

The release of Java SE 8 included a new and improved standard Date and Time API commonly referred to as java.time (JSR-310). The Joda-Time project now recommends migrating to java.time (JSR-310).

While java.time (JSR-310) was heavily inspired by Joda-Time, it is not backwards compatible and concepts and terminologies have changed. Thats why migrating from Joda-Time to java.time requires careful attention on each and every line of code that you change. This can be time-consuming and would almost make you wish there was an easier and automated way to migrate.

There is a better way to migrate and we’ve created it using Sensei - an IntelliJ plugin to automatically perform code transformations as per the recipes (rules) defined by you. Spend your time defining reusable recipes, rather than performing repetitive migration tasks. The automation will not not only transform your legacy Joda-Time code, but also help teams follow the guidelines right there in the IDE as they write new code.

To help you get a head start, we have created a public Sensei cookbook Standardization on java.time (JSR-310) which includes recipes to migrate from Joda-Time to java.time in a less painful way. This is a growing set of recipes that we will continue to expand to add more coverage with more recipes.

Here is an example of a sample migration that might help you see how Sensei makes it painless to migrate legacy code.

From repetitive manual migration to automated code transformations

Let’s look at an example of creating a new DateTime which demonstrates a few hidden traps when migrating a single line of code from Joda-Time to java.time. We will then look at one of our Sensei recipes from our Standardization on java.time (JSR-310) cookbook and show how it captures all this information, so that this same migration can be re-used again and again by any developer.

In this example, we are constructing a Joda-Time DateTime from 7 int arguments representing values of the DateTime fields.

How do we migrate this to a java.time equivalent?

The javadoc in Joda-Time for this constructor says:

Constructs an instance from datetime field values using ISOChronology in the default time zone.

At first, we might assume there is DateTime class in java.time, but there isn’t one. If you google ‘migrate from joda time to java time’ you will most likely find Stephen Colebourne’s blog post Converting from Joda-Time to java.time.

This gives you a good start, and points us in the direction of using java.time.ZonedDateTime or java.time.OffsetDateTime. Here is our first question, which one do I use? Probably ZonedDateTime based on Stephen’s comments.

Looking up the ZonedDateTime javadoc, we can’t see any constructors at all. Returning to Stephen’s blog post we read further down:

‍Construction. Joda-Time has a constructor that accepts an Object and performs type conversion. java.time only has factory methods, so conversion is a user problem, although a parse() method is provided for strings.

So there must be a static factory method, searching the static methods we find one that looks pretty close, but it’s not exactly the same.

It has 7 int parameters like our original Joda-Time DateTime constructor, however if you don’t pay attention you will miss an important detail.  The 7th parameter no longer represents milliseconds, it expects nanoseconds instead, this is because java.time has increased precision over Joda-Time and measures instants to the nano-second. An important detail that you could have easily missed. Additionally, this method expects a ZoneId, so it makes you wonder as to why you didn’t need one before and why do you need it now.

Remembering the javadoc of our original constructor which mentioned it would use the default time zone, maybe there is a way to get the default ZoneId?

The javadoc for ZoneId does not tell us about any constructors listed, but looking at the static methods we see we can use systemDefault()

Now that we have sorted out the ZoneId, what should we do about our milliseconds to nanoSeconds conversion? Maybe we can use java.util.concurrent.TimeUnit to perform the conversion.

This method returns a long, and our method expects an int, so now we have a conversion problem to solve as well. Maybe we could try something simple. A multiplication?

This will work but does look a little out of place. If you haven’t noticed already, we have spent a considerable amount of time and effort to migrate a single line of code. But as you can imagine, we have many such edits to do by hand and it does not get better.

However, if we were to look a little harder at java.time API, we can discover a solution that looks a little bit more fluent.

Although ZonedDateTime has no obvious way to set the Milliseconds, it can be done using the with(TemporalField field, long newValue) method, using ChronoField.MILLI_OF_SECOND as the TemporalField.

And the java doc mentions that it will perform the Conversion to Nanoseconds for us:

When this field is used for setting a value, it should behave in the same way as setting NANO_OF_SECOND with the value multiplied by 1,000,000.

So we can simply specify 0 for our nanoseconds in the factory method, and then use the with method to create a ZonedDateTime that has all the original values as well as the milliseconds.

Looking at our final result, it looks like we have only changed a single line of code, it doesn’t really show the effort that went researching just one migration!

‍

Create a recipe to migrate faster and easily

Sensei provides a way for us to share this hard-won information with other developers. By creating a recipe that captures all these requirements, it will allow Sensei users to perform this migration with the click of a mouse.

A Sensei recipe consists of 3 main sections:

• Metadata
• Search
• AvailableFixes

Let us look at a Sensei recipe (can also be viewed as a YAML recipe) that will help us migrate this call into its java.time equivalent.

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

Metadata Section

The metadata section contains information about the recipe and how it should be used.

Search Section

The search section of a Sensei recipe specifies what code elements this recipe should apply to.

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 this search section we see that we are:

• Searching for an instanceCreation, i.e. a usage of a Constructor. Note: there are many other search targets available
• The constructor should have 7 arguments, this is specified by the argCount property
• args 1-7 should be of type int
• We are searching for constructors of the type org.joda.time.DateTime

‍

Available Fixes Section

The availableFixes section can specify one or more fixes that can be applied to the matching code element. Each fix can have multiple actions, and in our case we have a single fix, that performs 2 actions.

‍

• The name of the fix is shown to the user in the ‘Quickfixes’ menu, and describes what will happen if the user applies this quickfix
• The actions list shows what actions will be performed by this quickfix
• The rewrite action will rewrite the code element using a mustache template. It can make use of variables and string replacement functions.
• The modifyAssignedVariable action will check to see if this constructor is being used to assign the value to a variable. If so, this action will modify the variable to be declared as the type specified by type

‍

Using the recipe to do code transformation

With our recipe is written and enabled, it scans our code and highlights the segments to which it can be applied.

In the screenshot below we can see the target constructor has been marked by Sensei. Hovering over the marked constructor shows us the Recipe shortDescription and the Quickfix option Migrate to java.time.ZonedDateTime

‍

After we select the Migrate to java.time.ZonedDateTime quickfix, the code is transformed according to the actions we specified in the recipe.

‍

A one-time migration and uniform coding practices across teams - with Sensei

We can see from our example above, the migration of a single line of code can involve hard-won knowledge. Sensei can turn that knowledge into actionable recipes or cookbooks that can be shared within teams. You may plan a one-time migration sprint or take the approach of doing incremental instant transformations to java.time as and when you come across Joda-Time code. You can enable/disable recipes as a way to do migrations in logical stages or steps and even, expand or reduce the scope of the files scanned by Sensei - the flexibility that makes code migrations less painful.

Library migration is just one example of the many ways Sensei can be used to standardize your projects. You can always be on the lookout for anti-patterns or certain manual code transformations that you frequently come across in pull requests or as you code yourself. If you have a set of coding guidelines that are often missed by developers then you could convert the guidelines into recipes - enabling developers to apply approved code transformations with confidence.

If you have any questions, we’d love to hear from you! Join us on Slack at: sensei-scw.slack.com

The phrase "it takes a village" is an old African proverb, spanning many diverse African cultures, dialects, and geographical locations. While the language used to convey this pearl of wisdom may be different, the sentiment is the same: it takes input from the entire community to create a safe, positive and enlightening environment to raise future generations into well-rounded adults.

This may seem like a long bow to draw, but truly, the developer community has thrived for decades on this very principle. The notion of the anti-social, "lone wolf" geek behind a computer is like most stereotypes: exaggerated and not the best way to learn how we operate. There are developers of all types, from all walks of life, and there has always been a sense of community in everything we do.

Long before the internet became the norm, we were on bulletin boards sharing tips, solving each other's problems and bickering over best practice (and, certainly on my side of the fence, working hard to break stuff). This sentiment hasn't changed. The internet is now a different beast, with more trolls under the bridge and a lot more noise, but a quick jump into places like Reddit and Stack Overflow will give you an immediate sense of willingness to help, camaraderie and a wealth of information.

However, one thing we could all help support are those real-world connections to people going through the same thing. There is a new layer of meaning when you interact in the real world, and facilitating an "IRL" community can accelerate knowledge sharing, clarification and expand horizons in wonderful ways.

How does the developer community support security?

Organizations like OWASP are doing incredible work in the security community, with abundant free resources on vulnerabilities, news, and critical alerts. Offline, there are OWASP chapters in cities all over the world, hosting regular events for people to come together, talk security and share tips for making our software safer. It really is awesome, and to me, it's what the development community is all about.

One thing that these communities, whether online or in-person, help to address is the skills and knowledge gap amongst developers. Many experienced developers are only too happy to pass on information, help someone get started or point them in the right direction (any good Jedi knows they need to help a Padawan every now and then).

So, it's always a real treat when we get to partner with them to host things like secure coding tournaments. So far, we have supported meetups in Australia, England, India, and the USA, and I hope there are many more to come.

What does an OWASP tournament meetup look like? Check out this video of an OWASP tournament held in London at the iconic BBC studios:

These events certainly assist in building awareness, and this momentum can be utilized within organizations when they support these grassroots initiatives, introduce fully-fledged secure coding training, as well as make a commitment to operating with positive security culture.

How do gamification and tournaments help create more secure developers?

OWASP meetups are built around socializing, sharing knowledge and discussing ideas with a wide range of security-aware individuals. However, for those who are new to security (or don't yet have an interest in it), these events may go unnoticed.

When organizations play an active role in building security awareness and sparking real interest among the developer cohort, it can have the positive flow-on effect of instilling a lifelong quest for security knowledge within - the kind we need to get everyone more serious about coding securely.

Typical training methods are rarely a huge motivator (think sitting in a classroom while your day job tasks pile up, or trying to stay awake watching endless videos), but igniting a sense of competition, fun and gamifying the process can make learning far less of a chore. Gamified learning methods make technical (and, at times, dry) knowledge far more digestible, breaking it into smaller chunks that are contextual, memorable and encourage repeat learning. Secure Code Warrior was built on a foundation of accessibility, allowing developers to keep adding to their previous learnings step-by-step, in a way that speaks to their creativity and general instinct to solve problems.

Assessments help to keep everyone on track and identifying areas for improvement, but a secure coding tournament can serve as a catalyst for organizational security awareness and positive change, as well as a way for participants to show off their robust skills. After all, when you see a tournament leaderboard updating in real-time, you're motivated to keep pushing for more points and really show off your security prowess.

What does a successful tournament look like?

The aim of our meetups with OWASP is always intended to invest in the ongoing health of the security community, helping them to promote the concept that learning about security can actually be fun.

Secure coding tournaments are a no-brainer when it comes to engaging developers, helping them to hone and realize their skills in a social environment with like-minded individuals. They assist in breaking down the artificial walls that may exist around the idea of "security", perhaps from a less-than-pleasant experience in work or education.

A truly great tournament typically consists of the following:

• A little bit of fanfare around the organization; let people outside of the development teams know what is happening and why
• An environment free of judgment, supporting developers at all levels
• A few special perks; order some food and drinks, give it a theme and encourage self-expression
• Rewards and recognition; us developers love swag, and neat prizes for winners are a bonus: remember, your future security champions might be unearthed during this process
• A sense of community and camaraderie.

We are becoming a DevSecOps world, and with security finally coming into focus from the very beginning of software development projects, developers need to be engaged early with effective training. They are integral to shielding an organization from vulnerabilities from the moment code is being written, and in a thriving security culture, everyone can rest a little easier.

Eine Version dieses Artikels erschien in TechCrunch. Es wurde hier aktualisiert und syndiziert.

‍

Als ob wir im Jahr, das nicht genannt werden kann, nicht schon genug Störungen gehabt hätten, begann 2021 für die US-Regierung mit einem ohrenbetäubenden Paukenschlag in Form einer der schlimmsten Datenschutzverletzungen aller Zeiten. Der SolarWinds-Vorfall war ein verheerender, ausgeklügelter Angriff der Nationalstaaten, der mehrere Regierungsbehörden und große Organisationen in Panik versetzte und sich bemühte, ihre Endgeräte zu sichern. Praktisch jeder Endbenutzer der SolarWinds-Software war gefährdet, und der Vorfall machte deutlich, dass Cybersicherheit und Verteidigung in den Software-Lieferketten von entscheidender Bedeutung sind.

Es ist offensichtlich, dass Cybersicherheit wichtig ist, aber was bedeutet das eigentlich im Zusammenhang mit Lieferketten?

Der Stand der Cybersicherheit in einem durchschnittlichen Entwicklungsteam

Jeden Tag wird eine enorme Menge an Software produziert, die jedes Jahr Milliarden von Codezeilen ausmacht, und das nimmt mit der Nachfrage, die durch unseren zunehmend digitalen Lebensstil entsteht, nur noch zu. Die Zahl der Entwickler weltweit ist auf dem besten Weg, um fast 29 Millionen bis 2024, und derzeit gibt es keine formelle Zertifizierung, mit der ihre Fähigkeit zum sicheren Programmieren bewertet und zertifiziert werden könnte. Das heißt nicht, dass jeder Entwickler unsicheren Code produziert oder wiederverwendet, aber es besteht zweifellos ein anhaltendes Risiko, dass grundlegende Sicherheitslücken in die Software gelangen, der wir unsere Daten anvertrauen.

Entwickler werden anhand ihrer Fähigkeit bewertet, Funktionen zu erstellen und Code so schnell wie möglich auszuliefern. Sicherheit war in den meisten Unternehmen kein Maßstab für ihren Erfolg, aber diese Meinung beginnt sich zu ändern, da immer mehr Unternehmen das Potenzial erkennen, das in der Verhinderung gängiger Sicherheitslücken in der frühesten Phase der Softwareentwicklung liegt. Realisierung und Implementierung sind jedoch zwei verschiedene Dinge, und da in den meisten tertiären Entwicklungskursen jeglicher Kontext rund um sichere Codierungspraktiken ausgelassen wird, liegt es oft am Arbeitsplatz eines Entwicklers, das Defizit auszugleichen. Wenn der Aufbau von Fähigkeiten und der Wissensaustausch selten oder irrelevant sind, werden sie wahrscheinlich unwirksam sein. Daher ist der Kreislauf wiederkehrender Sicherheitslücken aufgrund mangelnder Qualifikationsentwicklung nach wie vor ungebrochen.

Natürlich liegt es nicht in der Verantwortung eines durchschnittlichen Softwareentwicklers, die weltweiten Cybersicherheitsprobleme zu lösen. Schließlich stellen Unternehmen diese sehr teuren Sicherheitsexperten aus einem bestimmten Grund ein. Sicherheitsgurus sind jedoch Mangelware, und Entwickler können sicherlich dazu beitragen, die Belastung zu verringern.

Aber was bedeutet das für uns — und die Anbieter, die Software für kritische Infrastrukturen und sensible Organisationen entwickeln —, wenn es darum geht, einen verheerenden Cyberangriff zu verhindern? Dies wird zumindest eine Änderung des Status Quo der Softwarebeschaffung erfordern.

Die Fallstricke, die einer sicheren Software-Lieferkette im Weg stehen

Das alte Sprichwort, dass eine Kette nur so stark ist wie ihr schwächstes Glied, trifft leider genauso zu, wenn es um Softwarelieferungen geht. Es spielt wirklich keine Rolle, ob Ihr Unternehmen mit verschärften bewährten Sicherheitsmethoden, Investitionen in die Weiterbildung von Entwicklern und der Umstellung auf eine funktionierende DevSecOps-Umgebung auf die Party gegangen ist (d. h. jeder trägt die Verantwortung dafür, dass Software so sicher wie möglich hergestellt wird); wenn Sie Software von einem Anbieter verwenden, der Sicherheitsprobleme hat, werden Sie diese in Ihr Ökosystem übernehmen und die Konsequenzen tragen.

Sicher, das Sicherheitsteam sollte dabei helfen, die Sicherheit von Erweiterungen des Tech-Stacks durch Dritte zu beurteilen, aber Entscheidungen können auf der Grundlage geschäftlicher Anforderungen getroffen werden, ohne dass eine große Auswahl an Lösungen besteht. An diesem Punkt kann es sich um eine Vertrauensübung handeln. Kümmert sich der Anbieter genauso um Sicherheit wie Ihr Unternehmen? Und kann der Anbieter die Risiken tatsächlich so einschätzen, dass nur Sie sie verstehen können, ebenso wie die Vermögenswerte, die Sie schützen müssen?

Transparenz ist ein äußerst wichtiger Faktor bei der Bewertung der Sicherheitsfähigkeit von Softwareergänzungen von Anbietern. Sind sie im Voraus mit ihren eigenen Sicherheitspraktiken? Sie sollten stolz auf ihren Ansatz zur Datensicherheit sein, und dieser sollte oberste Priorität haben. Wenn die Sicherheitspraktiken nirgends veröffentlicht werden oder keine Informationen verfügbar sind, besteht eine hohe Wahrscheinlichkeit, dass Sicherheit nicht an erster Stelle steht. Der Anbieter sollte in der Lage sein, technische Fragen und unabhängige Zertifizierungen wie ISO 27001 und SOC2 würde auch nicht schaden. Und wenn Sie im Rahmen Ihrer internen Sorgfaltspflichten und Sicherheitspraktiken nicht „unter die Haube schauen“ und nach Sicherheitslücken suchen können, vergessen Sie es.

Da die Nachfrage die Umsetzung von Softwareanforderungen so schnell vorantreibt, insbesondere wenn der Code des Anbieters in bestehende Systeme integriert wird, um Aktionen in einem neuen Kontext auszuführen, müssen sowohl der Anbieter als auch der Käufer an der Spitze stehen, und beides sollten ihre Entwickler vor Ort haben, um häufig auftretende Sicherheitslücken und -fehler zu erkennen, bevor sie ausgeliefert werden. Es könnten Hunderte — oder Tausende — von Abhängigkeiten gefährdet sein, wenn das bestehende Spinnennetz der technischen Lösungen um eine neue Erweiterung erweitert wird, und ein kleiner Fehler könnte zu einem katastrophalen Untergang führen.

Also, was ist die Lösung? Alles intern codieren, von Grund auf neu? Wenn es 1998 wäre, könnte das Sinn machen. Aber genauso wie wir Jeeves nicht mehr „fragen“, wo sich die nächste Autowaschanlage befindet, müssen wir realistische Sicherheitsvorkehrungen treffen, die im heutigen Kontext funktionieren.

Es gibt immer noch keine Wunderwaffe, aber es gibt Lösungen

Für Käufer sollte die Sicherheitsbewertung der Herstellersoftware und der Entwicklungspraktiken eine Priorität des gesamten Sicherheitsprogramms und des Risikomanagementplans sein. Stellen Sie Fragen zu ihren Zertifizierungen, Praktiken und dem Ruf ihrer Entwickler im Bereich Sicherheit.

Anbieter (und in der Tat alle Unternehmen, die Software entwickeln) müssen bereit sein, nachzuweisen, dass Sicherheit oberste Priorität hat, und sollten sich auf Weiterqualifizierung konzentrieren. Entwickler mit Sicherheitskenntnissen sind sehr gefragt, und mit die richtigen Tools und Unterstützung, sie können aus Ihrem bestehenden Team aufgebaut werden und sind in der Lage, Angriffe abzuwehren, die auf häufig vorkommenden Sicherheitslücken beruhen. Aber werfen Sie ihnen kein altes Training auf die Sprünge. Geben Sie ihnen Zeit, um erfolgreich zu sein — mit Sicherheitstools, die ihre bestehenden Arbeitsabläufe ergänzen. Machen Sie es sich so einfach wie möglich und beobachten Sie, wie die lästigen Bugs im Code, der das Unternehmen antreibt, immer dünner werden.

Unter dem Strich verschärfen sich alle Softwarerisiken sofort, wenn sie Teil der Lieferkette sind, und betreffen alle Benutzer und alle Systeme, in denen anfällige Komponenten verwendet wurden. Wenn die Anbieter die Sicherheit nicht so ernst nehmen wie die Unternehmen, die ihre Software implementieren - oder sowohl der Anbieter als auch das Unternehmen ihr Sicherheitsprogramm nicht einhalten -, werden verheerendere, weitreichendere Angriffe auf die Lieferkette wie SolarWinds unweigerlich zur Norm werden — und das ist ein kritisches Problem für alle.