InfoGrab Docs

보안 용어집

요약

이 용어집은 GitLab의 보안 기능과 관련된 용어 정의를 제공합니다. 스캔 대상 유형에서 보안 취약점을 분석하는 소프트웨어입니다. CI/CD 기반 애널라이저는 CI/CD 작업을 사용하여 GitLab에 통합됩니다. 많은 GitLab 애널라이저는 Docker를 사용하여 래핑된 스캐너를 실행하는 표준 접근 방식을 따릅니다.

이 용어집은 GitLab의 보안 기능과 관련된 용어 정의를 제공합니다. 일부 용어는 다른 곳에서 다른 의미를 가질 수 있지만, 이 정의들은 GitLab에 특화된 것입니다.

Analyzer#

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

CI/CD 기반 애널라이저는 CI/CD 작업을 사용하여 GitLab에 통합됩니다. CI/CD 기반 애널라이저가 생성한 보고서는 작업이 완료된 후 아티팩트로 게시됩니다. GitLab은 이 보고서를 수집하여 사용자가 발견된 취약점을 시각화하고 관리할 수 있도록 합니다. 생성된 보고서는 보안 보고서 형식을 따릅니다.

많은 GitLab 애널라이저는 Docker를 사용하여 래핑된 스캐너를 실행하는 표준 접근 방식을 따릅니다. 예를 들어, semgrep 이미지는 Semgrep 스캐너를 래핑하는 애널라이저입니다. 그러나 일부 애널라이저는 별도의 컨테이너가 아닌 GitLab Rails 또는 다른 대상 환경에서 직접 실행됩니다.

공격 표면(Attack surface)#

애플리케이션에서 공격에 취약한 다양한 위치입니다. Secure 제품은 스캔 중에 공격 표면을 발견하고 검색합니다. 각 제품은 공격 표면을 다르게 정의합니다. 예를 들어, SAST는 파일과 줄 번호를 사용하고, DAST는 URL을 사용합니다.

컴포넌트(Component)#

소프트웨어 프로젝트의 일부를 구성하는 소프트웨어 컴포넌트입니다. 라이브러리, 드라이버, 데이터 등 다양한 유형이 있습니다.

코퍼스(Corpus)#

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

CNA#

CVE 번호 부여 기관(CVE Numbering Authorities, CNAs)은 전 세계의 조직으로, Mitre Corporation으로부터 각자의 범위 내에 있는 제품이나 서비스의 취약점에 CVE를 할당할 권한을 부여받은 기관입니다. 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)으로 생성되어 파일로 출력됩니다.

관련 용어: 잠금 파일(lockfile).

