• 애플리케이션 커버리지
  • 소스 코드 분석
  • 실행 중인 웹 애플리케이션 분석
  • 의존성 분석
  • 인프라스트럭처 분석
• 데이터 프라이버시
• 취약점 스캐너 유지보수
• Auto DevOps로 보안 스캐닝
• Auto DevOps 없이 보안 스캐닝
  • 기본 레지스트리 기본 주소 재정의
  • Merge Request 파이프라인에서 보안 스캔 도구 사용
• 보안 스캔
  • 파이프라인에 있는 보안 작업
  • 보안 작업 상태
  • JSON 아티팩트
• 보안 스캔 정보 보기
  • Merge Request
    • 모든 등급
    • Ultimate
  • 파이프라인 보안 탭
  • 보안 대시보드
  • 취약점 보고서
  • GitLab Workflow VS Code 확장
• Merge Request의 보안 승인
• 개인 Maven 리포지터리 사용
• 사용자 정의 스캔 단계 사용
• 자체 설치 옵션
• 보안 보고서 유효성 검사
• 결과 및 취약점과 상호 작용
• 보안 스캔 구성 팁
  • 스캔 실행 강제

애플리케이션 보안

GitLab는 애플리케이션의 보안 취약점을 확인할 수 있습니다. 여기에는 다음이 포함됩니다.

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

GitLab 애플리케이션 보안에 대한 개요는 보안을 좌로 이동(Shifting Security Left)를 참조하십시오.

클릭하여 데모를 확인하려면 파이프라인에 보안 통합(Integrating security to the pipeline)을 참조하십시오.

변경 사항이 Merge되기 전에 실현 가능한 정보를 제공하는 머지 요청에 약젹습니다.

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

애플리케이션 커버리지

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

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

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

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

소스 코드 분석

소스 코드 분석은 매 코드 커밋에서 발생합니다. 감지된 취약점의 세부 정보는 머지 요청에서 제공됩니다.

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

• 취약점을 위한 소스 코드 분석 - 정적 응용 프로그램 보안 테스팅(SAST)을 참조하십시오.
• 비밀값을 위한 깃 리포지터리의 히스토리 분석 - 시크릿 탐지을 참조하십시오.

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

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

• 알려진 공격 벡터에 대한 애플리케이션 테스트 - 동적 애플리케이션 보안 테스팅(DAST)을 참조하십시오.
• 알려진 공격 벡터에 대한 API 분석 - API 보안을 참조하십시오.
• 알려지지 않은 버그 및 취약점에 대한 웹 API 분석 - API 퍼징을 참조하십시오.

의존성 분석

코드 커밋마다 의존성 분석이 수행됩니다. 애플리케이션의 의존성은 알려진 취약점 데이터베이스와 대조됩니다.

의존성 분석은 다음에서 실행될 수 있습니다.

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

자세한 내용은 의존성 스캔과 컨테이너 스캔 비교를 참조하십시오.

또한, 운영 컨테이너 이미지의 의존성은 일정 또는 주기적으로 취약점을 분석할 수 있습니다. 자세한 내용은 운영 컨테이너 스캔을 참조하십시오.

인프라스트럭처 분석

애플리케이션의 인프라스트럭처는 잠재적인 취약점의 원천입니다. 이를 대비하기 위해 인프라스트럭처 분석이 모든 머지 요청에서 실행됩니다. 배포 환경을 정의하는 인프라스트럭처 코드(IaC) 구성 파일에 대해 확인이 실행됩니다.

• 응용 프로그램의 배포 환경을 정의하는 인프라스트럭처 코드(IaC) 구성 파일 - 인프라스트럭처 코드(IaC) 스캔을 참조하십시오.

데이터 프라이버시

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

저희 스캐너는 최신 시그니처, 규칙 및 패치를 다운로드하기 위해서만 인터넷에 액세스합니다. 스캐너가 인터넷에 액세스하지 않길 원한다면 오프라인 환경을 사용하는 것을 고려해보세요.

취약점 스캐너 유지보수

다음 취약점 스캐너 및 해당 데이터베이스는 정기적으로 업데이트됩니다.

동일한 주요 분석기 버전을 사용하는 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 파일에 추가하세요.

정적 응용 프로그램 보안 테스트, 의존성 스캐닝 및 시크릿 감지를 활성화하려면 다음을 추가하세요:

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 보안 스캐너는 도커 이미지의 기본 주소로 registry.gitlab.com/security-products를 사용합니다. 대부분의 스캐너에서 SECURE_ANALYZERS_PREFIX CI/CD 변수를 다른 위치로 설정하여 이를 재정의할 수 있습니다. 이는 한 번에 모든 스캐너에 영향을 미칩니다.

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

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

기본적으로 응용 프로그램 보안 작업은 브랜치 파이프라인에서만 실행되도록 구성됩니다. Merge Request 파이프라인에서 사용하려면 latest 템플릿을 참조해야 합니다.

