gitlab-org/security-products/sast-rulesRepository di regole Semgrep curate per GitLab SAST, che fornisce pattern di analisi statica per rilevare vulnerabilità di sicurezza in diversi linguaggi di programmazione con integrazione CI/CD.
Questo è il repository centrale delle regole Semgrep che ospita le regole Semgrep per l'analizzatore Semgrep di GitLab.
Il repository è strutturato come segue:
.
├── 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 struttura sopra segue il modello:
rules/<licenza>/<linguaggio>/<classe_regola>/rule-<nome_regola>\.(yml|<estensione>)
dove:
<licenza> è la licenza di tutte le regole sottostanti<linguaggio> il linguaggio di programmazione target<classe_regola> un nome descrittivo per la classe di regole sottostanti<nome_regola> un nome descrittivo per la regola effettiva<estensione> l'estensione file usuale per <linguaggio>Le regole più vecchie seguono il modello <linguaggio>/<classe_regola>/rule-..., mentre
quello più recente sopra dovrebbe essere preferito quando possibile.
La directory mappings include la configurazione del rule-pack.
Il Makefile definisce alcuni target utili quando si lavora sulle regole:
$ make help
TARGETS:
test test all rules with Semgrep
watch watch for file changes and auto-run affected tests
help prints this message
Le regole contenute in questo repository devono rispettare il seguente formato:
" per le stringhe, altrimenti il blocco letterale YAML |---La directory mappings in questo repository contiene file di configurazione YAML che mappano gli ID degli analizzatori nativi (es. Bandit, Brakeman, ecc.) alle corrispondenti regole Semgrep.
L'intenzione dei file di mapping è, prima di tutto, separare le informazioni specifiche dell'analizzatore dalle regole effettive e, in secondo luogo, fornire un modo non intrusivo per generare rule-pack o set di regole (attraverso confini di linguaggio o analizzatore) per scopi diversi.
I file di mapping si trovano sotto la directory mappings/ dove il nome del file si riferisce
al rulepack e/o all'analizzatore rappresentato dall'insieme di regole utilizzate nel
rispettivo file. Se si desidera che le regole siano incluse nel ruleset standard di GitLab
e la regola non rientra in uno dei rule-pack (o analizzatori) già disponibili
nella directory mappings/, è possibile aggiungere i propri mapping al file
mappings/gitlab_<licenza>_<linguaggio>.yml dove <licenza> è una licenza adeguata
dettata dalla fonte da cui proviene la regola e <linguaggio> è un segnaposto
del linguaggio a cui la regola si riferisce.
Se si desidera integrare una nuova regola sviluppata da zero, è possibile
aggiungere un mapping corrispondente al file mappings/gitlab_ee_<linguaggio>.yml.
Nel determinare quale licenza applicare a una particolare regola che si sta mappando,
fare riferimento a questa guida interna.
I mapping vengono utilizzati anche per assemblare automaticamente i rule-pack. Lo snippet seguente
illustra un esempio con file di mapping per l'analizzatore bandit. La sezione native_id
include alcune informazioni sull'ID dell'analizzatore nativo, ovvero meta-informazioni che l'analizzatore originale (in questo caso bandit)
allega al risultato che produce. I mapping effettivi delle regole sono definiti nella sezione mappings.
Ogni mapping mappa un ID di regola dell'analizzatore nativo (nell'esempio sotto B301) a un insieme di file semgrep
in questo repository che assomigliano, o sono idealmente de facto equivalenti, a quella particolare regola nativa.
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'anatomia di un file di mapping è spiegata più in dettaglio di seguito.
gl-sast-report.json) per scopi di deduplicazione.gl-sast-report.json prodotto dall'analizzatore Semgrep di GitLab e reso disponibile nel Report di Vulnerabilità.B301 che si riferisce a una delle regole dell'analizzatore python bandit). L'array rules punta ai file nel repository a cui questa regola si riferisce. In altre parole, la logica di B301 è implementata nei quattro file elencati nello snippet sopra.Utilizziamo due diversi tipi di identificatori id e primary_id per supportare lo split delle regole: più regole semgrep (id) possono essere mappate a una singola regola dell'analizzatore nativo (primary_id).
Le regole e i casi di test in questo repository provengono in parte dalle fonti elencate di seguito:
I dettagli sono elencati nelle intestazioni di tutti i file di regole e test, inclusi le informazioni sulla licenza e l'attribuzione corretta.
Se conosci un pattern che non è presente in questo repo o miglioramenti che potrebbero essere applicati alle regole in questo repository, puoi contribuire aprendo un issue, o anche inviare un miglioramento ai file delle regole/casi di test in questo repository.
Applichiamo il seguente schema di versionamento semantico a questo repository:
Le nuove versioni delle regole SAST devono essere incorporate nell'analizzatore semgrep per avere effetto. Per richiedere un nuovo rilascio di semgrep, crea un issue di rilascio utilizzando le istruzioni nel modello di issue di rilascio SAST.
Ringraziamo molto i seguenti autori per i loro preziosi contributi.
| Autore | MR/Issue |
|---|---|
| @masakura | !99, !107 |
| @niklas.volcz | !183 |
| @pieter39 | !668 |