Skip to main content
Corgea verwendet KI, um potenzielle Schwachstellen zu analysieren und festzustellen, ob sie wahrscheinlich False Positives sind. Die False-Positive-Analyse berücksichtigt unter anderem den Codekontext, die Art der Schwachstelle sowie relevante Programmiermuster und Best Practices. Das Modell bewertet den Befund als wahrscheinlich „valid“ oder „false positive“ und begründet diese Einschätzung. Wenn das Modell eine Schwachstelle als False Positive einstuft, erläutert es die Gründe für diese Bewertung. Corgea stellt die False-Positive-Analyse zusammen mit der Erläuterung der Schwachstelle und dem vorgeschlagenen Fix bereit. Entwickler können dadurch tatsächliche Schwachstellen schneller erkennen und priorisieren, ohne unnötig Zeit für Fehlalarme aufzuwenden.

​
Einen Befund als False Positive markieren

Wenn Sie einen Befund als False Positive markieren, begründen Sie nachvollziehbar, warum keine echte Schwachstelle vorliegt, etwa weil der Code unerreichbar ist, Eingaben bereinigt werden oder der Code nur in Tests verwendet wird. Eine Bezeichnung wie „False Positive“ oder ein Platzhalter wie „N/A“ reicht nicht aus. Dies gilt für einzelne Befunde, Sammelentscheidungen und Anfragen über Pull-Request-Kommentare. Wird Ihre Begründung abgelehnt, ergänzen Sie den fehlenden Kontext und versuchen Sie es erneut.

​
Typische von Corgea erkennbare False Positives

Dies sind einige Beispiele für False Positives, die Corgea erkennen kann:
  • Cross-Site Scripting: Überprüft, ob Benutzereingaben korrekt bereinigt oder kodiert werden, bevor sie mithilfe etablierter Bibliotheken oder Frameworks auf der Webseite angezeigt werden.
  • SQL-Injection: Prüft, ob Datenbankabfragen nach Best Practices vollständig parametrisierte oder vorbereitete Anweisungen verwenden und keine manipulierbaren Benutzer- oder externen Eingaben enthalten.
  • Offenlegung von Informationen: Prüft, ob die offengelegten sensiblen Informationen generischer Natur sind oder nur in einer Entwicklungsumgebung auftreten.
  • Unbehandelte Ausnahme: Prüft, ob der unerwartete Zustand in nicht kritischen Teilen der Anwendung anderweitig behandelt wird, beispielsweise durch Logging oder Monitoring.
  • Hartcodiertes Passwort: Überprüft, ob das hartcodierte Passwort für eine Nicht-Produktionsumgebung bestimmt oder für automatisierte Tests verwendet wird.
  • Passwort in Konfigurationsdatei: Überprüft, ob die Speicherung des Klartextpassworts durch alternative Sicherheitsmaßnahmen wie verschlüsselte Speicherung oder Zugriffskontrollen geschützt ist.
  • Hartcodierter kryptografischer Schlüssel: Überprüft, ob der hartcodierte kryptografische Schlüssel nur zu Testzwecken verwendet wird.
  • Cross-Site Request Forgery: Überprüft, ob Anti-CSRF-Tokens implementiert und serverseitig validiert werden oder ob der Code eine API ist, bei der CSRF-Schutz nicht anwendbar ist.
  • Fehlende Integritätsprüfung: Prüft, ob die Integrität durch alternative Verfahren wie digitale Signaturen oder Hash-Validierung sichergestellt wird.
  • Hartcodierte Zugangsdaten: Prüft, ob hartcodierte Zugangsdaten ausschließlich zu Testzwecken verwendet werden.
  • Code-Injektion: Überprüft, ob der Punkt für Code-Injektionen auf eine kontrollierte Umgebung beschränkt ist oder ob Eingabevalidierung und Ausgabeencoding angewendet werden.
Weitere Beispiele werden ebenfalls erkannt.