GitHub-Nutzer werden mit Klartext-Schmerzen zu Lösegeld gezwungen
... ein Dritter hat auf dein Repository zugegriffen, indem er den richtigen Benutzernamen und das richtige Passwort für einen der Benutzer verwendet hat, die die Erlaubnis haben, auf dein Repository zuzugreifen. Wir glauben, dass diese Anmeldeinformationen möglicherweise über einen anderen Dienst durchgesickert sind, da andere Git-Hosting-Dienste einem ähnlichen Angriff ausgesetzt sind.
Als Nutzer eines webbasierten Dienstes ist es nie eine gute Erfahrung, eine solche E-Mail über einen möglichen Verstoß gegen Ihre persönlichen Daten zu erhalten. Stellen Sie sich nun vor, dass es sich bei den Daten um ein Code-Repository handelt, das Ihre harte Arbeit oder sogar die Geschäftsgeheimnisse Ihrer Software repräsentiert. Mindestens 392 (bisher) GitHub, Bitbucket und GitLab Benutzer haben diese Woche diese herzzerreißende Benachrichtigung erhalten, und was noch mehr ist - ihr Code wurde von den Angreifern heruntergeladen, aus dem Repository gelöscht und als Lösegeld erpresst. Sobald alle Dateien der betroffenen Benutzer verschwunden sind, bleibt nur noch eine Textdatei mit dieser Meldung übrig:
Im Gegensatz zu den meisten anderen berichtenswerten Unternehmensverstößen (und sogar frühere Angriffe auf GitHub) wurde dieser nicht durch einen Bug auf ihrer Plattform verursacht. Vielmehr wurden Kontoinformationen unsicher im Klartext gespeichert und sind wahrscheinlich aus Repository-Management-Diensten Dritter durchgesickert. Entwickler haben aktiv wichtige Passwörter falsch gespeichert und häufig dieselben Zugangsdaten für mehrere hochwertige Konten wiederverwendet.
Es scheint, dass die Betrüger nicht die besten und klügsten der Programmierwelt sind, da (zum Zeitpunkt des Schreibens) kein einziger Benutzer das Lösegeld gezahlt hat, um seinen Code wiederherzustellen, und einige clevere sicherheitsbewusste Leute haben bereits Problemumgehungen für betroffene Benutzer gefunden gelöschten Code wiederherstellen.
Dennoch werden dadurch Probleme aufgezeigt, die wir in der Sicherheitsbranche seit langem kennen: Die meisten Entwickler sind einfach nicht ausreichend sicherheitsbewusst, und wertvolle Daten können jederzeit gefährdet sein... selbst für diejenigen, die keine Hacker-Genies sind.
Warum ist unser Passwortmanagement immer noch so schlecht?
Menschen haben natürlich Fehler, und wir neigen dazu, uns das Leben leichter zu machen. Es ist sicherlich viel einfacher, denselben Benutzernamen und dasselbe Passwort immer wieder zu verwenden, und es ist viel einfacher, sich den Namen Ihres ersten Welpen zu merken, als „z7B3#! q0HWxXv29!“ einzugeben nur um auf Ihre E-Mail zuzugreifen. Da jedoch ständig so viele groß angelegte Cyberangriffe stattfinden, sollten Entwickler es inzwischen wirklich besser wissen.
GitHubs eigener Rat In dieser Angelegenheit war es einfach zu beurteilen, dass dieser Lösegeldangriff nicht stattgefunden hätte, wenn eine Zwei-Faktor-Authentifizierung eingeführt worden wäre und sichere Passwortmanager verwendet worden wären. Das ist absolut richtig, aber wie ich immer wieder sage, es ist klar, dass die Bildung noch weiter gehen muss. Alle Entwickler müssen — auf einer grundlegenden Ebene — verstehen, warum bestimmte Aktionen ihre Konten anfällig für Angriffe machen könnten.
Bildung: Die magische Pille?
Sicherheitserfahrene Programmierer wissen, dass ein einfacher Fehlkonfiguration der Sicherheit kann verheerende Folgen haben, und im Fall dieses GitHub-Angriffs scheinen falsch konfigurierte Dateien dazu beigetragen zu haben, dass die Angreifer erfolgreich bösartige Skimmer injizieren konnten, um die Schlüssel zu ihren Schlössern zu finden.
Offenlegung sensibler Daten ist ebenfalls eine kritische Sicherheitslücke, die es zu überwinden gilt und immer noch auf Platz drei der OWASP Top 10 steht. Das Speichern von Passwörtern im Klartext ist ein klarer Beweis dafür, dass viele nicht verstehen, welche Gefahren damit verbunden sind und wie leicht Systeme durch Brute-Force-Passwortangriffe durchbrochen werden können.
Das Verständnis der Kryptografie (und insbesondere des kryptografischen Speichers) ist eine wichtige Komponente für die Verwaltung von Passwörtern in einer Codebasis mit eiserner Sicherheit. Wenn alle gespeicherten Passwörter erfolgreich gesalzen und gehasht werden, um ihre Eindeutigkeit zu erzwingen, wird es weitaus schwieriger werden, Situationen wie diesen Lösegeld-Vorfall zu erzwingen.
Es ist wichtig zu verstehen, dass sich unsere kollektive Einstellung zur Sicherheit ändern muss, wobei der Schwerpunkt mehr auf einer angemessenen Ausbildung der Entwickler und der Ernsthaftigkeit von Cyberbedrohungen liegen muss. Wir müssen das Lernen über Sicherheit zu einer positiven und lohnenden Erfahrung machen, und ich denke, das wird für eine allgemeine Anhebung der Standards für alle Entwickler, die ihre Arbeit selbst beurteilen, von grundlegender Bedeutung sein.
Möchten Sie versuchen, die Sicherheitslücken zu beheben, über die Sie hier gelesen haben? Du kannst verwandte Herausforderungen auf spielen Sicherer Codekrieger gerade jetzt:
Der jüngste Angriff auf GitHub-Repositorys verdeutlicht ein bekanntes Problem in der Sicherheitsbranche: Die meisten Entwickler sind einfach nicht ausreichend sicherheitsbewusst, und wertvolle Daten können jederzeit gefährdet sein.
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchen
Chief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
... ein Dritter hat auf dein Repository zugegriffen, indem er den richtigen Benutzernamen und das richtige Passwort für einen der Benutzer verwendet hat, die die Erlaubnis haben, auf dein Repository zuzugreifen. Wir glauben, dass diese Anmeldeinformationen möglicherweise über einen anderen Dienst durchgesickert sind, da andere Git-Hosting-Dienste einem ähnlichen Angriff ausgesetzt sind.
Als Nutzer eines webbasierten Dienstes ist es nie eine gute Erfahrung, eine solche E-Mail über einen möglichen Verstoß gegen Ihre persönlichen Daten zu erhalten. Stellen Sie sich nun vor, dass es sich bei den Daten um ein Code-Repository handelt, das Ihre harte Arbeit oder sogar die Geschäftsgeheimnisse Ihrer Software repräsentiert. Mindestens 392 (bisher) GitHub, Bitbucket und GitLab Benutzer haben diese Woche diese herzzerreißende Benachrichtigung erhalten, und was noch mehr ist - ihr Code wurde von den Angreifern heruntergeladen, aus dem Repository gelöscht und als Lösegeld erpresst. Sobald alle Dateien der betroffenen Benutzer verschwunden sind, bleibt nur noch eine Textdatei mit dieser Meldung übrig:
Im Gegensatz zu den meisten anderen berichtenswerten Unternehmensverstößen (und sogar frühere Angriffe auf GitHub) wurde dieser nicht durch einen Bug auf ihrer Plattform verursacht. Vielmehr wurden Kontoinformationen unsicher im Klartext gespeichert und sind wahrscheinlich aus Repository-Management-Diensten Dritter durchgesickert. Entwickler haben aktiv wichtige Passwörter falsch gespeichert und häufig dieselben Zugangsdaten für mehrere hochwertige Konten wiederverwendet.
Es scheint, dass die Betrüger nicht die besten und klügsten der Programmierwelt sind, da (zum Zeitpunkt des Schreibens) kein einziger Benutzer das Lösegeld gezahlt hat, um seinen Code wiederherzustellen, und einige clevere sicherheitsbewusste Leute haben bereits Problemumgehungen für betroffene Benutzer gefunden gelöschten Code wiederherstellen.
Dennoch werden dadurch Probleme aufgezeigt, die wir in der Sicherheitsbranche seit langem kennen: Die meisten Entwickler sind einfach nicht ausreichend sicherheitsbewusst, und wertvolle Daten können jederzeit gefährdet sein... selbst für diejenigen, die keine Hacker-Genies sind.
Warum ist unser Passwortmanagement immer noch so schlecht?
Menschen haben natürlich Fehler, und wir neigen dazu, uns das Leben leichter zu machen. Es ist sicherlich viel einfacher, denselben Benutzernamen und dasselbe Passwort immer wieder zu verwenden, und es ist viel einfacher, sich den Namen Ihres ersten Welpen zu merken, als „z7B3#! q0HWxXv29!“ einzugeben nur um auf Ihre E-Mail zuzugreifen. Da jedoch ständig so viele groß angelegte Cyberangriffe stattfinden, sollten Entwickler es inzwischen wirklich besser wissen.
GitHubs eigener Rat In dieser Angelegenheit war es einfach zu beurteilen, dass dieser Lösegeldangriff nicht stattgefunden hätte, wenn eine Zwei-Faktor-Authentifizierung eingeführt worden wäre und sichere Passwortmanager verwendet worden wären. Das ist absolut richtig, aber wie ich immer wieder sage, es ist klar, dass die Bildung noch weiter gehen muss. Alle Entwickler müssen — auf einer grundlegenden Ebene — verstehen, warum bestimmte Aktionen ihre Konten anfällig für Angriffe machen könnten.
Bildung: Die magische Pille?
Sicherheitserfahrene Programmierer wissen, dass ein einfacher Fehlkonfiguration der Sicherheit kann verheerende Folgen haben, und im Fall dieses GitHub-Angriffs scheinen falsch konfigurierte Dateien dazu beigetragen zu haben, dass die Angreifer erfolgreich bösartige Skimmer injizieren konnten, um die Schlüssel zu ihren Schlössern zu finden.
Offenlegung sensibler Daten ist ebenfalls eine kritische Sicherheitslücke, die es zu überwinden gilt und immer noch auf Platz drei der OWASP Top 10 steht. Das Speichern von Passwörtern im Klartext ist ein klarer Beweis dafür, dass viele nicht verstehen, welche Gefahren damit verbunden sind und wie leicht Systeme durch Brute-Force-Passwortangriffe durchbrochen werden können.
Das Verständnis der Kryptografie (und insbesondere des kryptografischen Speichers) ist eine wichtige Komponente für die Verwaltung von Passwörtern in einer Codebasis mit eiserner Sicherheit. Wenn alle gespeicherten Passwörter erfolgreich gesalzen und gehasht werden, um ihre Eindeutigkeit zu erzwingen, wird es weitaus schwieriger werden, Situationen wie diesen Lösegeld-Vorfall zu erzwingen.
Es ist wichtig zu verstehen, dass sich unsere kollektive Einstellung zur Sicherheit ändern muss, wobei der Schwerpunkt mehr auf einer angemessenen Ausbildung der Entwickler und der Ernsthaftigkeit von Cyberbedrohungen liegen muss. Wir müssen das Lernen über Sicherheit zu einer positiven und lohnenden Erfahrung machen, und ich denke, das wird für eine allgemeine Anhebung der Standards für alle Entwickler, die ihre Arbeit selbst beurteilen, von grundlegender Bedeutung sein.
Möchten Sie versuchen, die Sicherheitslücken zu beheben, über die Sie hier gelesen haben? Du kannst verwandte Herausforderungen auf spielen Sicherer Codekrieger gerade jetzt:
... ein Dritter hat auf dein Repository zugegriffen, indem er den richtigen Benutzernamen und das richtige Passwort für einen der Benutzer verwendet hat, die die Erlaubnis haben, auf dein Repository zuzugreifen. Wir glauben, dass diese Anmeldeinformationen möglicherweise über einen anderen Dienst durchgesickert sind, da andere Git-Hosting-Dienste einem ähnlichen Angriff ausgesetzt sind.
Als Nutzer eines webbasierten Dienstes ist es nie eine gute Erfahrung, eine solche E-Mail über einen möglichen Verstoß gegen Ihre persönlichen Daten zu erhalten. Stellen Sie sich nun vor, dass es sich bei den Daten um ein Code-Repository handelt, das Ihre harte Arbeit oder sogar die Geschäftsgeheimnisse Ihrer Software repräsentiert. Mindestens 392 (bisher) GitHub, Bitbucket und GitLab Benutzer haben diese Woche diese herzzerreißende Benachrichtigung erhalten, und was noch mehr ist - ihr Code wurde von den Angreifern heruntergeladen, aus dem Repository gelöscht und als Lösegeld erpresst. Sobald alle Dateien der betroffenen Benutzer verschwunden sind, bleibt nur noch eine Textdatei mit dieser Meldung übrig:
Im Gegensatz zu den meisten anderen berichtenswerten Unternehmensverstößen (und sogar frühere Angriffe auf GitHub) wurde dieser nicht durch einen Bug auf ihrer Plattform verursacht. Vielmehr wurden Kontoinformationen unsicher im Klartext gespeichert und sind wahrscheinlich aus Repository-Management-Diensten Dritter durchgesickert. Entwickler haben aktiv wichtige Passwörter falsch gespeichert und häufig dieselben Zugangsdaten für mehrere hochwertige Konten wiederverwendet.
Es scheint, dass die Betrüger nicht die besten und klügsten der Programmierwelt sind, da (zum Zeitpunkt des Schreibens) kein einziger Benutzer das Lösegeld gezahlt hat, um seinen Code wiederherzustellen, und einige clevere sicherheitsbewusste Leute haben bereits Problemumgehungen für betroffene Benutzer gefunden gelöschten Code wiederherstellen.
Dennoch werden dadurch Probleme aufgezeigt, die wir in der Sicherheitsbranche seit langem kennen: Die meisten Entwickler sind einfach nicht ausreichend sicherheitsbewusst, und wertvolle Daten können jederzeit gefährdet sein... selbst für diejenigen, die keine Hacker-Genies sind.
Warum ist unser Passwortmanagement immer noch so schlecht?
Menschen haben natürlich Fehler, und wir neigen dazu, uns das Leben leichter zu machen. Es ist sicherlich viel einfacher, denselben Benutzernamen und dasselbe Passwort immer wieder zu verwenden, und es ist viel einfacher, sich den Namen Ihres ersten Welpen zu merken, als „z7B3#! q0HWxXv29!“ einzugeben nur um auf Ihre E-Mail zuzugreifen. Da jedoch ständig so viele groß angelegte Cyberangriffe stattfinden, sollten Entwickler es inzwischen wirklich besser wissen.
GitHubs eigener Rat In dieser Angelegenheit war es einfach zu beurteilen, dass dieser Lösegeldangriff nicht stattgefunden hätte, wenn eine Zwei-Faktor-Authentifizierung eingeführt worden wäre und sichere Passwortmanager verwendet worden wären. Das ist absolut richtig, aber wie ich immer wieder sage, es ist klar, dass die Bildung noch weiter gehen muss. Alle Entwickler müssen — auf einer grundlegenden Ebene — verstehen, warum bestimmte Aktionen ihre Konten anfällig für Angriffe machen könnten.
Bildung: Die magische Pille?
Sicherheitserfahrene Programmierer wissen, dass ein einfacher Fehlkonfiguration der Sicherheit kann verheerende Folgen haben, und im Fall dieses GitHub-Angriffs scheinen falsch konfigurierte Dateien dazu beigetragen zu haben, dass die Angreifer erfolgreich bösartige Skimmer injizieren konnten, um die Schlüssel zu ihren Schlössern zu finden.
Offenlegung sensibler Daten ist ebenfalls eine kritische Sicherheitslücke, die es zu überwinden gilt und immer noch auf Platz drei der OWASP Top 10 steht. Das Speichern von Passwörtern im Klartext ist ein klarer Beweis dafür, dass viele nicht verstehen, welche Gefahren damit verbunden sind und wie leicht Systeme durch Brute-Force-Passwortangriffe durchbrochen werden können.
Das Verständnis der Kryptografie (und insbesondere des kryptografischen Speichers) ist eine wichtige Komponente für die Verwaltung von Passwörtern in einer Codebasis mit eiserner Sicherheit. Wenn alle gespeicherten Passwörter erfolgreich gesalzen und gehasht werden, um ihre Eindeutigkeit zu erzwingen, wird es weitaus schwieriger werden, Situationen wie diesen Lösegeld-Vorfall zu erzwingen.
Es ist wichtig zu verstehen, dass sich unsere kollektive Einstellung zur Sicherheit ändern muss, wobei der Schwerpunkt mehr auf einer angemessenen Ausbildung der Entwickler und der Ernsthaftigkeit von Cyberbedrohungen liegen muss. Wir müssen das Lernen über Sicherheit zu einer positiven und lohnenden Erfahrung machen, und ich denke, das wird für eine allgemeine Anhebung der Standards für alle Entwickler, die ihre Arbeit selbst beurteilen, von grundlegender Bedeutung sein.
Möchten Sie versuchen, die Sicherheitslücken zu beheben, über die Sie hier gelesen haben? Du kannst verwandte Herausforderungen auf spielen Sicherer Codekrieger gerade jetzt:
Klicken Sie auf den Link unten und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenEine Demo buchen
Chief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
... ein Dritter hat auf dein Repository zugegriffen, indem er den richtigen Benutzernamen und das richtige Passwort für einen der Benutzer verwendet hat, die die Erlaubnis haben, auf dein Repository zuzugreifen. Wir glauben, dass diese Anmeldeinformationen möglicherweise über einen anderen Dienst durchgesickert sind, da andere Git-Hosting-Dienste einem ähnlichen Angriff ausgesetzt sind.
Als Nutzer eines webbasierten Dienstes ist es nie eine gute Erfahrung, eine solche E-Mail über einen möglichen Verstoß gegen Ihre persönlichen Daten zu erhalten. Stellen Sie sich nun vor, dass es sich bei den Daten um ein Code-Repository handelt, das Ihre harte Arbeit oder sogar die Geschäftsgeheimnisse Ihrer Software repräsentiert. Mindestens 392 (bisher) GitHub, Bitbucket und GitLab Benutzer haben diese Woche diese herzzerreißende Benachrichtigung erhalten, und was noch mehr ist - ihr Code wurde von den Angreifern heruntergeladen, aus dem Repository gelöscht und als Lösegeld erpresst. Sobald alle Dateien der betroffenen Benutzer verschwunden sind, bleibt nur noch eine Textdatei mit dieser Meldung übrig:
Im Gegensatz zu den meisten anderen berichtenswerten Unternehmensverstößen (und sogar frühere Angriffe auf GitHub) wurde dieser nicht durch einen Bug auf ihrer Plattform verursacht. Vielmehr wurden Kontoinformationen unsicher im Klartext gespeichert und sind wahrscheinlich aus Repository-Management-Diensten Dritter durchgesickert. Entwickler haben aktiv wichtige Passwörter falsch gespeichert und häufig dieselben Zugangsdaten für mehrere hochwertige Konten wiederverwendet.
Es scheint, dass die Betrüger nicht die besten und klügsten der Programmierwelt sind, da (zum Zeitpunkt des Schreibens) kein einziger Benutzer das Lösegeld gezahlt hat, um seinen Code wiederherzustellen, und einige clevere sicherheitsbewusste Leute haben bereits Problemumgehungen für betroffene Benutzer gefunden gelöschten Code wiederherstellen.
Dennoch werden dadurch Probleme aufgezeigt, die wir in der Sicherheitsbranche seit langem kennen: Die meisten Entwickler sind einfach nicht ausreichend sicherheitsbewusst, und wertvolle Daten können jederzeit gefährdet sein... selbst für diejenigen, die keine Hacker-Genies sind.
Warum ist unser Passwortmanagement immer noch so schlecht?
Menschen haben natürlich Fehler, und wir neigen dazu, uns das Leben leichter zu machen. Es ist sicherlich viel einfacher, denselben Benutzernamen und dasselbe Passwort immer wieder zu verwenden, und es ist viel einfacher, sich den Namen Ihres ersten Welpen zu merken, als „z7B3#! q0HWxXv29!“ einzugeben nur um auf Ihre E-Mail zuzugreifen. Da jedoch ständig so viele groß angelegte Cyberangriffe stattfinden, sollten Entwickler es inzwischen wirklich besser wissen.
GitHubs eigener Rat In dieser Angelegenheit war es einfach zu beurteilen, dass dieser Lösegeldangriff nicht stattgefunden hätte, wenn eine Zwei-Faktor-Authentifizierung eingeführt worden wäre und sichere Passwortmanager verwendet worden wären. Das ist absolut richtig, aber wie ich immer wieder sage, es ist klar, dass die Bildung noch weiter gehen muss. Alle Entwickler müssen — auf einer grundlegenden Ebene — verstehen, warum bestimmte Aktionen ihre Konten anfällig für Angriffe machen könnten.
Bildung: Die magische Pille?
Sicherheitserfahrene Programmierer wissen, dass ein einfacher Fehlkonfiguration der Sicherheit kann verheerende Folgen haben, und im Fall dieses GitHub-Angriffs scheinen falsch konfigurierte Dateien dazu beigetragen zu haben, dass die Angreifer erfolgreich bösartige Skimmer injizieren konnten, um die Schlüssel zu ihren Schlössern zu finden.
Offenlegung sensibler Daten ist ebenfalls eine kritische Sicherheitslücke, die es zu überwinden gilt und immer noch auf Platz drei der OWASP Top 10 steht. Das Speichern von Passwörtern im Klartext ist ein klarer Beweis dafür, dass viele nicht verstehen, welche Gefahren damit verbunden sind und wie leicht Systeme durch Brute-Force-Passwortangriffe durchbrochen werden können.
Das Verständnis der Kryptografie (und insbesondere des kryptografischen Speichers) ist eine wichtige Komponente für die Verwaltung von Passwörtern in einer Codebasis mit eiserner Sicherheit. Wenn alle gespeicherten Passwörter erfolgreich gesalzen und gehasht werden, um ihre Eindeutigkeit zu erzwingen, wird es weitaus schwieriger werden, Situationen wie diesen Lösegeld-Vorfall zu erzwingen.
Es ist wichtig zu verstehen, dass sich unsere kollektive Einstellung zur Sicherheit ändern muss, wobei der Schwerpunkt mehr auf einer angemessenen Ausbildung der Entwickler und der Ernsthaftigkeit von Cyberbedrohungen liegen muss. Wir müssen das Lernen über Sicherheit zu einer positiven und lohnenden Erfahrung machen, und ich denke, das wird für eine allgemeine Anhebung der Standards für alle Entwickler, die ihre Arbeit selbst beurteilen, von grundlegender Bedeutung sein.
Möchten Sie versuchen, die Sicherheitslücken zu beheben, über die Sie hier gelesen haben? Du kannst verwandte Herausforderungen auf spielen Sicherer Codekrieger gerade jetzt:
Inhaltsverzeichniss
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Securecode-Schulung
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um der sich ständig ändernden Softwareentwicklungslandschaft unter Berücksichtigung Ihrer Rolle gerecht zu werden. Themen, die alles von KI bis XQuery Injection abdecken und für eine Vielzahl von Rollen angeboten werden, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Einblick in das Angebot unseres Inhaltskatalogs nach Themen und Rollen.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Ressourcen für den Einstieg
Cybermon is back: Beat the Boss KI-Missionen jetzt auf Abruf verfügbar
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzt fortschrittliche KI/LLM-Sicherheitsanforderungen ein, um die sichere KI-Entwicklung in einem großen Maßstab zu stärken.
Cyber-Resilienz-Gesetz erklärt: Was das für die Entwicklung von Secure by Design-Software bedeutet
Erfahren Sie, was der EU Cyber Resilience Act (CRA) verlangt, für wen er gilt und wie sich Entwicklungsteams mit sicheren Methoden, der Vorbeugung von Sicherheitslücken und dem Aufbau von Fähigkeiten für Entwickler darauf vorbereiten können.
