Sec 섹션 개발 가이드라인

요약

Sec 섹션은 DevSecOps의 "Sec" 부분에 해당하는 GitLab 애플리케이션 보안 기능을 담당합니다. 공통 용어에 대한 개요는 용어를 참고합니다. Secure 기능을 지원하는 아키텍처는 크게 두 부분으로 나뉩니다.

Sec 섹션은 DevSecOps의 "Sec" 부분에 해당하는 GitLab 애플리케이션 보안 기능을 담당합니다. Sec 섹션에만 해당하는 개발 가이드를 여기에 정리했습니다.

공통 용어에 대한 개요는 용어를 참고합니다.

아키텍처#

보안 인벤토리#

백그라운드 작업

개요#

Secure 기능을 지원하는 아키텍처는 크게 두 부분으로 나뉩니다.

스캐닝
처리, 시각화 및 관리

Mermaid 다이어그램 (13줄)

소스 코드 보기

flowchart LR
  subgraph G1[Scanning]
    Scanner
    Analyzer
    CI[CI Jobs]
  end
  subgraph G2[Processing, visualization, and management]
   Parsers
   Database
   Views
   Interactions
  end
  G1 --Report Artifact--> G2

스캐닝#

스캐닝 부분은 주어진 리소스에서 취약점을 찾고 결과를 내보내는 역할을 합니다. 스캔은 분석기라고 하는 여러 소규모 프로젝트를 통해 CI/CD job에서 실행되며, 이 프로젝트들은 Analyzers 하위 그룹에서 확인할 수 있습니다. 분석기는 내부 또는 외부에서 개발된 스캐너라는 보안 도구를 GitLab에 통합하기 위한 래퍼입니다. 분석기는 주로 Go로 작성되어 있습니다.

일부 서드파티 통합 업체도 같은 아키텍처를 활용하는 통합 문서를 따라 추가 스캐너를 제공합니다.

스캔 결과는 Secure 리포트 형식을 준수해야 하는 JSON 리포트로 내보내지며, 파이프라인 완료 후 처리할 수 있도록 CI/CD job 리포트 아티팩트로 업로드됩니다.

처리, 시각화 및 관리#

데이터가 리포트 아티팩트로 제공되면 GitLab Rails 애플리케이션이 이를 처리해 다음을 비롯한 보안 기능을 제공할 수 있습니다.

보안 대시보드, 머지 리퀘스트 위젯, 파이프라인 뷰 등.
보안 스캔 결과.
승인 규칙.

컨텍스트에 따라 보안 리포트는 데이터베이스에 저장되거나, 필요할 때 접근할 수 있도록 리포트 아티팩트로 남습니다.

보안 리포트 수집 개요#

GitLab이 스캐너가 생성한 리포트를 처리하는 방식은 보안 리포트 수집 개요를 참고합니다.

CI/CD 템플릿 개발#

CI/CD 템플릿은 Verify 섹션의 책임이지만, 상당수가 Sec 섹션 기능 사용에 필수적입니다. CI/CD 템플릿을 다룬다면 GitLab CI/CD 템플릿 개발 가이드를 참고합니다.

기본 식별자의 중요성#

분석기 JSON 리포트에서 identifiers 필드는 취약점을 설명할 수 있는 유형과 범주(즉, CWE 계열)의 모음을 담습니다.

identifiers 모음의 첫 항목은 기본 식별자라고 하며, 취약점을 설명하고 추적하는 데 모두 중요한 구성 요소입니다.

그 밖의 대부분의 경우 identifiers 모음은 순서가 없으며, 나머지 보조 식별자는 취약점을 묶기 위한 메타데이터 역할을 합니다 (예외는 아래 분석기 취약점 변환 참고).

기본 식별자가 바뀐 상태에서 프로젝트 파이프라인을 다시 실행하면, 새 리포트를 수집할 때 기존 DB 레코드가 "고아" 상태가 됩니다. 처리 로직이 서로 다른 두 취약점의 델타를 생성하는 방식에 의존하므로, 결과가 상당히 혼란스럽게 보일 수 있습니다. 예를 들면 다음과 같습니다.

MR 위젯의 기본 식별자 불일치 스크린샷

병합된 후 기존 취약점 레코드의 상태는 Resolved로 바뀌고, 새 취약점 레코드의 상태는 Needs triage로 설정됩니다.

기본 식별자 안정성 보장을 위한 기본 원칙#

타당한 이유가 없는 한 기본 식별자는 바꾸지 않습니다.
취약점 변환을 지원하는 분석기는 결과가 "고아" 상태가 되지 않도록 기존 기본 식별자를 보조 위치에 포함해야 합니다.
기본 식별자를 제외하면 보조 식별자의 순서는 중요하지 않습니다.
식별자는 Type 필드와 Value 필드의 조합으로 고유해집니다(식별자 핑거프린트 참고).
기본 식별자를 바꾼 경우, 분석기를 이전 버전으로 되돌려도 고아 상태가 된 결과는 복구되지 않습니다. 이미 데이터베이스에 수집된 데이터는 과거 job의 산물이며, 데이터 마이그레이션을 자동화할 방법이 거의 없습니다.

분석기 취약점 변환#

SAST Semgrep 분석기의 경우 특히 중요한 보조 식별자가 하나 있습니다. 리포트의 취약점을 기존 분석기(즉, bandit 또는 ESLint)와 연결하는 식별자입니다.

취약점 변환을 활성화하려면 Semgrep 분석기는 기존 분석기의 기본 식별자와 정확히 일치하는 보조 식별자에 의존합니다.

예를 들어 이전에 eslint로 취약점 레코드를 생성했다면, semgrep 분석기는 원래 ESLint 기본 식별자를 포함하는 식별자 모음을 만들어야 합니다.

원래 eslint 리포트가 다음과 같다고 가정합니다.

{
  "version": "14.0.4",
  "vulnerabilities": [
    {
      "identifiers": [
        {
          "type": "eslint_rule_id",
          "name": "ESLint rule ID security/detect-eval-with-expression",
          "value": "security/detect-eval-with-expression"
        }
      ]
    }
  ]
}

이에 대응하는 Semgrep 리포트에는 eslint_rule_id가 포함되어야 합니다.

{
  "version": "14.0.4",
  "vulnerabilities": [
    {
      "identifiers": [
        {
          "type": "semgrep_id",
          "name": "eslint.detect-eval-with-expression",
          "value": "eslint.detect-eval-with-expression",
          "url": "https://semgrep.dev/r/gitlab.eslint.detect-eval-with-expression"
        },
        {
          "type": "eslint_rule_id",
          "name": "ESLint rule ID security/detect-eval-with-expression",
          "value": "security/detect-eval-with-expression"
        }
      ]
    }
  ]
}

취약점 추적은 두 식별자의 조합에 의존해, 기존 분석기로 생성한 DB 레코드를 새 semgrep 분석기로 생성한 레코드에 다시 매핑합니다.

개발 환경 설정: 패키지 메타데이터 데이터베이스 동기화#

패키지 메타데이터 데이터베이스(PMDB)를 사용하는 보안 스캔 및 라이선스 컴플라이언스 기능을 쓰려면 개발 환경에서 PMDB 동기화를 설정해야 합니다.

자세한 설정 방법은 GDK 문서의 패키지 메타데이터 동기화 가이드를 참고합니다.

GitLab이 악성코드 권고(GLAM)를 인스턴스로 동기화하는 방식은 악성코드 권고 동기화를 참고합니다.