• 어플리케이션 커버리지
  • 소스 코드 분석
  • 실행 중인 웹 어플리케이션 분석
  • 종속성 분석
  • 인프라스트럭처 분석
• 데이터 프라이버시
• 취약점 스캐너 유지 보수
• Auto DevOps를 사용한 보안 스캐닝
• Auto DevOps 없는 보안 스캐닝
  • 기본 레지스트리 기본 주소 재정의
  • Merge Request 파이프라인에서 보안 스캐닝 도구 사용
• 보안 스캐닝
  • 파이프라인의 보안 작업
  • 안전 작업 상태
  • JSON Artifact
• 보안 스캔 정보 보기
  • 병합 요청
    • 모든 티어
    • 얼티메이트
  • 파이프라인 보안 탭
  • 보안 대시보드
  • 취약점 보고서
  • GitLab Workflow for VS Code 확장
• 병합 요청에서의 보안 승인
• 개인 Maven 저장소 사용
• 사용자 정의 스캔 단계 사용
• 자체 관리 설치 옵션
• 보안 보고서 유효성 검증
• 발견 및 취약점과 상호 작용
• 보안 스캔 구성 팁
  • 스캔 실행 강제화

어플리케이션 보안

GitLab은 다음과 같은 보안 취약점을 포함하여 어플리케이션을 점검할 수 있습니다:

• 무단 액세스.
• 데이터 유출.
• 서비스 거부 (DoS) 공격.

GitLab 어플리케이션 보안에 대한 개요는 보안을 좌측으로 이동를 참조하세요.

클릭 스루 데모를 보려면 파이프라인에 보안 통합을 참조하세요.

통계 및 취약점에 대한 자세한 내용은 병합 요청에 포함되어 있습니다. 변경 사항을 병합하기 전에 실행 가능한 정보를 제공하여 예방적 조치를 취할 수 있습니다.

취약점을 관리하고 대응하는 작업을 돕기 위해, GitLab은 프로젝트나 그룹에서 액세스할 수 있는 보안 대시보드를 제공합니다. 자세한 내용은 보안 대시보드에서 확인하세요.

어플리케이션 커버리지

GitLab은 CI/CD 파이프라인이나 일정에 근거하여 여러 어플리케이션 세부 정보를 분석합니다. 커버리지는 다음을 포함합니다:

• 소스 코드.
• 프로젝트나 컨테이너 이미지의 종속성.
• 실행 중인 웹 어플리케이션의 취약점.
• 인프라스트럭처 코드 구성.

각 GitLab 어플리케이션 보안 도구는 특정 기능 개발 워크플로우 단계에 관련이 있습니다.

• 커밋
  • SAST
  • 시크릿 탐지
  • IaC 스캔
  • 종속성 스캔
  • 커버리지 가이드된 Fuzz 테스트
• 빌드
  • 컨테이너 스캔
• 테스트
  • API 보안
  • DAST
• 배포
  • 운영용 컨테이너 스캔

소스 코드 분석

소스 코드 분석은 매 코드 커밋마다 발생합니다. 감지된 취약점의 자세한 내용은 병합 요청에서 제공됩니다.

소스 코드 분석은 다음을 수행할 수 있습니다:

• 취약점에 대한 소스 코드 분석 - 정적 어플리케이션 보안 테스트(SAST).
• 깃 리포지토리의 히스토리를 시크릿으로부터 분석 - 시크릿 탐지.

실행 중인 웹 어플리케이션 분석

웹 어플리케이션 분석은 매 코드 커밋마다 발생합니다. CI/CD 파이프라인의 일부로, 어플리케이션이 구축되어 테스트 환경에 배포되고 다음 테스트를 받습니다:

• 알려진 공격 벡터에 대한 어플리케이션 테스트 - 동적 어플리케이션 보안 테스트(DAST).
• 알려진 공격 벡터를 위한 API 분석 - API 보안.
• 알려지지 않은 버그 및 취약점에 대한 웹 API 분석 - API fuzzing.

종속성 분석

코드 커밋마다 종속성 분석이 발생합니다. 어플리케이션의 종속성이 모아지고 알려진 취약점 데이터베이스와 대조됩니다.

종속성 분석은 다음에서 실행될 수 있습니다:

