이 용어집은 GitLab의 보안 기능과 관련된 용어의 정의를 제공합니다. 일부 용어는 다른 곳에서 다른 의미로 쓰이지만, 여기의 정의는 GitLab에 한정됩니다.

분석기(Analyzer)#

스캔 대상 유형에서 보안 취약점을 분석하는 소프트웨어입니다. 내부적으로는 필요한 구성 매개변수를 수집하고, 스캐너가 스캔 작업을 실행할 수 있도록 대상을 표준 형식으로 변환하는 데이터 변환을 수행합니다. 마지막으로 호출자가 요구하는 형식으로 보고서를 생성합니다.

CI/CD 기반 분석기는 CI/CD job을 사용해 GitLab에 통합됩니다. CI/CD 기반 분석기가 생성한 보고서는 job 이 완료된 뒤 아티팩트로 게시됩니다. GitLab은 이 보고서를 수집해 사용자가 발견된 취약점을 시각화하고 관리하도록 합니다. 생성된 보고서는 Secure 보고서 형식을 따릅니다.

많은 GitLab 분석기는 Docker로 래핑된 스캐너를 실행하는 표준 방식을 따릅니다. 예를 들어 semgrep 이미지는 Semgrep 스캐너를 래핑하는 분석기입니다. 다만 일부 분석기는 별도 컨테이너가 아니라 GitLab Rails 또는 다른 대상 환경에서 직접 실행됩니다.

공격 표면(Attack surface)#

애플리케이션에서 공격에 취약한 여러 지점입니다. Secure 제품은 스캔 중에 공격 표면을 찾아 탐색합니다. 제품마다 공격 표면을 다르게 정의합니다. 예를 들어 SAST는 파일과 줄 번호를 사용하고, DAST는 URL을 사용합니다.

컴포넌트(Component)#

소프트웨어 프로젝트의 일부를 구성하는 소프트웨어 컴포넌트입니다. 라이브러리, 드라이버, 데이터 등이 이에 해당하며 그 밖에도 여러 가지가 있습니다.

코퍼스(Corpus)#

퍼저가 실행되는 동안 생성되는 의미 있는 테스트 케이스의 집합입니다. 의미 있는 각 테스트 케이스는 테스트 대상 프로그램에서 새로운 커버리지를 만듭니다. 코퍼스는 재사용해 이후 실행에 전달합니다.

CNA#

CVE 번호 관리 기관(CNA)은 각자의 범위에 속한 제품이나 서비스의 취약점에 CVE를 할당할 권한을 Mitre Corporation으로부터 부여받은 전 세계 조직입니다. GitLab도 CNA 입니다.

CVE#

Common Vulnerabilities and Exposures(CVE®)는 공개적으로 알려진 사이버 보안 취약점에 대한 공통 식별자 목록입니다. 이 목록은 Mitre Corporation이 관리합니다.

CVSS#

Common Vulnerability Scoring System(CVSS)은 컴퓨터 시스템 보안 취약점의 심각도를 평가하는 무료 공개 산업 표준입니다.

CWE#

Common Weakness Enumeration(CWE™)은 보안에 영향을 주는 일반적인 소프트웨어 및 하드웨어 약점 유형을 커뮤니티가 정리한 목록입니다. 약점은 소프트웨어나 하드웨어의 구현, 코드, 설계, 아키텍처에 존재하는 결함, 오류, 버그, 취약점, 그 밖의 오류를 말합니다. 약점을 그대로 두면 시스템, 네트워크, 하드웨어가 공격에 노출될 수 있습니다. CWE 목록과 그에 연결된 분류 체계는 이러한 약점을 CWE 기준으로 식별하고 설명하는 데 쓰는 공통 언어 역할을 합니다.

중복 제거(Deduplication)#

카테고리의 처리 과정이 여러 발견을 같은 것으로 판단하거나, 노이즈를 줄여야 할 만큼 서로 비슷하다고 판단하면 하나만 남기고 나머지는 제거합니다. 자세한 내용은 중복 제거 과정을 참고합니다.

의존성 그래프 내보내기(Dependency graph export)#

의존성 그래프 내보내기는 프로젝트가 사용하는 직접 의존성과 간접 의존성, 그리고 그 사이의 관계를 나열합니다. 패키지 관리자 명령(예: go mod graph 또는 mvn dependency:tree)으로 생성되어 파일로 출력됩니다.

관련 용어: 잠금 파일.

의존성 버전 충돌(Dependency version conflict)#

의존성 버전 충돌은 의존성 버전 제약 조건을 충족할 수 없을 때 발생합니다.

다음 예를 살펴봅니다:

