• 애플리케이션 커버리지
  • 소스 코드 분석
  • 실행 중인 웹 애플리케이션 분석
  • 종속성 분석
  • 인프라 분석
• 데이터 개인 정보 보호
• 취약점 스캐너 유지 관리
• Auto DevOps를 통한 보안 스캔
• Auto DevOps 없이 보안 스캔
  • 기본 레지스트리 기본 주소 재정의
  • 템플릿 버전
  • 병합 요청 파이프라인에서 보안 스캐닝 도구 사용
• 보안 스캐닝
  • 파이프라인의 보안 작업
    • 작업 상태
    • 작업 아티팩트
• 보안 스캔 정보 보기
  • 병합 요청
    • 모든 티어
    • 궁극적인
  • 파이프라인 보안 탭
  • 보안 대시보드
  • 취약점 보고서
  • VS Code용 GitLab Workflow 확장
• 병합 요청의 보안 승인
• 개인 Maven 리포지토리 사용하기
• 사용자 정의 스캔 단계 사용하기
• 셀프 관리형 설치 옵션
• 보안 보고서 검증
• 결과 및 취약점 상호작용
• 보안 스캐닝 구성 팁
  • 스캔 실행 강제화
• 맞춤형 보안 역할

애플리케이션 보안

GitLab은 다음과 같은 보안 취약점을 확인할 수 있습니다:

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

GitLab 애플리케이션 보안에 대한 개요는 Shifting Security Left를 참조하세요.

클릭 가능한 데모는 파이프라인에 보안통합을 참조하세요.

취약점에 대한 통계 및 세부 정보는 병합 요청에 포함됩니다.

변경 사항이 병합되기 전 실행 가능한 정보를 제공하면 사전 예방적으로 대응할 수 있습니다.

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

애플리케이션 커버리지

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

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

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

• 커밋
  • SAST
  • 비밀 감지
  • IaC 스캐닝
  • 종속성 스캐닝
  • 커버리지 기반 퍼즈 테스트
• 빌드
  • 컨테이너 스캐닝
• 테스트
  • API 보안
  • DAST
• 배포
  • 운영 컨테이너 스캐닝

소스 코드 분석

소스 코드 분석은 모든 코드 커밋 시 발생합니다. 발견된 취약점의 세부 정보는 병합 요청에 제공됩니다.

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

• 취약점에 대한 소스 코드 분석 - 정적 애플리케이션 보안 테스트(SAST).
• 비밀에 대한 Git 리포지토리의 기록 분석 - 비밀 감지.

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

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

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

종속성 분석

종속성 분석은 모든 코드 커밋 시 발생합니다. 애플리케이션의 종속성이 수집되어 알려진 취약점의 데이터베이스와 비교됩니다.

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

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

자세한 내용은 종속성 스캐닝과 컨테이너 스캐닝 비교를 참조하세요.

또한, 운영 컨테이너 이미지의 종속성은 정기적인 일정 또는 주기로 취약점을 분석할 수 있습니다.
자세한 내용은 운영 컨테이너 스캐닝을 참조하세요.

인프라 분석

애플리케이션의 인프라는 잠재적 취약점의 원천입니다. 이를 방어하기 위해 인프라 분석은 모든 병합 요청 시 수행됩니다. 다음을 검사합니다:

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

데이터 개인 정보 보호

보안 스캐너 영역에서 데이터 개인 정보 보호와 관련하여, GitLab은 소스 코드를 처리하고 GitLab Runner에서 로컬로 분석을 수행합니다. 데이터는 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.yml 파일에 GitLab CI/CD 템플릿을 추가하세요.

경고:
모든 GitLab 보안 스캐닝 도구의 사용자 정의는 이 변경 사항을 기본 브랜치에 병합하기 전에 병합 요청에서 테스트해야 합니다.
이 절차를 따르지 않으면 예상치 못한 결과를 초래할 수 있으며, 대량의 거짓 긍정이 발생할 수 있습니다.

정적 애플리케이션 보안 테스트, 종속성 스캐닝 및 비밀 탐지를 활성화하려면, 다음을 추가하세요:

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 이미지를 재정의하려면,
오프라인 환경에서 컨테이너 스캐닝 실행하기 의 지침을 참조하세요.

템플릿 버전

대부분의 GitLab 애플리케이션 보안 도구는 두 가지 템플릿 버전을 가지고 있습니다:

