Sec 섹션 개발 지침
Sec 섹션은 GitLab 애플리케이션 보안 기능, DevSecOps의 “Sec” 부분에 책임이 있습니다. Sec 섹션에 특화된 개발 가이드가 여기에 나열되어 있습니다.
공유 용어집에서 공유 용어의 전반적인 내용을 확인하세요.
아키텍처
개요
보안 기능을 지원하는 아키텍처는 주로 두 가지 부분으로 나뉩니다.
- 스캔
- 처리, 시각화 및 관리
스캔
스캔 부분은 주어진 리소스에서 취약점을 찾고 결과를 내보내는 역할을 합니다. 스캔은 분석기(Analyzers)라고 불리는 여러 작은 프로젝트를 통해 CI/CD 작업에서 실행됩니다. 이 프로젝트는 분석기 하위 그룹에서 찾을 수 있습니다. 분석기는 GitLab에 통합하기 위해 내부적으로 또는 외부적으로 개발된 보안 도구인 스캐너를 래핑한 것입니다. 분석기는 주로 Go로 작성됩니다.
몇몇 제3자 통합업체는 통합 문서를 따라 추가적인 스캐너를 사용할 수 있으며, 이는 동일한 아키텍처를 활용합니다.
스캔 결과는 보안 보고서 형식을 준수해야 하며, 이는 CI/CD 작업 보고서 자산로 업로드되어 파이프라인 완료 후 처리를 위해 사용할 수 있게 됩니다.
처리, 시각화 및 관리
데이터가 보고서 자산으로 사용 가능한 상태가 되면 GitLab Rails 애플리케이션에 의해 처리되어 보안 기능을 활성화할 수 있습니다. 이러한 기능에는 다음이 포함됩니다.
- 보안 대시보드, Merge Request 위젯, 파이프라인 보기 등
- 취약점과 상호 작용
- 승인 규칙
문맥에 따라 보안 보고서는 데이터베이스에 저장되거나 보고서 자산으로 유지될 수 있습니다.
보안 보고서 입력 개요
스캐너가 생성한 보고서를 GitLab이 어떻게 처리하는지에 대한 자세한 내용은 보안 보고서 입력 개요를 참조하세요.
CI/CD 템플릿 개발
CI/CD 템플릿은 Verify 섹션이 책임지지만, 많은 것들이 Sec 섹션의 기능 사용에 중요합니다. CI/CD 템플릿을 사용 중이라면 GitLab CI/CD 템플릿 개발 가이드를 읽어보세요.
주요 식별자의 중요성
분석기 JSON 보고서 내의 identifiers 필드는 취약점을 설명 및 추적할 수 있는 유형 및 범주의 컬렉션을 포함합니다(CWE 패밀리).
identifiers 컬렉션 내 첫 번째 항목은 주요 식별자로, 취약점을 설명하고 추적하는 데 중요한 컴포넌트입니다.
다른 대부분의 경우, identifiers 컬렉션은 순서가 없으며 나머지 보조 식별자가 취약점을 그룹화하는 메타데이터 역할을 합니다(예외인 분석기 취약점 번역은 특별한 경우입니다).
주요 식별자가 변경되고 프로젝트 파이프라인이 다시 실행될 때마다 새 보고서가 “이전 DB 레코드를 고아”로 만듭니다. 우리의 처리 논리는 두 가지 다른 취약점의 델타를 생성하는 데 의존하기 때문에, 혼란스러워 보일 수 있습니다. 예를 들어 아래와 같습니다:
Merge된 후, 이전 취약점은 “해결됨”으로 표시되고 도입된 것은 “감지됨”으로 표시됩니다.
주요 식별자 안정성 보장을 위한 지침 원칙
- 강력한 이유가 없는 한 주요 식별자는 변경해서는 안 됩니다.
- 취약점 번역을 지원하는 분석기는 고아가 되지 않도록 이전 주요 식별자를 보조 위치에 포함해야 합니다.
- 주요 식별자 이외에도 보조 식별자의 순서는 중요하지 않습니다.
- 식별자는
유형(Type)및값(Value)필드의 조합을 기준으로 고유합니다(참조: 식별자 지문). - 주요 식별자를 변경할 경우, 이전 버전의 분석기로 롤백해도 이전 작업에서 생성된 데이터가 수정되지 않습니다. 이전 작업으로 인해 생성된 데이터는 자동화하는 데는 몇 가지 방법만 있는 데이터 마이그레이션의 결과입니다.
분석기 취약점 번역
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으로 생성된 레코드로 다시 매핑합니다.
도움말