의존성 버전 충돌(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과 같은 일부 잠금 파일에는 의존성 관계 정보도 포함되어 있지만 이것은 요구 사항이 아닙니다.

관련 용어: 의존성 그래프 내보내기(dependency graph export).

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

패키지 관리자#

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

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

패키지 유형#

각 패키지 관리자, 플랫폼, 유형 또는 에코시스템은 소프트웨어 패키지를 식별, 위치 지정 및 제공하기 위한 자체 규칙과 프로토콜을 가지고 있습니다.

다음 표는 GitLab 문서 및 소프트웨어 도구에서 참조되는 패키지 관리자 및 유형의 비포괄적인 목록입니다.

Package Type Package Manager
gem Bundler
Packagist Composer
Conan Conan
go go
maven Gradle
Maven
sbt
npm npm
yarn
NuGet NuGet
PyPI Setuptools
pip
Pipenv
Poetry

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

연관된 CI 파이프라인에서 발견된 결과를 표시하는 페이지입니다.

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

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

사후 필터(Post-filter)#

사후 필터는 스캐너 결과의 노이즈를 줄이고 수동 작업을 자동화하는 데 도움이 됩니다. 스캐너 결과를 기반으로 취약점 데이터를 업데이트하거나 수정하는 기준을 지정할 수 있습니다. 예를 들어, 발견을 잠재적 거짓 양성으로 표시하고 더 이상 감지되지 않는 취약점을 자동으로 해결할 수 있습니다. 이는 영구적인 조치가 아니며 변경할 수 있습니다.

발견 자동 해결에 대한 지원은 에픽 7478에서 추적되고 있으며, 저렴한 스캔에 대한 지원은 에픽 7886에서 제안되어 있습니다.

사전 필터(Pre-filter)#

분석이 발생하기 전에 대상을 필터링하기 위해 수행되는 되돌릴 수 없는 조치입니다. 이는 일반적으로 사용자가 범위와 노이즈를 줄이고 분석 속도를 높일 수 있도록 제공됩니다. GitLab은 건너뛰거나 제외된 코드나 자산과 관련된 어떤 것도 저장하지 않기 때문에 기록이 필요한 경우에는 수행하지 않아야 합니다.

예: DS_EXCLUDED_PATHS는 제공된 경로를 기반으로 스캔에서 파일과 디렉토리를 제외해야 합니다.

기본 식별자(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)#

JSON 보고서를 생성할 때 Secure 제품이 준수하는 표준 보고서 형식입니다. 이 형식은 JSON 스키마로 설명됩니다.

보안 대시보드(Security dashboard)#

프로젝트, 그룹 또는 GitLab 인스턴스의 모든 취약점에 대한 개요를 제공합니다. 취약점은 프로젝트의 기본 브랜치에서 발견된 결과에서만 생성됩니다.

시드 코퍼스(Seed corpus)#

퍼즈 대상에 초기 입력으로 제공되는 테스트 케이스 집합입니다. 이는 일반적으로 퍼즈 대상을 상당히 가속화합니다. 수동으로 생성된 테스트 케이스이거나 이전 실행에서 퍼즈 대상 자체로 자동 생성된 것일 수 있습니다.

벤더(Vendor)#

애널라이저를 유지 관리하는 당사자입니다. 따라서 벤더는 스캐너를 GitLab에 통합하고 그것이 발전함에 따라 호환성을 유지할 책임이 있습니다. 벤더는 오픈 코어 또는 OSS 프로젝트를 제품의 기본 솔루션으로 사용하는 경우처럼 반드시 스캐너의 작성자 또는 유지 관리자일 필요는 없습니다. GitLab 배포 또는 GitLab 구독의 일부로 포함된 스캐너의 경우 벤더는 GitLab으로 나열됩니다.

취약점(Vulnerability)#

환경 보안에 부정적인 영향을 미치는 결함입니다. 취약점은 오류 또는 약점을 설명하며, 오류가 위치한 곳을 설명하지 않습니다(발견 참조).

각 취약점은 고유한 발견에 매핑됩니다.

취약점은 기본 브랜치에 존재합니다. 발견(발견 참조)은 스캐너가 MR/기능 브랜치에서 식별하는 모든 잠재적 취약점 항목입니다. 기본 브랜치에 병합된 후에야 발견이 취약점이 됩니다.

취약점 발견(Vulnerability finding)#

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

취약점 추적(Vulnerability tracking)#

발견의 수명 주기를 이해할 수 있도록 스캔 전반에 걸쳐 발견을 매칭하는 책임을 다룹니다. 엔지니어와 보안 팀은 이 정보를 사용하여 코드 변경을 병합할지 여부를 결정하고, 해결되지 않은 발견과 언제 도입되었는지를 확인합니다.

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

취약점 발생(Vulnerability occurrence)#

더 이상 사용되지 않음. 발견을 참조하세요.

보안 용어집

Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

이 용어집은 GitLab의 보안 기능과 관련된 용어 정의를 제공합니다. 스캔 대상 유형에서 보안 취약점을 분석하는 소프트웨어입니다. CI/CD 기반 애널라이저는 CI/CD 작업을 사용하여 GitLab에 통합됩니다. 많은 GitLab 애널라이저는 Docker를 사용하여 래핑된 스캐너를 실행하는 표준 접근 방식을 따릅니다.

이 용어집은 GitLab의 보안 기능과 관련된 용어 정의를 제공합니다. 일부 용어는 다른 곳에서 다른 의미를 가질 수 있지만, 이 정의들은 GitLab에 특화된 것입니다.

Analyzer#

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

CI/CD 기반 애널라이저는 CI/CD 작업을 사용하여 GitLab에 통합됩니다. CI/CD 기반 애널라이저가 생성한 보고서는 작업이 완료된 후 아티팩트로 게시됩니다. GitLab은 이 보고서를 수집하여 사용자가 발견된 취약점을 시각화하고 관리할 수 있도록 합니다. 생성된 보고서는 보안 보고서 형식을 따릅니다.

많은 GitLab 애널라이저는 Docker를 사용하여 래핑된 스캐너를 실행하는 표준 접근 방식을 따릅니다. 예를 들어, semgrep 이미지는 Semgrep 스캐너를 래핑하는 애널라이저입니다. 그러나 일부 애널라이저는 별도의 컨테이너가 아닌 GitLab Rails 또는 다른 대상 환경에서 직접 실행됩니다.

공격 표면(Attack surface)#

애플리케이션에서 공격에 취약한 다양한 위치입니다. Secure 제품은 스캔 중에 공격 표면을 발견하고 검색합니다. 각 제품은 공격 표면을 다르게 정의합니다. 예를 들어, SAST는 파일과 줄 번호를 사용하고, DAST는 URL을 사용합니다.

컴포넌트(Component)#

소프트웨어 프로젝트의 일부를 구성하는 소프트웨어 컴포넌트입니다. 라이브러리, 드라이버, 데이터 등 다양한 유형이 있습니다.

코퍼스(Corpus)#

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

CNA#

CVE 번호 부여 기관(CVE Numbering Authorities, CNAs)은 전 세계의 조직으로, Mitre Corporation으로부터 각자의 범위 내에 있는 제품이나 서비스의 취약점에 CVE를 할당할 권한을 부여받은 기관입니다. 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)으로 생성되어 파일로 출력됩니다.