최신 버전의 템플릿에는 파괴적인 변경 내용이 포함될 수 있습니다. 최신 템플릿에서만 제공되는 기능이 필요한 경우를 제외하고는 안정적인 템플릿을 사용하세요.

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

예를 들어 SAST와 의존성 스캔을 모두 실행하려면 다음 템플릿을 사용합니다:

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에서 결과를 사용할 수 있습니다. 결과는 매뉴얼 작업을 포함하여 모든 작업이 완료되어야만 표시됩니다. 또한 일부 기능에 대해서는 결과가 기본 브랜치에서 파이프라인을 실행할 때에만 표시됩니다.

보안 작업 상태

작업은 스캔을 완료할 수 있는 경우 통과합니다. 통과 결과는 해당 작업이 결과를 식별했는지 여부를 나타내지 않습니다. 유일한 예외는 커버리지 퍼징(Coverage Fuzzing)으로, 해당 작업은 결과를 식별하는 경우에 실패합니다.

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

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

Merge되는 취약점을 방지하려면 Merge Request의 보안 승인을 추가하여 특정 사용자 그룹의 승인 없이 알 수 없는, 높은 또는 중요한 결과가 Merge되지 않도록 해야 합니다.

작업의 allow_failure 설정을 변경하는 것은 전체적으로 파이프라인을 실패하게 만드는 것을 권장하지 않습니다.

JSON 아티팩트

보안 분석기가 생성하는 아티팩트에는 대상 브랜치에서 발견한 모든 결과가 포함됩니다. 그 결과가 이전에 발견되었던 것, 해제되었던 것 또는 완전히 새로운 것이든 관계없이 모든 것을 담습니다.

보안 스캔 정보 보기

보안 스캔 정보는 여러 위치와 형식에서 표시됩니다:

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

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

Free 등급에서는 위의 보고서가 GitLab에서 파싱되지 않습니다. 결과에 따라 위젯이 변경되지 않습니다.

Ultimate

Merge Request에는 새로운 결과를 요약하는 보안 위젯이 포함되어 있습니다. 새로운 결과는 Merge Request의 결과와 기본 브랜치에 대한 가장 최근 완료된 파이프라인(success, failed, canceled 또는 skipped)과 비교하여 결정됩니다. 특징 브랜치가 대상 브랜치에서 생성된 커밋에 대한 10개의 파이프라인을 확인합니다.

특징 브랜치가 대상 브랜치에서 생성된 커밋에 대한 마지막 10개의 완료된 파이프라인에서 보안 스캔이 실행되지 않은 경우 비교를 위한 기본이 없습니다. Merge Request의 취약점은 새로운 것으로 표시됩니다. 개발자의 특징 브랜치 스캔을 활성화하기 전에 기본 브랜치의 스캔을 실행하는 것이 좋습니다.

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

Merge Request 보안 위젯은 생성된 JSON 아티팩트에 있는 일부 취약점만 표시합니다. 이는 새로운 및 기존의 발견 사항을 모두 포함합니다.

Merge Request 보안 위젯에서 확장을 선택하여 위젯을 펼쳐 새로운 및 더 이상 감지되지 않는(제거된) 발견 사항을 표시하세요.

각 보안 보고서 유형에 대해 위젯은 소스 브랜치 및 대상 브랜치 파이프라인에서 발견된 첫 25개의 추가 및 수정된 발견 사항을 중요도에 따라 정렬하여 표시합니다.

이를 예로 들어, 다음과 같은 스캔 결과를 가진 두 개의 파이프라인이 있는 경우를 생각해봅시다:

• 소스 브랜치 파이프라인은 V1 및 V2로 식별된 두 가지 취약점을 감지합니다.
• 대상 브랜치 파이프라인은 V1와 V3로 식별된 두 가지 취약점을 감지합니다.
• V2는 Merge Request 위젯에서 “추가됨”으로 표시됩니다.
• V3은 Merge Request 위젯에서 “수정됨”으로 표시됩니다.
• V1은 양쪽 브랜치에 모두 존재하며 Merge Request 위젯에 표시되지 않습니다.

소스 브랜치의 모든 발견 사항을 보려면 전체 보고서 보기를 선택하여 가장 최근 소스 브랜치 파이프라인의 보안 탭으로 직접 이동합니다.

파이프라인 보안 탭

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

보안 대시보드

보안 대시보드는 프로젝트의 기본 브랜치에서의 취약점을 표시합니다. 데이터는 24시간마다 업데이트됩니다. 기본에 Merge된 새로운 취약점을 포함한 새로운 취약성이 적용됩니다.

더 많은 세부 정보는 보안 대시보드를 참조하십시오.

취약점 보고서

