JetBrains hat die Sicherheitsanalysefunktionen der Qodana-Plattform durch die Integration von Prüfungen erweitert, die von der OpenGrep-Engine für .NET- und JavaScript-Projekte unterstützt werden. Dadurch kommen Hunderte Sicherheitsprüfungen zu den bestehenden Funktionen von Qodana für Codequalität, Schwachstellenerkennung, Abhängigkeitsanalyse und der als Taint Analysis bekannten Datenflussanalyse hinzu. Außerdem können OpenGrep-Regeln verwendet werden, die von Teams selbst erstellt oder von Drittanbietern bereitgestellt werden.
Die Ankündigung erfolgte am 17. August 2026, zeitgleich mit dem Hinweis auf die Veröffentlichung von Qodana 2026.2. JetBrains zufolge soll die Integration den Umfang der Risikoerkennung erweitern, ohne Entwicklungs- und Sicherheitsteams dazu zu zwingen, ein separates Tool sowie zusätzliche Berichte und Arbeitsabläufe zu verwalten.
Was fügen die OpenGrep-Prüfungen hinzu?
Die Integration ergänzt Prüfungen, die auf häufige Arten von Sicherheitsproblemen abzielen. Die tatsächlichen Ergebnisse unterscheiden sich je nach Programmiersprache, Framework und aktivierten Regeln. Die in der Ankündigung genannte Abdeckung umfasst:
- Injektionsschwachstellen, darunter SQL-, Befehls- und Code-Injektionen.
- Cross-Site-Scripting-Angriffe (XSS) und Path Traversal.
- Server-Side Request Forgery (SSRF).
- Bestimmte Probleme bei der Deserialisierung und der Ressourcenzuweisung.
- Unsichere Programmiermuster, die vom Qodana-Regelwerk abgedeckt werden.
- Unsichere Datenflüsse im Zusammenhang mit den unterstützten Schwachstellen.
- Benutzerdefinierte Prüfungen für interne Programmierschnittstellen, Frameworks und Unternehmensrichtlinien.
Diese Prüfungen ersetzen die bestehenden Funktionen von Qodana nicht, sondern arbeiten neben der plattformeigenen statischen Analyse, Abhängigkeits- und Lizenzprüfungen, Schwachstellenerkennung, Quality Gates und Taint Analysis. Qodana verwendet eine auf OpenGrep basierende Binärversion, die auf der von JetBrains weiterentwickelten Variante des Projekts beruht.
Was ändert sich praktisch für Entwicklungsteams?
Die Ergebnisse werden in den bestehenden Qodana-Arbeitsabläufen angezeigt, statt in einem eigenständigen Sicherheitstool isoliert zu werden. JetBrains zufolge können Entwickler die Ergebnisse in den unterstützten integrierten Entwicklungsumgebungen, während der CI/CD-Analyse und in Qodana-Berichten prüfen. Außerdem können automatisierte Quality Gates verwendet werden, um Standards vor dem Zusammenführen oder der Bereitstellung des Codes durchzusetzen.
Das bedeutet, dass Sicherheitsteams den Umfang der Prüfungen erweitern können, während Entwickler Qualitäts- und Sicherheitsprobleme in einem gemeinsamen Kontext prüfen. Dieser Aspekt gewinnt angesichts der zunehmenden Menge an täglich erzeugtem Code besondere Bedeutung, einschließlich Code, der mithilfe künstlicher Intelligenz generiert wird, wie JetBrains im Kontext der Ankündigung darlegte.
Sprachen und Verfügbarkeit
Die integrierten OpenGrep-Prüfungen sind derzeit für .NET- und JavaScript-Projekte verfügbar. JetBrains plant, künftig Unterstützung für Kotlin und Java hinzuzufügen, ohne dass die Ankündigung dafür einen Termin nennt. Die verfügbaren Funktionen hängen außerdem von der Qodana-Version und der analysierten Sprache ab.
JetBrains betont, dass die Prüfungen auf regelbasierter statischer Analyse beruhen und nicht auf probabilistischen Ausgaben. Dieser Ansatz ermöglicht reproduzierbare Prüfungen, wobei die Genauigkeit der Ergebnisse weiterhin von den Regeln, der Sprache und dem verwendeten Framework abhängt.
Transparenz und Leistungsmessung
JetBrains arbeitet daran, eine klarere Messung der Leistung der Qodana-Sicherheitsprüfungen durch das Tool SABER zu ermöglichen, eine Abkürzung für Static Analysis Benchmark Evolution Runner. Die Initiative soll Teams dabei helfen, Erkennungsfähigkeiten sowie Richtig- und Falsch-Positiv-Raten zu bewerten, anstatt sich ausschließlich auf Marketingaussagen zu verlassen.
Die Ankündigung enthielt keine konkreten Zahlen zu den Ergebnissen dieser Vergleiche. Zudem wurde darauf hingewiesen, dass weiterhin an der Hinzufügung weiterer Regeln und am Ausbau der OWASP- und CWE-Abdeckung gearbeitet wird. Daher hängt der endgültige Umfang der Abdeckung weiterhin von der Qodana-Version, der Sprache, den aktivierten Regeln und der Art des untersuchten Codes ab.