관련 용어: 잠금 파일(lockfile).

의존성 버전 충돌(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과 같은 일부 잠금 파일에는 의존성 관계 정보도 포함되어 있지만 이것은 요구 사항이 아닙니다.

관련 용어: 의존성 그래프 내보내기(dependency graph export).

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

패키지 관리자#

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

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

패키지 유형#

각 패키지 관리자, 플랫폼, 유형 또는 에코시스템은 소프트웨어 패키지를 식별, 위치 지정 및 제공하기 위한 자체 규칙과 프로토콜을 가지고 있습니다.

다음 표는 GitLab 문서 및 소프트웨어 도구에서 참조되는 패키지 관리자 및 유형의 비포괄적인 목록입니다.

Package Type Package Manager
gem Bundler
Packagist Composer
Conan Conan
go go
maven Gradle
Maven
sbt
npm npm
yarn
NuGet NuGet
PyPI Setuptools
pip
Pipenv
Poetry

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

연관된 CI 파이프라인에서 발견된 결과를 표시하는 페이지입니다.

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

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

사후 필터(Post-filter)#

사후 필터는 스캐너 결과의 노이즈를 줄이고 수동 작업을 자동화하는 데 도움이 됩니다. 스캐너 결과를 기반으로 취약점 데이터를 업데이트하거나 수정하는 기준을 지정할 수 있습니다. 예를 들어, 발견을 잠재적 거짓 양성으로 표시하고 더 이상 감지되지 않는 취약점을 자동으로 해결할 수 있습니다. 이는 영구적인 조치가 아니며 변경할 수 있습니다.

발견 자동 해결에 대한 지원은 에픽 7478에서 추적되고 있으며, 저렴한 스캔에 대한 지원은 에픽 7886에서 제안되어 있습니다.

사전 필터(Pre-filter)#

분석이 발생하기 전에 대상을 필터링하기 위해 수행되는 되돌릴 수 없는 조치입니다. 이는 일반적으로 사용자가 범위와 노이즈를 줄이고 분석 속도를 높일 수 있도록 제공됩니다. GitLab은 건너뛰거나 제외된 코드나 자산과 관련된 어떤 것도 저장하지 않기 때문에 기록이 필요한 경우에는 수행하지 않아야 합니다.

예: DS_EXCLUDED_PATHS는 제공된 경로를 기반으로 스캔에서 파일과 디렉토리를 제외해야 합니다.

기본 식별자(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)#

JSON 보고서를 생성할 때 Secure 제품이 준수하는 표준 보고서 형식입니다. 이 형식은 JSON 스키마로 설명됩니다.

보안 대시보드(Security dashboard)#

프로젝트, 그룹 또는 GitLab 인스턴스의 모든 취약점에 대한 개요를 제공합니다. 취약점은 프로젝트의 기본 브랜치에서 발견된 결과에서만 생성됩니다.

시드 코퍼스(Seed corpus)#

퍼즈 대상에 초기 입력으로 제공되는 테스트 케이스 집합입니다. 이는 일반적으로 퍼즈 대상을 상당히 가속화합니다. 수동으로 생성된 테스트 케이스이거나 이전 실행에서 퍼즈 대상 자체로 자동 생성된 것일 수 있습니다.

벤더(Vendor)#

애널라이저를 유지 관리하는 당사자입니다. 따라서 벤더는 스캐너를 GitLab에 통합하고 그것이 발전함에 따라 호환성을 유지할 책임이 있습니다. 벤더는 오픈 코어 또는 OSS 프로젝트를 제품의 기본 솔루션으로 사용하는 경우처럼 반드시 스캐너의 작성자 또는 유지 관리자일 필요는 없습니다. GitLab 배포 또는 GitLab 구독의 일부로 포함된 스캐너의 경우 벤더는 GitLab으로 나열됩니다.

취약점(Vulnerability)#

환경 보안에 부정적인 영향을 미치는 결함입니다. 취약점은 오류 또는 약점을 설명하며, 오류가 위치한 곳을 설명하지 않습니다(발견 참조).

각 취약점은 고유한 발견에 매핑됩니다.

취약점은 기본 브랜치에 존재합니다. 발견(발견 참조)은 스캐너가 MR/기능 브랜치에서 식별하는 모든 잠재적 취약점 항목입니다. 기본 브랜치에 병합된 후에야 발견이 취약점이 됩니다.

취약점 발견(Vulnerability finding)#

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

취약점 추적(Vulnerability tracking)#

발견의 수명 주기를 이해할 수 있도록 스캔 전반에 걸쳐 발견을 매칭하는 책임을 다룹니다. 엔지니어와 보안 팀은 이 정보를 사용하여 코드 변경을 병합할지 여부를 결정하고, 해결되지 않은 발견과 언제 도입되었는지를 확인합니다.

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

취약점 발생(Vulnerability occurrence)#

더 이상 사용되지 않음. 발견을 참조하세요.