Semgrep Regeln

Dies ist das zentrale Semgrep-Regel-Repository, das die Semgrep-Regeln für den GitLab semgrep analyzer hostet.

Das Repository ist wie folgt strukturiert:

.
├── mappings
│   ├── find_sec_bugs.yml
│   ├── eslint.yml
│   └── ...
├── rules
│   ├── lpgl
│   │   ├── java
│   │   │   ├── webview
│   │   │   │   ├── rule-ignore_ssl_certificate_error.yml
│   │   │   │   ├── rule-ignore_ssl_certificate_error.java
│   │   │   │   └── ...
│   │   │   └── ...
│   │   ├── python
│   │   │   └── ...
│   │   └── ...
│   ├── lpgl-cc
│   │   ├── java
│   │   │   └── ...
│   │   └── ...
│   └── ...
├── c
│   ├── buffer
│   │   ├── rule-strcpy.yml
│   │   ├── test-strcpy.c
│   │   ├── rule-memcpy.yml
│   │   └── test-memcpy.c
│   └── ...
└── javascript
│   └── ...
└── ...

Die obige Struktur folgt dem Muster:

rules/<license>/<language>/<ruleclass>/rule-<rulename>\.(yml|<ext>)

wobei:

1. <license> ist die Lizenz aller darunter liegenden Regeln
2. <language> die Ziel-Programmiersprache
3. <ruleclass> ein beschreibender Name für die Klasse der darunter liegenden Regeln
4. <rulename> ein beschreibender Name für die eigentliche Regel
5. <ext> die übliche Dateierweiterung für <language>

Ältere Regeln folgen dem Muster <language>/<ruleclass>/rule-..., und das neuere oben sollte wann immer möglich bevorzugt werden.

Das Verzeichnis mappings enthält die Regelpaket-Konfiguration.

Makefile

Das Makefile definiert einige Ziele, die bei der Arbeit an Regeln hilfreich sind:

$ make help
TARGETS:
  test                  test all rules with Semgrep
  watch                 watch for file changes and auto-run affected tests
  help                  prints this message

Formatierungsrichtlinien

Regeln in diesem Repository müssen folgendem Format entsprechen:

• Verwende " für Zeichenketten, ansonsten den YAML-Literal-Block |
• Kein Zusammenklappen von Array-Elementen
• maximale Zeilenlänge/Textbreite: 100 Zeichen
• Einrückung: 2 Leerzeichen
• jede Regel muss einen entsprechenden Testfall haben
• falls vorhanden, Kommentare-Abschnitt oben in der Regeldatei
• jede YAML-Datei beginnt mit ---

Mappings

Das Verzeichnis mappings in diesem Repository enthält YAML-Konfigurationsdateien, die native Analyzer-IDs (z.B. Bandit, Brakeman usw.) auf die entsprechenden Semgrep-Regeln abbilden.

Die Absicht der Mapping-Dateien ist es, in erster Linie analyzerspezifische Informationen von den eigentlichen Regeln zu trennen und zweitens eine nicht-intrusive Möglichkeit zu bieten, Regelpakete oder Regelsets (sprach- oder analyzerübergreifend) für verschiedene Zwecke zu generieren.

Mapping-Dateien befinden sich unter dem Verzeichnis mappings/, wobei der Dateiname auf das Regelpaket und/oder den Analysator verweist, das/der durch den Satz von Regeln in der jeweiligen Datei repräsentiert wird.

Wenn Sie möchten, dass die Regeln in das GitLab-Standardregelset aufgenommen werden und die Regel in keines der bereits im Verzeichnis mappings/ verfügbaren Regelpakete (oder Analysatoren) passt, können Sie Ihre Mappings zur Datei mappings/gitlab_<license>_<language>.yml hinzufügen, wobei <license> eine geeignete Lizenz ist, die durch die Quelle, aus der die Regel stammt, vorgegeben wird, und <language> ein Platzhalter für die Sprache ist, auf die sich die Regel bezieht.

Wenn Sie eine neue, von Grund auf entwickelte Regel integrieren möchten, können Sie ein entsprechendes Mapping zur Datei mappings/gitlab_ee_<language>.yml hinzufügen.

Bestimmen Sie die anzuwendende Lizenz für eine bestimmte Regel, die Sie mappen, anhand dieser internen Anleitung.

Mappings werden auch verwendet, um automatisch Regelpakete zusammenzustellen. Das folgende Snippet zeigt ein Beispiel mit Mapping-Dateien für den bandit-Analysator. Der Abschnitt native_id enthält einige Informationen über die native Analyzer-ID, d.h. Metainformationen, die der ursprüngliche Analysator (in diesem Fall bandit) an den von ihm erzeugten Befund anhängt. Die eigentlichen Regel-Mappings werden im Abschnitt mappings definiert. Jedes Mapping bildet eine native Analyzer-Regel-ID (im Beispiel unten B301) auf einen Satz von Semgrep-Dateien in diesem Repository ab, die dieser bestimmten nativen Regel ähneln oder idealerweise de facto äquivalent sind.

bandit:
  native_id:
    type: "bandit_test_id"
    name: "Bandit Test ID: $ID"
    value: "$ID"
  mappings:
  - id: "B301"
    rules:
    - path: "python/deserialization/rule-pickle"
      primary_id: "bandit.B301-1"
      id: "bandit.B301-1"
    - path: "python/deserialization/rule-cpickle"
      primary_id: "bandit.B301-2"
      id: "bandit.B301-2"
    - path: "python/deserialization/rule-dill"
      primary_id: "bandit.B301-3"
      id: "bandit.B301-3"
    - path: "python/deserialization/rule-shelve"
      primary_id: "bandit.B301-4"
      id: "bandit.B301-4"
  # ...

Der Aufbau einer Mapping-Datei wird unten näher erläutert.

1. id wird verwendet, um stabile und eindeutige Semgrep-Regelkennungen in dem Regelpaket zu generieren, das einer Mapping-Datei entspricht.
2. primary_id hilft, stabile primäre Schwachstellenkennungen zu generieren, die an Schwachstellen angehängt werden, so wie sie vom GitLab Semgrep analyzer (in der gl-sast-report.json) zu Deduplizierungszwecken erzeugt werden.
3. native_id ist der Eintrag, der genau die Struktur der Schwachstellenkennung abbildet, wie sie vom nativen Analysator erzeugt würde. Dies wird zu der vom GitLab Semgrep analyzer erzeugten gl-sast-report.json hinzugefügt und im Schwachstellenbericht verfügbar gemacht.
4. mappings enthält die native Analyzer-ID (im obigen Fall B301, die sich auf eine der Regeln des Python-Analysators bandit bezieht). Das Array rules verweist auf Dateien im Repository, auf die sich diese Regel bezieht. Mit anderen Worten, die Logik von B301 ist in den vier oben aufgeführten Dateien implementiert.

Wir verwenden zwei verschiedene Arten von Kennungen, id und primary_id, um die Aufteilung von Regeln zu unterstützen: Mehrere Semgrep-Regeln (id) können auf eine einzelne native Analysator-Regel (primary_id) abgebildet werden.

Datenquellen

Die Regeln und Testfälle in diesem Repository stammen teilweise aus den unten aufgeführten Quellen:

1. https://github.com/returntocorp/semgrep-rules
2. https://github.com/PyCQA/bandit
3. https://github.com/nodesecurity/eslint-plugin-security
4. https://github.com/jsx-eslint/eslint-plugin-react
5. https://github.com/david-a-wheeler/flawfinder/blob/master/flawfinder.py

Die Details sind in den Kopfzeilen aller Regel- und Testdateien aufgeführt, einschließlich der Lizenzinformationen und der korrekten Quellenangabe.

Mitwirken

Wenn Sie ein Muster kennen, das in diesem Repository nicht vorhanden ist, oder Verfeinerungen, die auf die Regeln in diesem Repository angewendet werden könnten, können Sie durch das Öffnen eines Issues beitragen oder sogar eine Verbesserung der Regeldateien/Testfälle in diesem Repository einreichen.

Versionierung

Wir wenden das folgende Schema der semantischen Versionierung auf dieses Repository an:

1. Patch-Versionserhöhung: für aktualisierte/gepatchte/hinzugefügte Regeln.
2. Minor-Versionserhöhung: abwärtskompatible YAML-Schemaänderungen (z.B. Hinzufügen/Entfernen optionaler Felder).
3. Major-Versionserhöhung: nicht abwärtskompatible YAML-Schemaänderungen (z.B. Hinzufügen/Entfernen erforderlicher Felder)

SAST-Regeln Freigabeprozess

Neue SAST-Regelversionen müssen in den semgrep analyzer integriert werden, um wirksam zu werden. Um eine neue Semgrep-Version anzufordern, erstellen Sie ein Release-Issue mit den Anweisungen in der SAST-Release-Issue-Vorlage.

Danksagungen

Wir möchten den folgenden Autoren sehr für ihre wertvollen Beiträge danken.