gitlab-org/security-products/sast-rulesRepositório de regras Semgrep selecionado para SAST do GitLab, fornecendo padrões de análise estática para detectar vulnerabilidades de segurança em várias linguagens de programação com integração CI/CD.
Este é o repositório central de regras do Semgrep que hospeda as regras do Semgrep para o analisador semgrep do GitLab.
O repositório está estruturado da seguinte forma:
.
├── 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
│ └── ...
└── ...
A estrutura acima segue o padrão:
rules/<license>/<language>/<ruleclass>/rule-<rulename>\.(yml|<ext>)
onde:
<license> é a licença de todas as regras abaixo<language> a linguagem de programação alvo<ruleclass> um nome descritivo para a classe de regras abaixo<rulename> um nome descritivo para a regra em si<ext> a extensão de arquivo usual para <language>Regras mais antigas seguem o padrão <language>/<ruleclass>/rule-..., e o
padrão mais novo acima deve ser preferido sempre que possível.
O diretório mappings inclui a configuração do pacote de regras.
O Makefile define alguns alvos que são úteis ao trabalhar com regras:
$ make help
TARGETS:
test test all rules with Semgrep
watch watch for file changes and auto-run affected tests
help prints this message
As regras contidas neste repositório devem aderir ao seguinte formato:
" para strings, caso contrário, o bloco literal YAML |---O diretório de mapeamentos neste repositório contém arquivos de configuração YAML que mapeiam ids de analisadores nativos (por exemplo, Bandit, Brakeman, etc.) para as regras Semgrep correspondentes.
A intenção dos arquivos de mapeamento é, antes de tudo, separar informações específicas do analisador das regras reais e, em segundo lugar, fornecer uma maneira não intrusiva de gerar pacotes de regras ou conjuntos de regras (através dos limites de linguagem ou analisador) para diferentes propósitos.
Os arquivos de mapeamento estão localizados no diretório mappings/, onde o nome
do arquivo se refere ao pacote de regras e/ou analisador que é representado pelo
conjunto de regras usado no respectivo arquivo. Se você deseja que as regras sejam
incluídas no conjunto de regras padrão do GitLab e a regra não se encaixa em um
dos pacotes de regras (ou analisadores) já disponíveis no diretório mappings/,
você pode adicionar seus mapeamentos ao arquivo
mappings/gitlab_<license>_<language>.yml onde <license> é uma licença adequada
ditada pela fonte da qual a regra é originada e <language> é um espaço reservado
para a linguagem à qual a regra se refere.
Se você deseja integrar uma nova regra que foi desenvolvida do zero, pode
adicionar um mapeamento correspondente ao arquivo mappings/gitlab_ee_<language>.yml.
Ao determinar qual licença deve ser aplicada a uma regra específica que você está
mapeando, consulte esta orientação interna.
Os mapeamentos também são usados para montar automaticamente pacotes de regras.
O trecho abaixo ilustra um exemplo com arquivos de mapeamento para o analisador
bandit. A seção native_id inclui algumas informações sobre o id do analisador
nativo, ou seja, meta-informação que o analisador original (neste caso bandit)
anexa ao achado que produz. Os mapeamentos de regras reais são definidos na seção
mappings. Cada mapeamento mapeia um id de regra do analisador nativo (no exemplo
abaixo B301) para um conjunto de arquivos semgrep neste repositório que se
assemelham ou são idealmente de fato equivalentes a essa regra nativa específica.
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"
# ...
A anatomia de um arquivo de mapeamento é explicada em mais detalhes abaixo.
gl-sast-report.json) para fins de deduplicação.gl-sast-report.json produzido pelo analisador Semgrep do GitLab e disponibilizado no Relatório de Vulnerabilidade.B301 que se refere a uma das regras do analisador python bandit). O array rules aponta para arquivos no repositório aos quais esta regra se refere. Em outras palavras, a lógica de B301 é implementada nos quatro arquivos listados no trecho acima.Usamos dois tipos diferentes de identificadores id e primary_id para suportar a divisão de regras:
várias regras semgrep (id) podem ser mapeadas para uma única regra do analisador nativo (primary_id).
As regras e casos de teste neste repositório são parcialmente originados das fontes listadas abaixo:
Os detalhes estão listados nos cabeçalhos de todos os arquivos de regra e teste, incluindo as informações de licenciamento e a devida atribuição.
Se você conhece um padrão que não está presente neste repositório ou refinamentos que poderiam ser aplicados às regras neste repositório, você pode contribuir abrindo uma issue, ou até mesmo submeter uma melhoria para os arquivos de regra/casos de teste neste repositório.
Aplicamos o seguinte esquema de versionamento semântico a este repositório:
Novas versões de regras SAST devem ser incorporadas ao analisador semgrep para entrar em vigor. Para solicitar uma nova versão do semgrep, crie uma issue de release usando as instruções no modelo de issue de release SAST.
Gostaríamos de agradecer muito aos seguintes autores por suas valiosas contribuições.
| Autor | MRs/Issues |
|---|---|
| @masakura | !99, !107 |
| @niklas.volcz | !183 |
| @pieter39 | !668 |