Aperçu des codes sécurisés

Le 13 juillet, nous avons annoncé la clôture de notre série C de financement, après avoir levé 50 millions de dollars pour la prochaine phase de notre mission : aider davantage d'entreprises pionnières à exploiter le potentiel de leur cohorte de développement pour contrer les failles de sécurité courantes.

Notre suite d'outils d'apprentissage agiles, leader sur le marché, a été développée avec pour objectif principal non seulement d'améliorer les compétences des développeurs en matière de programmation sécurisée, mais également de les accompagner dans leur manière de travailler, leur apprentissage et leur utilisation des possibilités de formation continue. Ce financement permettra à notre équipe exceptionnelle de poursuivre son travail et d'atteindre de nouveaux jalons passionnants dans notre feuille de route produit.

Avec les réglementations officielles, quel est l'avenir des entreprises qui commencent à former leurs développeurs le plus tôt possible, ce qui, pour la plupart d'entre elles, implique une transformation profonde de leur culture de la sécurité ?

Réagir de manière flexible aux menaces grâce à l'apprentissage agile

L'une des citations les plus célèbres du philosophe chinois Confucius est la suivante : « Le roseau vert qui plie sous le vent est plus fort que le chêne puissant qui se brise sous la tempête. » À l'ère moderne, où la technologie évolue rapidement et où les cybermenaces insidieuses ne sont pas en reste, les entreprises ne peuvent se permettre de perdre du temps avec des solutions de formation statiques. Il n'est pas rare que les manuels sur la cybersécurité soient obsolètes avant même d'être imprimés, et les cours présentiels rigides ne sont tout simplement pas conçus pour présenter les meilleures techniques et solutions aux problèmes de sécurité dès qu'ils apparaissent.

Secure Code Warrior un leader dans le domaine de la formation à la sécurité pour les développeurs et utilise une approche agile pour aider les développeurs à devenir les ingénieurs de référence de demain. Notre plateforme d'apprentissage et nos outils, qui placent les développeurs au premier plan, nous permettent d'être beaucoup plus dynamiques, de suivre le rythme des menaces actuelles et de résoudre ces problèmes de la manière la plus efficace possible dès qu'ils surviennent. Si vous êtes ancré à un seul endroit en raison des racines de votre solution dans le domaine de l'éducation, il est peu probable que vous puissiez « suivre le vent » dans la formation continue des développeurs, ce qui entraîne une frustration tant pour l'enseignant que pour l'élève et un succès bien moindre dans la correction des failles de sécurité.

Selon Gartner, d'ici 2025, 70 % des grandes entreprises adopteront des approches d'apprentissage agiles. Cette transition vers le micro-apprentissage, l'amélioration continue et le développement de connaissances clés pouvant être utilisées pour atteindre les objectifs commerciaux et les résultats de sécurité les plus pertinents recèle un énorme potentiel. Cependant, cela nécessite de remettre en question le statu quo. Les entreprises doivent s'engager à aligner les besoins en formation sur les tâches quotidiennes, plutôt que d'ajouter un complément monolithique qui semble augmenter le niveau de stress plus que les compétences.

Développement de nos compétences et de notre leadership afin d'offrir un apprentissage agile de premier ordre

Dans le cadre de notre engagement à fournir des outils d'apprentissage agiles de premier ordre à nos clients professionnels tournés vers l'avenir, nous sommes fiers d'annoncer la récente expansion de notre équipe de direction. Nous avons accueilli Nanhi Singh, directeur de la clientèle chez Imperva, au sein de notre conseil d'administration et avons nommé Patrick Collins au poste de directeur des produits et technologies.

Les entreprises intelligentes sont conscientes qu'il n'existe pas de solution universelle pour l'apprentissage pratique dans le domaine de la cybersécurité et s'efforcent d'offrir plusieurs parcours d'apprentissage à leurs équipes de développement. Nous rendons cela possible chaque jour grâce à notre plateforme d'apprentissage agile et à un flux constant d'améliorations et d'expériences, y compris notre option de retour d'information en temps réel avec Coding Labs, afin de créer un environnement d'apprentissage aussi attrayant et complet que possible. Notre méthode « juste à temps » garantit qu'aucun temps n'est perdu avec des modules ou des cours non pertinents et fournit les informations appropriées exactement au moment où elles sont le plus nécessaires.

Cette réalité ne serait pas possible sans l'engagement inébranlable des membres de notre équipe et la confiance indéfectible de nos investisseurs. Les possibilités offertes par l'apprentissage agile sont infinies, et je suis ravi d'accueillir Nanhi et Patrick, qui apporteront sans aucun doute une contribution inestimable au cours des prochains mois.

Cet article a été publié à l'origine dans le cadre du Forbes Technology Council. Il a été mis à jour et publié ici.

‍

Selon vous, combien d'enregistrements de données ont été compromis en 2022 ? Vous seriez sur la bonne voie si vous deviniez environ un demi-milliard. D'après les données publiques sur les atteintes à la vie privée, environ 480 014 323 enregistrements ont été volés rien que l'année dernière, mais ce chiffre est probablement beaucoup plus élevé. Quoi qu'il en soit, il s'agit d'une statistique qui donne à réfléchir au citoyen moyen et qui est très préoccupante pour tout professionnel de la sécurité en entreprise.

Nous sommes arrivés à un point où la plupart des habitants des pays développés ont probablement vu au moins une partie de leurs données personnelles tomber entre les mains de criminels à la suite d'une cyberattaque réussie ; il est donc tout à fait naturel que les gouvernements du monde entier cherchent des solutions pour endiguer ce flux perturbateur d'activités criminelles en ligne. La dernière initiative en date émane de l'administration Biden et prend la forme d'une stratégie nationale de cybersécurité, que j'observe avec un vif intérêt. Cette stratégie comprend des directives sur l'un de mes sujets préférés en ce moment : la responsabilité en matière de sécurité.

Cette stratégie, publiée à la suite d'une présentation décisive de Jen Easterly, directrice de la cybersécurité et de la sécurité des infrastructures à la CISA, a, à juste titre, suscité des divisions au sein de la communauté de la sécurité. Cependant, je pense qu'elle représente la meilleure chance que nous ayons d'améliorer les normes logicielles dans tous les domaines et, enfin, d'inaugurer une nouvelle ère de développeurs compétents en matière de sécurité.

Les fournisseurs auraient toujours dû être tenus responsables des logiciels non sécurisés.

Cela fait des décennies qu'en matière de sécurité des logiciels, la responsabilité est une patate chaude avec laquelle aucune équipe ne cherche à jongler. Les cadres et les équipes ont tendance à ne pas être d'accord sur la responsabilité finale de la sécurité des logiciels. Un rapport de Venafi révèle que 97 % des cadres supérieurs de l'informatique reconnaissent que les processus de création de logiciels ne sont pas suffisamment sûrs, mais qu'il existe une divergence sur la responsabilité finale de la mise en œuvre des meilleures pratiques en matière de sécurité. 61 % des cadres ont déclaré que les équipes de sécurité informatique devraient assumer la responsabilité de la sécurité des logiciels, tandis que 31 % ont déclaré que c'était à l'équipe de développement d'assumer cette responsabilité. Et ce n'est qu'une partie de l'équation : la question des composants commerciaux open-source et tiers dans les logiciels est une expansion constante de la surface d'attaque. Même entre les équipes AppSec et de sécurité, il y a rarement un "propriétaire" évident malgré la nécessité d'une vigilance continue dans la mise à jour, la surveillance et les tests.

Cette même enquête a également mis en lumière que - malgré un conflit interne sur qui devrait être responsable de la sécurité et de l'intégrité des logiciels - 94% des cadres estiment qu'il devrait y avoir des pénalités pour les fournisseurs de logiciels qui ne protègent pas leurs pipelines de construction contre les acteurs de la menace, et mettent les clients et les utilisateurs finaux en danger. 

Avec les récentes poursuites engagées contre le RSSI d'Uber pour sa mauvaise gestion d'une cyberattaque dévastatrice en 2016, ainsi que les initiatives réglementaires telles que le GDPR, nous voyons peu à peu les enjeux s'élever pour les fournisseurs qui jouent avec le feu en privant la sécurité de sa priorité. Cependant, cela ne suffit tout simplement pas. Nous sommes en train de perdre la bataille contre les cybercriminels, et bien que la pilule soit difficile à avaler, ce sont les pratiques laxistes des éditeurs de logiciels qui leur offrent des opportunités illimitées de prospérer. 

La stratégie nationale de cybersécurité cherche à tracer une ligne dans le sable et à mettre fin au jeu des reproches circulaires en attribuant la pleine responsabilité des logiciels non sécurisés au vendeur.

Jetons un coup d'œil :

Objectif stratégique 3.3 - Déplacer la responsabilité des produits et services logiciels non sécurisés :

"Trop de fournisseurs "ignorent les meilleures pratiques en matière de développement sécurisé, livrent des produits dont les configurations par défaut ne sont pas sûres ou dont les vulnérabilités sont connues, et intègrent des logiciels tiers dont la provenance n'est pas vérifiée ou inconnue.

Nous devons commencer à faire porter la responsabilité sur les entités qui ne prennent pas de précautions raisonnables pour sécuriser leurs logiciels, tout en reconnaissant que même les programmes de sécurité logicielle les plus avancés ne peuvent pas prévenir toutes les vulnérabilités".

