Sec 섹션 개발 가이드라인

요약

Sec 섹션은 GitLab 애플리케이션 보안 기능, 즉 DevSecOps의 "Sec" 부분을 담당합니다. 공유 용어 개요는 용어 설명을 참조하세요. Secure 기능을 지원하는 아키텍처는 크게 두 부분으로 나뉩니다: flowchart LR subgraph G1[Scanning] Scanner Analyzer CI[CI Jobs] end subgraph G2[Processing, visualization, and management] Parsers Database Views I...

Sec 섹션은 GitLab 애플리케이션 보안 기능, 즉 DevSecOps의 "Sec" 부분을 담당합니다. Sec 섹션에 특화된 개발 가이드가 이 문서에 나열되어 있습니다.

공유 용어 개요는 용어 설명을 참조하세요.

아키텍처#

보안 인벤토리#

백그라운드 작업

개요#

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

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

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

스캐닝#

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

일부 3rd party 통합자는 동일한 아키텍처를 활용하는 통합 문서를 따라 추가적인 Scanner를 제공하기도 합니다.

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

처리, 시각화 및 관리#

데이터가 Report Artifact로 제공되면 GitLab Rails 애플리케이션에서 처리되어 다음을 포함한 보안 기능을 활성화할 수 있습니다:

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

컨텍스트에 따라 보안 보고서는 데이터베이스에 저장되거나, 온디맨드 액세스를 위해 Report Artifact로 유지될 수 있습니다.

보안 보고서 수집 개요#

스캐너가 생성한 보고서를 GitLab이 처리하는 방법에 대한 자세한 내용은 보안 보고서 수집 개요를 참조하세요.

CI/CD 템플릿 개발#

CI/CD 템플릿은 Verify 섹션의 책임이지만, 많은 템플릿이 Sec 섹션의 기능 사용에 중요합니다. CI/CD 템플릿을 다루는 경우 GitLab CI/CD 템플릿 개발 가이드를 참조하세요.

기본 식별자의 중요성#

Analyzer JSON 보고서 내에서 identifiers 필드에는 취약점을 설명할 수 있는 타입 및 카테고리 컬렉션(예: CWE 패밀리)이 포함됩니다.

identifiers 컬렉션의 첫 번째 항목은 기본 식별자로 알려져 있으며, 취약점을 설명하고 추적하는 데 있어 중요한 구성 요소입니다.

대부분의 다른 경우에서 identifiers 컬렉션은 순서가 없으며, 나머지 보조 식별자는 취약점을 그룹화하기 위한 메타데이터 역할을 합니다 (예외 사항은 아래 Analyzer 취약점 변환 참조).

기본 식별자가 변경되고 프로젝트 파이프라인이 재실행될 때마다, 새 보고서 수집 시 이전 DB 레코드가 "고아(orphan)" 상태가 됩니다. 처리 로직이 서로 다른 두 취약점의 델타를 생성하는 데 의존하기 때문에 상당히 혼란스러운 상황이 발생할 수 있습니다. 예를 들면:

[

](/19.2/development/sec/img/primary_identifier_changed_v15_6.png)

병합 후, 이전 취약점 레코드의 상태는 Resolved로 변경되고, 새 취약점 레코드의 상태는 Needs triage로 설정됩니다.

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

기본 식별자는 충분한 이유가 없는 한 절대 변경해서는 안 됩니다.
취약점 변환을 지원하는 Analyzer는 결과의 "고아화"를 방지하기 위해 기존 기본 식별자를 보조 위치에 포함해야 합니다.
기본 식별자 외에 보조 식별자의 순서는 중요하지 않습니다.
식별자는 Type과 Value 필드의 조합을 기반으로 고유합니다(식별자 지문 참조).
기본 식별자를 변경하는 경우, Analyzer를 이전 버전으로 롤백해도 고아화된 결과는 수정되지 않습니다. 이전에 데이터베이스에 수집된 데이터는 이전 job의 아티팩트로, 데이터 마이그레이션을 자동화할 수 있는 방법이 거의 없습니다.

Analyzer 취약점 변환#

SAST Semgrep Analyzer의 경우, 특별히 중요한 보조 식별자가 있습니다. 바로 보고서의 취약점을 기존 Analyzer(예: bandit 또는 ESLint)에 연결하는 식별자입니다.

취약점 변환 활성화를 위해 Semgrep Analyzer는 기존 Analyzer의 기본 식별자와 정확히 일치하는 보조 식별자에 의존합니다.

예를 들어, eslint가 이전에 취약점 레코드를 생성하는 데 사용되었을 때, semgrep Analyzer는 원래 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"
        }
      ]
    }
  ]
}

취약점 추적은 두 식별자의 조합을 활용하여 기존 Analyzer로 생성된 DB 레코드를 새로운 semgrep Analyzer로 생성된 레코드에 재매핑합니다.

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

Package Metadata Database(PMDB)를 사용하는 보안 스캐닝 및 라이선스 컴플라이언스 기능의 경우, 개발 환경에서 PMDB 동기화를 설정해야 합니다.

자세한 설정 지침은 GDK 문서의 패키지 메타데이터 동기화 가이드를 참조하세요.