Skip to content

Sicherheits-Diagnostics

Auf programmweite Sicherheitsfindings (SQL-Injection, XXE, schwache Kryptografie) aus einer Regel heraus reagieren, über die typisierte Diagnostics-Collection und benannte Aliase.

Aktualisiert am 2026-07-23

Manche Prüfungen lassen sich mit den lokalen DSL-Prädikaten nicht ausdrücken, weil sie einen Datenfluss über das ganze Programm brauchen: SQL-Injection, XML External Entity (XXE) und andere taint-basierte Sicherheitsfindings. Statt diese Analyse nachzubauen, delegiert CodeCharter sie an die gepflegten, MIT-lizenzierten Microsoft.CodeAnalysis.NetAnalyzers-Sicherheitsanalyzer und stellt jedes Finding als typisierten Fakt in der Diagnostics-Collection bereit — über dieselbe typisierte Oberfläche, die auch jede andere Regel nutzt.

Die Diagnostics-Collection

Diagnostics ist eine Top-Level-Collection (wie Types oder Methods). Jedes Element ist ein DiagnosticModel mit diesen Membern:

Member Typ Bedeutung
Rule string Die Analyzer-Regel-ID, z. B. CA2100 oder CA5351.
Category string Die Analyzer-Kategorie, z. B. Security.
Message string Die lesbare Diagnose-Meldung.
OffendingText string Der Quelltext, auf den die Diagnose zeigt (kann null sein).
SourceFile string Absoluter Pfad zur Datei, in der die Diagnose gemeldet wurde.
Line int 1-basierte Quellzeile.
Column int 1-basierte Quellspalte.

Über einen benannten Alias filtern, nicht über einen CA…-String

Vergleiche nicht d.Rule == "CA2100". Filtere über einen lesbaren Alias-Member. Aliase dokumentieren die Absicht und halten eine Regel auch dann gültig, wenn sich die zugrunde liegende ID-Menge ändert:

Alias Zugrunde liegende IDs Meldet
SqlInjection CA2100, CA3001 SQL aus nicht vertrauenswürdigem / nicht konstantem Text
WeakHashing CA5350, CA5351 MD5 / SHA1 / DES und andere gebrochene Algorithmen
XmlExternalEntity CA3075 Unsichere XML-External-Entity-Verarbeitung (XXE)
DisabledCertificateValidation CA5359 Deaktivierte Zertifikatsvalidierung
DeprecatedSecurityProtocol CA5364 SSL3 / TLS 1.0 und andere veraltete Protokolle 
@name "SQL injection"
@severity error
@category "Security"

Diagnostics.Where(d => d.SqlInjection)

Ein Alias, den es nicht gibt (ein Tippfehler wie d.SqlInjektion), ist ein klarer Authoring-Fehler, kein still auf false fallender Vergleich.

Lokale Prüfungen bleiben in den typisierten Membern

Schwache Kryptografie gibt es sowohl als Alias hier (WeakHashing) als auch, für die rein lokal entscheidbaren Teile, über die gewöhnlichen typisierten Member. Die Grenze ist einfach: Eine Prüfung, die sich durch das Betrachten eines einzelnen Ausdrucks treffen lässt, gehört in die lokalen Member (m.Invocations, m.MemberAccesses, …); eine Prüfung, die das ganze Programm braucht — woher kommt dieser String, erreicht er eine SQL-Senke — gehört in Diagnostics.

Zwei Dinge, die man wissen sollte

  • Opt-in. Die Analyzer laufen nur, wenn eine Regel die Diagnostics-Collection liest. Ein Lauf, dessen Regeln sie nie berühren, zahlt nichts für die Analyzer-Ausführung.
  • Nur bei voller Solution. Diese Findings entstehen bei einer echten Solution-Analyse mit vollständigen Referenzen. Der In-Memory-Spec-Harness (den test nutzt) hat einen dünnen Referenzsatz, sodass taint-lastige Analyzer dort nicht auflösen können. Eine Diagnose, die mangels Referenzen nicht laufen kann, wird protokolliert, nicht still verworfen.

Quelle und Lizenz

Die Diagnostics stammen ausschließlich aus Microsoft.CodeAnalysis.NetAnalyzers, das MIT-lizenziert ist. Die LGPL-3.0-Analyzer SecurityCodeScan werden bewusst nicht gebündelt. Die Analyse läuft lokal, in-process — kein Code verlässt die Maschine, passend zur allgemeinen Datenschutz-Haltung von CodeCharter.

Wie geht's weiter