• 애플리케이션 범위
  • 소스 코드 분석
  • 실행 중인 웹 애플리케이션 분석
  • 의존성 분석
  • 인프라 분석
• 데이터 프라이버시
• 취약점 스캐너 유지 관리
• Auto DevOps를 사용한 보안 스캔
• Auto DevOps를 사용하지 않은 보안 스캔
  • 기본 레지스트리 기본 주소 덮어쓰기
  • Merge Request 파이프라인에서 보안 스캔 도구 사용
• 보안 스캔
  • 파이프라인에서 실행되는 보안 작업
• 보안 스캔 정보보기
  • Merge Request
    • 모든 티어
    • Ultimate
  • 파이프라인 보안 탭
  • 보안 대시보드
  • 취약점 보고서
  • GitLab Workflow VS Code 확장자
• Merge Request의 보안 승인
• 사설 Maven 리포지터리 사용
• 사용자 정의 스캔 단계 사용
• 자체 설치 옵션
• 보안 보고서 유효성 검사
• 발견 및 취약점과 상호 작용
• 보안 스캔 구성 팁
  • 스캔 실행 강제

Application security

GitLab은 애플리케이션의 보안 취약점을 확인할 수 있습니다. 이는 다음을 포함합니다:

• 무단 접근
• 데이터 누출
• 서비스 거부(DoS) 공격

GitLab 애플리케이션 보안에 대한 개요는 보안을 좌초를 참조하세요.

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

Merge Request에 포함된 취약점의 통계 및 세부 정보가 포함됩니다. 변경 사항이 Merge되기 전에 사용 가능한 정보를 제공함으로써 예방적으로 대응할 수 있습니다.

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

애플리케이션 범위

GitLab은 CI/CD 파이프라인 또는 일정에 따라 애플리케이션의 다양한 세부 정보를 분석합니다. 이는 다음을 포함합니다:

• 소스 코드
• 프로젝트 또는 컨테이너 이미지의 의존성
• 실행 중인 웹 애플리케이션의 취약점
• 코드 구성의 인프라

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

• 커밋
  • SAST
  • 시크릿 탐지
  • IaC 스캔
  • 의존성 스캔
  • 커버리지 기반 퍼즈 테스팅
• 빌드
  • 컨테이너 스캔
• 테스트
  • API 보안
  • DAST
• 배포
  • 운영 컨테이너 스캔

소스 코드 분석

소스 코드 분석은 모든 코드 커밋에서 발생합니다. 감지된 취약점의 세부 정보가 Merge Request에 제공됩니다.

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

• 취약점을 위한 소스 코드 분석 - 정적 애플리케이션 보안 테스트(SAST).
• 비밀 정보를 위한 깃 리포지터리의 이력 분석 - 시크릿 탐지.

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

웹 애플리케이션의 분석은 모든 코드 커밋에서 발생합니다. CI/CD 파이프라인의 일부로 애플리케이션이 빌드되고 테스트 환경에 배포되며 다음과 같은 테스트가 수행됩니다:

• 알려진 공격 벡터를 위한 애플리케이션 테스트 - 동적 애플리케이션 보안 테스트(DAST).
• 알려진 공격 벡터를 위한 API 분석 - API 보안.
• 알려진 버그 및 취약점을 위한 웹 API 분석 - API 퍼징.

의존성 분석

의존성 분석은 모든 코드 커밋에서 발생합니다. 애플리케이션의 의존성이 모아지고 알려진 취약점 데이터베이스와 비교됩니다.

의존성 분석은 다음을 실행할 수 있습니다:

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

자세한 내용은 의존성 스캔 대 컨테이너 스캔을 참조하세요.

또한, 운영 중인 컨테이너 이미지의 의존성도 정기적인 일정에 따라 취약점을 분석할 수 있습니다. 자세한 내용은 운영중인 컨테이너 스캔을 참조하세요.

인프라 분석

애플리케이션의 인프라도 잠재적인 취약점의 원천입니다. 이를 대비하기 위해, 인프라 분석은 모든 Merge Request에서 수행됩니다. 다음에 대해 확인이 이루어집니다:

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

데이터 프라이버시

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

저희 스캐너들은 최신의 서명, 규칙 및 패치를 다운로드하기 위해서만 인터넷에 액세스합니다. 스캐너가 인터넷에 액세스하지 않길 원하신다면 오프라인 환경을 고려해 보시기 바랍니다.

취약점 스캐너 유지 관리

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