• Stable: 안정적인 템플릿은 기본값입니다. 안정적이고 일관된 애플리케이션 보안 경험을 제공합니다. 대부분의 사용자 및 안정성과 예측 가능한 동작을 요구하는 프로젝트에서는 안정적인 템플릿을 사용하는 것이 좋습니다.
• Latest: 최신 템플릿은 최첨단 기능에 접근하고 테스트하려는 사용자에게 해당됩니다. 템플릿 이름에 latest라는 단어가 포함되어 있습니다. 안정적인 것으로 간주되지 않으며, 다음 주요 릴리즈를 위한 계획된 변경 사항이 포함될 수 있습니다. 이 템플릿을 사용하면 새로운 기능 및 업데이트를 안정적인 릴리스 전에 시도할 수 있습니다.

주의:
다양한 보안 템플릿 버전을 혼합하면 병합 요청 및 브랜치 파이프라인이 모두 실행될 수 있습니다.
프로젝트에서는 stabile 또는 latest 템플릿 중 하나만 사용해야 합니다.

병합 요청 파이프라인에서 보안 스캐닝 도구 사용

기본적으로, 애플리케이션 보안 작업은 브랜치 파이프라인에서만 실행되도록 구성되어 있습니다.

병합 요청 파이프라인에서 이를 사용하려면, 그들의 latest edition template를 참조해야 합니다.

예를 들어, SAST와 종속성 스캐닝을 모두 실행하려면 다음 템플릿을 사용합니다:

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

보안 스캐닝

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

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

파이프라인의 보안 작업

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

1. 보안 스캐닝 템플릿 포함

   보안 스캐닝 작업의 선택은 포함된 템플릿에 의해 먼저 결정됩니다.

   템플릿은 AutoDevOps, 스캔 실행 정책 또는 .gitlab-ci.yml 구성 파일을 사용하여 포함될 수 있습니다.

2. 규칙 평가

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

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

   rules:
     - if: $CI_COMMIT_BRANCH
   

3. 분석기 논리

   템플릿의 규칙이 작업 실행을 지정하는 경우, 템플릿에 지정된 파이프라인 단계에서 작업이 생성됩니다. 그러나 각 분석기는 자체 논리를 가지고 있어 분석기가 실행될 것인지 판단합니다.

   예를 들어, 종속성 스캐닝이 기본 깊이에서 지원되는 파일을 감지하지 못하면, 분석기는 실행되지 않으며 아티팩트도 출력되지 않습니다.

작업이 성공적으로 완료된 후, 각 작업은 아티팩트를 출력합니다. 이 아티팩트는 처리되며 결과는 GitLab에서 확인할 수 있습니다. 모든 작업이 완료된 경우에만 결과가 표시되며, 수동 작업도 포함됩니다. 또한, 일부 기능의 경우 결과는 파이프라인이 기본 브랜치에서 실행될 때만 표시됩니다.

작업 상태

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

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

모든 작업은 기본적으로 실패가 허용됩니다. 즉, 실패하더라도 파이프라인이 실패하지 않습니다.

취약점이 병합되는 것을 방지하고자 한다면, 특정 집단의 승인이 없이는 알려지지 않은, 높은 또는 치명적인 발견 사항이 병합되는 것을 방지하는 병합 요청의 보안 승인을 추가해야 합니다.

작업의 allow_failure 설정을 변경하는 것은 추천하지 않으며, 이는 전체 파이프라인을 실패하게 만듭니다.

작업 아티팩트

보안 스캔 작업은 하나 이상의 아티팩트를 생성할 수 있습니다. GitLab 17.0부터 이러한 아티팩트는 developer role로 제한됩니다.

보안 분석기가 생성한 보안 보고서 아티팩트에는 대상 브랜치에서 발견된 모든 발견 사항이 포함되며, 이전에 발견되었는지, 무시되었는지, 완전히 새로운 경우와 관계없이 모든 것(발견한 모든 내용을 포함합니다)이 포함됩니다.

보안 스캔 정보 보기

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

• 병합 요청
• 파이프라인 보안 탭
• 보안 대시보드
• 취약점 보고서
• 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

Free 티어에서는 위의 보고서가 GitLab에 의해 파싱되지 않습니다. 그 결과, 위젯은 보안 스캔 결과에 따라 변경되지 않습니다.

궁극적인

병합 요청에는 새로운 결과의 요약을 표시하는 보안 위젯이 포함되어 있습니다. 새로운 결과는 병합 요청의 발견 사항을 가장 최근 완료된 파이프라인(success, failed, canceled 또는 skipped)의 발견 사항과 비교하여 결정됩니다.

GitLab은 기능 브랜치가 대상 브랜치에서 생성된 커밋에 대해 보안 보고서를 사용하는 파이프라인에서 10개의 마지막 파이프라인을 확인하여 비교 논리를 찾습니다. 기능 브랜치가 생성될 때, 대상 브랜치에서 마지막 10개의 완료된 파이프라인에 대해 보안 스캔이 실행되지 않았다면 비교할 기준이 없습니다. 병합 요청의 발견 사항에서 발견된 취약점은 병합 요청 보안 위젯에서 새로운 것으로 나열됩니다. 기능 브랜치 스캔을 활성화하기 전에 default(대상) 브랜치의 스캔을 실행하는 것이 좋습니다.