• 빌드 시간에 - 종속성 스캔.
• 컨테이너 이미지를 사용하는 프로젝트의 경우, 최종 컨테이너 이미지가 구축된 후에도 - 컨테이너 스캔.

자세한 내용은 종속성 스캔 대비 컨테이너 스캔에서 확인하세요.

또한, 운영용 컨테이너 이미지의 종속성은 정기적으로 또는 주기적으로 취약점에 대해 분석될 수 있습니다. 자세한 내용은 운영용 컨테이너 스캔에서 확인하세요.

인프라스트럭처 분석

어플리케이션의 인프라스트럭처는 잠재적인 취약점의 원천입니다. 이를 방어하는 데 도움을 주기 위해, 인프라스트럭처 분석은 매 병합 요청에서 실행됩니다. 다음을 대상으로 체크를 실행합니다:

• 어플리케이션의 배포 환경을 정의하는 인프라스트럭처 코드 파일 - 인프라스트럭처 코드 (IaC) 스캔.

데이터 프라이버시

보안 스캐너의 데이터 프라이버시에 관한 논의에서 GitLab은 소스 코드를 처리하고 GitLab 러너 내에서 로컬 분석을 수행합니다. GitLab 인프라스트럭처(서버 및 러너) 외부로 데이터가 전송되지 않습니다.

저희 스캐너들은 최신 싸인, 규칙, 및 패치를 다운로드하기 위해 인터넷에만 접속합니다. 스캐너들이 인터넷에 접속하지 않길 원하신다면 오프라인 환경을 고려해보세요.

취약점 스캐너 유지 보수

다음 취약점 스캐너 및 그들의 데이터베이스는 정기적으로 업데이트됩니다:

같은 주요 버전의 분석기를 사용하는 GitLab 버전에서는 최신 취약점 정의를 얻기 위해 그들을 업데이트할 필요가 없습니다. 보안 도구들은 Docker 이미지로 릴리즈됩니다. 그들을 가능하도록 하는 벤더화된 작업 정의들은 의미 있는 버전 관리 형식에 따라 주요 릴리즈 태그를 사용합니다. 새로운 툴의 릴리스마다 이러한 태그는 대체됩니다. 분석기 주요 버전에서는 스캐닝 툴의 최신 버전을 자동으로 얻지만, 이러한 방식에 대한 알려진 이슈도 있습니다.

Auto DevOps를 사용한 보안 스캐닝

기본 설정으로 모든 GitLab 보안 스캐닝 도구를 활성화하려면 Auto DevOps를 활성화하세요:

• Auto SAST
• Auto Secret Detection
• Auto DAST
• Auto Dependency Scanning
• Auto Container Scanning

Auto DevOps를 직접 사용자 정의할 수는 없지만 프로젝트의 .gitlab-ci.yml 파일에 Auto DevOps 템플릿을 포함시킬 수 있습니다.

Auto DevOps 없는 보안 스캐닝

사용자 정의 설정 옵션을 포함한 모든 GitLab 보안 스캐닝 도구를 활성화하려면 GitLab CI/CD 템플릿을 .gitlab-ci.yml 파일에 추가하세요.

경고: GitLab 보안 스캐닝 도구의 모든 사용자 정의는 기본 브랜치로의 변경 병합 전에 merge request에서 테스트되어야 합니다. 이를 하지 않으면 예기치 않은 결과가 발생할 수 있으며, 거짓 긍정의 수가 많아질 수 있습니다.

정적 애플리케이션 보안 테스트, 의존성 스캐닝, 그리고 Secret Detection을 활성화하려면 다음을 추가하세요:

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml

동적 애플리케이션 보안 테스트 (DAST) 스캐닝을 활성화하려면 다음을 .gitlab-ci.yml에 추가하세요. https://staging.example.com을 스테이징 서버의 웹 주소로 대체하세요:

include:
  - template: Security/DAST.gitlab-ci.yml

variables:
  DAST_WEBSITE: https://staging.example.com

기본 레지스트리 기본 주소 재정의

기본 설정으로 GitLab 보안 스캐너는 Docker 이미지의 기본 주소로 registry.gitlab.com/security-products를 사용합니다. 이를 다른 위치로 재정의하려면 대부분의 스캐너에 대해 CI/CD 변수 SECURE_ANALYZERS_PREFIX를 설정하세요. 이는 한꺼번에 모든 스캐너에 영향을 줍니다.