취약점 보고서는 기본 브랜치에서 마지막으로 완료된 파이프라인의 결과를 보여줍니다. 이 보고서는 모든 탐지된 취약점을 표시하며, 최신 검사 중에 더 이상 탐지되지 않은 이전 취약점도 표시됩니다. 더 이상 탐지되지 않는 취약성은 복구되거나 제거되었을 수 있으며 올바른 확인 후에 “해결됨”으로 표시할 수 있습니다. 이제 더 이상 탐지되지 않는 취약점은 필터링 및 검토를 위한 아이콘으로 나타냅니다.

기본적으로 취약점 보고서에는 ‘해결됨’ 또는 ‘해결됨’ 상태의 취약성은 표시되지 않으므로 열린 취약성에 중점을 두실 수 있습니다. 상태 필터를 변경하여 이를 볼 수 있습니다.

취약점 보고서에 대한 자세한 내용을 읽어보세요.

GitLab Workflow VS Code 확장

GitLab Workflow VS Code 확장을 사용하면 비주얼 스튜디오 코드(VS Code)에서 직접 보안 결과를 볼 수 있습니다. 이는 Merge Request과 마찬가지로 동작합니다.

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

Merge Request의 보안 승인

• 제거됨 GitLab 15.0에서 보안 취약성 확인 기능이 제거되었습니다.
• 제거됨 GitLab 16.0에서 라이선스 확인 기능이 제거되었습니다.

다음 보안 문제를 포함하는 Merge Request에 대해 추가 승인을 강제할 수 있습니다:

• 보안 취약성. 자세한 내용은 Merge Request 승인 정책을 읽어보세요.

개인 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>

사용자 정의 스캔 단계 사용

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

예를 들어, 다음은 unit-tests 단계를 사용하려고 시도하는 경우입니다: ```yaml 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은 다음과 같은 린트 오류를 발생시킵니다: plaintext 파이프라인을 생성할 수 없음 - dependency_scanning 작업: 선택한 스테이지가 존재하지 않음; 사용 가능한 스테이지는 .pre, unit-tests, .post입니다

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

• .gitlab-ci.yml에서 test 단계를 추가합니다: ```yaml 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 단계를 사용하려면: ```yaml 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 러너에서 실행할 수도 있습니다.

보안 보고서 유효성 검사

GitLab 15.0은 취약성 보고서 아티팩트의 유효성을 강제로 실행하여 데이터베이스에 손상된 취약성 데이터가 들어가는 것을 방지합니다. GitLab은 보고서의 스키마 버전에 따라 아티팩트를 유효성 검사하며 유효성 검사 오류 메시지를 표시합니다.

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

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

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

결과 및 취약점과 상호 작용

여러 위치에서 보안 스캔 도구의 결과와 취약성을 상호 작용할 수 있습니다.

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

해당 위치에서 볼 수 있는 발견물 또는 취약점에 대한 자세한 내용은 각 링크를 선택하세요. 각 페이지는 발견물과 취약점과 상호 작용할 수 있는 방법에 대한 세부 정보를 제공합니다. 예를 들어, 대부분의 경우 발견물은 검출됨 상태로 시작합니다.

변경할 수 있는 옵션은 다음과 같습니다.

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

보안 스캔 구성 팁

각 GitLab 보안 스캔 도구에는 기본 CI/CD 구성 파일(별칭 템플릿)이 있습니다.

구성을 사용자 정의할 때:

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

스캔 실행 강제

보안 및 컴플라이언스 팀은 보안 스캔이 다음을 보장해야 합니다:

• 모든 프로젝트에서 정기적으로 실행됨.
• 개발자에 의해 비활성화되지 않음.

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

• 컴플라이언스 프레임워크 파이프라인
  • GitLab 템플릿을 사용하는 스캐너(예: SAST IaC, DAST, 의존성 스캔, API Fuzzing 또는 Coverage-guided Fuzzing)의 경우 스캔 실행 강제가 필요한 경우 권장됩니다.
  • GitLab 외부의 스캐너의 경우 스캔 실행 강제가 필요한 경우 권장됩니다.
  • 성격 보안 스캔 이외의 사용자 정의 작업의 경우 스캔 실행 강제가 필요한 경우 권장됩니다.
• 스캔 실행 정책
  • DAST에서 DAST 사이트 또는 스캔 프로필을 사용하는 경우 스캔 실행 강제가 필요한 경우 권장됩니다.
  • SAST, SAST IaC, 시크릿 검출, 의존성 스캔 또는 프로젝트별 변수 사용을 위해 컨테이너 스캔스를 사용하는 경우 별도의 보안 정책을 생성해야 합니다. 이를 실현하기 위해 사용자는 프로젝트 당 별도의 보안 정책을 생성해야 합니다.
  • 정기적으로 실행되어야 하는 스캔이 필요한 경우 권장됩니다.
• 두 해결책은 다음 경우에 모두 잘 사용할 수 있습니다:
  • 프로젝트별 변수 사용이 없는 컨테이너 스캔을 위해 스캔 실행 강제가 필요한 경우.

두 솔루션 간의 차이에 대한 자세한 정보는 아래에 나와 있습니다: