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