Règles Semgrep

Ceci est le dépôt central de règles Semgrep qui héberge les règles Semgrep pour l'analyseur Semgrep GitLab.

Le dépôt est structuré comme suit :

.
├── 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
│   └── ...
└── ...

La structure ci-dessus suit le modèle :

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

où :

1. <license> est la licence de toutes les règles en dessous
2. <language> le langage de programmation cible
3. <ruleclass> un nom descriptif pour la classe des règles en dessous
4. <rulename> un nom descriptif pour la règle elle-même
5. <ext> l'extension de fichier habituelle pour <language>

Les règles plus anciennes suivent le modèle <language>/<ruleclass>/rule-..., et le nouveau modèle ci-dessus doit être préféré lorsque c'est possible.

Le répertoire mappings inclut la configuration du pack de règles.

Makefile

Le Makefile définit quelques cibles utiles pour travailler sur les règles :

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

Formatage des règles

Les règles contenues dans ce dépôt doivent respecter le format suivant :

• Utilisez " pour les chaînes, sinon le bloc littéral YAML |
• Pas de réduction des éléments de tableau
• longueur/largeur de ligne maximale : 100 caractères
• indentation : 2 espaces
• chaque règle doit avoir un cas de test correspondant
• si fournie, section de commentaires en haut du fichier de règle
• chaque fichier YAML commence par ---

Mappings

Le répertoire mappings de ce dépôt contient des fichiers de configuration YAML qui mappent les identifiants natifs de l'analyseur (par exemple Bandit, Brakeman, etc.) aux règles Semgrep correspondantes.

L'intention des fichiers de mapping est, avant tout, de séparer les informations spécifiques à l'analyseur des règles elles-mêmes et, deuxièmement, de fournir un moyen non intrusif de générer des packs de règles ou des ensembles de règles (au-delà des frontières de langage ou d'analyseur) pour différents objectifs.

Les fichiers de mapping se trouvent dans le répertoire mappings/ où le nom du fichier fait référence au pack de règles et/ou à l'analyseur représenté par l'ensemble des règles utilisées dans le fichier respectif. Si vous souhaitez que les règles soient incluses dans l'ensemble de règles standard de GitLab et que la règle ne correspond à aucun des packs de règles (ou analyseurs) déjà disponibles dans le répertoire mappings/, vous pouvez ajouter vos mappings au fichier mappings/gitlab_<license>_<language>.yml où <license> est une licence appropriée dictée par la source dont provient la règle et <language> est un espace réservé pour le langage auquel la règle se rapporte.

Si vous souhaitez intégrer une nouvelle règle développée de toutes pièces, vous pouvez ajouter un mapping correspondant au fichier mappings/gitlab_ee_<language>.yml. Pour déterminer la licence qui doit s'appliquer à une règle particulière que vous mappez, reportez-vous à ce guide interne.

Les mappings sont également utilisés pour assembler automatiquement des packs de règles. L'extrait ci-dessous illustre un exemple avec des fichiers de mapping pour l'analyseur bandit. La section native_id inclut des informations sur l'identifiant natif de l'analyseur, c'est-à-dire des méta-informations que l'analyseur d'origine (dans ce cas bandit) attache à la constatation qu'il produit. Les mappings réels des règles sont définis dans la section mappings. Chaque mapping mappe un identifiant de règle d'analyseur natif (dans l'exemple ci-dessous B301) à un ensemble de fichiers semgrep dans ce dépôt qui ressemblent à cette règle native particulière, ou sont idéalement de facto équivalents.

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"
  # ...

L'anatomie d'un fichier de mapping est expliquée plus en détail ci-dessous.

1. id est utilisé pour générer des identifiants de règle semgrep stables et uniques dans le pack de règles semgrep qui correspond à un fichier de mapping.
2. primary_id aide à générer des identifiants primaires de vulnérabilité stables qui sont attachés aux vulnérabilités telles qu'elles sont générées par l'analyseur Semgrep GitLab (dans le gl-sast-report.json) à des fins de déduplication.
3. native_id est l'entrée qui ressemble exactement à la structure de l'identifiant de vulnérabilité tel qu'il serait généré par l'analyseur natif. Cela sera ajouté au gl-sast-report.json produit par l'analyseur Semgrep GitLab et rendu disponible dans le rapport de vulnérabilité.
4. mappings inclut l'identifiant de l'analyseur natif (dans le cas ci-dessus B301 qui fait référence à l'une des règles de l'analyseur python bandit). Le tableau rules pointe vers les fichiers du dépôt auxquels cette règle fait référence. En d'autres termes, la logique de B301 est implémentée dans les quatre fichiers listés dans l'extrait ci-dessus.

Nous utilisons deux types différents d'identifiants id et primary_id pour prendre en charge la division des règles : plusieurs règles semgrep (id) peuvent être mappées à une seule règle d'analyseur natif (primary_id).

Sources de données

Les règles et cas de test de ce dépôt proviennent en partie des sources listées ci-dessous :

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

Les détails sont listés dans les en-têtes de tous les fichiers de règles et de test, y compris les informations de licence et l'attribution appropriée.

Contribution

Si vous connaissez un modèle qui n'est pas présent dans ce dépôt ou des améliorations qui pourraient être appliquées aux règles de ce dépôt, vous pouvez contribuer en ouvrant un problème, ou même soumettre une amélioration aux fichiers de règles/cas de test de ce dépôt.

Versionnement

Nous appliquons le schéma de versionnement sémantique suivant à ce dépôt :

1. incrément de version corrective : pour les règles mises à jour/corrigées/ajoutées.
2. incrément de version mineure : modifications de schéma YAML rétrocompatibles (par exemple, ajout/suppression de champs optionnels).
3. incrément de version majeure : modifications de schéma YAML non rétrocompatibles (par exemple, ajout/suppression de champs obligatoires)

Processus de publication des règles SAST

Les nouvelles versions de règles SAST doivent être intégrées dans l'analyseur semgrep pour prendre effet. Pour demander une nouvelle version de semgrep, créez un problème de version en utilisant les instructions dans le modèle de problème de version SAST.

Crédits

Nous tenons à remercier vivement les auteurs suivants pour leurs précieuses contributions.