Semgrep 규칙

이것은 GitLab semgrep 분석기를 위한 Semgrep 규칙을 호스팅하는 중앙 Semgrep 규칙 저장소입니다.

저장소는 다음과 같이 구성됩니다:

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

위 구조는 다음 패턴을 따릅니다:

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

여기서:

1. <license>는 그 아래 모든 규칙의 라이선스입니다.
2. <language>는 대상 프로그래밍 언어입니다.
3. <ruleclass>는 그 아래 규칙 클래스에 대한 설명 이름입니다.
4. <rulename>는 실제 규칙에 대한 설명 이름입니다.
5. <ext>는 <language>의 일반적인 파일 확장자입니다.

이전 규칙은 <language>/<ruleclass>/rule-... 패턴을 따르며, 가능하면 위의 새로운 패턴을 선호해야 합니다.

mappings 디렉토리는 규칙 팩 구성을 포함합니다.

Makefile

Makefile은 규칙 작업 시 유용한 몇 가지 대상을 정의합니다:

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

포맷팅 지침

이 저장소에 포함된 규칙은 다음 형식을 준수해야 합니다:

• 문자열에는 "를 사용하고, 그렇지 않으면 YAML 리터럴 블록 |
• 배열 요소 축소 금지
• 최대 줄 길이/텍스트 너비: 100자
• 들여쓰기: 2칸
• 모든 규칙은 해당하는 테스트 케이스를 가져야 합니다.
• 제공되는 경우, 규칙 파일 상단에 주석 섹션
• 모든 YAML 파일은 ---로 시작합니다.

매핑

이 저장소의 mappings 디렉토리에는 네이티브 분석기 ID(예: Bandit, Brakeman 등)를 해당 Semgrep 규칙에 매핑하는 YAML 구성 파일이 포함되어 있습니다.

매핑 파일의 목적은 첫째로 분석기별 정보를 실제 규칙과 분리하고, 둘째로 다양한 목적을 위해 (언어 또는 분석기 경계를 넘어) 규칙 팩 또는 규칙 세트를 생성하는 비침습적인 방법을 제공하는 것입니다.

매핑 파일은 mappings/ 디렉토리에 있으며, 파일 이름은 해당 파일에 사용된 규칙 집합으로 표현되는 규칙 팩 및/또는 분석기를 나타냅니다. 규칙이 GitLab 표준 규칙셋에 포함되어야 하지만 해당 규칙이 mappings/ 디렉토리에 이미 있는 규칙 팩(또는 분석기) 중 하나에 맞지 않는 경우, mappings/gitlab_<license>_<language>.yml 파일에 매핑을 추가할 수 있습니다. 여기서 <license>는 규칙이 출처된 소스에 의해 결정된 적절한 라이선스이고, <language>는 규칙이 참조하는 언어의 자리 표시자입니다.

처음부터 개발된 새 규칙을 통합하려면 mappings/gitlab_ee_<language>.yml 파일에 해당 매핑을 추가할 수 있습니다. 매핑하는 특정 규칙에 적용할 라이선스를 결정할 때는 이 내부 가이드를 참조하십시오.

매핑은 또한 규칙 팩을 자동으로 조립하는 데 사용됩니다. 아래 스니펫은 bandit 분석기에 대한 매핑 파일의 예를 보여줍니다. native_id 섹션은 네이티브 분석기 ID에 대한 일부 정보, 즉 원래 분석기(이 경우 bandit)가 생성한 결과에 첨부하는 메타 정보를 포함합니다. 실제 규칙 매핑은 mappings 섹션에 정의됩니다. 각 매핑은 네이티브 분석기 규칙 ID(아래 예에서는 B301)를 이 저장소에 있는 해당 네이티브 규칙과 유사하거나 이상적으로는 실질적으로 동등한 semgrep 파일 집합에 매핑합니다.

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

매핑 파일의 구성은 아래에서 더 자세히 설명합니다.

1. id는 매핑 파일에 해당하는 semgrep 규칙 팩에서 안정적이고 고유한 semgrep 규칙 식별자를 생성하는 데 사용됩니다.
2. primary_id는 중복 제거 목적으로 GitLab Semgrep 분석기가 생성할 때 취약점에 첨부되는 안정적인 취약점 기본 식별자를 생성하는 데 도움이 됩니다.
3. native_id는 네이티브 분석기가 생성할 취약점 식별자의 구조와 정확히 일치하는 항목입니다. 이는 GitLab Semgrep 분석기가 생성한 gl-sast-report.json에 추가되어 취약점 보고서에서 사용할 수 있게 됩니다.
4. mappings에는 네이티브 분석기 ID(위의 경우 Python 분석기 bandit의 규칙 중 하나를 참조하는 B301)가 포함됩니다. rules 배열은 이 규칙이 참조하는 저장소의 파일을 가리킵니다. 즉, B301의 로직은 위 스니펫에 나열된 네 개의 파일에 구현되어 있습니다.

규칙 분할을 지원하기 위해 id와 primary_id라는 두 가지 유형의 식별자를 사용합니다: 여러 semgrep 규칙(id)이 단일 네이티브 분석기 규칙(primary_id)에 매핑될 수 있습니다.

데이터 소스

이 저장소의 규칙과 테스트 케이스는 아래 나열된 소스에서 부분적으로 가져왔습니다:

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

자세한 내용은 라이선스 정보와 적절한 저작자 표시를 포함하여 모든 규칙 및 테스트 파일의 헤더에 나열되어 있습니다.

기여

이 저장소에 없는 패턴이나 이 저장소의 규칙에 적용할 수 있는 개선 사항을 알고 있다면, 이슈를 열어 기여하거나 이 저장소의 규칙 파일/테스트 케이스에 대한 개선 사항을 제출할 수 있습니다.

버전 관리

이 저장소에 다음과 같은 시맨틱 버전 관리 체계를 적용합니다:

1. 패치 버전 증가: 업데이트/패치/추가된 규칙의 경우.
2. 마이너 버전 증가: 하위 호환되는 YAML 스키마 변경(예: 선택적 필드 추가/제거).
3. 메이저 버전 증가: 하위 호환되지 않는 YAML 스키마 변경(예: 필수 필드 추가/제거)

SAST 규칙 릴리스 프로세스

새로운 SAST 규칙 릴리스는 적용되려면 semgrep 분석기에 통합되어야 합니다. 새로운 semgrep 릴리스를 요청하려면 SAST 릴리스 이슈 템플릿의 지침을 사용하여 릴리스 이슈를 생성하십시오.

크레딧

다음 저자분들의 귀중한 기여에 깊이 감사드립니다.