MR 보안 위젯은 병합 요청이 승인이 필요한지를 결정할 때 소스와 대상 브랜치의 결과를 비교할 때 모든 지원되는 파이프라인 소스를 고려합니다 ( CI_PIPELINE_SOURCE 변수에 따라서). 파이프라인 소스인 webide와 parent_pipeline은 지원되지 않습니다.

병합 요청 보안 위젯은 생성된 JSON 아티팩트에서 새로운 발견과 기존 발견을 포함하기 때문에 생성된 취약점의 하위 집합만 표시합니다.

병합 요청 보안 위젯에서 확장을 선택하여 위젯을 펼치고 스캔 유형에 따라 새로운 발견 및 더 이상 감지되지 않은(제거된) 발견 사항을 표시하세요.

각 보안 보고서 유형에 대해, 위젯은 심각도에 따라 정렬된 25개의 추가 발견과 25개의 수정된 발견을 표시합니다. 이는 소스 브랜치와 대상 브랜치 파이프라인의 보안 보고서를 비교하여 결정됩니다.

예를 들어, 다음과 같은 스캔 결과가 있는 두 개의 파이프라인을 고려하세요:

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

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

파이프라인 보안 탭

파이프라인의 보안 탭은 파이프라인의 작업 아티팩트에서 보안 보고서의 모든 발견 사항을 나열합니다. 더 많은 정보는 파이프라인의 취약점을 참조하세요.

보안 대시보드

보안 대시보드는 프로젝트의 기본 브랜치에서 취약점을 보여줍니다. 데이터는 24시간마다 업데이트됩니다. 기본 브랜치에 병합된 새로운 취약점을 도입하는 모든 기능 브랜치로 인한 취약점 수 업데이트는 매일 데이터 새로 고침 후에 포함됩니다.

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

취약점 보고서

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

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

취약점 보고서에 대해 더 읽어보세요.

VS Code용 GitLab Workflow 확장

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

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

병합 요청의 보안 승인

• GitLab 15.0에서 Vulnerability-Check 기능이 제거되었습니다.
• GitLab 16.0에서 License-Check 기능이 제거되었습니다.

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

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

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

사용자 정의 스캔 단계 사용하기

자동 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은 린트 오류를 발생시킵니다:

Unable to create pipeline
- dependency_scanning job: chosen stage does not exist; available stages are .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"
  

보안 작업을 재정의하는 것에 대한 더 많은 정보는 다음을 참조하세요:

• SAST 작업 재정의하기.
• Dependency Scanning 작업 재정의하기.
• Container Scanning 작업 재정의하기.
• Secret Detection 작업 재정의하기.
• DAST 작업 재정의하기.

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

셀프 관리형 설치 옵션

셀프 관리형 설치의 경우, 인터넷에 연결되어 있지 않아도 대부분의 GitLab 보안 스캐너를 실행할 수 있습니다 not connected to the internet.

셀프 관리형 설치는 OpenShift 내에서 실행 중인 GitLab Runner에서 보안 스캐너를 실행할 수 있습니다 running inside OpenShift.

보안 보고서 검증

GitLab 15.0은 취약점을 수집하기 전에 보안 보고서 아티팩트의 검증을 강제합니다.

이것은 손상된 취약점 데이터를 데이터베이스에 수집하는 것을 방지합니다. GitLab은 보고서에서 선언된 스키마 버전에 따라 report schemas와 아티팩트를 검증합니다.

파이프라인의 Security 탭은 검증에 실패한 모든 보고서 아티팩트와 검증 오류 메시지를 나열합니다.

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

• 보안 보고서가 지원되는 스키마 버전을 지정하는 경우, GitLab은 이 버전을 사용하여 검증합니다.
• 보안 보고서가 더 이상 지원되지 않는 버전을 사용하는 경우, GitLab은 해당 버전으로 검증을 시도하고 검증 결과에 더 이상 지원되지 않는 경고를 추가합니다.
• 보안 보고서가 지원되는 MAJOR-MINOR 버전을 사용하지만 PATCH 버전이 어떤 공급업체 버전과도 일치하지 않는 경우, GitLab은 스키마의 최신 공급업체 PATCH 버전에 대해 검증을 시도합니다.
  • 예: 보안 보고서가 14.1.1 버전을 사용하지만 최신 공급업체 버전이 14.1.0인 경우, GitLab은 스키마 버전 14.1.0으로 검증합니다.