컨테이너 스캐닝 분석기는 예외이며 SECURE_ANALYZERS_PREFIX 변수를 사용하지 않습니다. 해당 Docker 이미지를 재정의하려면 오프라인 환경에서 컨테이너 스캐닝 실행 지침을 참조하세요.

Merge Request 파이프라인에서 보안 스캐닝 도구 사용

기본적으로 애플리케이션 보안 작업은 브랜치 파이프라인에서만 실행되도록 구성되어 있습니다. 이를 merge request 파이프라인에서 사용하려면 latest 템플릿을 참조해야 합니다.

최신 버전의 템플릿은 파괴적인 변경 사항을 포함할 수 있습니다. 최신 템플릿에서만 제공되는 기능이 필요하지 않은 경우 안정적인 템플릿을 사용하세요.

모든 latest 보안 템플릿은 merge request 파이프라인을 지원합니다.

예를 들어, SAST와 Dependency Scanning을 모두 실행하려면 다음 템플릿을 사용합니다:

include:
  - template: Jobs/Dependency-Scanning.latest.gitlab-ci.yml
  - template: Jobs/SAST.latest.gitlab-ci.yml

참고: latest 및 stable 보안 템플릿을 혼합하면 MR 및 브랜치 파이프라인이 모두 실행될 수 있습니다. 모든 보안 스캐너에 대해 latest 또는 stable을 선택하는 것이 좋습니다.

참고: 최신 템플릿은 어떤 릴리스에서도 파괴적인 변경 사항을 받을 수 있습니다.

템플릿 버전에 대한 자세한 내용은 CI/CD 문서를 참조하세요.

보안 스캐닝

CI/CD 파이프라인에서 실행되는 보안 스캐닝의 결과는 다음에 의해 결정됩니다:

• 파이프라인에서 실행되는 보안 스캐닝 작업.
• 각 작업의 상태.
• 각 작업의 출력.

파이프라인의 보안 작업

CI/CD 파이프라인에서 실행되는 보안 스캐닝 작업은 다음 기준에 따라 결정됩니다:

1. 보안 스캔 템플릿 포함

   보안 스캔 작업의 선택은 먼저 포함된 템플릿에 의해 결정됩니다. 템플릿은 AutoDevOps, 스캔 실행 정책 또는 .gitlab-ci.yml 구성 파일을 사용하여 포함할 수 있습니다.

2. 규칙 평가

   각 템플릿에는 실행 여부를 결정하는 정의된 규칙이 있습니다.

   예를 들어, Secret Detection 템플릿에는 다음과 같은 규칙이 포함됩니다. 이 규칙에 따르면 보안 요소 감지는 브랜치 파이프라인에서 실행되어야 합니다. MR 파이프라인의 경우 Secret Detection이 실행되지 않습니다.

   rules:
     - if: $CI_COMMIT_BRANCH
   

3. 분석기 논리

   템플릿의 규칙이 작업을 실행하도록 하면 해당 템플릿에서 지정된 파이프라인 단계에 작업이 생성됩니다. 그러나 각 분석기에는 해당 분석기 자체를 실행할지 여부를 결정하는 고유한 논리가 있습니다.

   예를 들어, 의존성 스캐닝에서 지원되는 파일을 기본적인 깊이에서 감지하지 못하면 해당 분석기가 실행되지 않으며 아무런 결과물도 출력되지 않습니다.

성공적으로 완료된 각 작업은 결과물을 출력합니다. 이러한 결과물은 처리되어 GitLab에서 결과가 사용 가능해집니다. 모든 작업이 완료된 경우에만 결과가 표시되며, 수동 작업도 포함됩니다. 또한 일부 기능의 경우 기본 브랜치에서만 파이프라인이 실행될 때 결과가 표시됩니다.

안전 작업 상태

작업이 스캔을 완료할 수 있는 경우 작업은 통과합니다. 통과 결과는 그들이 발견했는지 여부를 나타내지 않습니다. 유일한 예외는 커버리지 퍼징인데, 이 경우 발견 사항을 식별하면 실패합니다.

작업이 스캔을 완료할 수 없는 경우 작업이 실패합니다. 자세한 내용은 파이프라인 로그에서 확인할 수 있습니다.

기본적으로 모든 작업은 실패할 수 있습니다. 즉, 실패하더라도 파이프라인이 실패하지는 않습니다.

취약점이 병합되지 않도록 하려면 선택한 특정 그룹의 승인 없이 알 수 없는, 높은 또는 중요한 발견 사항이 병합되는 것을 방지하기 위해 병합 요청에서 보안 승인을 추가하세요.

작업 allow_failure 설정을 변경하는 것을 권장하지 않습니다. 해당 설정은 전체 파이프라인을 실패하게 만듭니다.

JSON Artifact

안전 분석기에 의해 생성된 artifact에는 이전에 발견되었던 것인지, 기각되었던지, 아니면 새로 발견된 모든 발견 사항이 타깃 브랜치에 대해 포함됩니다(발견한 모든 것을 담습니다).

보안 스캔 정보 보기

보안 스캔 정보는 여러 위치와 형식에서 나타납니다:

• 병합 요청
• 파이프라인 보안 탭
• 보안 대시보드
• 취약점 보고서
• VS Code용 GitLab Workflow 확장

병합 요청

활성화된 모든 응용 프로그램 보안 도구의 결과가 병합 요청 위젯에 표시됩니다. 이 정보를 사용하여 소스 브랜치에서 식별된 모든 문제의 위험을 관리할 수 있습니다.

모든 티어

보안 스캔을 실행한 병합 요청은 생성된 보고서를 다운로드할 수 있는지 안내합니다. 보고서를 다운로드하려면 결과 다운로드를 선택하고 원하는 보고서를 선택하세요.

보안 스캔은 최소한 하나의 다음 CI artifacts:reports 유형을 생성합니다:

• artifacts:reports:api_fuzzing
• artifacts:reports:container_scanning
• artifacts:reports:coverage_fuzzing
• artifacts:reports:dast
• artifacts:reports:dependency_scanning
• artifacts:reports:sast
• artifacts:reports:secret_detection

무료 티어에서는 위의 보고서들이 GitLab에 의해 구문 분석되지 않습니다. 결과적으로 보안 스캔의 결과에 따라 위젯이 변경되지 않습니다.

얼티메이트

병합 요청에는 새로운 결과를 요약으로 표시하는 보안 위젯이 포함됩니다. 새로운 결과는 생성된 병합 요청의 발견 사항을 타깃 브랜치로부터 생성된 최근 완료된 파이프라인(success, failed, canceled, skipped)의 발견 사항과 비교함으로써 결정됩니다.

GitLab은 타깃 브랜치에서의 feature 브랜치 생성 시 커밋에 대해 비교 논리에 사용할 보안 보고서를 찾기 위해 해당 커밋에 대한 최근 10개의 파이프라인을 확인합니다. 기능 브랜치가 생성된 타깃 브랜치에 대해 최근 10개의 완료된 파이프라인에 대한 보안 스캔이 실행되지 않은 경우, 비교할 기준이 없습니다. 병합 요청 발견 사항의 취약성은 “new”로 나열됩니다. 개발자들을 위한 기능 브랜치 스캔을 활성화하기 전에 default(타깃) 브랜치를 스캔 실행하는 것을 권장합니다.

병합 요청 보안 위젯은 병합 요청 승인이 필요한지 여부를 결정할 때 소스 및 타깃 브랜치의 결과를 비교함으로써 지원되는 파이프라인 소스(based on the CI_PIPELINE_SOURCE variable)를 모두 고려합니다. webide 및 parent_pipeline 파이프라인 소스는 지원되지 않습니다.

병합 요청 보안 위젯은 생성된 JSON artifact의 취약성 중 하위 집합만 표시합니다. 이는 새로운 발견 사항과 기존의 발견 사항을 모두 포함하기 때문입니다.

병합 요청 보안 보고서 유형마다 위젯은 소스 브랜치 및 타깃 브랜치 파이프라인의 보안 보고서를 비교하여 중요도에 따라 추가된 25개 및 수정된 25개의 발견 사항을 표시합니다.

예를 들어, 두 파이프라인의 스캔 결과를 고려해 보겠습니다:

• 소스 브랜치 파이프라인은 V1 및 V2로 식별된 두 가지 취약점을 감지합니다.
• 타깃 브랜치 파이프라인은 V1 및 V3로 식별된 두 가지 취약점을 감지합니다.
• V2는 병합 요청 위젯에서 “added”로 표시됩니다.
• V3은 병합 요청 위젯에서 “fixed”로 표시됩니다.
• V1은 양쪽 브랜치에 모두 존재하며 병합 요청 위젯에 표시되지 않습니다.

병합 요청의 원본 브랜치에서 모든 발견 사항을 보려면 전체 보고서 보기를 선택하여 가장 최근 소스 브랜치 파이프라인의 보안 탭으로 바로 이동하세요.

파이프라인 보안 탭

파이프라인의 보안 탭은 파이프라인 작업 아티팩트에서 보안 보고서의 모든 결과를 나열합니다. 자세한 내용은 파이프라인의 취약점을 참조하세요.

보안 대시보드

보안 대시보드는 프로젝트의 기본 브랜치에서의 취약점을 보여줍니다. 데이터는 매 24시간마다 업데이트됩니다. 새로운 취약점을 도입하는 기능 브랜치로 병합되어 기본 브랜치에 반영된 결과로 인한 취약성 카운트 업데이트는 매일 데이터 갱신 이후에 포함됩니다.

자세한 내용은 보안 대시보드를 참조하세요.

취약점 보고서

취약점 보고서는 기본 브랜치에서 마지막으로 완료된 파이프라인의 결과를 보여줍니다. 파이프라인 완료마다 업데이트됩니다. 모든 검출된 취약점이 표시되며, 최신 스캔에서 더 이상 감지되지 않는 이전 취약점도 표시됩니다. 더 이상 감지되지 않는 취약점은 개선되었거나 다른 방식으로 제거되었을 수 있으며, 적절한 검증 후 ‘해결됨’으로 표시할 수 있습니다. 더 이상 감지되지 않는 취약점은 필터링 및 검토를 위한 아이콘으로 표시됩니다.

기본적으로 취약점 보고서에는 ‘해결됨’ 또는 ‘해결됨’ 상태의 취약점이 표시되지 않으므로 열린 취약점에 집중할 수 있습니다. 이를 보려면 상태 필터를 변경할 수 있습니다.

취약점 보고서에 대해 자세히 알아보기.

GitLab Workflow for VS Code 확장

이제 GitLab Workflow for VS Code 확장을 사용하여 Visual Studio Code (VS Code)에서 직접 보안 결과를 볼 수 있습니다. 이는 병합 요청에서 하는 것과 동일합니다.

자세한 내용은 확장 페이지를 참조하세요.

병합 요청에서의 보안 승인

• GitLab 12.2에 도입됨.
• GitLab 15.0에서 보안 취약성 확인 기능이 제거됨.
• GitLab 16.0에서 라이선스 확인 기능이 제거됨.

다음 보안 문제 중 하나를 도입할 병합 요청에 대해 추가 승인을 강제할 수 있습니다:

• 보안 취약점. 자세한 내용은 병합 요청 승인 정책을 참조하세요.

개인 Maven 저장소 사용

로그인 자격 증명이 필요한 개인 Apache Maven 저장소가 있는 경우 MAVEN_CLI_OPTS CI/CD 변수를 사용하여 사용자 이름 및 비밀번호를 전달할 수 있습니다. 프로젝트 설정에서 이를 설정하여 .gitlab-ci.yml에 자격 증명이 노출되지 않도록 할 수 있습니다.

사용자 이름이 myuser이고 비밀번호가 verysecret인 경우 프로젝트 설정에서 다음 변수를 설정할 수 있습니다:

<!-- mysettings.xml -->
<settings>
    ...
    <servers>
        <server>
            <id>private_server</id>
            <username>${private.username}</username>
            <password>${private.password}</password>
        </server>
    </servers>
</settings>

사용자 정의 스캔 단계 사용

보안 스캔이 활성화되어 있고 Auto DevOps 없이 보안 스캔 섹션에서 설명한대로 CI/CD 템플릿을 포함하는 경우, 스캔 작업은 기본적으로 미리 정의된 test 단계를 사용합니다. .gitlab-ci.yml 파일에서 test 단계를 포함하지 않고 사용자가 사용자 정의 단계를 지정한 경우 오류가 발생합니다.

