애플리케이션 범위
데이터 개인 정보
취약점 스캐너 유지 관리
Auto DevOps를 사용한 보안 스캐닝
Auto DevOps 없이 보안 스캐닝
보안 스캐닝
- 파이프라인의 보안 작업
  - 작업 상태
  - 작업 아티팩트
보안 스캔 정보 보기
병합 요청에서의 보안 승인
개인 Maven 저장소 사용
사용자 정의 스캔 단계 사용
자체 설치 옵션
보안 보고서 유효성 검사
결과 및 취약성 상호 작용
보안 스캔 구성 팁
- 스캔 실행 강제
사용자 정의 보안 역할

애플리케이션 보안

Tier: Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

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

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

GitLab 애플리케이션 보안에 대한 개요는 보안을 좌측으로 이동하기를 참조하십시오.

클릭으로하는 데모를 보려면 파이프라인에 보안 통합을 참조하십시오.

병합 요청에 취약점에 대한 통계 및 상세 정보가 포함되어 있습니다. 변경 사항이 병합되기 전에 실행 가능한 정보를 제공하여 예방적으로 대응할 수 있습니다.

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

애플리케이션 범위

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

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

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

커밋
- SAST
- 비밀 검출
- IaC 스캔
- 종속성 스캔
- 커버리지가 제어되는 퍼즈 테스트
빌드
- 컨테이너 스캔
테스트
- API 보안
- DAST
배포
- 운영용 컨테이너 스캔

소스 코드 분석

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

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

취약점을 분석하기 - 정적 애플리케이션 보안 테스트 (SAST).
Git 저장소의 기록에서 비밀 정보를 분석 - 비밀 검출.

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

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

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

종속성 분석

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

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

빌드 시간 - 종속성 스캔.
컨테이너 이미지를 사용하는 프로젝트의 경우, 최종 컨테이너 이미지 빌드 후에도 분석을 실행합니다 - 컨테이너 스캔.

자세한 내용은 종속성 스캔 대 컨테이너 스캔 비교을 참조하십시오.

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

인프라스트럭처 분석

애플리케이션의 인프라스트럭처는 잠재적인 취약점의 원천입니다. 이를 방어하기 위해 병합 요청마다 인프라스트럭처 분석이 수행됩니다. 다음을 실행합니다.

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

데이터 개인 정보

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

우리의 스캐너는 최신 집합의 서명, 규칙 및 패치를 다운로드하기 위해서만 인터넷에 접근합니다. 스캐너가 인터넷에 접근하지 않기를 원한다면 오프라인 환경을 사용하는 것을 고려하십시오.

취약점 스캐너 유지 관리

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

보안 스캐닝 도구	취약점 데이터베이스 업데이트
컨테이너 스캔	매일 새로운 이미지를 빌드하여 상위 스캐너의 최신 취약점 데이터베이스 업데이트를 실행합니다. 데이터베이스가 48시간 이상 오래된 경우 기술 부서에 경고를 보내는 내부 경고가 존재합니다. 자세한 내용은 취약점 데이터베이스 업데이트를 확인하십시오.
의존성 스캔	GitLab 기관 데이터베이스를 기반으로합니다. 매일 NVD, `ruby-advisory-db` 및 GitHub 기관 데이터베이스의 데이터를 사용하여 업데이트됩니다. 자세한 내용은 data from NVD, the `ruby-advisory-db` and the GitHub Advisory Database as data sources를 확인하십시오.
동적 애플리케이션 보안 테스트 (DAST)	수시로 DAST proxy-based 및 browser-based 엔진이 업데이트됩니다. DAST proxy-based 분석기는 스캔 실행 시 스캔 규칙을 다운로드합니다. 기반이 되는 도구 `zaproxy`의 버전을 확인하십시오. DAST browser-based 규칙은 다양한 취약점 확인을 실행합니다.
비밀 검출	GitLab은 감지 규칙을 유지하고 커뮤니티 기여를 받습니다. 중요한 업데이트가 있는 경우 적어도 매월 한 번 스캔 엔진이 업데이트됩니다.
정적 애플리케이션 보안 테스트 (SAST)	스캔 규칙의 소스는 각 지원되는 프로그래밍 언어에 사용되는 분석기에 따라 다릅니다. GitLab은 Semgrep 기반 분석기에 대한 규칙 집합을 유지 관리하고 내부 연구와 사용자 피드백에 기반하여 정기적으로 업데이트합니다. 다른 분석기의 경우, 규칙 집합은 상위 오픈 소스 스캐너에서 가져옵니다. 각 분석기는 중요한 업데이트가 있는 경우 적어도 한 달에 한 번씩 업데이트됩니다.

같은 주요 버전의 분석기를 사용하는 GitLab 버전에서는 최신 취약점 정의의 이점을 얻으려면 분석기를 업데이트할 필요가 없습니다. 보안 도구는 Docker 이미지로 릴리스되며 시맨틱 버전에 따라 주요 릴리스 태그를 사용하도록 조정됩니다. 도구의 각 새 릴리스가 이러한 태그를 덮어씁니다. 주요 분석기 버전에서 최신 버전의 스캐닝 도구를 자동으로 얻지만, 이러한 방식에는 알려진 문제가 있습니다.

참고: 기존 취약점에 대한 가장 최신 정보를 얻기 위해서는 기본 브랜치의 파이프라인을 다시 실행해야 할 수도 있습니다.

Auto DevOps를 사용한 보안 스캐닝

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

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

Auto DevOps 없이 보안 스캐닝

사용자 정의 설정을 선택할 수 있는 모든 GitLab 보안 스캐닝 도구를 활성화하려면 GitLab CI/CD 템플릿을 .gitlab-ci.yml 파일에 추가하세요.

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

정적 응용프로그램 보안 테스트(SAST), 종속성 스캐닝 및 시크릿 검색을 활성화하려면 다음과 같이 추가하세요:

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를 사용합니다. 대부분의 스캐너에 대해 이를 다른 위치로 덮어씌워 SECURE_ANALYZERS_PREFIX CI/CD 변수를 설정할 수 있습니다.

컨테이너 스캐닝 분석기는 예외로, SECURE_ANALYZERS_PREFIX 변수를 사용하지 않으며, 다른 Docker 이미지로 덮어쓰기 위해 아래 오프라인 환경에서 컨테이너 스캐닝 실행 지침을 참조하세요.

템플릿 버전

대부분의 GitLab 응용프로그램 보안 도구에는 두 가지 템플릿 버전이 있습니다:

Stable: 안정적인 템플릿은 기본값입니다. 안정적이고 일관된 응용프로그램 보안 경험을 제공합니다. 안정성과 CI/CD 파이프라인에서의 예측 가능한 동작이 필요한 대부분의 사용자 및 프로젝트에 대해 안정 템플릿을 사용해야 합니다.
Latest: 최신 템플릿은 최신 기능을 테스트하고 액세스하고자 하는 사용자를 위한 것입니다. 템플릿 이름에 latest라는 단어가 있습니다. 안정적이지 않고 다음 주요 릴리스에 계획된 파손 변경 사항을 포함할 수 있습니다. 이 템플릿을 사용하면 새로운 기능 및 업데이트를 안정 릴리스로 이전되기 전에 시도할 수 있습니다.

참고: 다른 보안 템플릿 버전을 혼합하면 병합 요청 및 브랜치 파이프라인이 모두 실행될 수 있습니다. 프로젝트에서는 안정 또는 최신 버전 템플릿을 하나만 사용해야 합니다.

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

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

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

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

보안 스캐닝

CI/CD 파이프라인에서 실행되는 보안 스캐닝에 대한 결과는 다음과 같은 기준으로 결정됩니다:

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

파이프라인의 보안 작업

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

보안 스캐닝 템플릿 포함 보안 스캐닝 작업의 선택은 먼저 어떤 템플릿이 포함되는지에 따라 결정됩니다. 템플릿은 AutoDevOps, 스캔 실행 정책 또는 .gitlab-ci.yml 구성 파일을 사용하여 포함시킬 수 있습니다.
규칙 평가 각 템플릿에는 분석기를 실행할지 여부를 결정하는 정의된 규칙이 있습니다.
예를 들어, 시크릿 검색 템플릿에는 다음 규칙이 포함되어 있습니다. 이 규칙은 시크릿 검색이 브랜치 파이프라인에서 실행되어야 함을 명시합니다. 병합 요청 파이프라인의 경우, 시크릿 검색이 실행되지 않습니다.
```
rules:
  - if: $CI_COMMIT_BRANCH
```
분석기 로직 템플릿 규칙에 따라 작업을 실행해야 할 경우, 템플릿에서 지정된 파이프라인 단계에 작업이 생성됩니다. 그러나 각 분석기에는 자체 로직이 있어 분석기 자체가 실행될지를 결정합니다.
예를 들어, 종속성 스캐닝에서 지원되는 파일을 기본 깊이에서 감지하지 못한 경우, 분석기가 실행되지 않고 아무런 결과가 출력되지 않습니다.

성공적으로 완료되면 각 작업이 출력을 생성합니다. 이러한 출력은 처리되며 결과가 GitLab에 제공됩니다. 모든 작업이 완료되어야만 결과가 표시됩니다. 또한 일부 기능에 대해서는 기본 브랜치에서 파이프라인이 실행될 때만 결과가 표시됩니다.

작업 상태

작업은 스캔을 완료할 수 있는 경우 합격합니다. 합격 결과는 어떤 식으로든 결과를 식별하거나 식별하지 못했음을 나타내지 않습니다. 결과를 식별하면 무조건 실패합니다(즉, 침투 퍼징만 해당).

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

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

병합 요청에서 취약점이 병합되지 않도록하려면, 병합 요청에서 보안 승인을 추가하여 선택한 특정 그룹의 사람들의 승인 없이 알 수 없는, 높은 또는 크리티컬한 결과물이 병합되지 않도록 해야 합니다.

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

작업 아티팩트

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

보안 보고서는 보안 분석기가 대상 브랜치에서 발견한 모든 결과를 포함하며, 이전에 발견된 것인지 여부와 상관없이 새롭게 발견 된 것임에 상관없이 모두 담고 있습니다.

보안 스캔 정보 보기

보안 스캔 정보는 여러 위치 및 형식에서 볼 수 있습니다: - 병합 요청 - 파이프라인 보안 탭 - 보안 대시보드 - 취약점 보고서 - GitLab Workflow 확장 프로그램 for VS Code

병합 요청

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

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

모든 티어

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

보안 스캔은 다음과 같은 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은 대상 브랜치에서의 마지막 10개의 파이프라인을 찾아 병합 요청에서의 취약점을 확인합니다. 기능 브랜치가 대상 브랜치로부터 생성된 커밋에 대해 마지막 10개의 완료된 파이프라인으로 보안 스캔이 실행되지 않은 경우, 비교 로직에 사용할 수 있는 기준이 없습니다. 병합 요청에서의 취약점은 “new”로 표시됩니다. 개발자가 기능 브랜치의 보안 스캔을 활성화하기 전에 ‘default’ (대상) 브랜치를 스캔하는 것을 권장합니다.

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

병합 요청 보안 위젯은 생성된 JSON 아티팩트의 취약점의 일부만 표시합니다. 이는 새로운 결과와 이전 결과 모두를 포함하고 있습니다.

병합 요청 보안 위젯에서 확장을 선택하여 위젯을 펼쳐서 스캔 유형별로 추가될 새로운 결과와 더 이상 감지되지 않는 (제거된) 결과를 확인할 수 있습니다.

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

예를 들어, 이러한 스캔 결과를 포함한 두 개의 파이프라인을 고려해보겠습니다: - 소스 브랜치 파이프라인은 V1 및 V2로 식별된 두 가지 취약점을 감지합니다. - 대상 브랜치 파이프라인은 V1 및 V3로 식별된 두 가지 취약점을 감지합니다. - V2는 병합 요청 위젯에 “추가됨”으로 표시됩니다. - V3은 병합 요청 위젯에 “수정됨”으로 표시됩니다. - V1은 양쪽 브랜치에 모두 존재하며 병합 요청 위젯에 표시되지 않습니다.

병합 요청의 소스 브랜치의 모든 결과를 보려면, 가장 최근의 소스 브랜치 파이프라인의 Security 탭으로 직접 이동하려면 전체 보고서 보기를 선택하세요.

파이프라인 보안 탭

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

보안 대시보드

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

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

취약점 보고서

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

기본적으로 취약점 보고서는 권한 박탈됨 또는 해결됨 상태의 취약점을 표시하지 않으므로 열린 취약점에 집중할 수 있습니다. 상태 필터를 변경하여 이를 볼 수 있습니다.

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

VS Code용 GitLab Workflow 확장 프로그램

GitLab Workflow 확장 프로그램 for VS Code을 사용하면 비주얼 스튜디오 코드(VS Code)에서 직접 보안 결과를 확인할 수 있습니다. 병합 요청과 마찬가지로, 더 많은 정보를 얻으세요.

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

병합 요청에서의 보안 승인

제거됨 GitLab 15.0에서 취약점 확인 기능.
제거됨 GitLab 16.0에서 라이센스 확인 기능.

다음 보안 문제 중 하나를 도입할 수 있는 병합 요청에 대해 추가적인 승인을 강제할 수 있습니다: - 보안 취약점. 자세한 내용은 병합 요청 승인 정책을 참조하십시오.

개인 Maven 저장소 사용

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

사용자 이름이 myuser이고 암호가 verysecret인 경우 프로젝트 설정에서 다음 변수를 설정하면 됩니다:

유형	키	값
변수	`MAVEN_CLI_OPTS`	`--settings mysettings.xml -Drepository.password=verysecret -Drepository.user=myuser`

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

사용자 정의 스캔 단계 사용

보안 스캔이 활성화된 경우 기본적으로 사전 정의된 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

stage:
  - unit-tests

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

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

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

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

.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에서 보안 스캐너를 실행할 수도 있습니다. OpenShift 내부에서 실행하는 GitLab Runner를 사용할 수 있습니다.

보안 보고서 유효성 검사

GitLab 15.0은 취약점을 가져오기 전에 보안 보고서 아티팩트의 유효성을 강제합니다. 이를 통해 데이터베이스에 손상된 취약성 데이터를 가져오는 것을 방지합니다. GitLab은 보고서에 선언된 스키마 버전에 따라 아티팩트를 유효성 검사합니다.

파이프라인의 보안 탭에 유효성을 통과하지 못한 보고서 아티팩트와 유효성 오류 메시지가 나열됩니다.

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

보안 보고서가 지원되는 스키마 버전을 지정하는 경우 GitLab은 해당 버전을 사용하여 유효성을 검사합니다.
보안 보고서가 사용하지 않는 버전을 사용하는 경우 GitLab은 해당 버전에 대한 유효성 검사를 시도하고 유효성 결과에 사용 중단 경고를 추가합니다.
보안 보고서가 지원되는 MAJOR-MINOR 버전을 사용하지만 PATCH 버전이 판매된 버전과 일치하지 않는 경우 GitLab은 최신 판매된 PATCH 버전의 스키마에 대해 유효성을 검사합니다.
- 예: 보안 보고서가 버전 14.1.1을 사용하지만 최신 판매된 버전이 14.1.0인 경우 GitLab은 스키마 버전 14.1.0에 대해 유효성을 검사합니다.
보안 보고서가 지원되지 않는 버전을 사용하는 경우 GitLab은 설치의 가장 이른 시점에서 사용 가능한 스키마 버전에 대해 유효성을 검사하지만 보고서를 가져오지 않습니다.
보안 보고서가 스키마 버전을 지정하지 않는 경우 GitLab은 GitLab에서 가장 이른 시점에서 사용 가능한 스키마 버전에 대해 유효성을 검사합니다. version 속성이 필요하기 때문에 이 경우 항상 유효성이 실패하지만 다른 유효성 오류도 발생할 수 있습니다.

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

결과 및 취약성 상호 작용

보안 스캔 도구의 결과에 대한 상호 작용은 다음 위치에서 수행할 수 있습니다:

각 위치에서 볼 수 있는 발견 또는 취약성에 따라 이러한 결과와 취약성과 상호 작용할 수 있는 방법에 대한 자세한 내용은 각 링크를 참조하십시오. 대부분의 경우 발견은 검색됨 상태로 시작됩니다.

다음을 선택할 수 있습니다:

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

보안 스캔 구성 팁

각 GitLab 보안 스캔 도구에는 CI/CD 구성 파일, 즉 _템플릿_이라고도 하는 기본값이 있습니다.

구성을 사용자 정의할 때:

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

스캔 실행 강제

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

모든 프로젝트에 대해 정기적으로 실행됩니다.
개발자에 의해 비활성화될 수 없습니다.

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

컴플라이언스 프레임워크 파이프라인
- GitLab 템플릿을 사용하는 모든 스캐너(예: SAST IaC, DAST, 의존성 스캐닝, API Fuzzing, 또는 Coverage-guided Fuzzing)에 대해 스캔 실행 강제가 필요한 경우를 권장합니다.
- GitLab 외부의 스캐너에 대해 스캔 실행 강제가 필요한 경우를 권장합니다.
- 보안 스캔 이외의 사용자 지정 작업에 대해 스캔 실행 강제가 필요한 경우를 권장합니다.
스캔 실행 정책
- DAST가 DAST 사이트 또는 스캔 프로필을 사용하는 경우 스캔 실행 강제가 필요한 경우를 권장합니다.
- 프로젝트별 변수 사용자화를 통해 SAST, SAST IaC, Secret Detection, 의존성 스캐닝 또는 컨테이너 스캐닝에 대해 스캔 실행 강제가 필요한 경우를 권장합니다. 이를 위해 사용자는 프로젝트당 별도의 보안 정책을 작성해야 합니다.
- 스캔은 정기적으로 예정된 주기로 실행되어야 합니다.
어느 솔루션도 다음과 같을 때 동일하게 잘 사용될 수 있습니다:
- 프로젝트별 변수 사용자화없이 컨테이너 스캐닝에 대해 스캔 실행 강제가 필요한 경우.

두 솔루션 간의 차이에 대한 자세한 내용은 아래에서 설명하고 있습니다:

	컴플라이언스 프레임워크 파이프라인	스캔 실행 정책
유연성	CI 파일에서 수행 가능한 모든 작업을 지원합니다.	GitLab이 명시적으로 지원한 항목에만 제한됩니다. DAST, SAST, SAST IaC, Secret Detection, 의존성 스캐닝 및 컨테이너 스캐닝 스캔을 지원합니다.
사용성	CI YAML에 대한 지식이 필요합니다.	`rules` 및 `actions`을 기반으로 한 YAML 구조를 따릅니다.
CI 파이프라인 내 포함	프로젝트의 `.gitlab-ci.yml` 파일 대신 컴플라이언스 파이프라인이 실행됩니다. 프로젝트의 `.gitlab-ci.yml` 파일을 포함하기 위해서 `include` 문을 사용해야 합니다. 정의된 변수들은 포함된 프로젝트의 YAML 파일에 의해 덮어쓰이는 것을 허용하지 않습니다.	CI 파이프라인에 새 작업을 강제로 포함합니다. 프로젝트별로 사용자 정의해야 하는 DAST 작업에 프로젝트 수준 사이트 프로필 및 스캔 프로필이 정의될 수 있습니다. 역할의 분리를 보장하기 위해 이러한 프로필은 스캔 실행 정책에서 참조될 때 변경할 수 없습니다. 모든 작업은 일반적으로 CI 작업에 사용 가능한 동일한 변수를 사용하여 보안 정책 자체의 일부로 사용자 정의할 수 있습니다.
스케줄 가능	각 프로젝트에 대해 예정된 파이프라인을 통해 예정되어야 합니다.	정책 구성 자체를 통해 기본적으로 예정할 수 있습니다.
역할의 분리	그룹 소유자만이 컴플라이언스 프레임워크 레이블을 만들 수 있습니다. 프로젝트 소유자만이 프로젝트에 컴플라이언스 프레임워크 레이블을 적용할 수 있습니다. 컴플라이언스 파이프라인을 포함하는 프로젝트에 명시적으로 액세스 권한이 부여된 개인만이 컴플라이언스 파이프라인을 포함하거나 변경할 수 있습니다.	프로젝트 소유자만이 연결된 보안 정책 프로젝트를 정의할 수 있습니다. 보안 정책에 변경을 가할 수 있는 권한은 해당 보안 정책 프로젝트에 명시적으로 액세스 권한이 부여된 개인에게만 제한됩니다.
여러 프로젝트에 같은 표준을 적용할 수 있는 능력	동일한 컴플라이언스 프레임워크 레이블이 그룹 내의 여러 프로젝트에 적용될 수 있습니다.	동일한 보안 정책 프로젝트가 GitLab 전체의 여러 프로젝트에 사용될 수 있으며 동일한 그룹에 위치할 필요가 없습니다.

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

사용자 정의 보안 역할

응용 프로그램 보안 기능에 대한 액세스 권한이 필요한 보안 팀 구성원을 위해 사용자 정의 역할을 만들 수 있습니다. 이 접근 방식을 사용하면 보안 팀 구성원에게 Developer 또는 Maintainer로 승격하지 않고 필요한 권한을 부여함으로써 최소한의 권한 원칙을 준수할 수 있습니다.

예를 들어, 사용자 정의 보안 역할은 다음과 같은 권한을 가질 수 있습니다:

이름: 사용자 정의 보안 역할
설명: 취약점 관리 및 보안 정책 프로젝트 연결 관리
기본 역할: 보고자 (또는 기본 역할은 무엇이든 상관없음)
권한: admin_vulnerability, read_dependency, manage_security_policy_link

애플리케이션 보안

애플리케이션 범위

소스 코드 분석

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

종속성 분석

인프라스트럭처 분석

데이터 개인 정보

취약점 스캐너 유지 관리

Auto DevOps를 사용한 보안 스캐닝

Auto DevOps 없이 보안 스캐닝

기본 레지스트리 기본 주소 덮어쓰기

템플릿 버전

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

보안 스캐닝

파이프라인의 보안 작업

작업 상태

작업 아티팩트

보안 스캔 정보 보기

병합 요청

모든 티어

얼티메이트

파이프라인 보안 탭

보안 대시보드

취약점 보고서

VS Code용 GitLab Workflow 확장 프로그램

병합 요청에서의 보안 승인

개인 Maven 저장소 사용

사용자 정의 스캔 단계 사용

자체 설치 옵션

보안 보고서 유효성 검사

결과 및 취약성 상호 작용

보안 스캔 구성 팁

스캔 실행 강제

사용자 정의 보안 역할

도움말

기능 사용 가능성과 제품 평가판

도움받기