Gewinne:
- Fähigkeit, künstliche Intelligenz als zweites Auge zu nutzen und Schwachstellen der OWASP-Klasse (Injection, Hard Secret, Zugriffskontrolle) im Code durch Angabe von Kontext zu kennzeichnen
- Fähigkeit, durch künstliche Intelligenz erzeugte Fehlalarme mit Kontext zu eliminieren und zu verhindern, dass jeder Befund als echte Schwachstelle behandelt wird, ohne ihn zu validieren
- Fähigkeit zu erkennen, dass die von der künstlichen Intelligenz vorgeschlagene Lösung neue Schwachstellen/Bugs einführen kann, und jeden Patch durch die Überprüfungs- und Test-Gate zu leiten
Schwachstellen innerhalb von Software gehören zu den teuersten Schwachstellen, da sie von Anfang an in das Produkt eingebettet sind und an Millionen von Benutzern verteilt werden. Bei der sicheren Codeüberprüfung wird der Quellcode Zeile für Zeile gelesen und Schwachstellen – SQL-Injection, Authentifizierungsschwachstelle, hartcodiertes Passwort, falsche Autorisierung – erkannt, bevor sie in Produktion gehen. Wenn es von Hand gemacht wird, ist es langsam und ermüdend; Es ist leicht, eine Schwachstelle in einer großen Codebasis zu übersehen.
KI ist aus zwei Gründen bei der Codeüberprüfung leistungsstark: Code ist auch eine Sprache und KI ist gut in der Mustererkennung. KI kann gefährliche Muster in einem Codeabschnitt schnell erkennen (direkte Eingabe von Benutzereingaben in die Abfrage, unverschlüsselte Datenspeicherung, fehlende Eingabevalidierung), erklären, warum jedes einzelne Muster riskant ist, und eine Lösung vorschlagen. Aber die KI sieht nicht den gesamten Betriebskontext des Codes (die Eingabe wird möglicherweise auf einer anderen Ebene gelöscht), sie kann eine Schwachstelle erfinden, die nicht existiert (falsch positiv) oder eine echte Schwachstelle übersehen (falsch negativ), und am wichtigsten ist, dass die von ihr vorgeschlagene „Lösung“ möglicherweise eine neue Schwachstelle oder einen neuen Fehler einführt. KI ist ein zweites Auge und ein Zeiger bei der Codeüberprüfung; Der Entwickler und Sicherheitsexperte entscheiden, ob es sich bei einem Fund um eine echte Schwachstelle handelt und ob die Behebung korrekt und sicher ist.
Schritte der Codeüberprüfung
- Geben Sie Umfang und Kontext an. Welche Sprache, welches Framework, wo nimmt dieser Code Eingaben entgegen, wo gibt er Ausgaben aus, auf welcher Ebene funktioniert er? Eine Codeüberprüfung ohne Kontext führt zu falsch positiven Ergebnissen.
- Suchen Sie nach gefährlichen Mustern. Suchen Sie nach bekannten KI-Schwachstellenklassen (z. B. OWASP Top 10): Injektion, Authentifizierung, Offenlegung sensibler Daten, Zugriffskontrolle.
- Lassen Sie jede Feststellung begründen. Für jedes Flag: welche Zeile, welche Schwachstellenklasse, wie kann sie ausgenutzt werden, was sind die Beweise. Eine ungerechtfertigte Feststellung wird nicht ernst genommen.
- Eliminieren Sie falsch positive Ergebnisse. Wird die Eingabe tatsächlich gelöscht, ist dieser Pfad wirklich zugänglich – prüfen Sie den Kontext.
- Überprüfen Sie den Fix. Bestätigen Sie, dass der von AI empfohlene Patch die Schwachstelle tatsächlich schließt, keine neuen Schwachstellen/Bugs einführt und die Tests bestanden hat.
- Menschliche Zustimmung. Entwickler + Sicherheitsexperte überprüfen den Befund und beheben; So gelangt es in das Code-Repository.
Begriffe: SAST (Static Application Security Testing – statisches Sicherheitstesten, das den Quellcode analysiert, ohne ihn auszuführen). DAST (Dynamisch – dynamisches Testen, das die laufende Anwendung extern testet). OWASP Top 10 ist die Standardliste der häufigsten Schwachstellen in Webanwendungen. Bei der Injektion handelt es sich um eine Schwachstelle, die dadurch entsteht, dass Benutzereingaben als Befehl/Abfrage interpretiert werden (z. B. SQL-Injection). Die parametrisierte Abfrage ist die richtige Methode, die die Injektion verhindert, indem sie die Eingabe vom Code trennt.
Tabelle gängiger Schwachstellenklassen
Schwachstellenklasse
Symptom (im Code)
richtige Lösung
KI-Falle
SQL-Injection
Eingaben in Abfrage einbinden
Parametrisierte Abfrage
Kann die Desinfektion ignorieren
hartcodiertes Geheimnis
Passwort/Eingabecode
Geheimtresor (Tresor), Env
Falsch positiv (Probe/Test)
Schwache Authentifizierung
Fehlende/falsche Steuerung
Leistungsstarke, zentralisierte Steuerung
fehlt der Kontext
Fehlerhafte Zugangskontrolle
Keine Berechtigungsprüfung
Serverseitige Autorisierung
Versteht komplexe Abläufe nicht
Offenlegung sensibler Daten
Passwortfreie Speicherung/Protokollierung
Verschlüsselung, Maskierung
Kann die Kritikalität nicht kennen
Unsichere Serialisierung
Deserialisieren Sie unzuverlässige Daten
Sicheres Parsen
Seltenes Muster fehlt
drei Mini-Koffer
Fall 1 – Erfassen der tatsächlichen Injektion. Ein Entwickler lässt die KI eine Datenzugriffsfunktion untersuchen. Die KI markiert die Zeile, in der der userId-Wert des Benutzers direkt in den SQL-Text verkettet wird, und sagt: „Dies ist klassische SQL-Injection, wandeln Sie sie in eine parametrisierte Abfrage um“; Bietet Beispielkorrektur. Der Entwickler bestätigt, dass die Eingabe nicht an anderer Stelle bereinigt wurde, verifiziert, dass es sich um eine echte Schwachstelle handelt, implementiert die vorgeschlagene parametrisierte Abfrage und schreibt einen Test. KI hat die Schwachstelle hervorgehoben; Verifizierung und Korrekturtests kamen vom Entwickler.
Fall 2 – Falsch positives festes Geheimnis. Die KI sieht die Zeile „passwort=“test1234“ in einer Datei und sagt „kritisch: hartcodiertes Passwort“. Der Entwickler prüft den Kontext: Es handelt sich um eine Unit-Test-Datei, Dummy-Testdaten, die nicht in die Produktion freigegeben und nicht auf ein reales System portiert wurden. Der Befund ist falsch positiv. Der Entwickler dokumentiert dies, ergreift jedoch keine Maßnahmen, da es sich nicht um ein echtes Geheimnis handelt. Lektion: Das „harte Geheimnis“-Zeichen der KI muss durch den Kontext eliminiert werden; Nicht jede Saite ist ein Geheimnis.
Fall 3 – Neue Schwachstellenbehebung. AI schlägt eine Lösung für eine XSS-Schwachstelle (Cross-Site-Scripting) vor; aber der von ihm vorgeschlagene Code löscht die Eingabe an der falschen Stelle und überspringt die Ausgabekodierung in einem anderen Bereich; Dadurch wird die Lücke nicht vollständig geschlossen. Der Sicherheitsexperte überprüft den Fix, bemerkt die fehlende Codierung und behebt ihn auf der richtigen Ebene. Lektion: Der von AI empfohlene Patch ist nicht automatisch sicher. Jeder Fix wird überprüft und getestet.
Schwache Eingabeaufforderung / Starke Eingabeaufforderung
Schwache Eingabeaufforderung:
Gibt es eine Lücke in diesem Code? Beheben Sie diese: [Code]
Diese Eingabeaufforderung gibt keinen Kontext an (Sprache, Framework, Eingabequelle), fragt nicht nach einer Begründung, stellt das falsch positive Ergebnis nicht in Frage und ist offen dafür, die von der KI erstellte Korrektur blind zu akzeptieren. KI vermischte Anzeichen sowohl einer echten als auch einer nicht vorhandenen Verwundbarkeit.
Kraftvolle Aufforderung:
Ihre Rolle: Assistent, der das ZWEITE AUGE des Entwicklers bei der sicheren Codeüberprüfung ist. Entscheidungsfindung; Betrachten Sie den direkt angewendeten Fix. Code: [Sprache/Framework angeben].Kontext: diese Funktion [Eingabequelle: z.B. empfängt [externe HTTP-Anfrage] und schreibt in [Ausgabeziel]. Ihre Aufgabe: (1) Markieren Sie mögliche Schwachstellen mit der OWASP-Klasse, geben Sie Zeilennummer + warum riskant + wie auszunutzen + Beweise für jede an, (2) schreiben Sie mindestens 1 falsch positives Szenario für jedes Ergebnis (z. B. wenn die Eingabe in einer anderen Ebene bereinigt wird), (3) schlagen Sie eine Lösung vor, aber mit dem Zeichen „[Überprüfung + Test schreiben]“; Bewerten Sie auch, ob der Fix neue Schwachstellen/Bugs mit sich bringt. Hinzufügen einer gefälschten Sicherheitslücke.[Code]
Eine starke Aufforderung liefert Kontext, fragt nach OWASP-Klasse und Beweisen, hinterfragt Fehlalarme und Risiken einer Abhilfe und erzwingt eine menschliche Überprüfung.
Kopierbare Eingabeaufforderungsvorlagen
VULNERABILITY SCAN-VORLAGE Untersuchen Sie den [Sprache/Framework]-Code für OWASP Top 10. Für jedes mögliche Ergebnis: Zeilennummer, Schwachstellenklasse, Warum es riskant ist, Beispiel-Exploit, Stärke der Beweise (sicher/wahrscheinlich/schwach). Kontext: Eingabe [Quelle], Ausgabe [Ziel]. Hinzufügen erfundener Erkenntnisse; Wenn Sie sich nicht sicher sind, geben Sie „[muss überprüft werden]“ ein. Code: [einfügen]
FALSCH POSITIVES ELIMINIERUNGSMUSTER Listen Sie für die folgende Codefindung die Szenarien auf, in denen KEINE echte Schwachstelle vorliegt: Könnte die Eingabe auf einer anderen Ebene gelöscht werden, ist dieser Pfad zugänglich, handelt es sich bei diesem Wert um einen Test/Beispiel, ist das Framework automatisch geschützt? Schreiben Sie, wie Sie die einzelnen Schritte bestätigen können. Befund: [Einfügen]
FIX-BEWERTUNGSVORLAGEEmpfehlen Sie einen Fix für die folgende Schwachstelle; Kritisieren Sie dann Ihren eigenen Fix: (1) Schließt er die Schwachstelle wirklich, (2) führt er zu einer neuen Schwachstelle/einem neuen Fehler, (3) welchen Test soll ich schreiben (positiver und negativer Fall), (4) Auswirkungen auf Leistung/Funktionalität. Ich werde das Update überprüfen und testen. Sicherheitslücke + Code: [Einfügen]
SICHERE MUSTER-LEHRVORLAGE für die Schwachstellenklasse [z. B. SQL-Injection] zeigen vergleichsweise sichere Tippmuster und häufige fehlerhafte Muster in dieser Sprache/diesem Framework. Allgemeine Regel + Codebeispiel angeben; Ich möchte jedoch, dass Sie den Kontext erfragen, bevor Sie ihn in meinen Code implementieren. Sprache/Rahmen: [schreiben]
Häufige Fehler
- Rezension ohne Kontext. Ohne Sprache, Framework und Eingabe-/Ausgabekontext verwechselt KI sowohl echte als auch falsche Ergebnisse; Geben Sie unbedingt den Kontext an.
- Jedes Zeichen mit echter Schwäche verwechseln. KI erzeugt falsch positive Ergebnisse (Testdaten, Eingaben werden auf einer anderen Ebene bereinigt); Überprüfen Sie jedes Ergebnis anhand des Kontexts.
- Die Korrektur der KI blind anwenden. Der empfohlene Patch kann zu neuen Schwachstellen/Bugs führen. Prüfungen überprüfen und schreiben.
- Dem falschen Negativ vertrauen. Auch wenn die KI sagt „keine Schwachstellen“, prüfen Sie selbst die kritischen Pfade; Statisches Scannen erkennt nicht jede Schwachstelle.
- Weitergabe des Codes/Geheimnisses an das externe Tool. Privater Code und echte Geheimnisse (Schlüssel, Passwort) sind geistiges Eigentum und Schwachstelle; Anonymisieren oder unternehmenseigene, isolierte Tools verwenden.
Tipp: Wenn Sie über den KI-Überprüfungscode verfügen, besteht der effizienteste Filter darin, für jeden Befund nach der „Stärke der Beweise“ (sicher/wahrscheinlich/schwach) zu fragen. Die meisten als „schwach“ gekennzeichneten Ergebnisse sind falsch positive Ergebnisse. Sie verteilen Ihre Energie auf die „Sicheren“.
Achtung: Der von AI vorgeschlagene Sicherheitsupdate sollte nicht ungetestet ins Lager gelangen. Ein falscher „Fix“ kann sowohl die Schwachstelle offen lassen als auch zu einem Funktionsfehler in der Produktion führen; Jeder Patch durchläuft die Überprüfungs- und Testphase.
Zusammenfassend
Eine sichere Codeüberprüfung ist die kostengünstigste Möglichkeit, Schwachstellen zu erkennen, bevor sie in Produktion gehen. Und da Code eine Sprache ist, wird KI hier zu einem leistungsstarken zweiten Auge: Sie kennzeichnet gefährliche Muster, erklärt Risiken und schlägt Korrekturen vor. Aber die KI erkennt nicht den gesamten Betriebskontext, erzeugt falsch-positive und falsch-negative Ergebnisse und der von ihr empfohlene Patch kann neue Schwachstellen mit sich bringen. Die Überprüfung umfasst also sechs Schritte (Kontext, Überprüfung, Begründung, Falsch-Positiv-Beseitigung, Fehlerbehebungsüberprüfung, menschliche Genehmigung) und die Entscheidung liegt beim Entwickler und dem Sicherheitsexperten. Drei Prinzipien: Kein Befund wird ohne Kontext interpretiert, jedes Zeichen wird mit Kontext eliminiert, kein Fix geht ungetestet in die Speicherung. Und der Code/das Geheimnis wird niemals ohne Anonymisierung an ein externes Tool weitergegeben.
Anwendungsaufgabe
Nehmen Sie ein Beispielcode-Snippet (entfernen Sie entweder sensible Teile aus Ihrem eigenen Code oder einen Beispielcode mit Schwachstellen). Lassen Sie es von der KI mit der Vorlage „Vulnerability Scanning“ untersuchen. Wenden Sie die Vorlage „False Positive Elimination“ für jeden Befund an und eliminieren Sie die echten. Nehmen Sie die Korrektur des gravierendsten Befundes mit der Vorlage „Remediation Evaluation“ vor, überprüfen Sie ihn selbst und schreiben Sie einen positiven + einen negativen Testfall. Beachten Sie, wie viele Ergebnisse falsch positiv waren.
Checkliste
- [ ] Ich habe die Sprache, das Framework und den Eingabe-/Ausgabekontext angegeben, bevor ich den Code überprüft habe.
- [ ] Ich habe für jeden Befund nach Zeilennummer, Schwachstellenklasse, Exploit-Pfad und Beweisen gefragt.
- [ ] Ich habe jedes Ergebnis anhand des Kontexts auf falsch positive Ergebnisse überprüft.
- [ ] Ich habe die Korrektur der KI nicht blind angewendet; Ich habe einen Test rezensiert und geschrieben.
- [ ] Trotz der Ausgabe „Keine Schwachstellen“ habe ich die kritischen Pfade selbst untersucht.
- [ ] Ich habe den Code/die Geheimnisse anonymisiert oder isolierte Unternehmenstools verwendet.
- [ ] Ich habe die Entdeckung und Behebung durch den Entwickler und die Sicherheitsgenehmigung bestanden.