같은 주요 버전의 분석기를 사용하는 GitLab의 버전에서는 최신 취약점 정의를 적용하기 위해 분석기를 업데이트할 필요가 없습니다. 보안 도구는 도커 이미지로 출시됩니다. 이들을 가능케 하는 벤더 정의 작업 정의는 의미론적 버전에 따라 주요릴리스 태그를 사용합니다. 도구의 새로운 릴리스가 이러한 태그를 무효화합니다. 분석기 버전에서 최신 스캐닝 도구의 최신 버전을 자동으로 받을 수 있지만, 이 접근 방식에는 알려진 문제가 있습니다.

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 파일에 추가하세요.

정적 응용 프로그램 보안 테스트, 의존성 검사 및 비밀 감지를 활성화하려면 다음을 추가하세요:

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를 설정하세요.

Container Scanning 분석기는 예외이며 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

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

보안 스캔

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

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

파이프라인에서 실행되는 보안 작업

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

1. 보안 스캔 템플릿 포함

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

2. 규칙 평가

   각 템플릿에는 분석기가 실행되는지를 결정하는 정의된 규칙이 있습니다.

   예를 들어, Secret Detection 템플릿에는 다음 규칙이 포함됩니다. 이 규칙은 비밀 감지가 브랜치 파이프라인에서 실행되어야 한다고 명시합니다. Merge Request 파이프라인의 경우, 비밀 감지가 실행되지 않습니다.

   rules:
     - if: $CI_COMMIT_BRANCH
   

3. 분석기 로직

   템플릿의 규칙이 작업을 실행해야 한다고 명시하면, 해당 템플릿에 명시된 파이프라인 단계에 작업이 생성됩니다. 그러나 각 분석기에는 해당 분석기 자체가 실행되어야 하는지를 결정하는 자체 로직이 있습니다.

   예를 들어, 의존성 검사가 기본 깊이에서 지원되는 파일을 감지하지 못하면 분석기가 실행되지 않으며, 결과물도 생성되지 않습니다.

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

보안 스캔 정보보기

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

• Merge Request
• 파이프라인 보안 탭
• 보안 대시보드
• 취약점 보고서
• GitLab Workflow 확장자 for VS Code

Merge Request

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

모든 티어

보안 스캔을 실행한 Merge Request은 생성된 보고서를 다운로드할 수 있는 옵션을 제공합니다. 보고서를 다운로드하려면 결과 다운로드를 선택하고 원하는 보고서를 선택하세요.

보안 스캔은 적어도 다음 중 하나의 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에서 구문 분석되지 않습니다. 따라서 위젯은 보안 스캔 결과에 따라 변하지 않습니다.

Ultimate

Merge Request에는 새로운 결과를 요약하는 보안 위젯이 포함되어 있습니다. 새로운 결과는 특징 브랜치가 대상 브랜치에서 만들어질 때의 커밋에 대한 가장 최근 완료된 파이프라인 (성공, 실패, 취소 또는 건너뜀)의 결과와 Merge Request의 발견을 비교하여 결정됩니다.

GitLab은 특징 브랜치가 대상 브랜치로부터 만들어진 커밋에 대한 마지막 10개의 파이프라인을 확인하여 비교 논리에 사용할 보안 보고서가 있는지 확인합니다. 특징 브랜치가 만들어진 대상 브랜치의 마지막 10개의 완료된 파이프라인에 대해 보안 스캔이 실행되지 않았다면 비교 대상이 없습니다. Merge Request 발견의 취약점은 Merge Request 보안 위젯에서 new로 나열됩니다. 개발자가 특징 브랜치 스캔을 활성화하기 전에 default (대상) 브랜치의 스캔을 실행하는 것을 권장합니다.

Merge Request 보안 위젯은 Merge Request이 승인을 요구하는지 여부를 결정할 때 소스 브랜치와 대상 브랜치의 결과를 비교하여 CI_PIPELINE_SOURCE 변수를 기반으로 모든 지원되는 파이프라인 출처를 고려합니다. webide 및 parent_pipeline 파이프라인 출처는 지원되지 않습니다.

Merge Request 보안 위젯은 생성된 JSON artifact에 있는 취약점의 하위 집합만 표시합니다. 이것은 새로운 및 기존 발견을 모두 포함하기 때문입니다.

Merge Request 보안 위젯에서는 확장을 선택하여 위젯을 펼쳐서 새로운 및 더 이상 감지되지 않는 (제거된) 발견들을 스캔 유형별로 표시할 수 있습니다.

각 보안 보고서 유형에 대해 위젯은 심각도별로 정렬된 처음 25개의 추가 및 수정된 발견을 표시합니다.

예를 들어, 다음과 같은 스캔 결과가 포함된 두 개의 파이프라인을 고려해보세요:

• 소스 브랜치 파이프라인에서 V1 및 V2로 식별된 두 개의 취약점이 감지됨.
• 대상 브랜치 파이프라인에서 V1 및 V3로 식별된 두 개의 취약점이 감지됨.
• V2는 Merge Request 위젯에 “added”로 표시됩니다.
• V3은 Merge Request 위젯에 “fixed”로 표시됩니다.
• V1은 두 브랜치 모두에 존재하며 Merge Request 위젯에 표시되지 않습니다.

Merge Request의 소스 브랜치에서 모든 발견을 보려면 전체 보고서 보기를 선택하여 최신 소스 브랜치 파이프라인의 보안 탭으로 직접 이동할 수 있습니다.

파이프라인 보안 탭

파이프라인의 보안 탭에는 파이프라인의 작업 artifact에서 보안 보고서에서 모든 발견을 나열합니다. 자세한 내용은 파이프라인의 취약점을 참조하세요.

보안 대시보드

보안 대시보드에서는 프로젝트의 기본 브랜치에 있는 취약점이 표시됩니다. 데이터는 매 24시간마다 업데이트되며, 새로운 취약점을 도입하는 모든 특징 브랜치가 기본 브랜치로 Merge될 때 일일 데이터 업데이트 후에 포함됩니다.

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

취약점 보고서

취약점 보고서에는 기본 브랜치의 마지막 완료된 파이프라인의 결과가 표시됩니다. 파이프라인 완료시마다 업데이트됩니다. 감지된 모든 취약점이 표시되며, 최신 스캔에서 더 이상 감지되지 않는 이전 취약점이 포함됩니다. 더 이상 감지되지 않는 취약점은 적절한 확인 후 해결됨으로 표시될 수 있습니다. 더 이상 감지되지 않는 취약점은 필터링 및 검토를 위한 아이콘으로 표시됩니다.

기본 설정으로 취약점 보고서에는 기각됨 또는 해결됨 상태의 취약점이 표시되지 않아서 오픈된 취약점에 집중할 수 있습니다. 상태 필터를 변경하여 이를 볼 수 있습니다.

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

GitLab Workflow VS Code 확장자

이제 GitLab Workflow VS Code 확장을 사용하여 비주얼 스튜디오 코드 (VS Code)에서 보안 발견을 직접 볼 수 있습니다. 이는 Merge Request에서 볼 수 있는 것과 동일합니다.

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

Merge Request의 보안 승인

• GitLab 12.2에서 소개됨.
• GitLab 15.0에서 취소됨 Vulnerability-Check 기능.
• GitLab 16.0에서 취소됨 License-Check 기능.

다음 보안 문제를 도입할 수 있는 Merge Request에 대한 추가 승인을 강제로 요구할 수 있습니다.

• 보안 취약점에 대한 자세한 내용은 Merge Request 승인 정책을 참조하세요.

사설 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 단계를 사용합니다. test 단계를 포함하지 않고 .gitlab-ci.yml 파일에서 사용자 정의 단계를 지정하면 오류가 발생합니다.

예를 들어, 다음은 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

사용자 지정 작업:
  stage: unit-tests
  script:
    - echo "사용자 정의 작업"

위의 .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
    
  사용자 지정 작업:
    stage: unit-tests
    script:
      - echo "사용자 정의 작업"
  

• 각 보안 작업의 기본 단계를 무시합니다. 예를 들어, 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
    
  사용자 지정 작업:
    stage: unit-tests
    script:
      - echo "사용자 정의 작업"
  

보안 작업 무시에 대한 자세한 내용은 다음을 참조하십시오.

• SAST 작업 무시
• Dependency Scanning 작업 무시
• 컨테이너 스캔 작업 무시
• 시크릿 검색 작업 무시
• DAST 작업 무시

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

자체 설치 옵션

자체 설치에서는 인터넷에 연결되지 않은 상태에서도 대부분의 GitLab 보안 스캐너를 실행할 수 있습니다.

자체 설치에서는 GitLab Runner를 사용하여 GitLab Runner 내에서도 보안 스캐너를 실행할 수 있습니다. (../../install/openshift_and_gitlab/index.md).

보안 보고서 유효성 검사

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

GitLab 15.0에서 취약점을 가져 오기 전에 보안 보고서 artifact의 유효성을 강제로 검사합니다. 이렇게 함으로써 깨진 취약점 데이터가 데이터베이스에 가져와지는 것을 방지합니다. GitLab은 보고서에서 선언된 스키마 버전에 따라 artifact를 검사합니다.

파이프라인의 보안 탭은 유효성 검사에 실패한 보고서 artifact를 나열하고, 유효성 검사 오류 메시지를 표시합니다.

유효성 검사는 보고서 artifact에서 선언된 스키마 버전에 따라 달라집니다:

• 보안 보고서에서 지원되는 스키마 버전을 지정한 경우, GitLab은 이 버전을 사용하여 유효성을 검사합니다.
• 보고서에서 폐기된 버전을 사용하는 경우, GitLab은 해당 버전을 사용하여 유효성을 검사하고 유효성 검사 결과에 폐기 경고를 추가합니다.
• 보고서에서 지원되는 주요-마이너 버전의 보고서 스키마를 사용하지만 패치 버전이 어떤 판매 앱 버전과 일치하지 않는 경우, GitLab은 최신 판매 앱 패치 버전에 대해 유효성을 검사합니다.
  • 예: 보고서는 버전 14.1.1을 사용하지만 최신 판매 앱 버전은 14.1.0입니다. GitLab은 스키마 버전 14.1.0에 대해 유효성을 검사합니다.
• 보고서에서 지원되지 않는 버전을 사용하는 경우, GitLab은 설치 가능한 최신 스키마 버전으로 유효성을 검사하고 보고서를 가져오지 않습니다.
• 보고서에서 스키마 버전을 지정하지 않은 경우, GitLab은 GitLab에서 사용 가능한 최신 스키마 버전에 대해 유효성을 검사합니다. 버전 속성이 필요하기 때문에 이 경우 항상 유효성이 실패하지만 다른 유효성 오류도 발생할 수 있습니다.

항상 지원되는 버전 및 폐기된 스키마 버전을 소스 코드에서 찾을 수 있습니다.

발견 및 취약점과 상호 작용

보안 스캐닝 도구의 결과물과 취약점과의 상호 작용은 다음 위치에서 가능합니다.

• Merge Request의 스캔 정보
• 프로젝트 보안 대시보드
• 보안 파이프라인 탭
• 그룹 보안 대시보드
• 보안 센터
• 취약점 보고서
• 취약점 페이지
• 의존성 디렉터리

각 위치에서 볼 수 있는 발견물이나 취약점에 대한 자세한 내용은 해당 링크를 선택하십시오. 각 페이지에는 발견물과 취약점과의 상호 작용 방법이 상세히 설명되어 있습니다. 대부분의 경우, 발견물은 처음에 검색됨 상태로 시작됩니다.

여러분은 다음을 선택할 수 있습니다:

• 상태 변경.
• 이슈 생성.
• 기존 이슈에 연결.
• 취약점을 해결합니다. 해결책이 알려진 경우.

보안 스캔 구성 팁

각 GitLab 보안 스캔 도구에는 기본적으로 CI/CD 구성 파일이 있으며, 이를 _템플릿_이라고 합니다.

구성을 사용자 정의할 때:

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

스캔 실행 강제

보안 및 준수 팀은 보안 스캔이 다음을 보장해야 합니다:

• 모든 프로젝트에 대해 정기적으로 실행됨.
• 개발자에 의해 비활성화될 수 없음.

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

• 준수 프레임워크 파이프라인
  • SAST IaC, DAST, 의존성 스캔, API Fuzzing 또는 Coverage-guided Fuzzing과 같은 GitLab 템플릿을 사용하는 스캐너에 대한 스캔 실행 강제가 필요한 경우 권장됩니다.
  • GitLab 외부의 스캐너에 대한 스캔 실행 강제가 필요한 경우 권장됩니다.
  • 보안 스캔 이외에 사용자 정의 작업에 대한 스캔 실행 강제가 필요한 경우 권장됩니다.
• 스캔 실행 정책
  • DAST가 DAST 사이트 또는 스캔 프로필을 사용하는 경우에 스캔 실행 강제가 필요한 경우 권장됩니다.
  • 프로젝트별 변수 사용자 지정을 통해 SAST, SAST IaC, Secret Detection, 의존성 스캔 또는 컨테이너 스캔에 대한 스캔 실행 강제가 필요한 경우 사용자는 프로젝트마다 별도의 보안 정책을 만들어야 합니다. 이를 위해 동일한 보안 정책마다 스캔 프로파일을 참조할 때 이 프로파일은 변경할 수 없습니다. 모든 작업은 일반적으로 CI 작업에서 사용할 수 있는 동일한 변수를 사용하여 보안 정책 자체의 일부로 사용자 지정할 수 있습니다.
  • 정기적으로 예정된 주기로 스캔을 실행해야 하는 경우.
• 두 가지 솔루션은 다음과 같은 경우에 모두 효과적으로 사용할 수 있습니다:
  • 프로젝트별 변수 사용자 지정이 없는 컨테이너 스캔에 대한 스캔 실행 강제가 필요한 경우.

두 솔루션 간의 차이점에 대한 추가 세부 정보는 아래에 개요가 되어 있습니다:

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