예를 들어, 다음과 같이 unit-tests 단계를 사용하려고 하는 경우:

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml

stages:
  - unit-tests

custom job:
  stage: unit-tests
  script:
    - echo "custom job"

위의 .gitlab-ci.yml은 다음과 같은 린트 오류를 발생시킵니다:

파이프라인을 만들 수 없음
- dependency_scanning 작업: 선택한 단계가 존재하지 않음; 사용 가능한 단계는 .pre, unit-tests, .post 입니다.

이 오류는 보안 스캔 작업에서 사용하는 test 단계가 .gitlab-ci.yml 파일에 선언되지 않았기 때문에 발생합니다. 이 문제를 해결하려면 다음을 수행할 수 있습니다:

• .gitlab-ci.yml에 test 단계를 추가합니다:

  include:
    - template: Jobs/Dependency-Scanning.gitlab-ci.yml
    - template: Jobs/SAST.gitlab-ci.yml
    - template: Jobs/Secret-Detection.gitlab-ci.yml
  
  stages:
    - test
    - unit-tests
  
  custom job:
    stage: unit-tests
    script:
      - echo "custom job"
  

• 각 보안 작업의 기본 단계를 재정의합니다. 예를 들어, 사전 정의된 unit-tests 단계를 사용하려면 다음을 수행합니다:

  include:
    - template: Jobs/Dependency-Scanning.gitlab-ci.yml
    - template: Jobs/SAST.gitlab-ci.yml
    - template: Jobs/Secret-Detection.gitlab-ci.yml
  
  stages:
    - unit-tests
  
  dependency_scanning:
    stage: unit-tests
  
  sast:
    stage: unit-tests
  
  .secret-analyzer:
    stage: unit-tests
  
  custom job:
    stage: unit-tests
    script:
      - echo "custom job"
  

보안 스캔 도구는 모두 자신의 단계를 정의하므로 이 오류는 모든 보안 스캔 도구에서 발생할 수 있습니다.

자체 관리 설치 옵션

자체 관리 설치의 경우, 인터넷에 연결되지 않은 경우에도 GitLab 보안 스캐너 대부분을 실행할 수 있습니다.

자체 관리 설치는 GitLab Runner에서도 보안 스캐너를 실행할 수 있습니다. 이 때 GitLab Runner는 OpenShift 내에서 실행되어야 합니다.

보안 보고서 유효성 검증

• GitLab 13.11에 도입됨.
• 스키마 유효성 검증 메시지가 GitLab 14.0에 추가됨.

GitLab 15.0에서는 취약점을 데이터베이스로 가져가기 전에 보안 보고서 아티팩트의 유효성을 강제합니다. GitLab은 보고서에서 선언된 스키마 버전에 따라 아티팩트의 유효성을 보고서 스키마에 대해 확인합니다.

파이프라인의 보안 탭에는 유효성 검증에 실패한 모든 보고서 아티팩트와 검증 오류 메시지가 나열됩니다.

유효성 검증은 보안 보고서 아티팩트에서 선언된 스키마 버전에 따라 달라집니다.

• 보안 보고서가 지원되는 스키마 버전을 지정한 경우, GitLab은 이 버전을 사용하여 유효성을 검증합니다.
• 보안 보고서가 더 이상 사용되지 않는 버전을 사용한 경우, GitLab은 해당 버전에 대한 유효성 검증을 시도하고 유효성 검증 결과에 유효하지 않음 경고를 추가합니다.
• 보안 보고서가 지원되는 주요-부 버전을 사용하지만 패치 버전이 상응하는 버전과 일치하지 않은 경우, GitLab은 최신 패치 버전으로 유효성을 검증하려고 시도합니다.
  • 예: 보안 보고서가 버전 14.1.1을 사용하는 경우, 최신 패치 버전이 14.1.0이라면 GitLab은 스키마 버전 14.1.0을 사용하여 유효성을 검증합니다.