• 의존성 X는 정확히 버전 1.0.0의 packageA를 요구합니다
• 의존성 Y는 버전 1.0.1 이상의 packageA를 요구합니다

이 예시에서는 어떤 packageA 버전도 두 제약 조건을 모두 충족할 수 없으므로 의존성 버전 충돌이 발생합니다.

의존성 버전 비호환성(Dependency version incompatibility)#

의존성 버전 비호환성은 패키지 버전이 버전 제약 조건을 충족하지 않을 때 발생합니다.

다음 예를 살펴봅니다:

• packageA에는 1.0.0과 1.0.1 버전이 있습니다
• 의존성 X는 버전 1.0.1 이상의 packageA를 요구합니다

이 예시에서 packageA의 1.0.0 버전은 버전 제약 조건을 충족하지 않으므로 비호환입니다. 반면 packageA의 1.0.1 버전은 제약 조건을 충족합니다.

중복 발견(Duplicate finding)#

여러 번 보고된 정상적인 발견입니다. 서로 다른 스캐너가 같은 발견을 찾아내거나, 하나의 스캔이 같은 발견을 의도치 않게 두 번 이상 보고할 때 생깁니다.

거짓 양성(False positive)#

실제로는 존재하지 않는데 존재한다고 잘못 보고된 발견입니다.

발견(Finding)#

분석기가 프로젝트에서 식별한, 취약할 가능성이 있는 자산입니다. 자산에는 소스 코드, 바이너리 패키지, 컨테이너, 의존성, 네트워크, 애플리케이션, 인프라 등이 포함되며 이에 한정되지 않습니다.

발견은 스캐너가 MR 또는 기능 브랜치에서 식별한 잠재적 취약점 항목 전체입니다. 기본 브랜치에 머지된 뒤에야 발견이 취약점이 됩니다.

취약점 발견은 두 가지 방식으로 다룰 수 있습니다.

1. 취약점 발견에 대해 이슈 또는 머지 리퀘스트를 생성할 수 있습니다.
2. 취약점 발견을 기각할 수 있습니다. 발견을 기각하면 기본 보기에서 숨겨집니다.

그룹화(Grouping)#

서로 관련이 있을 가능성이 높지만 중복 제거 대상은 아닌 발견이 여러 개일 때, 취약점을 그룹으로 묶어 시각적으로 정리하는 유연하고 비파괴적인 방식입니다. 예를 들어 함께 평가해야 하거나, 같은 조치로 해결되거나, 같은 출처에서 나온 발견을 묶을 수 있습니다.

식별자(Identifier)#

식별자는 Common Vulnerabilities and Exposures(CVE)나 Common Weakness Enumeration(CWE) 같은 외부 데이터베이스에서 부여한 취약점 ID 입니다. 하나의 취약점에 여러 식별자가 있을 수 있습니다. 식별자는 유형(예: CVE)과 ID(예: CVE-2021-44228)로 구성됩니다.

중요하지 않은 발견(Insignificant finding)#

정상적인 발견이지만 특정 고객에게는 중요하지 않은 발견입니다.

알려진 영향 컴포넌트(Known affected component)#

취약점이 악용될 수 있는 조건에 부합하는 컴포넌트입니다. 예를 들어 packageA@1.0.3은 FAKECVE-2023-0001의 이름, 패키지 유형, 그리고 영향받는 버전 또는 버전 범위 중 하나와 일치합니다.

위치 핑거프린트(Location fingerprint)#

발견의 위치 핑거프린트는 공격 표면의 각 위치마다 고유한 텍스트 값입니다. 보안 제품마다 공격 표면 유형에 맞게 이 값을 정의합니다. 예를 들어 SAST는 파일 경로와 줄 번호를 사용합니다.

잠금 파일(Lockfile)#

애플리케이션의 직접 의존성과 간접 의존성, 그리고 그 버전 번호를 나열한 파일입니다. 목적은 재현성으로, 애플리케이션의 의존성을 설치하는 누구나 완전히 동일한 버전을 받도록 보장합니다. Gemfile.lock처럼 의존성 관계 정보를 함께 담는 잠금 파일도 있지만, 이는 필수 요건이 아닙니다.

관련 용어: 의존성 그래프 내보내기.

패키지 관리자와 패키지 유형#

패키지 관리자#

패키지 관리자는 프로젝트 의존성을 관리하는 시스템입니다.

패키지 관리자는 새 의존성("패키지"라고도 합니다)을 설치하는 방법을 제공하고, 파일 시스템에서 패키지가 저장되는 위치를 관리하며, 직접 만든 패키지를 게시하는 기능을 제공합니다.

패키지 유형#