• 보안 보고서가 지원되지 않는 버전을 사용하는 경우, GitLab은 설치 내에서 가장 이른 스키마 버전으로 검증을 시도하지만 보고서를 수집하지는 않습니다.
• 보안 보고서가 스키마 버전을 명시하지 않는 경우, GitLab은 GitLab에서 사용 가능한 가장 이른 스키마 버전에 대해 검증을 시도합니다. version 속성이 필요하기 때문에 이 경우 검증이 항상 실패하지만 다른 검증 오류가 존재할 수도 있습니다.

항상 지원되거나 더 이상 지원되지 않는 스키마 버전은 source code에서 확인할 수 있습니다.

결과 및 취약점 상호작용

보안 스캐닝 도구의 결과에 대해서 여러 위치에서 상호작용할 수 있습니다:

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

각 위치에서 볼 수 있는 발견 또는 취약점에 대한 자세한 내용은 해당 링크를 선택하세요.

각 페이지는 발견 및 취약점과 상호작용할 수 있는 방법을 상세히 설명합니다. 예를 들어, 대부분의 경우 발견은 detected 상태로 시작됩니다.

당신은 다음과 같은 옵션을 가집니다:

• 상태 변경.
• 이슈 생성.
• 기존 이슈와 연결하기.
• 해결책이 알려진 경우 취약점 해결.

보안 스캐닝 구성 팁

각 GitLab 보안 스캐닝 도구는 기본 CI/CD 구성 파일인 _template_을 가지고 있습니다.

구성을 사용자 정의할 때:

• 스캐닝 도구의 CI/CD 템플릿을 포함하세요. 템플릿의 내용을 _복사_하지 마세요.
• 생산 워크플로를 위해 각 템플릿의 stable 버전을 사용하세요. 안정적인 버전은 덜 자주 변경되며, 주요 GitLab 버전 간에만 중단 변경 사항이 발생합니다. latest 버전은 가장 최근의 변경 사항을 포함하지만, 마이너 GitLab 버전 간에 중요한 변경 사항이 있을 수 있습니다.
• 필요한 경우에만 템플릿의 값을 재정의하세요. 다른 모든 값은 템플릿에서 상속됩니다.

스캔 실행 강제화

보안 및 규정 준수 팀은 보안 스캔이 다음과 같이 수행되도록 해야 합니다:

• 모든 프로젝트에 대해 정기적으로 실행되어야 합니다.
• 개발자가 비활성화할 수 없어야 합니다.

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

• 규정 준수 프레임워크 파이프라인 은 다음과 같은 경우에 권장됩니다:

  • GitLab 템플릿을 사용하는 모든 스캐너에 대해 스캔 실행 강제화가 필요할 때, 예를 들어 SAST IaC, DAST, 종속성 스캐닝, API 퍼징 또는 커버리지 기반 퍼징.
  • GitLab 외부 스캐너에 대해 스캔 실행 강제화가 필요할 때.
  • 보안 스캔 이외의 맞춤 작업에 대해 스캔 실행 강제화가 필요할 때.

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

  • DAST 사이트 또는 스캔 프로파일을 사용하는 DAST에 대해 스캔 실행 강제화가 필요할 때.
  • SAST, SAST IaC, 비밀 탐지, 종속성 스캐닝 또는 프로젝트별 변수가 사용자 정의된 컨테이너 스캐닝에 대해 스캔 실행 강제화가 필요할 때. 이를 위해 사용자들은 각 프로젝트에 대해 별도의 보안 정책을 생성해야 합니다.
  • 스캔이 정기적으로 예약된 속도로 실행되어야 할 때.

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

  • 프로젝트별 변수가 사용자 정의되지 않은 컨테이너 스캐닝의 경우 스캔 실행 강제화가 필요할 때.

두 솔루션의 차이에 대한 추가 세부사항은 아래에 설명되어 있습니다:

이 두 기능의 사용자 경험을 통합하기 위한 우리의 비전에 대한 피드백은 언제든지 환영합니다 여기에서 확인하세요.

맞춤형 보안 역할

응용 프로그램 보안 기능(예: 취약점 관리, 보안 정책 또는 종속성)에 대한 접근이 필요한 보안 팀 구성원을 위한 맞춤형 역할을 생성할 수 있습니다. 이 접근 방식은 조직이 보안 팀 구성원에게 개발자 또는 관리자로 승진시키지 않고도 필요한 권한을 제공함으로써 최소 권한 원칙을 따를 수 있도록 합니다.

예를 들어, 맞춤형 보안 역할은 다음과 같은 권한을 가질 수 있습니다:

• 이름: 맞춤형 보안 역할
• 설명: 취약점을 관리하고 보안 정책 프로젝트를 연결합니다.
• 기본 역할: 리포터(또는 모든 기본 역할)
• 권한: admin_vulnerability, read_dependency, manage_security_policy_link