• 보안 보고서가 지원되지 않는 버전을 사용한 경우, GitLab은 설치된 최신 스키마 버전을 사용하여 유효성을 검증하지만 보고서를 가져오지는 않습니다.
• 보안 보고서가 스키마 버전을 지정하지 않은 경우, GitLab은 GitLab에서 제공하는 최신 스키마 버전을 사용하여 유효성을 검증하려고 시도합니다. 해당 경우 항상 유효성 검증이 실패하지만 다른 유효성 검증 오류가 존재할 수도 있습니다.

지원되는 및 중지된 스키마 버전의 세부 정보는 소스 코드에서 언제든지 확인할 수 있습니다.

발견 및 취약점과 상호 작용

보안 스캐닝 도구의 결과물과 다양한 위치에서 상호 작용할 수 있습니다:

• 병합 요청에서 스캔 정보
• 프로젝트 보안 대시보드
• 보안 파이프라인 탭
• 그룹 보안 대시보드
• 보안 센터
• 취약점 보고서
• 취약점 페이지
• 의존성 목록

해당 위치에서 볼 수 있는 발견 또는 취약점에 대한 자세한 내역은 각 링크를 선택하면 확인할 수 있습니다. 각 페이지는 발견과 취약점과의 상호 작용 방법에 대해 설명합니다. 대부분의 경우, 발견은 감지됨 상태로 시작합니다.

다음과 같은 옵션이 있습니다:

• 상태 변경.
• 이슈 생성.
• 기존 이슈에 연결.
• 취약점 해결, 해결 방법이 알려진 경우.

보안 스캔 구성 팁

각 GitLab 보안 스캐닝 도구에는 기본 CI/CD 구성 파일(템플릿이라고도 함)이 있습니다.

구성을 사용자화할 때:

• 스캐닝 도구의 CI/CD 템플릿을 포함(include)하십시오. 템플릿 내용을 _복사_하지 마십시오.
• 프로덕션 워크플로우에는 각 템플릿의 안정된 버전을 사용하십시오. 안정 버전은 자주 변경되지 않으며, 중요한 변경 사항은 메이저 GitLab 버전 간에만 이루어집니다. 최신 버전은 가장 최근의 변경 사항이 포함되어 있지만, 마이너 GitLab 버전 간에 중요한 변경 사항이 있을 수 있습니다.
• 템플릿의 다른 값은 필요한 대로만 재정의하십시오. 다른 모든 값은 템플릿에서 상속됩니다.

스캔 실행 강제화

보안 및 규정 준수 팀은 다음과 같이 보안 스캔을:

• 모든 프로젝트에 정기적으로 실행해야 합니다.
• 개발자에 의해 비활성화되지 않아야 합니다.

GitLab은 이를 달성하기 위해 두 가지 방법을 제공합니다. 각각의 장단점이 있습니다.

• 컴플라이언스 프레임워크 파이프라인은 다음 경우에 권장됩니다:

  • SAST IaC, DAST, 종속성 스캐닝, API Fuzzing 또는 Coverage-guided Fuzzing과 같은 GitLab 템플릿을 사용하는 스캐너의 경우 스캔 실행 강제가 필요한 경우.
  • GitLab 외부의 스캐너에 대해서 스캔 실행 강제가 필요한 경우.
  • 사용자 지정 보안 스캔 이외의 사용자 지정 작업에 대해서 스캔 실행 강제가 필요한 경우.

• 스캔 실행 정책은 다음 경우에 권장됩니다:

  • DAST가 DAST 사이트나 스캔 프로필을 사용하는 경우 스캔 실행 강제가 필요한 경우.
  • 프로젝트별 변수 사용자 정의와 함께 SAST, SAST IaC, Secret Detection, 종속성 스캐닝, 또는 컨테이너 스캐닝에 대한 스캔 실행 강제가 필요한 경우. 이를 위해 사용자는 프로젝트당 별도의 보안 정책을 생성해야 합니다.
  • 일정에 따라 스캔을 실행해야 하는 경우.

• 두 솔루션은 다음 경우에 모두 사용할 수 있습니다:

  • 프로젝트별 변수 사용자 정의 없이 컨테이너 스캐닝에 대한 스캔 실행 강제가 필요한 경우.

두 솔루션의 차이에 대한 자세한 내역은 다음과 같습니다:

두 기능의 사용자 경험을 통합하는 것에 대한 저희의 비전에 대한 피드백을 환영합니다.