패키지 관리자, 플랫폼, 유형, 에코시스템은 저마다 소프트웨어 패키지를 식별하고 위치를 찾고 제공하는 고유한 규칙과 프로토콜을 가집니다.

다음 표는 GitLab 문서와 소프트웨어 도구에서 참조하는 패키지 관리자 및 유형의 일부를 정리한 목록입니다.

파이프라인 보안 탭(Pipeline Security tab)#

연결된 CI 파이프라인에서 발견된 항목을 표시하는 페이지입니다.

잠재적 영향 컴포넌트(Possibly affected component)#

취약점의 영향을 받을 가능성이 있는 소프트웨어 컴포넌트입니다. 예를 들어 알려진 취약점을 찾기 위해 프로젝트를 스캔할 때, 먼저 컴포넌트가 이름과 패키지 유형에 일치하는지 평가합니다. 이 단계에서는 취약점의 영향을 받을 가능성이 있는 상태이며, 영향받는 버전 범위에 든다는 점이 확인된 뒤에야 알려진 영향 컴포넌트가 됩니다.

사후 필터(Post-filter)#

사후 필터는 스캐너 결과의 노이즈를 줄이고 수동 작업을 자동화합니다. 스캐너 결과를 바탕으로 취약점 데이터를 업데이트하거나 수정하는 기준을 지정할 수 있습니다. 예를 들어 발견을 거짓 양성일 가능성이 높은 항목으로 표시하고, 더 이상 탐지되지 않는 취약점을 자동으로 해결 처리할 수 있습니다. 이러한 조치는 영구적이지 않으며 변경할 수 있습니다.

발견을 자동으로 해결 처리하는 기능은 에픽 7478에서 추적하며, 저비용 스캔 지원은 에픽 7886에서 제안되었습니다.

사전 필터(Pre-filter)#

분석 전에 대상을 걸러내기 위해 수행하는 되돌릴 수 없는 조치입니다. 보통 사용자가 범위와 노이즈를 줄이고 분석 속도를 높이도록 제공됩니다. GitLab은 건너뛰거나 제외한 코드 또는 자산과 관련된 내용을 저장하지 않으므로, 기록이 필요한 경우에는 사용하지 않습니다.

예시: DS_EXCLUDED_PATHS는 Exclude files and directories from the scan based on the paths provided. 동작을 수행해야 합니다.

기본 식별자(Primary identifier)#

첫 번째 식별자가 기본 식별자입니다. 기본 식별자는 안정적이어야 합니다. 이후 스캔에서는 취약점 위치가 바뀌었더라도 같은 발견에 대해 같은 값을 반환해야 합니다.

프로세서(Processor)#

입력을 받아 지정된 기준에 따라 변환하는 소프트웨어로, 입력 데이터를 수정하거나 추가 메타데이터를 출력에 덧붙입니다. 프로세서는 스캐너 작업을 지원하기 위해 존재하며 스캔 전후 단계에서 주로 사용됩니다. 필터와 달리 프로세서는 비즈니스 로직에 따라 워크플로를 계속할지 중단할지 판단하는 기능이 없습니다. 대신 변환을 수행하고 결과를 조건 없이 다음 단계로 전달합니다.

사전 프로세서(Pre-processor)#

사전 프로세서는 입력 형식 정규화, 스캔 대상에 대한 컨텍스트 보강, 대상별 변환 적용, 구성 매개변수 보강 같은 데이터 준비 작업을 주로 수행합니다. 이를 통해 스캐너가 스캔 작업에 맞게 형식이 갖춰지고 보강된 입력을 받도록 보장합니다.

사후 프로세서(Post-processor)#

사후 프로세서는 스캐너가 작업을 마친 뒤 스캔 결과를 분석합니다. 사후 프로세서는 취약점 분류, 거짓 양성 필터링, 심각도 조정, 컨텍스트 보강 같은 작업으로 스캐너의 원시 출력을 보강합니다. 스캐너 결과는 처리 결과가 분석기로 반환되기 전에 여러 사후 프로세서를 차례로 거칠 수 있습니다.

도달 가능성(Reachability)#

도달 가능성은 프로젝트에 의존성으로 등록된 컴포넌트가 실제로 코드베이스에서 사용되는지를 나타냅니다.

보고서 발견(Report finding)#

분석기가 생성한 보고서에만 존재하며 아직 데이터베이스에 저장되지 않은 발견입니다. 보고서 발견은 데이터베이스로 가져온 뒤 취약점 발견이 됩니다.

스캔 유형(Scan type, report type)#

스캔의 유형을 나타냅니다. 다음 중 하나여야 합니다:

• api_fuzzing
• container_scanning
• coverage_fuzzing
• dast
• dependency_scanning
• sast
• secret_detection

이 목록은 스캐너가 추가되면서 변경될 수 있습니다.

스캔 대상 유형(Scan target type)#

스캔 실행의 범위 경계가 되는 개별 콘텐츠 또는 아티팩트 단위입니다. 각 스캔 대상 유형은 스캔 제약이 정의된 독립적인 개체를 나타냅니다. 특정 Git 리포지터리나 컨테이너 이미지처럼 스캔 대상 유형의 구체적인 인스턴스는 "스캔 대상"이라고 합니다. 스캔 대상 유형에는 Git 리포지터리, 파일 시스템, 컨테이너 등이 있습니다.

스캐너(Scanner)#

스캔 대상(스캔 대상 유형의 인스턴스)에서 보안 취약점을 스캔하는 소프트웨어입니다. 일반적으로 분석기로부터 필요한 스캔 구성 매개변수와 스캔 페이로드를 받는 무상태 컴포넌트입니다. 결과로 나온 스캔 보고서가 반드시 Secure 보고서 형식일 필요는 없습니다. 스캐너는 하나 이상의 스캔 엔진을 추가 프로세서와 함께 래핑한 복합 컴포넌트(예: 시크릿 탐지 스캐너)일 수도 있고, 독립 실행형 스캔 엔진(예: Trivy)처럼 단순할 수도 있습니다.

Secure 제품(Secure product)#

GitLab 이 정식으로 지원하는, 애플리케이션 보안의 특정 영역과 관련된 기능 모음입니다.

컨테이너 스캐닝, 의존성 스캐닝, 동적 애플리케이션 보안 테스트(DAST), 시크릿 탐지, 정적 애플리케이션 보안 테스트(SAST), 퍼즈 테스트가 이에 해당합니다.

이러한 제품에는 보통 하나 이상의 분석기가 포함됩니다.

Secure 보고서 형식(Secure report format)#

Secure 제품이 JSON 보고서를 만들 때 준수하는 표준 보고서 형식입니다. 이 형식은 JSON 스키마로 기술됩니다.

보안 대시보드(Security dashboard)#

프로젝트, 그룹 또는 GitLab 인스턴스의 모든 취약점을 개괄해 보여줍니다. 취약점은 프로젝트의 기본 브랜치에서 발견된 항목에서만 생성됩니다.

시드 코퍼스(Seed corpus)#

퍼즈 타깃에 초기 입력으로 주어지는 테스트 케이스 집합입니다. 보통 퍼즈 타깃의 속도를 크게 높입니다. 직접 만든 테스트 케이스일 수도 있고, 이전 실행에서 퍼즈 타깃이 자동 생성한 것일 수도 있습니다.

벤더(Vendor)#

분석기를 유지 관리하는 주체입니다. 따라서 벤더는 스캐너를 GitLab에 통합하고 스캐너가 발전하는 동안 호환성을 유지할 책임을 집니다. 오픈 코어나 OSS 프로젝트를 제공 제품의 기반 솔루션으로 사용하는 경우처럼, 벤더가 반드시 스캐너의 작성자나 유지 관리자인 것은 아닙니다. GitLab 배포판이나 GitLab 구독에 포함된 스캐너의 벤더는 GitLab으로 표시됩니다.

취약점(Vulnerability)#

환경의 보안에 부정적인 영향을 주는 결함입니다. 취약점은 오류나 약점 자체를 설명하며, 오류가 어디에 있는지는 설명하지 않습니다(발견 참고).

각 취약점은 고유한 발견 하나에 대응합니다.

취약점은 기본 브랜치에 존재합니다. 발견(발견 참고)은 스캐너가 MR 또는 기능 브랜치에서 식별한 잠재적 취약점 항목 전체입니다. 기본 브랜치에 머지된 뒤에야 발견이 취약점이 됩니다.

취약점 발견(Vulnerability finding)#

보고서 발견이 데이터베이스에 저장되면 취약점 발견이 됩니다.

취약점 추적(Vulnerability tracking)#

발견의 수명 주기를 파악할 수 있도록 여러 스캔에 걸쳐 발견을 대조하는 역할을 맡습니다. 엔지니어와 보안 팀은 이 정보를 바탕으로 코드 변경을 머지할지 결정하고, 해결되지 않은 발견과 그 발견이 유입된 시점을 확인합니다.

취약점은 위치 핑거프린트, 기본 식별자, 보고서 유형을 비교해 추적합니다.

취약점 발생(Vulnerability occurrence)#

더 이상 사용되지 않습니다. 발견을 참고합니다.