Cela a, à juste titre, froissé certaines personnes. Mais, comme pour d'autres moments décisifs dans l'élaboration de normes et de réglementations dans la plupart des secteurs, c'est la douleur à moyen terme qui garantit un meilleur résultat à long terme. En tant qu'éditeur de logiciels, il est logique que la responsabilité nous incombe en matière de sécurité. Il s'agit de notre pipeline de construction, de nos processus et de notre contrôle de la qualité, et si nous commettons une erreur, il est de notre responsabilité d'y remédier.

En outre, nous devrions être dans une situation où nous cherchons à créer des logiciels de la plus haute qualité possible, et le codage sécurisé doit faire partie des paramètres qui définissent un résultat réussi. Il s'agit là d'une tâche ardue dans un monde qui privilégie la rapidité à tout prix, mais il incombe aux responsables de la sécurité qui guident notre avenir de veiller à ce que tous les acteurs du processus de création de logiciels, et en particulier les développeurs, reçoivent une formation adéquate leur permettant d'appliquer les meilleures pratiques en matière de sécurité dans le cadre de leur rôle. 

Nous manquons encore d'indications sur les meilleures pratiques à long terme.

L'objectif stratégique 3.3 fait référence au cadre bien établi de développement de logiciels sécurisés du NIST comme base de ses meilleures pratiques générales, et il s'agit de lignes directrices complètes et globales. Elles précisent la nécessité de "veiller à ce que le personnel, les processus et la technologie de l'organisation soient prêts à assurer le développement de logiciels sécurisés au niveau de l'organisation", mais ne sont pas particulièrement prescriptives sur les facteurs que, par exemple, un responsable de la sensibilisation à la sécurité devrait connaître lorsqu'il choisit des solutions d'habilitation.

Pour que l'approche soit réellement transformatrice, les développeurs doivent être considérés comme faisant partie intégrante du programme de sécurité et se voir offrir toutes les possibilités d'améliorer leurs compétences et de partager la responsabilité de la détection et de l'éradication des vulnérabilités. Ils ne peuvent y parvenir de manière mesurable sans un apprentissage et des outils hyper pertinents et contextuels, ni si cela est considéré comme un exercice de conformité annuel au lieu d'un parcours de développement continu des compétences. 

Les développeurs sont une pièce importante du puzzle lorsqu'il s'agit de résoudre l'énigme de la sécurité, et une équipe de développeurs compétents en matière de sécurité est essentiellement l'ingrédient manquant dans la plupart des organisations. Ils permettent d'accélérer la sécurité, mais uniquement lorsque du temps et des ressources sont consacrés à cette tâche au sein de l'équipe. En attendant, toutes les lignes directrices générales sur les meilleures pratiques du monde ne parviendront pas à faire bouger l'aiguille.

Le long chemin vers le nirvana de la sécurité des logiciels.

L'administration Biden s'est engagée à financer la CISA à hauteur de 3 milliards de dollars, dans le but d'assurer une résilience rapide des infrastructures critiques. Si le financement et le soutien des plus hauts niveaux de gouvernement sont essentiels, pour que nous ayons une chance de contrecarrer les acteurs de la menace, il faudra un effort mondial pour réécrire l'histoire de la culture de la sécurité.

La route est longue, mais elle commence avec chaque éditeur de logiciels qui fait le premier pas courageux vers la responsabilisation en matière de sécurité au niveau de l'organisation.

Dieses Interview erschien ursprünglich in Cyber-Nachrichten.

‍

Trotz der Verbreitung von Sicherheitstools und -diensten haben Unternehmen immer noch Schwierigkeiten, mit der sich ständig weiterentwickelnden Bedrohungslandschaft Schritt zu halten.

Dies ist auf das mangelnde Sicherheitsbewusstsein und die mangelnde Schulung der Entwickler zurückzuführen, was dazu führen kann, dass riskanter Code veröffentlicht und von böswilligen Akteuren ausgenutzt wird. Während Sicherheitsmaßnahmen wie Antivirensoftware oder starke Lösungen zum Scannen von Sicherheitslücken eine zusätzliche Sicherheitsebene hinzufügen können, erklärt unser heutiger Gast, dass alles mit einem sicherheitsorientierten Entwicklungsteam beginnt.

Um zu besprechen, wie Entwickler darin geschult werden können, Sicherheitsbedrohungen zu erkennen und abzuwehren, traf sich das Team von CyberNews mit Pieter Danhieux, CEO und Mitbegründer von Sicherer Codekrieger, ein Unternehmen, das eine Lernplattform und eine Reihe von entwicklerorientierten Tools anbietet, die Entwicklungsteams bei der Behebung von Sicherheitslücken unterstützen.

Wie war deine Reise? Wie ist die Idee von Secure Code Warrior entstanden?

Als junger Nerd war ich fasziniert davon, Technologie auseinanderzunehmen, um herauszufinden, was darin steckt und wie sie funktioniert. Sehr zur Erleichterung meiner Familie und unserer gemeinsam genutzten Geräte entschied ich mich schließlich dafür, bei Hard- und Software den gleichen Ansatz zu verfolgen und nach Möglichkeiten zu suchen, diese zu knacken und kaputt zu machen. Eine lebenslange Leidenschaft für Sicherheit war geboren, und viele Jahre lang konzentrierte ich mich darauf, meine „bahnbrechenden“ Fähigkeiten mit Studenten, Kollegen und der Sicherheitsgemeinschaft zu teilen und zu zeigen, wie man Fehler in Software findet, verwendet und missbraucht. Später konzentrierte ich mich wieder darauf, die Verteidiger weiterzubilden, Entwicklern gute, sichere Codierungsmuster in einer Unterrichtsumgebung beizubringen und ihnen zu helfen, häufige Sicherheitslücken zu verstehen und ihnen zu helfen, sie zu vermeiden. Ich war auch in der Beratung tätig, wo ich große Unternehmen darin beriet, wie sie ihre Sicherheitsprogramme verbessern könnten, insbesondere in Bezug auf die Einbindung von Entwicklern. In dieser Zeit habe ich Kontakt zu meinem heutigen Gründungsteam bei Secure Code Warrior aufgenommen. Gemeinsam verstanden wir die Probleme, mit denen sowohl die Sicherheits- als auch die Entwicklungsteams konfrontiert waren, wenn es um Sicherheitslücken auf Codeebene ging, sowie die Probleme, die bei den meisten Schulungslösungen auftraten, die auf die Verbesserung der Sicherheitsfähigkeiten von Entwicklern abzielten. Wir machten uns an die Arbeit an unserer Vision einer Lernplattform, die auf Unternehmensebene skaliert werden kann und gleichzeitig für Entwickler unterhaltsam und ansprechend bleibt. Letztlich wollten wir eine Reihe von Tools entwickeln, die auf die Arbeitsumgebung der Entwickler zugeschnitten sind, weniger störend sind und ihnen helfen, eine Denkweise zu entwickeln, bei der Sicherheit an erster Stelle steht. Und wir haben uns vorgenommen, dies so sprachflexibel und inhaltsreich wie möglich zu gestalten.

Kannst du uns vorstellen, was du tust? Was sind die wichtigsten Herausforderungen, bei denen du hilfst?

Letztlich unterstützen wir Unternehmen dabei, ihre Softwareentwicklung zu beschleunigen, indem wir die Sicherheitsprobleme und Verzögerungen beseitigen, die häufig durch die Verwendung schlechter Sicherheitsmuster im Code entstehen. Wir haben eine Lernplattform und eine Reihe von entwicklerorientierten Tools entwickelt, die Entwicklungsteams dabei unterstützen, häufig auftretende Sicherheitslücken zu erkennen, von denen viele schon seit Jahrzehnten bestehen und Unternehmen auch heute noch Cyberrisiken aussetzen. Der Grund dafür ist, dass es den Entwicklern an der Ausbildung und den Fähigkeiten mangelt, um diese Probleme auf Codeebene zu lösen, und dass sie sie häufig erst einführen, indem sie weiterhin schlechte Codierungsmuster und -techniken verwenden. Im Tertiärbereich wird ihnen kein sicheres Programmieren beigebracht, und die meisten Schulungsprogramme am Arbeitsplatz sind ineffektiv, wenn es darum geht, Inhalte zu vermitteln, die für ihre tägliche Arbeit relevant sind, und sie kommen auch zu selten vor, um im Laufe der Zeit wirklich Auswirkungen auf die Codequalität und -sicherheit zu haben. Unsere Lösungen zielen darauf ab, ansprechende, relevante Fähigkeiten zu entwickeln, die das Programmierverhalten verändern und ihnen helfen, Sicherheit in der realen Welt an die erste Stelle zu setzen. Wir integrieren uns zunehmend in die Umgebungen, mit denen Entwickler am besten vertraut sind, und unser Fokus auf kontextbezogenes Lernen bietet Benutzern die beste Chance, wichtige Bildungsergebnisse beizubehalten. Wir bemühen uns auch, dies so zu tun, dass Entwickler Sicherheit in einem positiven, unterhaltsamen Licht sehen, das Erfolg belohnt und eine Community aufbaut.

Da es für manche mühsam klingt, etwas über sicheres Programmieren zu lernen, wie schaffen Sie es, Ihr Training effektiv und dennoch unterhaltsam zu gestalten?

Unsere Flaggschiff-Lernplattform wurde mit Blick auf das Engagement der Entwickler entwickelt. Eine der beliebtesten Funktionen ist der Turniermodus, in dem die Teilnehmer das Wissen, das sie während des Trainings erworben haben, gegen Gleichaltrige testen können. Punkte werden für jede richtige Antwort vergeben und während der gesamten Turniersitzung werden die Bestenlisten live aktualisiert. Wir haben diese Spiele auf Community-Events und Konferenzen veranstaltet, und einige unserer Kunden haben unglaublich komplizierte Themen entworfen, bei denen jeder verkleidet ist. Es ist eine großartige Teambuilding-Erfahrung und der perfekte Zeitpunkt, um das Engagement für die Weiterbildung mit Pizza, Preisen und einer Pause vom normalen Alltag zu feiern. Darüber hinaus sind unsere Inhalte im Allgemeinen in mehr als sechzig Programmier-Frameworks verfügbar, wobei echte Codefragmente verwendet werden, die sie bei ihrer täglichen Arbeit tatsächlich sehen werden. Es ist viel einfacher, bei der Stange zu bleiben, wenn die Inhalte hochrelevant sind und bei der Lösung echter Probleme helfen, als wenn Sie sich Videos ansehen oder eine jährliche Konformitätsprüfung durchführen müssen.

Was sind Ihrer Meinung nach die größten Herausforderungen, vor denen Entwickler heutzutage stehen?

Ich denke, es ist wichtig, klarzustellen, dass Entwickler gute Leistungen erbringen wollen, aber sie wurden in ihrer Ausbildung oder Karriere nicht ausreichend in Bezug auf Sicherheit geschult. Dies ist der Schlüssel zu vielen Problemen, mit denen sie aus Sicherheitsgründen konfrontiert sind. Sie neigen auch dazu, Sicherheit außerhalb ihres Zuständigkeitsbereichs zu sehen, und in der überwiegenden Mehrheit der Unternehmen enthalten ihre KPIs nichts, was mit sicheren Codierungsergebnissen zu tun hat.Wenn wir eine Veränderung der Anzahl von Sicherheitslücken auf Codeebene sehen wollen, muss dieser Status Quo durchbrochen werden. Entwickler benötigen jedoch die richtige Unterstützung und die richtigen Tools, um den Wandel, den wir uns wünschen, zu verwirklichen. Die Herausforderung liegt in der effektiven Unterstützung, ihnen Zeit zum Training zu geben und jetzt in diese Weiterbildung zu investieren, um später schnell Sicherheit zu erreichen.

Wie haben sich die jüngsten globalen Ereignisse auf Ihr Arbeitsfeld ausgewirkt?

Zwar spürte zweifellos jedes Unternehmen einige Auswirkungen des aktuellen globalen Klimas auf seine Ziele, Prognosen und Budgets, aber wir hatten das Glück, den Sturm bisher überstanden zu haben. Cybersicherheit ist in den meisten Unternehmen ein nicht verhandelbares Element, und wir arbeiten hart daran, Teil dieses Gesprächs mit Kunden und Interessenten zu bleiben.

Was sind einige der Best Practices, die Unternehmen bei der Entwicklung von Software oder Anwendungen befolgen sollten?

Jedes Unternehmen hat seine Nuancen, aber im Allgemeinen sind die Unternehmen, die mit den besten Sicherheitspraktiken arbeiten, bereit, um die Ecke zu denken und andere Ansätze auszuprobieren. Sie vergessen nicht, dass Menschen in der Lage sind, die Sicherheitsergebnisse positiv zu beeinflussen. In den meisten Fällen spielen Entwickler in einem Sicherheitsprogramm keine große Rolle. Angesichts der weltweiten Qualifikationslücke im Bereich Sicherheit, die in absehbarer Zeit wahrscheinlich nicht geschlossen werden wird, können sicherheitsorientierte Entwickler jedoch dazu beitragen, Risiken zu reduzieren und die Einhaltung von Vorschriften aus Sicht der Softwareentwicklung zu gewährleisten. Sie können in der frühestmöglichen und kostengünstigsten Phase des Prozesses Wirkung zeigen.

Welche anderen Maßnahmen oder Praktiken können Ihrer Meinung nach neben sicheren Codierungstools den Geschäftsbetrieb nicht nur verbessern, sondern auch sichern?

Jedes Unternehmen sollte über eine Art rollenbasiertes Sicherheitstraining verfügen. Abgesehen von Exploits auf Codeebene, die von Bedrohungsakteuren genutzt werden, gibt es eine Vielzahl von Bedrohungen. Daher muss jede einzelne Person im Unternehmen regelmäßig über Sicherheitsprinzipien verfügen, die sie für ihre Arbeit anwenden. In diesem Sinne sollte jeder, vom Büroleiter bis zum Buchhaltungsteam, die Rolle, die er bei Maßnahmen und Sensibilisierung für Cybersicherheit spielt, verstehen und akzeptieren.

Angesichts des aktuellen Wirtschaftsklimas stehen CISOs unter großem Druck, die Sicherheit von Unternehmen zu den niedrigsten Kosten zu gewährleisten. Welchen Rat hätten Sie für sie?

CISOs müssen in diesem Umfeld etwas Kreativität einsetzen, insbesondere da die Cybersicherheitsgesetze immer anspruchsvoller werden und in einigen Fällen dazu führen, dass CISOs im Falle eines Verstoßes persönlich zur Rechenschaft gezogen werden. Hinzu kommen Entlassungen, und Sie haben eine Situation, in der von weniger Ingenieuren erwartet wird, dass sie mehr Verantwortung übernehmen, während sie dieselbe Menge an Software schreiben. CISOs können dem Unternehmen helfen, seinen Erfolg zu sichern, indem sie eines der größten Hindernisse angehen, das sie ausbremst: die Sicherheit.

Der mit Abstand günstigste Schritt, um Sicherheitslücken und Fehlkonfigurationen auf Codeebene zu beheben, ist vor der Auslieferung der Software, was den Entwickler natürlich in die beste Position versetzt, um dieses Risiko zu reduzieren. Um dies zu erreichen, benötigen sie jedoch maßgeschneiderte Unterstützung. Schnelle Sicherheit ist möglich, wenn sie der technischen Abteilung Tools zur Verfügung stellen, bei denen die Entwickler an erster Stelle stehen und deren aktueller Arbeitsablauf und Technologie-Stack berücksichtigt werden. Sie müssen befähigt werden, Sicherheitsgenauigkeit mit hoher Geschwindigkeit zu erreichen, und dieses Problem lässt sich am besten lösen, indem sie ihnen zeigen, wie sie sichere Codierungsmuster verwenden und Probleme schneller beheben können.

Gegen die Kosten einer umfassenden Entwicklerschulung können Sie im Wesentlichen daran arbeiten, Sicherheitslücken an der Quelle zu beseitigen und so später im Softwareentwicklungszyklus (SDLC) Zeit und Geld zu sparen. Angesichts der Häufigkeit groß angelegter Angriffe und einer höheren Haftung für CISOs als je zuvor in der Geschichte müssen wir aufhören, einem Fachkräftemangel im Bereich Cybersicherheit die Schuld dafür zu geben, dass er ins Hintertreffen gerät. Priorisieren Sie defensive Sicherheitspraktiken und stärken Sie das Personal, das sich bereits direkt vor Ihnen befindet.

Was hält die Zukunft für Secure Code Warrior bereit?

Wir wollen weiterhin innovativ sein, wobei die Entwickler bei den Lösungen, die wir auf den Markt bringen, stets im Mittelpunkt stehen. Wir konzentrieren uns darauf, sie in die Lage zu versetzen, Sicherheit zu bieten, ohne Kompromisse bei der Geschwindigkeit der Bereitstellung von Funktionen oder ihrer geistigen Gesundheit einzugehen, wenn sie mehrere Prioritäten unter einen Hut bringen.

Unser Ziel ist es, Unternehmen dabei zu unterstützen, ihr defensives Sicherheitsprogramm zu revolutionieren, und wir möchten, dass sicherheitsorientierte Entwickler die Helden dieser Geschichte sind. Beobachten Sie diesen Bereich.

Am 19. April 2022, Neil Madden hat eine Sicherheitslücke aufgedeckt in Oracle Java 15 bis 18 und OpenJDK 15, 17 und 18. Die Sicherheitsanfälligkeit liegt in der Kryptografie für ECDSA-Signaturen, die es einem Angreifer ermöglicht, Signaturprüfungen für diese Signaturen vollständig zu umgehen.

Angesichts der undurchsichtigen Natur der ECDSA-Signaturen ist es leicht, Schlagzeilen über diese Sicherheitslücke zu lesen und direkt an ihnen vorbeizufliegen. ECDSA-Signaturen spielen jedoch tatsächlich eine wichtige Rolle beim Schutz von Systemen im Internet bei kritischen Aufgaben wie der Authentifizierung.

Bevor wir ins Detail gehen, wenn Sie erleben möchten, wie Hacker Psychic Signatures auf praktische Weise ausnutzen. Springen Sie direkt in unsere free lab - Missionen um es selbst auszuprobieren.

Was ist die große Sache mit ECDSA?

Möglicherweise haben Sie noch nie von ECDSA gehört. Es ist der Kurzname für Elliptic Curve Digital Signature Algorithm. Dabei handelt es sich um eine Art der Kryptografie, die die mathematischen Eigenschaften elliptischer Kurven nutzt und derzeit einige der stärksten kryptografischen Sicherheitsstandards der Branche bietet.

Das bedeutet, dass es für viele wichtige Funktionen verwendet wird, wie zum Beispiel:

• Das Signieren von SSL-Zertifikaten
• Handshakes bei verschlüsselter Kommunikation
• SAML
• JWT-Signaturen
• OpenID Connect-Signaturen

Dies bedeutet, dass ECDSA ein wichtiger Bestandteil vieler der empfindlichsten Funktionen zum Schutz von Systemen ist. Die Möglichkeit, Signaturprüfungen zu umgehen, wäre potenziell verheerend.

Wie wird die Sicherheitslücke ausgenutzt?

Die Mathematik von ECDSA ist leider etwas kompliziert. Aber das Wichtigste, was Sie wissen müssen, ist, dass eine ECDSA-Signatur zwei Informationen enthält: r, und s.

Diese Zahlen werden verwendet, um die Gültigkeit der Signatur zu berechnen. Der Wert r ist das „Ergebnis“ (linke Seite) einer Berechnung mit beiden r und s auf der rechten Seite der Gleichung. Da die Multiplikation mit 0 eine schlechte Idee ist, wird in der ECDSA-Spezifikation ausdrücklich darauf hingewiesen, dass, wenn der Wert von r oder s ist immer 0, sie sollten verworfen werden.

Die Java-Implementierung von ECDSA hat jedoch vergessen, dies zu berücksichtigen. Daher akzeptiert es eine Signatur mit beiden r und s ist 0, was immer wahr sein wird. Wir können dies anhand eines Beispiels eines JWT demonstrieren, das zeigt, wie einfach es ist. Benutzen https://token.dev/, wir können ein Token mit dem Algorithmus ES256 generieren, ähnlich einem, das von einer Anwendung generiert würde:

Denken Sie daran, dass ein JWT in 3 Teile aufgeteilt ist:

• Header (blau)
• Nutzlast (grün)
• Signatur (in Rot)

Nun, wenn wir die Signaturprüfung umgehen wollten, wie würden wir das angehen? Die Signatur spezifiziert die Werte für r und s, und ist im DER-Format kodiert.

Lassen Sie uns unser JWT ändern, um diese neue Signatur zu verwenden. Beachten Sie, dass in JWTs das Gleichheitszeichen nicht enthalten ist.

Nun, unsere Unterschrift hat r und s auf 0 gesetzt, und in anfälligen Versionen von Java wird die Signaturprüfung jetzt für jede von Ihnen angegebene Nutzlast erfolgreich sein.

Wer ist betroffen und wie kann es gemildert werden?

Die Sicherheitslücke betrifft sowohl Oracle Java als auch OpenJDK. Dazu gehören:

Oracle Java SE (und ältere, nicht unterstützte Versionen):

• 18

• 17.0.2

Oracle GraalVM Enterprise Edition :

• 22.0.0.2
• 21,3.1

JDK öffnen:

• 18
• 17.0.2
• 15,0.6
• 13.0,10
• 11.0,14
• 8 Uhr 32
• 7 u31

Beides Orakel und JDK öffnen haben Hinweise und Patches für das Problem veröffentlicht, die sofort angewendet werden können.

Praktische Methoden zur Abwehr dieser Sicherheitsanfälligkeit

Hier bei Secure Code Warrior bemühen wir uns, Entwicklern die relevantesten Informationen und praktischen Übungen für kritische Sicherheitslücken zur Verfügung zu stellen, unabhängig davon, ob es sich um eine aktuelle Sicherheitslücke wie Psychic Signatures handelt oder um etwas, das es schon seit Jahren gibt.

Wir glauben, dass es notwendig ist, Entwickler von Anfang an in die Lage zu versetzen, den Abwehrmechanismus zu verstehen und sicheren Code zu schreiben, um Risiken wirklich in Schach zu halten. Aus diesem Grund erstellen wir für Sie und die betroffenen Teams eine schrittweise Anleitung für diese Sicherheitsanfälligkeit (und viele andere).

In der exemplarischen Vorgehensweise können Sie den Anweisungen zur Nutzung der Physic Signature in JWTS folgen und die Auswirkungen auf eine funktionierende App in Echtzeit verfolgen.

Probiere es jetzt aus.

‍

Une version de cet article a été publiée dans DZone. Elle a été mise à jour et publiée ici.

‍

Pendant ce qui semble être une éternité, nous avons discuté du "déplacement vers la gauche" dans le SDLC, en prenant en compte les meilleures pratiques de sécurité dès le début du développement du logiciel. DevSecOps a été un grand pas en avant, en grande partie parce qu'il met l'accent sur le partage des responsabilités en matière de sécurité et sur la capacité d'un développeur sensibilisé à la sécurité à déjouer les vulnérabilités courantes au fur et à mesure qu'il écrit le code. 

Nous savons également - là encore, depuis des lustres - que le type de formation au code sécurisé choisi pour impliquer et perfectionner les développeurs fait toute la différence. Les solutions à faible effort motivées uniquement par la conformité réglementaire ne permettent pas de former les brillants esprits de sécurité de demain, et la plupart des professionnels de la sensibilisation à la sécurité l'ont compris. Un apprentissage dynamique et adapté au contexte est préférable, mais il est essentiel de comprendre les nuances qu'il comporte. 

Si nous voulons avoir une chance de nous battre contre les acteurs de la menace - et ils ont toujours une longueur d'avance sur une organisation - les développeurs ont besoin d'un environnement de formation holistique, avec un apprentissage en couches qui renforce continuellement les compétences ancrées dans les meilleures pratiques.

Les mesures de sécurité défensives prises par les développeurs ne sont pas automatiquement gagnantes.

Notre philosophie repose sur le fait que le développeur est au cœur d'une stratégie de sécurité préventive, dès le niveau du code. C'est une évidence, et les développeurs compétents en matière de sécurité constituent la voie la plus facile pour contrecarrer les types de bogues de sécurité courants qui sont apparents dans les modèles de codage médiocres (comme Log4Shell, qui est un exemple récent et dévastateur).

Cependant, les techniques défensives que nous pouvons utiliser pour améliorer les compétences des développeurs varient, même si elles peuvent à juste titre exister dans le même panier de formation. 

Imaginez, par exemple, que l'on vous dise comment faire un gâteau, en utilisant uniquement des instructions basées sur ce qu'il ne faut pas faire. "Ne pas trop le cuire" et "ne pas oublier les œufs" laissent place à l'interprétation et à un énorme potentiel d'erreurs qui donneront un résultat final digne d'un gâteau. C'est raté !. Il en va de même pour l'éducation à la sécurité défensive ; ce qu'il ne faut pas faire est une partie très limitée de la conversation, et n'offre aucun conseil pratique pour agir véritablement avec un état d'esprit défensif. Vous pouvez dire aux développeurs "ne configurez pas mal cette API", mais si vous ne comprenez pas ce qu'est une configuration correcte et sûre, il y a beaucoup de place pour l'erreur.

Les développeurs n'auront pas d'impact positif sur la réduction des vulnérabilités sans une compréhension fondamentale du fonctionnement des vulnérabilités, de la raison pour laquelle elles sont dangereuses, des modèles qui les causent et des modèles de conception ou de codage qui les corrigent dans un contexte qui a du sens dans leur monde. Une approche par échafaudage permet aux couches de connaissances de donner une image complète de ce que signifie coder en toute sécurité, défendre une base de code et se tenir debout en tant que développeur conscient de la sécurité. Et oui, une partie de cet apprentissage en couches doit être consacrée à l'offensive et à la compréhension de l'état d'esprit d'un attaquant ; c'est essentiel pour affiner les compétences de pensée latérale, qui sont inestimables dans la modélisation des menaces et la stratégie défensive. 

Renforcer les mauvaises habitudes de codage est un piège que nous ne pouvons pas ignorer.

Malheureusement, certaines méthodes de formation des développeurs ont pour effet que la partie "défensive" - même lorsque la formation est structurée avec des techniques offensives - peut renforcer les mauvaises habitudes, même si elles valident techniquement la sécurité du code. 

La production d'un code de haute qualité devrait être la base de tout développement de logiciel, mais la définition de la "qualité" semble toujours faire l'objet d'un débat. En réalité, un code non sécurisé ne peut pas être considéré comme un code de qualité, même s'il est par ailleurs fonctionnel et beau. Le comble, c'est que le codesécurisé n'est pas non plus intrinsèquement de haute qualité. En d'autres termes, de mauvais schémas de codage peuvent résoudre un problème de sécurité, mais, ce faisant, en introduire un autre, voire casser entièrement le logiciel. 

Examinons un exemple de code de mauvaise qualité sous la forme d'un correctif pour une authentification défectueuse, ainsi que la version la plus sûre pour les meilleures pratiques :

‍

en utilisant System ;

using System.Collections.Generic ;

using System.Linq ;

using System.Threading.Tasks ;

using Microsoft.AspNetCore.Authorization ;

using Microsoft.AspNetCore.Http ;

utilisant Microsoft.AspNetCore.Mvc ;

‍

namespace BadFixesAPI.Controllers

{

    [Route("api/[controller]")]

    [ApiController]

    public class AlertsController : ControllerBase

    {

        private DatabaseContext context = new DatabaseContext() ;

‍

        [HttpGet(Name = "GetAlerts")]

        // Does not ensure that the user is authenticated 

        public IEnumerable<Alert> Get()

        {

            return context.GetAlerts() ;

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // Ensures that the user is authenticated, but does not check any roles

        [Authorize()]

        public IEnumerable<Alert> GetBadFix()

        {

            return context.GetAlerts() ;

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // Ensures that the user is authenticated, AND that they have the "Administrator" role

        [Authorize(Roles = "Administrator")]

        public IEnumerable<Alert> GetGoodFix()

        {

            return context.GetAlerts() ;

        }

    }

}

‍

Dans le premier extrait, aucun contrôle n'est effectué pour vérifier que l'utilisateur est authentifié, ce qui est à peu près aussi peu sûr que possible. Le deuxième extrait, bien que meilleur en termes de vérification de l'authentification, n'examine pas les rôles attribués et ne vérifie pas si les autorisations sont suffisamment élevées pour permettre l'accès aux informations demandées. La troisième vérifie à la fois l'authentification de l'utilisateur et l' attribution du rôle d'"administrateur". À une époque où le contrôle de l'accès au moindre privilège devrait être la norme dans la plupart des cas, il est essentiel que les rôles soient définis et vérifiés pour s'assurer que les informations ne sont accessibles que sur la base du besoin de savoir. 

La priorité absolue des développeurs est de créer des fonctionnalités, et même si la sécurité n'est pas intentionnellement mise de côté, ils n'ont pas nécessairement les compétences nécessaires pour éviter les mauvais schémas de codage qui conduisent à des bogues de sécurité, et la référence d'un bon ingénieur inclut rarement des prouesses en matière de codage sécurisé. Nous encourageons indirectement ces mauvaises habitudes si les fonctionnalités sont suffisamment géniales, et c'est cet état d'esprit qui doit changer. Le problème est que la façon dont certains parcours d'apprentissage encouragent la remédiation pratique du code renforce aussi potentiellement le code qui est sûr, mais de qualité inférieure. En appliquant une approche binaire du type "oui c'est sûr / non ce n'est pas sûr" assessment, au lieu de chercher à savoir si c'est vraiment la meilleure approche pour résoudre le bogue et maintenir l'intégrité du logiciel, il y a des diables dans les détails qui passent inaperçus. 

Si elle n'accompagne pas les développeurs tout au long du processus pour leur donner une vue d'ensemble du codage sécurisé, cette approche perpétue les mêmes problèmes qu'elle tente de résoudre. Imaginez que nous obtenions tous notre permis de conduire sur la seule base de notre capacité à conduire un véhicule jusqu'à une destination ; une note de passage même si nous avons grillé des feux rouges, traversé une haie et manqué de peu un piéton qui traversait la rue pour arriver à destination. Nous avons atteint l'objectif, mais c'est le voyage que nous avons effectué pour y parvenir qui compte le plus. 

Il faut permettre aux développeurs de se préoccuper davantage de la création de logiciels sûrs.

Le développeur moderne doit faire tourner beaucoup de choses, et il n'est pas surprenant qu'il trouve la formation à la sécurité ennuyeuse, surtout lorsqu'elle n'est pas mise en œuvre en tenant compte de sa journée de travail, et qu'elle l'éloigne de ses échéances et de ses priorités. Il est également tout à fait injuste de modifier leurs indicateurs clés de performance pour mettre l'accent sur le codage sécurisé, alors qu'ils ne disposent pas des compétences acquises grâce à des opportunités d'apprentissage régulières et adaptées et à des outils supplémentaires. Cependant, on ne saurait trop insister sur l'importance du développement de logiciels sécurisés, et il est crucial de rallier les développeurs à cette cause. 

En tant qu'ancien développeur, nous voulons généralement faire du bon travail et il est très motivant d'être considéré comme supérieur aux autres en termes de qualité de production. Inciter les développeurs à s'engager dans un renforcement continu des compétences en matière de sécurité est une évidence, et ils devraient être récompensés pour avoir reconnu l'importance de la sécurité au niveau du code. Les programmes de champions de la sécurité, les primes aux bogues et les hackathons peuvent être d'excellentes occasions de créer une culture positive de la sécurité, et ceux qui se retroussent les manches et s'impliquent devraient recevoir le butin.

Eine Version dieses Artikels erschien in der SD-Zeiten. Es wurde hier aktualisiert und syndiziert.

‍

Wenn wir über Fortschritt sprechen, steht in der Regel der digitale Fortschritt im Vordergrund der Konversation. Wir wollen, dass alles besser, schneller, bequemer und leistungsfähiger ist, und das mit weniger Geld, Zeit und Risiko. In den meisten Fällen werden diese „unmöglichen“ Ziele irgendwann erreicht; es kann mehrere Jahre und mehrere Versionen dauern (und ein Team von Entwicklern, die einen Coup starten könnten, wenn sie gebeten werden, beim Feature-Design umzuschalten) noch ein verdammtes Mal), aber jeden Tag verändert Code die Welt.

Mit einer großen Softwareerweiterung geht jedoch auch eine große Verantwortung einher, und die Realität ist, dass wir aus Sicherheitsgründen einfach nicht bereit sind, uns damit zu befassen. Softwareentwicklung ist keine Insel mehr, und wenn wir alle Aspekte des softwaregestützten Risikos berücksichtigen — von der Cloud über eingebettete Systeme in Geräten und Fahrzeugen bis hin zu unserer kritischen Infrastruktur, ganz zu schweigen von den APIs, die alles verbinden —, ist die Angriffsfläche grenzenlos und außer Kontrolle geraten.

Wir können keine magische Zeit erwarten, in der jede Codezeile von erfahrenen Sicherheitsexperten akribisch überprüft wird - Diese Qualifikationslücke wird sich in absehbarer Zeit nicht schließen - aber wir können als Branche einen ganzheitlicheren Ansatz für die Sicherheit auf Codeebene verfolgen.

Lassen Sie uns untersuchen, wie wir diese unendliche Angriffsfläche mit den zur Verfügung stehenden Tools in den Griff bekommen können:

Seien Sie realistisch in Bezug auf das Ausmaß des Geschäftsrisikos (und was Sie bereit sind zu akzeptieren)

Perfekte Sicherheit ist nicht nachhaltig, aber auch nicht, eine Augenbinde aufzusetzen und so zu tun, als wäre alles blau. Wir wissen bereits, dass Unternehmen wissentlich anfälligen Code versenden, und es ist klar, dass dies ein kalkuliertes Risiko ist, das auf der Zeit basiert, in der neue Funktionen und Produkte auf den Markt gebracht werden.

Schnelle Sicherheit ist eine Herausforderung, insbesondere an Orten, an denen DevSecOps nicht die Standardentwicklungsmethode ist. Wir müssen uns jedoch nur die neuesten ansehen Log4Shell-Exploit um herauszufinden, wie relativ kleine Sicherheitsprobleme im Code Möglichkeiten für einen erfolgreichen Angriff eröffnet haben, und um zu erkennen, dass die Folgen dieser kalkulierten Risiken für den Versand von Code mit geringerer Qualität weitaus größer sein könnten als erwartet.

Machen Sie sich damit vertraut, ein Freak für (Zutritts-) Kontrollen zu sein

Eine alarmierende Anzahl kostspieliger Datenschutzverletzungen wird durch schlecht konfigurierte Cloud-Speicherumgebungen verursacht, und das Risiko, dass vertrauliche Daten aufgrund von Fehlern bei der Zugriffskontrolle gefährdet werden, verfolgt die Sicherheitsteams in den meisten Unternehmen weiterhin.

Im Jahr 2019 hat das Fortune-500-Unternehmen First American Financial Corp. habe das auf die harte Tour herausgefunden. Ein Authentifizierungsfehler, der relativ einfach zu beheben war, führte zur Offenlegung von über 800 Millionen Datensätzen, darunter Kontoauszüge, Hypothekenverträge und Lichtbildausweise. Ihre Dokumentenlinks erforderten keine Benutzeridentifikation oder Anmeldung, sodass sie für jeden mit einem Webbrowser zugänglich waren. Schlimmer noch, sie wurden mit fortlaufenden Nummern protokolliert, was bedeutet, dass eine einfache Änderung der Nummer im Link einen neuen Datensatz enthüllte.

Dieses Sicherheitsproblem wurde intern identifiziert, bevor es in den Medien enthülltDas Versäumnis, das Problem ordnungsgemäß als Sicherheitsproblem mit hohem Risiko einzustufen, und das Versäumnis, es der Geschäftsleitung zur dringenden Behebung zu melden, führte jedoch zu einem Fallout, mit dem bis heute umgegangen wird.

Es gibt einen Grund, warum eine kaputte Zugangskontrolle jetzt ganz oben auf der OWASP Top 10: Es ist so alltäglich wie Dreck, und Entwickler benötigen ein verifiziertes Sicherheitsbewusstsein und praktische Fähigkeiten, um die Best Practices rund um Authentifizierung und Rechte in ihren eigenen Builds zu nutzen und sicherzustellen, dass Kontrollen und Maßnahmen zum Schutz vertraulicher Daten getroffen werden.

Die Art der APIs macht sie besonders relevant und knifflig. Sie sind von Natur aus sehr gesprächig mit anderen Anwendungen, und Entwicklungsteams sollten alle potenziellen Zugangspunkte im Blick haben. Schließlich können sie unbekannte Variablen und Anwendungsfälle nicht berücksichtigen, um sicherere Software bereitzustellen.

Analysieren Sie Ihr Sicherheitsprogramm: Wie viel Wert wird auf Prävention gelegt?

Es macht Sinn, dass ein großer Teil eines Sicherheitsprogramms der Reaktion und Reaktion auf Vorfälle gewidmet ist, aber vielen Unternehmen fehlt eine wertvolle Risikominimierung, da sie nicht alle verfügbaren Ressourcen nutzen, um einen Sicherheitsvorfall von vornherein zu verhindern.

Sicher, es gibt umfassende Stapel von Sicherheitstools, die bei der Aufdeckung problematischer Fehler helfen, aber fast 50% der Unternehmen gaben zu, dass ein Versandcode, von dem sie wussten, dass er anfällig war. Zeitbeschränkungen, die Komplexität der Tools und der Mangel an geschulten Experten, die auf die Berichterstattung reagieren, tragen zu einem im Wesentlichen kalkulierten Risiko bei. Die Tatsache, dass Code in der Cloud, in Anwendungen, in API-Funktionen, eingebetteten Systemen, Bibliotheken und einer ständig wachsenden Technologielandschaft gesichert werden muss, stellt jedoch sicher, dass wir mit dem aktuellen Ansatz immer einen Schritt hinterherhinken.

Sicherheitslücken sind ein vom Menschen verursachtes Problem, und wir können nicht erwarten, dass Roboter die ganze Behebung für uns erledigen. Wenn Ihre Entwicklungskohorte nicht effektiv weitergebildet wird — nicht nur ein jährliches Seminar, sondern geeignete Schulungsbausteine —, dann laufen Sie immer Gefahr, minderwertigen Code als Standard zu akzeptieren, und das damit verbundene Sicherheitsrisiko.

Haben Sie die Bereitschaft Ihrer Entwickler überschätzt?

Entwickler werden selten nach ihren Fähigkeiten zur sicheren Codierung bewertet, und das ist nicht ihre Priorität (und in vielen Fällen auch kein KPI). Sie können nicht die Sündenbock für schlechte Sicherheitspraktiken sein, wenn ihnen nicht ein besserer Weg aufgezeigt oder gesagt wird, dass dies ein Maßstab für ihren Erfolg ist.

Allzu oft wird in Unternehmen jedoch davon ausgegangen, dass die bereitgestellten Leitlinien das Entwicklungsteam effektiv darauf vorbereitet haben, allgemeine Sicherheitsrisiken zu minimieren. Abhängig von der Schulung und ihrem Bewusstsein für die Anwendung bewährter Sicherheitsmethoden sind sie möglicherweise nicht darauf vorbereitet, die erwünschte erste Verteidigungslinie zu sein (und zu verhindern, dass endlose Fehler die Pentest-Berichte verstopfen).

Im Idealfall werden Lernpfade mit zunehmender Komplexität abgeschlossen und die daraus resultierenden Fähigkeiten verifiziert, um sicherzustellen, dass sie für den Entwickler in der realen Welt tatsächlich funktionieren. Dazu ist jedoch ein kultureller Standard erforderlich, bei dem Entwickler von Anfang an berücksichtigt und korrekt befähigt werden. Wenn wir als Branche in die Wildnis gehen, um diese riesige Codelandschaft zu verteidigen, die wir selbst erstellt haben, brauchen wir jede Hilfe, die wir bekommen können... und es liegt mehr direkt vor uns, als wir denken.

Avec la publication par l'OWASP de son Top Ten 2025, les entreprises doivent prêter une attention particulière à quelques nouvelles catégories de risques, dont une toute nouvelle qui prouve, une fois pour toutes, que ce que vous ne savez pas peut effectivement vous nuire.

La nouvelle catégorie, Mauvaise gestion des conditions exceptionnelles, décrit ce qui peut se passer lorsque les organisations ne sont pas préparées à prévenir, détecter et répondre à des situations inhabituelles ou imprévisibles. Selon l'OWASP, cette vulnérabilité peut se déclencher lorsqu'une application n'empêche pas quelque chose d'inhabituel de se produire, n'identifie pas un problème lorsqu'il survient et/ou réagit mal ou pas du tout lorsqu'une situation inattendue se présente. 

L'idée que les entreprises doivent être prêtes à faire face à ce qu'elles n'ont pas vu venir reflète la réalité des systèmes hautement distribués et interconnectés d'aujourd'hui. Et ce n'est pas comme si l'OWASP parlait de problèmes inédits - la mauvaise gestion des circonstances exceptionnelles contient 24 énumérations de faiblesses communes (CWE). C'est simplement que ces CWE, qui impliquent une mauvaise gestion des erreurs, l'impossibilité d'ouvrir des événements, des erreurs logiques et d'autres scénarios, peuvent se produire dans des conditions anormales. Cela peut résulter, par exemple, d'une validation inadéquate des entrées, d'erreurs de haut niveau dans les fonctions de traitement et d'un traitement incohérent (ou inexistant) des exceptions. Comme l'indique l'OWASP, "chaque fois qu'une application n'est pas sûre de sa prochaine instruction, une condition exceptionnelle a été mal gérée".

Ces circonstances exceptionnelles peuvent faire basculer les systèmes dans un état imprévisible, entraînant des pannes, des comportements inattendus et des vulnérabilités durables en matière de sécurité. Pour éviter ce type de perturbation, il faut essentiellement s'attendre au pire et prévoir de se préparer à l'imprévu.

[VOIR VIDÉO]

Circonstances exceptionnelles et évolution du Top 10

La composition de la liste quadriennale des dix risques les plus graves pour la sécurité des applications web est restée relativement stable au fil des ans, avec quelques catégories qui se déplacent dans la liste et peut-être un ou deux ajouts tous les quatre ans. L'édition 2025 compte deux nouvelles entrées, dont la mauvaise gestion des conditions exceptionnelles, qui arrive en 10e position. L'autre catégorie, celle des défaillances de la chaîne d'approvisionnement en logiciels, qui occupe la troisième place, est une extension d'une catégorie antérieure, celle des composants vulnérables et obsolètes (n° 6 en 2021), qui comprend désormais un large éventail de compromissions logicielles. (Pour ceux qui comptent les points, le contrôle d'accès défaillant reste le risque numéro 1). 

Les conditions exceptionnelles qui constituent la catégorie la plus récente peuvent créer une multitude de vulnérabilités, des bogues logiques aux débordements, et des transactions frauduleuses aux problèmes de mémoire, de synchronisation, d'authentification, d'autorisation et d'autres facteurs. Ces types de vulnérabilités peuvent avoir un impact sur la confidentialité, la disponibilité et l'intégrité d'un système ou de ses données. Elles permettent à un attaquant de manipuler le traitement défectueux des erreurs d'une application, par exemple, pour exploiter la vulnérabilité, a déclaré l'OWASP. 

Un exemple d'incapacité à gérer des conditions inattendues est celui d'une application qui identifie des exceptions pendant le téléchargement de fichiers lors d'une attaque par déni de service, mais qui ne libère pas les ressources par la suite. Dans ce cas, les ressources restent bloquées ou indisponibles, ce qui entraîne l'épuisement des ressources. Si un pirate s'introduit dans une transaction financière en plusieurs étapes, un système qui n'annule pas la transaction lorsqu'une erreur est détectée peut permettre au pirate de vider le compte de l'utilisateur. Si une erreur est détectée au cours d'une transaction, il est très important de procéder à un "échec fermé", c'est-à-dire d'annuler toute la transaction et de la recommencer. Essayer de récupérer une transaction en cours de route peut créer des erreurs irrécupérables.

Défaut fermé ou défaut ouvert

Quelle est donc la différence entre ces deux actions ? Clarifions les choses :

Défaillance ouverte: si un système est "défaillant ouvert", il continue à fonctionner ou reste "ouvert" en cas de problème. Cette solution est utile lorsqu'il est très important que les choses continuent à fonctionner, mais elle peut être risquée en termes de sécurité.

Fermé par défaut: Si un système est "fermé par défaut", il s'arrête automatiquement ou se met en sécurité en cas de problème. Cette méthode est plus sûre du point de vue de la sécurité, car elle permet d'éviter les accès non autorisés.

Gestion des erreurs imprévues

Pour prévenir ce type de risque, il faut d'abord prévoir l'inconnu. Cela implique d'être en mesure de détecter toute erreur système possible lorsqu'elle se produit et de prendre des mesures pour résoudre le problème. Vous devez être en mesure d'informer correctement l'utilisateur (sans révéler d'informations critiques à l'attaquant), d'enregistrer l'événement et, le cas échéant, de lancer une alerte. 

Voici un exemple de divulgation d'une erreur de requête SQL, ainsi que du chemin d'installation du site, qui peut être utilisé pour identifier un point d'injection :

Warning : odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:appindex_new.php on line 188

Dans l'idéal, un système devrait disposer d'un gestionnaire d'exception global pour détecter les erreurs négligées, ainsi que de fonctions telles que des outils de surveillance ou d'observabilité, ou d'une fonction qui détecte les erreurs répétées ou les schémas qui pourraient signaler une attaque en cours. Cela peut aider à se défendre contre les attaques visant à tirer parti des faiblesses de l'entreprise en matière de traitement des erreurs.

Pour une application web Java standard, par exemple, un gestionnaire d'erreurs global peut être configuré au niveau du descripteur de déploiement web.xml - dans ce cas, une configuration utilisée à partir de la version 2.5 de la spécification Servlet.

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

ns="http://java.sun.com/xml/ns/javaee"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
‍
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"

‍‍version="3.0">
...
  <error-page>
     <exception-type>java.lang.Exception</exception-type>
     <location>/error.jsp</location>
</error-page>
...
</web-app>
‍

Ce petit bloc de code indique à une application web Java ce qu'il faut faire lorsque quelque chose ne va pas dans les coulisses. Au lieu d'afficher aux utilisateurs un message d'erreur confus ou un écran vide, il détecte discrètement le problème et les envoie vers une page d'erreur personnalisée. Dans ce cas, cette page serait error.jsp.

Parce qu'il est configuré pour gérer les types généraux d'exceptions java.lang.Exception, il agit comme un gestionnaire d'erreurs principal pour l'ensemble de l'application. Cela signifie que, quel que soit l'endroit où une erreur se produit, les utilisateurs seront redirigés vers la même page d'erreur conviviale et cohérente au lieu de voir des détails techniques bruts.

Prévenir l'inattendu

Dans l'idéal, les organisations devraient s'efforcer d'empêcher, autant que possible, que des conditions exceptionnelles ne se produisent. La mise en œuvre de limitations de débit, de quotas de ressources, d'étranglements et d'autres limites peut aider à lutter contre les attaques par déni de service et par force brute, par exemple. Vous voudrez peut-être identifier les erreurs répétées identiques et les inclure uniquement dans les statistiques, afin qu'elles n'interfèrent pas avec la journalisation et la surveillance automatisées. Un système doit également comprendre

une validation stricte des entrées, afin de garantir que seules des données correctement formées et assainies entrent dans le flux de travail. Elle doit intervenir tôt dans le flux de données, idéalement dès la réception des données.

Les meilleures pratiques en matière de traitement des erreurs, afin d'attraper les erreurs là où elles se produisent. Elles doivent être traitées efficacement : Indiquez clairement aux utilisateurs qu'ils doivent tenir un journal et envoyer des alertes si nécessaire. Un gestionnaire d'erreurs global est également idéal pour rattraper tout ce qui n'a pas été pris en compte. 

La sécurité générale des transactions est également indispensable. Toujours "fail closed" : si quelque chose ne va pas, annulez l'ensemble de la transaction. Et n'essayez pas de réparer une transaction à mi-chemin, car cela peut entraîner des problèmes plus importants.

La centralisation de la journalisation, de la surveillance et des alertes, ainsi qu'un gestionnaire d'exception global, qui permet d'enquêter rapidement sur les incidents et d'uniformiser le processus de traitement des événements, tout en facilitant le respect des exigences de conformité.

Modélisation de la menace et/ou examen de la conception sécurisée, effectués au cours de la phase de conception des projets.

L'examen du code ou l'analyse statique, ainsi que les tests de stress, de performance et de pénétration effectués sur le système final.

La mauvaise gestion des conditions exceptionnelles est peut-être une nouvelle catégorie, mais elle fait appel à certains principes de base de la cybersécurité et souligne pourquoi les entreprises doivent être préparées à ce qu'elles n'anticipent pas nécessairement. Vous ne savez peut-être pas quelle forme prendront les conditions exceptionnelles, mais vous savez qu'elles se produiront. L'essentiel est d'être prêt à les gérer toutes de la même manière, ce qui facilitera la détection et la réponse à ces conditions lorsque l'inévitable se produira. 

Note aux utilisateurs duSCW Trust Score™ :

Comme nous mettons à jour le contenu de notre Learning Platform pour l'aligner sur la norme OWASP Top 10 2025, il se peut que vous observiez des ajustements mineurs dans le score de confiance de vos développeurs Full Stack. N'hésitez pas à contacter votre représentant Customer Success si vous avez des questions ou si vous avez besoin d'aide.

Avec l'arrivée très attendue du Top 10 de l'OWASP 2025, les entreprises doivent faire face à une série de nouvelles menaces auxquelles elles doivent prêter une attention particulière, dont une qui figure en tête de liste. Les failles dans la chaîne logistique des logiciels, qui constituent une nouvelle catégorie mais ne sont pas tout à fait nouvelles, occupent la troisième place du classement quadriennal des risques de sécurité les plus graves pour les applications web établi par l'Open Web Application Security Project. Il s'agit d'un risque que les entreprises doivent prendre très au sérieux, si ce n'est déjà le cas.

Les erreurs dans la chaîne logistique des logiciels proviennent d'une catégorie de la liste précédente de 2021. Composants vulnérables et obsolètes, elle englobe désormais un éventail plus large de compromis dans l'ensemble de l'écosystème logiciel, depuis les dépendances jusqu'aux systèmes de compilation et aux infrastructures de distribution. Son apparition dans la liste n'est pas particulièrement surprenante compte tenu des dommages causés par des attaques de grande envergure contre la chaîne d'approvisionnement, comme SolarWinds en 2019, le piratage de Bybit au début de cette année et la campagne Shai-Hulud en cours, un ver npm particulièrement malveillant et auto-réplicatif qui sème le chaos dans les environnements de développement exposés.

Le Top 10 de l'OWASP est généralement cohérent, ce qui correspond à une liste publiée tous les quatre ans, mais avec des mises à jour intermédiaires. Il y a généralement quelques changements dans la liste : l'injection, qui figure depuis longtemps dans le classement, passe par exemple de la 3e à la 5e place, et la conception non sécurisée recule de deux places pour se classer 6e, tandis que la mauvaise configuration de la sécurité passe de la 5e à la 2e place. Le contrôle d'accès défaillant conserve la première place. L'édition 2025 comprend deux nouvelles entrées : les failles déjà mentionnées dans la chaîne logistique des logiciels et la mauvaise gestion des conditions exceptionnelles, qui occupent la 10e place de la liste. Nous allons ici examiner de plus près la nouvelle entrée concernant les failles de sécurité dans la chaîne logistique.

[REGARDER LA VIDÉO]

Les failles de sécurité peuvent apparaître presque partout.

Les défaillances de la chaîne logistique logicielle constituent une catégorie quelque peu inhabituelle dans cette liste, car elles sont les moins fréquentes parmi les 10 entrées répertoriées dans les données de recherche de l'OWASP, mais elles présentent également les valeurs moyennes d'exploitation et d'impact les plus élevées, qui résultent des cinq Common Weakness Enumerations (CWE) de cette catégorie. OWASP estime que la présence limitée de cette catégorie est due aux défis actuels liés aux tests dans ce domaine, qui pourraient finalement s'améliorer. Indépendamment de cela, les participants à l'enquête ont cité à une écrasante majorité les défaillances de la chaîne logistique des logiciels comme étant le principal problème.

La plupart des failles de sécurité dans la chaîne d'approvisionnement découlent de la mise en réseau des activités commerciales, auxquelles participent des partenaires en amont et en aval ainsi que des tiers. Chaque interaction implique des logiciels dont les composants (également appelés dépendances ou bibliothèques) peuvent être vulnérables. Une entreprise peut être vulnérable si elle ne suit pas toutes les versions de ses propres composants (côté client, côté serveur ou imbriqués) ainsi que les dépendances transitives (provenant d'autres bibliothèques) afin de s'assurer qu'ils ne sont pas vulnérables, qu'ils ne sont pas pris en charge ou qu'ils ne sont pas obsolètes. Les composants ont généralement les mêmes droits que l'application, de sorte que les composants compromis, y compris ceux provenant de fournisseurs tiers ou de référentiels open source, peuvent avoir des conséquences importantes. Il est essentiel d'appliquer les correctifs et les mises à jour en temps opportun. Même des plans de correctifs mensuels ou trimestriels réguliers peuvent exposer une entreprise à des risques pendant des jours, voire des mois.

De même, l'absence d'un processus de gestion du changement dans votre chaîne d'approvisionnement peut entraîner des failles de sécurité si vous ne suivez pas les environnements de développement intégrés (IDE) ou les modifications apportées à votre référentiel de code, à vos référentiels d'images et de bibliothèques ou à d'autres parties de la chaîne d'approvisionnement. Une entreprise doit sécuriser sa chaîne logistique en appliquant des contrôles d'accès et des politiques de privilèges minimaux afin de garantir que personne ne puisse créer de code et le déployer en production sans surveillance, et que personne ne puisse télécharger des composants provenant de sources non fiables.

Les attaques contre la chaîne d'approvisionnement peuvent prendre de nombreuses formes. La célèbre attaque SolarWinds a commencé lorsque des pirates russes ont introduit un logiciel malveillant dans une mise à jour du célèbre logiciel de gestion de réseau de l'entreprise. Environ 18 000 clients ont été touchés. Bien que le nombre d'entreprises réellement touchées soit plutôt de l'ordre de 100, cette liste comprenait également de grandes entreprises et des agences gouvernementales. Le piratage de Bybit, d'une valeur de 1,5 milliard de dollars, attribué à la Corée du Nord, a affecté des applications de cryptomonnaie compromises. La récente attaque de Glaswurm contre la chaîne d'approvisionnement impliquait un code invisible et auto-réplicatif qui a infecté l'Open VSX Marketplace.

Prévention des vulnérabilités dans la chaîne d'approvisionnement

Étant donné que les attaques contre la chaîne d'approvisionnement concernent l'interdépendance des systèmes, leur prévention nécessite une approche globale. L'OWASP fournit des conseils pour prévenir les attaques, notamment la mise en place de processus de gestion des correctifs pour :

• Veuillez vous informer sur votre nomenclature logicielle (SBOM) pour l'ensemble du logiciel et gérer la SBOM de manière centralisée. Il est recommandé de générer les SBOM pendant la compilation et non après, à l'aide de formats standard tels que SPDX ou CyclonedX, et de publier au moins une SBOM lisible par machine par version.
• Veuillez suivre toutes vos dépendances, y compris les dépendances transitives, et supprimer les dépendances inutilisées ainsi que les fonctions, composants, fichiers et documentations inutiles.
• Veuillez inventorier en continu les composants côté client et côté serveur ainsi que leurs dépendances à l'aide d'outils tels que OWASP Dependency Scanner ou retire.js.
• Restez informé des failles de sécurité et surveillez en permanence des sources telles que le site Web Common Vulnerabilities and Exposures (CVE) et la National Vulnerability Database (NVD). Nous vous recommandons également de vous abonner aux notifications par e-mail concernant les failles de sécurité liées aux composants que vous utilisez.
• Veuillez utiliser des composants provenant uniquement de sources fiables via des liens sécurisés. Un fournisseur fiable serait par exemple disposé à collaborer avec un chercheur afin de publier un CVE que ce dernier a découvert dans un composant.
• Veuillez sélectionner avec soin la version d'une dépendance que vous souhaitez utiliser et procéder à la mise à niveau uniquement si cela est nécessaire. Utilisez des bibliothèques tierces dont les failles de sécurité ont été publiées dans une source reconnue telle que NVD.
• Veuillez vérifier si les bibliothèques et les composants ne sont pas maintenus ou pris en charge. Si l'application d'un correctif n'est pas possible, il est recommandé d'envisager la mise en place d'un correctif virtuel afin de surveiller, détecter ou prévenir le problème identifié.
• Veuillez mettre à jour régulièrement les outils de développement.
• Veuillez traiter les composants de votre pipeline CI/CD comme faisant partie intégrante de ce processus en les renforçant et en les surveillant, tout en documentant les modifications.

La gestion du changement ou un processus de suivi doivent également s'appliquer à vos paramètres CI/CD, vos référentiels de code, vos sandbox, vos environnements de développement intégrés (IDE), vos outils SBOM, vos artefacts créés, vos systèmes de journalisation et vos journaux, vos intégrations tierces telles que SaaS, votre référentiel d'artefacts et votre registre de conteneurs. Il est également nécessaire de sécuriser les systèmes, depuis les postes de travail des développeurs jusqu'au pipeline CI/CD. Veuillez vous assurer d'activer l'authentification multifactorielle tout en appliquant des politiques strictes de gestion des identités et des accès.

La protection contre les défaillances de la chaîne logistique des logiciels est une entreprise complexe et continue dans notre monde fortement interconnecté. Les entreprises doivent mettre en place des mesures de défense solides tout au long du cycle de vie de leurs applications et composants afin de se protéger contre cette menace moderne en constante évolution.

Remarque à l'attention des utilisateursdu SCW Trust Score™ :

Pendant que nous actualisons le contenu de notre plateforme d'apprentissage afin de l'adapter à la norme OWASP Top 10 2025, vous constaterez peut-être de légères modifications dans le Trust Score de vos développeurs Full Stack. Veuillez contacter votre chargé de clientèle si vous avez des questions ou si vous avez besoin d'aide.

Tous les quelques années, le monde de la sécurité connaît un moment qui relance le débat. La publication de l'édition 2025 du Top 10 de l'OWASP est l'un de ces moments. Il s'agit de la première mise à jour majeure depuis 2021, et bien que la plupart des menaces habituelles figurent toujours sur la liste, la nouvelle structure met en évidence les risques auxquels les équipes logicielles modernes sont confrontées aujourd'hui. Il convient de mentionner le chaos des dépendances, la complexité des systèmes distribués et le rôle croissant de l'IA dans l'écriture et le déploiement de code.

Deux domaines ressortent particulièrement dans la liste de 2025 : les erreurs dans la chaîne logistique des logiciels et la mauvaise gestion des conditions exceptionnelles. Ces deux points reflètent la réalité selon laquelle les développeurs ne créent plus d'applications dans des environnements clairs et isolés. Ils collaborent avec des bibliothèques, des gestionnaires de paquets, des API, des services distribués et des outils d'IA tiers qui génèrent du code pour eux. Les équipes de développement ont depuis longtemps compris que les problèmes en amont ou les erreurs imprévues peuvent rapidement avoir des répercussions en cascade. La reconnaissance de cette réalité par l'OWASP confirme ce que les équipes constatent depuis des années.

Secure Code Warrior entièrement aligné la plateforme sur le Top 10 OWASP 2025, et nous souhaitons rendre cette transition aussi fluide et pratique que possible. Vous trouverez ci-dessous les informations relatives aux mises à jour effectuées, leur importance et la manière dont les équipes peuvent utiliser les nouveaux contenus dès aujourd'hui.

Pourquoi cette mise à jour est-elle importante ?

La révision 2025 du Top 10 de l'OWASP représente plus qu'un simple remaniement des catégories. Elle tient compte des réalités du paysage actuel du développement, notamment les modèles d'authentification modernes, les chaînes de dépendance, les architectures distribuées et l'influence croissante du code généré par l'IA. Ces changements renforcent la nécessité pour les développeurs d'acquérir des compétences pratiques et concrètes afin d'identifier et de prévenir les problèmes à un stade précoce.

C'est ici que les contenus OWASP actualisés de Secure Code Warrior deviennent Secure Code Warrior . Des thèmes tels que la vulnérabilité de la chaîne d'approvisionnement, la gestion sécurisée des erreurs et les risques liés à l'automatisation nécessitent des exercices pratiques, et non de la théorie. Les quêtes mises à jour, les thèmes liés aux vulnérabilités, les contenus d'apprentissage en autodidacte et les cours de SCW rendent ces connaissances accessibles et applicables. Les développeurs ont ainsi la possibilité de développer de véritables compétences dans les langages et les frameworks qu'ils utilisent quotidiennement.

Secure Code Warrior le processus

La structure OWASP Top 10 2025 est désormais intégrée à l'ensemble de l'expérience d'apprentissage SCW. Cela comprend des mises à jour des quêtes, des thèmes liés aux vulnérabilités, du contenu d'autoformation dans Learn, des cours et le cadre SCW Trust^Score®. Les développeurs acquièrent désormais naturellement les compétences du Top 10 OWASP 2025 dans le contexte de leur langage web, et les responsables peuvent évaluer les compétences par rapport aux normes les plus récentes.

Quêtes et thèmes liés à la vulnérabilité

L'un des principaux avantages de SCW est que l'OWASP est déjà intégré au cœur de nos quêtes, qui sont basées sur les failles de sécurité. Le nouveau Top 10 de l'OWASP est désormais directement intégré aux normes qui définissent tous les objectifs des quêtes. Cela signifie que :

• Chaque quête en ligne qui utilisait la norme OWASP Top 10 2021 utilise désormais la norme OWASP Top 10 2025 mise à jour dans sa structure.
• Les objectifs des quêtes de vulnérabilité Top 3, Top 5 et Top 10 sont automatiquement dérivés de l'OWASP Web Top 10 2025 pour tous les langages web pertinents.
• Nous utilisons les 10 normes principales de l'OWASP et d'autres normes industrielles importantes telles que CERT-C afin de garantir que la formation des développeurs couvre les sujets les plus pertinents et les plus importants pour les langages et les frameworks qu'ils utilisent.

Cours et plus encore

Toutes les quêtes et tous les cours liés à l'OWASP ont été mis à jour et réorganisés afin de refléter la nouvelle structure. Le contenu de Learn destiné à l'autoformation a également été mis à jour. L'ordre des modules, la terminologie et l'attribution des catégories ont été actualisés afin que les développeurs bénéficient d'instructions claires et précises, conformes à la norme de 2025.

^{SCW-Vertrauenswert®} 

Le SCW Trust Score reflète désormais les compétences et les progrès des développeurs dans le cadre de la structure de catégories actualisée OWASP Top 10 2025. Les clients pourraient remarquer de légères modifications dans les évaluations des développeurs Full Stack suite à cette adaptation. Cela est normal et garantit que le Trust Score reste correct et à jour, et qu'il correspond à la taxonomie OWASP Top 10 2025.

En avant avec le Top 10 OWASP 2025

La mise à jour OWASP Top 10 2025 représente une étape importante pour le secteur. OWASP a créé une structure qui reflète mieux la manière dont les logiciels sont développés aujourd'hui, et Secure Code Warrior fier d'aider les équipes à l'adopter rapidement et en toute sécurité. Toutes les mises à jour concernant les quêtes, les thèmes de vulnérabilité, Courses le Trust Score ont déjà été implémentées sur la plateforme. Vos développeurs disposent désormais du contenu, des instructions et de la structure nécessaires pour créer des logiciels plus sécurisés, et vos équipes de direction ont les informations requises pour évaluer les compétences par rapport aux dernières normes mondiales.

Si vous avez besoin d'aide pour intégrer ces mises à jour dans vos programmes existants, votre Secure Code Warrior ou votre responsable de la réussite client se fera un plaisir de vous assister. Ils pourront vous expliquer les changements apportés, leur impact sur vos équipes et comment tirer le meilleur parti du nouveau contenu OWASP Top 10 2025.