| Table of Contents |
|---|
*이
...
문서는 https://docs.gitlab.com/를 참조하여 작성되었습니다.
...
GitLab은 무단 액세스, 데이터 유출, 서비스 거부 등으로 이어질 수있는 보안 취약점에 대해 애플리케이션을 확인할 수 있습니다.
GitLab은 병합 요청에서 취약점을 보고하므로 병합하기 전에 수정할 수 있습니다.
보안 대시 보드 프로젝트, 파이프 라인 및 그룹에서 발견된 취약점에 대한 높은 수준의 보기를 제공합니다.
위협 모니터링 페이지는 애플리케이션 환경에 대한 런타임 보안 측정을 제공합니다. 제공된 정보를 통해 위험 분석 및 치료를 즉시 시작할 수 있습니다.
GitLab은 다음 도구를 사용하여 프로젝트에서 발견 된 알려진 취약점을 스캔하고 보고합니다.
...
안전한 스캔 도구
...
기술
...
...
알려진 취약점에 대해 Docker 컨테이너를 검사
...
...
프로젝트의 종속성 및 알려진 취약점을 검사
...
...
알려진 취약점에 대한 종속성을 분석
...
...
모든 프로젝트 및 그룹의 취약성을 검사
...
...
알려진 취약점에 대해 실행중인 웹 응용 프로그램을 분석
...
...
알려진 취약점에 대한 소스 코드를 분석
컨테이너 스캔
GitLab CI / CD를 사용하는 경우 컨테이너에 대한 취약점 정적 분석을위한 두 가지 오픈 소스 도구 인 Clair 및 klar 를 사용하여 알려진 취약점에 대한 Docker 이미지 (또는 컨테이너)를 확인할 수 있습니다 .
기존 파일
gitlab-ci.yml에 CI 작업을 포함 시키거나 Auto DevOps에서 제공하는 자동 컨테이너 검색을 통해 컨테이너 검색을 활용할 수 있습니다 .GitLab은 컨테이너 검색 보고서를 확인하고 소스와 대상 분기 사이에서 발견 된 취약점을 비교하고 병합 요청에 대한 정보를 보여줍니다.
파이프 라인에서 컨테이너 스캔을 활성화
docker또는kubernetes실행 프로그램이 있는 GitLab 러너18.09.03이상 버전이나 GitLab.com에서 공유 러너를 사용하고 있다면 러너가 실행중인 머신에
Docker가 설치되어 있습니다.Docker 이미지를 빌드하고 프로젝트의 컨테이너 레지스트리에 푸시합니다.
아래 정의된대로 다음과 같이 환경 변수를 지정해야 합니다.
$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA.gitlab-ci.yml파일에서 아래와 같이 직접 작성할 수 있습니다.
| Code Block |
|---|
build:
image: docker:19.03.8
stage: build
services:
- docker:19.03.8-dind
variables:
IMAGE_TAG: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $IMAGE_TAG .
- docker push $IMAGE_TAG |
GitLab 설치의 템플릿으로 제공합니다.
Container-Scanning.gitlab-ci.yml11.9 이전의 GitLab 버전의 경우 해당 템플릿에 정의 된대로 작업을 복사하고 사용할 수 있습니다.
.gitlab-ci.yml파일에 다음을 추가
| Code Block |
|---|
include: - template: Container-Scanning.gitlab-ci.yml |
GitLab 11.9 이상의 경우, 컨테이너 검색을 사용하려면 다음을 수행해야 합니다.
container_scanningCI / CD 파이프 라인에서 작업을 작성이미 빌드 된 Docker 이미지를 프로젝트의 컨테이너 레지스트리 에서 가져와 취약성을 스캔
결과는 나중에 다운로드하여 분석 할 수 있는 컨테이너 검색 보고서 아티팩트로 저장됩니다. 구현 제한으로 인해 항상 최신 컨테이너 검색 아티팩트를 사용할 수 있습니다. 무대 뒤에서 GitLab Klar 분석기가 사용되고 스캔을 실행합니다.
2. 컨테이너 검색 설정 사용자 정의
환경 변수를 변경하려면 의
variables매개 변수를 사용하여 컨테이너 검색 설정을 변경할 수 있습니다.컨테이너 변수는 환경 변수를 사용하여 구성할 수 있습니다
.gitlab-ci.yml
...
환경 변수
...
기술
...
기본
...
KLAR_TRACE
...
klar에서 자세한 출력을 사용하려면 true로 설정
...
"false"
...
CLAIR_TRACE
...
clair 서버 프로세스에서 자세한 출력을 사용하려면 true로 설정
...
"false"
...
DOCKER_USER
...
인증이 필요한 Docker 레지스트리에 액세스 하기위한 사용자 이름
...
$CI_REGISTRY_USER
...
DOCKER_PASSWORD
...
인증이 필요한 Docker 레지스트리에 액세스 하기위한 비밀번호
...
$CI_REGISTRY_PASSWORD
...
CLAIR_OUTPUT
...
심각도 수준 임계값이 이상의 심각도를 가진 취약점이 출력됩니다. 지원 하는 설정값은 Unknown, Negligible, Low, Medium, High, Critical, Defcon1
...
Unknown
...
REGISTRY_INSECURE
...
Klar가 안전하지 않은 레지스트리에 액세스하도록 허용
(HTTP만 해당) 이미지를 로컬에서 테스트 할 때만 true로 설정
...
"false"
...
DOCKER_INSECURE
...
Klar가 잘못된 (또는 자체 서명된) SSL 인증서가 있는 HTTPS를 사용하여 보안 Docker 레지스트리에 액세스하도록 허용
...
"false"
...
CLAIR_VULNERABILITIES_DB_URL
...
(CLAIR_DB_CONNECTION_STRING를 사용하는 대신 사용되지 않음) 이 변수는 명시 적으로 설정되어 서비스 섹션의 Container-Scanning.gitlab-ci.yml에 파일을 기본값으로 지정되고, clairvulnerabilities-db 값은 취약성 정의를 호스팅을
하는 PostgreSQL 서버의 실행중인 주소를 나타내며, 이미지를 로컬로 실행하지 않는 한 변경해서는 안됨.
...
clair-vulnerabilities-db
...
CLAIR_DB_CONNECTION_STRING
...
취약성 정의 데이터베이스를 호스팅 하는 PostgreSQL 서버에 대한 연결 문자열 을 나타내며 이미지를 로컬로 실행하지 않는 한 변경해서는 안됨. 연결 문자열의 호스트 값은 템플릿 파일 Container-Scanning.gitlab-ci.yml 의 별칭 값과 일치해야 하며 기본값은 clair-vulnerabilities-db입니다.
...
postgresql://postgres:password@clair-vulnerabilities-db:5432/postgres?sslmode=disable&statement_timeout=60000
...
CI_APPLICATION_REPOSITORY
...
스캔 할 이미지의 Docker 리포지토리 URL
...
$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG
...
CI_APPLICATION_TAG
...
스캔 할 이미지의 Docker 리포지토리 태그
...
$CI_COMMIT_SHA
...
CLAIR_DB_IMAGE
...
취약점 정의를 호스팅하는 PostgreSQL 서버의 Docker 이미지 이름 및 태그, 통합 테스트 목적으로 일관된 취약성 세트를 제공하거나 온 프레미스 오프라인 설치를 위해 로컬로 호스팅 된 취약성 데이터베이스를 참조하기 위해이 값을 특정 버전으로 대체하는 것이 유용 할 수 있습니다.
...
arminc/clair-db:latest
...
CLAIR_DB_IMAGE_TAG
...
(CLAIR_DB_IMAGE를 사용하는 대신 사용되지 않음)도커 이미지 태그 취약점 정의를 호스팅 PostgreSQL 서버를 통합 테스트 목적으로 일관된 취약성을 제공하기 위해 이 값을 특정 버전으로 재정의하는 것이 유용할 수 있습니다.
...
latest
...
DOCKERFILE_PATH
...
Dockerfile 수정 사항을 생성하는 데 사용될 경로 입니다. 기본적으로 스캐너는 Dockerfile 프로젝트의 루트 디렉토리에 이름이 지정된 파일을 검색하므로 이 변수는 Dockerfile하위 디렉토리와 같은 비표준 위치에 있는 경우에만 구성해야 합니다.
...
Dockerfile
...
ADDITIONAL_CA_CERT_BUNDLE
...
신뢰할 수 있는 CA 인증서 번들
종속성 목록
종속성 목록을 사용하면 프로젝트의 종속성 및 알려진 취약점을 포함하여 프로젝트의 종속성을 확인할 수 있습니다. 이를 확인하려면 프로젝트 사이드 바에서 보안 및 규정 준수> 종속성 목록 으로 이동
종속성 스캔 CI 작업이 프로젝트에 구성되야 합니다.
프로젝트는 Gemnasium에서 지원 하는 언어 및 패키지 관리자 중 하나 이상을 사용해야 합니다.
...
표시된 종속성은 이름별로 정렬됩니다. 또한 설치된 패키지 또는 알려진 취약점의 심각도 별로 정렬 할 수 있습니다.
종속성에 알려진 취약점이있는 경우 해당 종속성의
Status셀을 클릭하여 볼 수 있습니다. 그러면 각 취약점의 심각도와 설명이 아래에 표시됩니다.Vulnerable components탭 아래 에 알려진 취약점이있는 종속성 만 표시 하는 두 번째 목록이 있습니다 . 없는 경우이 탭은 비활성화됩니다.필드 별 설명
...
Field
...
Description
...
Status
...
종속성에 알려진 취약점이 있는지 여부를 표시
...
Component
...
의존성 이름
...
Version
...
프로젝트가 사용하는 종속성의 정확한 locked 버전
...
Packager
...
패키지를 설치하는데 사용된 패키지
...
Location
...
종속성을 선언한 프로젝트의 패키지 프로그램 특정 잠금 파일에 댛나 링크
...
License
...
종속성의 소프트웨어 라이센스에 대한 링크
종속성 스캔
응용 프로그램을 개발 및 테스트하는 동안 외부 (오픈 소스) 라이브러리를 사용하는 경우 종속성에서 보안 취약점을 자동으로 찾는데 도움이 됩니다.
GitLab CI / CD 를 사용하는 경우, 당신은 종속성 스캔을 사용하여 알려진 취약점에 대한 종속성을 분석 할 수 있습니다. 전이 종속성 (중첩 종속성이라고도 함)을 포함하여 모든 종속성이 스캔됩니다.
기존 파일
.gitlab-ci.yml에 종속성 검색 템플릿 을 포함하거나 Auto DevOps에서 제공하는 자동 종속성 검색을 암시 적으로 사용하여 종속성 검색을 활용할 수 있습니다.GitLab은 종속성 스캔 보고서를 확인하고 소스와 대상 분기간에 발견 된 취약점을 비교하고 병합 요청에 대한 정보를 보여줍니다.
...
종속성 검색 작업을 실행하려면 기본적으로 권한 모드에서
docker또는kubernetes실행 프로그램이 실행중인 GitLab Runner가 필요 합니다. GitLab.com에서 공유 러너를 사용하는 경우 기본적으로 활성화됩니다.
1. 지원되는 언어 및 패키지
언어 (패키지 관리자) | 지원 | 스캔 도구 |
|---|---|---|
Java (Gradle) | yes | |
Java (Maven) | yes | |
yes | ||
PHP (Composer) | yes | |
Python (pip) | yes | |
Python (Pipfile) | not currently (issue) | not available |
Python (poetry) | not currently (issue) | not available |
Ruby (gem) | yes | |
Scala (sbt) | yes | |
Go (Go Modules) | yes (alpha) |
당신의 GitLab 설치의 템플릿으로 제공합니다.
Dependency-Scanning.gitlab-ci.yml11.9 이전의 GitLab 버전의 경우 해당 템플릿에 정의 된대로 작업을 복사하고 사용할 수 있습니다.
.gitlab-ci.yml파일에 다음을 추가
| Code Block |
|---|
include:
- template: Dependency-Scanning.gitlab-ci.yml |
포함 된 템플릿
dependency_scanning은 CI / CD 파이프 라인에 작업을 생성하고 프로젝트의 소스 코드에서 가능한 취약성을 스캔합니다.결과는 나중에 다운로드하여 분석 할 수 있는 종속성 검색 보고서 아티팩트로 저장됩니다. 구현 제한으로 인해 항상 최신 종속성 검사 아티팩트를 사용할 수 있습니다.
2. 종속성 검색 설정 사용자 정의
환경 변수를 통해 종속성 스캔 설정을 변경할 수 있습니다
.gitlab-ci.yml파일에variables매개변수를 사용하여 전역 종속성 검색 설정을 구성
| Code Block |
|---|
include:
- template: Dependency-Scanning.gitlab-ci.yml
dependency_scanning:
variables:
CI_DEBUG_TRACE: "true" |
...
환경 변수
...
기술
...
DS_ANALYZER_IMAGE_PREFIX
...
공식 기본 이미지를 제공하는 Docker 레지스트리 이름을 대체 (프록시)
...
DS_DEFAULT_ANALYZERS
...
공식 기본 이미지의 이름 덮어쓰기
...
DS_DISABLE_DIND
...
Docker-in-Docker를 비활성화하고 분석기를 개별적으로 실행
...
ADDITIONAL_CA_CERT_BUNDLE
...
신뢰할 수있는 CA 인증서 번들
...
DS_EXCLUDED_PATHS
...
경로를 기반으로 출력에서 취약점을 제외합니다. 쉼표로 구분 된 패턴 목록. 패턴은 glob 또는 파일 또는 폴더 경로(doc,spec), 부모 디렉토리도 패턴과 일치합니다.
3. Docker-in-Docker orchestrator 구성
...
환경 변수
...
기본
...
기술
...
DS_ANALYZER_IMAGES
...
...
쉼표로 구분 된 사용자 정의 이미지 목록, 공식 기본 이미지 활성화
...
DS_ANALYZER_IMAGE_TAG
...
...
공식 기본 이미지의 Docker 태그를 재정의
...
DS_PULL_ANALYZER_IMAGES
...
...
Docker 레지스트리에서 이미지 (0으로 비활성화 설정)
...
DS_DOCKER_CLIENT_NEGOTIATION_TIMEOUT
...
2분
...
Docker 클라이언트 협상의 시간 제한, 시간 초과는 Go 'sParseDuration를 사용하여 구문 분석되고, 유효한 시간 단위는 ns, us(나 µs), ms, s, m, 또는 h
예를 들면 300ms, 1.5h또는 2h45m
...
DS_PULL_ANALYZER_IMAGE_TIMEOUT
...
5분
...
분석기 이미지를 가져올 때 시간 제한 시간 초과는 Go 'sParseDuration를 사용하여 구문 분석되고 유효한 시간 단위는 ns, us(나 µs), ms, s, m, 또는 h
예를 들면 300ms, 1.5h또는 2h45m
...
DS_RUN_ANALYZER_TIMEOUT
...
20분
...
분석기를 실행할 때 시간 제한 시간 초과는 Go 'sParseDuration를 사용하여 구문 분석되고 유효한 시간 단위는 ns, us(나 µs), ms, s, m, 또는 h
예를 들면 300ms, 1.5h또는 2h45m
4. 종속성 검색에 사용되는 특정 분석기 구성
...
환경 변수
...
분석기
...
기본
...
기술
...
GEMNASIUM_DB_LOCAL_PATH
...
gemnasium
...
/gemnasium-db
...
로컬 gemnasium 데이터베이스의 경로
...
GEMNASIUM_DB_REMOTE_URL
...
gemnasium
...
https://gitlab.com/gitlab-org/security-products/gemnasium-db.git
...
gemnasium 데이터베이스를 가져 오기위한 저장소 URL
...
GEMNASIUM_DB_REF_NAME
...
gemnasium
...
master
...
원격 저장소 데이터베이스의 분기 이름 GEMNASIUM_DB_REMOTE_URL 필요
...
DS_REMEDIATE
...
gemnasium
...
"true"
...
취약한 종속성을 자동으로 치료할 수 있음
...
PIP_INDEX_URL
...
gemnasium-python
...
https://pypi.org/simple
...
Python 패키지 색인의 기본 URL
...
PIP_EXTRA_INDEX_URL
...
gemnasium-python
...
...
PIP_INDEX_URL 에 추가로 사용할 패키지 색인 의 추가 URL 배열로 쉼표로 구분
...
PIP_REQUIREMENTS_FILE
...
gemnasium-python
...
...
스캔 할 핍 요구 사항 파일.
...
DS_PIP_VERSION
...
gemnasium-python
...
...
특정 pip 버전을 강제로 설치하지 않으면 예) "19.3"Docker 이미지에 설치된 pip가 사용됩니다. (GitLab 12.7에서 도입)
...
DS_PIP_DEPENDENCY_PATH
...
gemnasium-python
...
...
Python pip 종속성을 로드하는 경로 (GitLab 12.2에서 도입)
...
DS_PYTHON_VERSION
...
retire.js
...
...
파이썬의 버전.2로 설정하면 Python 3.6 대신 Python 2.7을 사용하여 종속성이 설치됨 (GitLab 12.1에서 도입)
...
MAVEN_CLI_OPTS
...
gemnasium-maven
...
"-DskipTests --batch-mode"
...
maven분석기가 전달할 명령 행 인수 목록, 개인 저장소 사용에 대한 예제를 참조
...
BUNDLER_AUDIT_UPDATE_DISABLED
...
bundler-audit
...
"false"
...
bundler-audit분석기의 자동 업데이트를 비활성화하고 Air-Gapped 오프라인 환경에서 종속성 검색을 실행하는 경우에 유용
...
BUNDLER_AUDIT_ADVISORY_DB_URL
...
bundler-audit
...
https://github.com/rubysec/ruby-advisory-db
...
bundler-audit에서 사용하는 권고 데이터베이스의 URL
...
BUNDLER_AUDIT_ADVISORY_DB_REF_NAME
...
bundler-audit
...
master
...
BUNDLER_AUDIT_ADVISORY_DB_URL 지정된 권고 데이터베이스에 대한 Git 참조
...
RETIREJS_JS_ADVISORY_DB
...
retire.js
...
https://raw.githubusercontent.com/RetireJS/retire.js/master/repository/jsrepository.json
...
retire.js 노드 취약점 데이터 파일의 경로나 URL, 데이터 파일을 호스팅하는 URL이고 사용자 정의 SSL 인증서를 오프라인 설치를 사용하는 경우에는 아래 환경 변수에 인증서를 전달ADDITIONAL_CA_CERT_BUNDLE
...
RETIREJS_NODE_ADVISORY_DB
...
retire.js
...
https://raw.githubusercontent.com/RetireJS/retire.js/master/repository/npmrepository.json
...
retire.js노드 취약성 데이터 파일의 경로 또는 URL 데이터 파일을 호스팅하는 URL이 사용자 정의 SSL 인증서를 오프라인 설치를 사용하는 경우에는 아래 환경 변수에 인증서를 전달ADDITIONAL_CA_CERT_BUNDLE
...
RETIREJS_ADVISORY_DB_INSECURE
...
retire.js
...
false
...
안전하지 않거나 자체 서명 된 SSL (TLS) 인증서를 사용하여 호스트에서 원격 JS 및 노드 취약성 데이터 파일 ( RETIREJS_JS_ADVISORY_DB및 RETIREJS_NODE_ADVISORY_DB변수로 정의)을 패치
5. 종속성 검색을 위해 Docker 비활성화
개별 분석기를 실행하여 Docker에서 Docker가 필요하지 않도록 할 수 있습니다. 이것은 특권 모드에서 실행기를 실행할 필요가 없습니다.
| Code Block |
|---|
include:
- template: Dependency-Scanning.gitlab-ci.yml
dependency_scanning:
variables:
CI_DEBUG_TRACE: "true" |
<analyzer-name>-dependency_scanningCI / CD 파이프 라인에서 실행되는 각 분석기마다 개별 작업이 생성제거함으로써 GitLab은 Linguist 를 사용하여 오케스트레이터 대신 탐지 된 리포지토리 언어에 따라 관련 분석기를 시작
보안 대시 보드
보안 대시 보드는 그룹, 프로젝트 및 파이프 라인의 모든 보안 취약성에 대한 개요를 얻을 수 있습니다.
취약성을 분석하고 추가 정보를 얻고, 어떤 프로젝트에서 왔는지, 파일에 포함 된 파일 및 다양한 메타 데이터를 확인하여 위험을 분석할 수 있습니다.
취약점을 악용하여 문제를 생성하거나 해제함으로써 이러한 취약점에 대한 조치를 취할 수 있습니다.
보안 대시 보드를 활용하려면 먼저 보안 보고서 중 하나를 구성해야 합니다.
인스턴스, 그룹, 프로젝트 또는 파이프 라인 보안 대시 보드를 사용하려면 아래와 같이 구성해야 합니다.
지원되는 보고서 중 하나 이상으로 그룹 내의 프로젝트를 하나 이상 구성
구성된 작업은 새
reports구문으로 사용GitLab Runner 11.5 이상을 사용
GitLab.com 에서 공유 러너를 사용하고 있다면 이미 구성되어 있음
1. 파이프 라인 보안
파이프 라인 수준에서 보안 섹션에는 파이프 라인이 실행 된 프로젝트 분기에 존재하는 취약성이 표시됨
보안 결과를 보려면 Security 탭을 클릭
...
2. 프로젝트 보안 대시 보드
프로젝트 수준에서 보안 대시 보드는 마지막으로 성공한 파이프 라인의 프로젝트에 대한 최신 보안 보고서를 표시합니다. 이를 사용하여 default branch에 영향을 미치는 취약성을 찾아 수정
...
보안 대시 보드 그룹은 그룹 및 하위 그룹에있는 모든 프로젝트의 취약성에 대한 개요를 제공합니다.
먼저 그룹의 보안 탭 아래에있는 보안 대시 보드로 이동 하십시오.
대시 보드에 있으면 맨 위에 다음에 대한 일련의 필터가 표시됩니다.
심각성
자신
보고서 유형
계획
필터 오른쪽에 숨기기 해제 토글 버튼이 표시됩니다
Threat Monitoring
위협 모니터링 페이지는 GitLab 응용 프로그램 실행시 보안 기능에 대한 통계를 제공합니다.
프로젝트의 Security & Compliance > Threat Monitoring 페이지로 이동하여 이러한 메트릭에 액세스 할 수 있습니다.
다음 보안 기능에 대한 통계를 지원합니다.
웹 애플리케이션 방화벽
웹 애플리케이션 방화벽 섹션은 NGINX Ingress 컨트롤러 및 ModSecurity 방화벽에 대한 메트릭을 제공합니다.
이 섹션에는 아래와 같은 전제 조건이 있습니다.
프로젝트에는 하나 이상의 환경이 있어야 합니다.
웹 응용 프로그램 방화벽이 활성화되어 있어야 합니다.
Elastic Stack 이 설치되어 있어야 합니다.
Web Application Firewall 섹션에서는 침투 트래픽에 대한 아래 정보를 표시합니다.
응용 프로그램에 대한 총 요청 수
구성된 규칙에 따라 비정상으로 간주되는 트래픽 비율
선택한 시간 간격에 대한 요청 분석 그래프
트래픽의 상당 부분이 비정상적인 경우 응용 프로그램 로그를 검사하여 잠재적인 위협에 대해 트래픽을 조사해야합니다.
컨테이너 네트워크 정책
Container Network Policy 섹션에서는 응용 프로그램의 Cubernetes 네임스페이스에 대한 패킷 흐름 메트릭을 제공합니다.
이 섹션에는 아래와 같은 전제 조건이 있습니다.
프로젝트에 하나 이상의 환경이 포함되어 있습니다
Cilium 설치
Prometheus 서비스 구성
Cilium에 사용자 지정 Helm 값을 사용하는 경우 Hubble 값에 다음 줄을 추가하여 각 네임 스페이스에 대한 흐름 메트릭으로 Hubble을 활성화해야 합니다.
| Code Block |
|---|
metrics:
enabled:
- 'flow:sourceContext=namespace;destinationContext=namespace' |
Container Network Policy 섹션을 표시하여 패킷 흐름에 대한 아래와 같은 정보를 제공합니다.
인바운드 및 아웃 바운드 패킷의 총량
구성된 정책에 따라 삭제 된 패킷 비율
요청 된 시간 간격 동안 시간 동안 누적 된 전달 및 삭제 된 패킷의 초당 평균 비율
패킷의 상당 부분이 삭제되면 Cilium 로그를 검사하여 잠재적인 위협이 있는지 조사해야 합니다.
...
Aplication security
GitLab은 무단 액세스, 데이터 유출, 서비스 거부 등으로 이어질 수 있는 보안 취약점에 대해 애플리케이션을 확인할 수 있습니다.
GitLab은 병합 요청에서 취약점을 보고하므로 병합하기 전에 수정할 수 있습니다.
보안 대시보드 프로젝트, 파이프 라인 및 그룹에서 발견된 취약점에 대한 높은 수준의 보기를 제공합니다.
위협 모니터링 페이지는 애플리케이션 환경에 대한 런타임 보안 측정을 제공합니다. 제공된 정보를 통해 위험 분석 및 치료를 즉시 시작할 수 있습니다.
GitLab은 다음 도구를 사용하여 프로젝트에서 발견 된 알려진 취약점을 스캔하고 보고합니다.
안전한 스캔 도구 | 기술 |
|---|---|
알려진 취약점에 대해 Docker 컨테이너를 검사 | |
프로젝트의 종속성 및 알려진 취약점을 검사 | |
알려진 취약점에 대한 종속성을 분석 | |
모든 프로젝트 및 그룹의 취약성을 검사 | |
알려진 취약점에 대해 실행중인 웹 응용 프로그램을 분석 | |
알려진 취약점에 대한 소스 코드를 분석 |
컨테이너 스캔
GitLab CI / CD를 사용하는 경우 컨테이너에 대한 취약점 정적 분석을위한 두 가지 오픈 소스 도구 인 Clair 및 klar 를 사용하여 알려진 취약점에 대한 Docker 이미지(또는 컨테이너)를 확인할 수 있습니다.
기존 파일
gitlab-ci.yml에 CI 작업을 포함 시키거나 Auto DevOps에서 제공하는 자동 컨테이너 검색을 통해 컨테이너 검색을 활용할 수 있습니다.GitLab은 컨테이너 검색 보고서를 확인하고 소스와 대상 분기 사이에서 발견된 취약점을 비교하고 병합 요청에 대한 정보를 보여줍니다.
1. 파이프 라인에서 컨테이너 스캔을 활성화
docker또는kubernetes실행 프로그램이 있는 GitLab 러너18.09.03이상 버전이나 GitLab.com에서 공유 러너를 사용하고 있다면 러너가 실행중인 머신에
Docker가 설치되어 있습니다.Docker 이미지를 빌드하고 프로젝트의 컨테이너 레지스트리에 푸시합니다.
아래 정의된대로 다음과 같이 환경 변수를 지정해야 합니다.
$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA.gitlab-ci.yml파일에서 아래와 같이 직접 작성할 수 있습니다.
| Code Block |
|---|
build:
image: docker:19.03.8
stage: build
services:
- docker:19.03.8-dind
variables:
IMAGE_TAG: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $IMAGE_TAG .
- docker push $IMAGE_TAG |
GitLab 설치의 템플릿으로 제공합니다.
Container-Scanning.gitlab-ci.yml11.9 이전의 GitLab 버전의 경우 해당 템플릿에 정의 된대로 작업을 복사하고 사용할 수 있습니다.
.gitlab-ci.yml파일에 다음을 추가
| Code Block |
|---|
include: - template: Container-Scanning.gitlab-ci.yml |
GitLab 11.9 이상의 경우, 컨테이너 검색을 사용하려면 다음을 수행해야 합니다.
container_scanningCI / CD 파이프 라인에서 작업을 작성합니다.이미 빌드 된 Docker 이미지를 프로젝트의 컨테이너 레지스트리 에서 가져와 취약성을 스캔합니다.
결과는 나중에 다운로드하여 분석 할 수 있는 컨테이너 검색 보고서 아티팩트로 저장되고 구현 제한으로 인해 항상 최신 컨테이너 검색 아티팩트를 사용할 수 있습니다. 무대 뒤에서 GitLab Klar 분석기가 사용되고 스캔을 실행합니다.
2. 컨테이너 검색 설정 사용자 정의
환경 변수를 변경하려면 의
variables매개 변수를 사용하여 컨테이너 검색 설정을 변경할 수 있습니다.컨테이너 변수는 환경 변수를 사용하여 구성할 수 있습니다.
.gitlab-ci.yml
환경 변수 | 기술 | 기본 |
|---|---|---|
KLAR_TRACE | klar에서 자세한 출력을 사용하려면 true로 설정 |
|
CLAIR_TRACE | clair 서버 프로세스에서 자세한 출력을 사용하려면 true로 설정 |
|
DOCKER_USER | 인증이 필요한 Docker 레지스트리에 액세스 하기위한 사용자 이름 |
|
DOCKER_PASSWORD | 인증이 필요한 Docker 레지스트리에 액세스 하기위한 비밀번호 |
|
CLAIR_OUTPUT | 심각도 수준 임계값이 이상의 심각도를 가진 취약점이 출력됩니다. 지원 하는 설정값은 |
|
REGISTRY_INSECURE | Klar가 안전하지 않은 레지스트리에 액세스하도록 허용 |
|
DOCKER_INSECURE | Klar가 잘못된 (또는 자체 서명된) SSL 인증서가 있는 HTTPS를 사용하여 보안 Docker 레지스트리에 액세스하도록 허용 |
|
CLAIR_VULNERABILITIES_DB_URL | ( |
|
CLAIR_DB_CONNECTION_STRING | 취약성 정의 데이터베이스를 호스팅 하는 PostgreSQL 서버에 대한 연결 문자열 을 나타내며 이미지를 로컬로 실행하지 않는 한 변경해서는 안됨. 연결 문자열의 호스트 값은 템플릿 파일 |
|
CI_APPLICATION_REPOSITORY | 스캔 할 이미지의 Docker 리포지토리 URL |
|
CI_APPLICATION_TAG | 스캔 할 이미지의 Docker 리포지토리 태그 |
|
CLAIR_DB_IMAGE | 취약점 정의를 호스팅하는 PostgreSQL 서버의 Docker 이미지 이름 및 태그, 통합 테스트 목적으로 일관된 취약성 세트를 제공하거나 온 프레미스 오프라인 설치를 위해 로컬로 호스팅 된 취약성 데이터베이스를 참조하기 위해이 값을 특정 버전으로 대체하는 것이 유용 할 수 있습니다. |
|
CLAIR_DB_IMAGE_TAG | ( |
|
DOCKERFILE_PATH | Dockerfile 수정 사항을 생성하는 데 사용될 경로 입니다. 기본적으로 스캐너는 Dockerfile 프로젝트의 루트 디렉토리에 이름이 지정된 파일을 검색하므로 이 변수는 Dockerfile하위 디렉토리와 같은 비표준 위치에 있는 경우에만 구성해야 합니다. |
|
ADDITIONAL_CA_CERT_BUNDLE | 신뢰할 수 있는 CA 인증서 번들 |
종속성 목록
종속성 목록을 사용하면 프로젝트의 종속성 및 알려진 취약점을 포함하여 프로젝트의 종속성을 확인할 수 있습니다. 이를 확인하려면 프로젝트 사이드 바에서 Security & Compliance > Dependency List 로 이동
종속성 스캔 CI 작업이 프로젝트에 구성되야 합니다.
프로젝트는 Gemnasium에서 지원 하는 언어 및 패키지 관리자 중 하나 이상을 사용해야 합니다.
...
표시된 종속성은 이름별로 정렬됩니다. 또한 설치된 패키지 또는 알려진 취약점의 심각도 별로 정렬 할 수 있습니다.
종속성에 알려진 취약점이있는 경우 해당 종속성의
Status셀을 클릭하여 볼 수 있습니다. 그러면 각 취약점의 심각도와 설명이 아래에 표시됩니다.Vulnerable components탭 아래 에 알려진 취약점이있는 종속성 만 표시 하는 두 번째 목록이 있습니다.
없는 경우이 탭은 비활성화됩니다.필드 별 설명
Field | Description |
|---|---|
Status | 종속성에 알려진 취약점이 있는지 여부를 표시 |
Component | 의존성 이름 |
Version | 프로젝트가 사용하는 종속성의 정확한 locked 버전 |
Packager | 패키지를 설치하는데 사용된 패키지 |
Location | 종속성을 선언한 프로젝트의 패키지 프로그램 특정 잠금 파일에 댛나 링크 |
License | 종속성의 소프트웨어 라이센스에 대한 링크 |
종속성 스캔
응용 프로그램을 개발 및 테스트하는 동안 외부 (오픈 소스) 라이브러리를 사용하는 경우 종속성에서 보안 취약점을 자동으로 찾는데 도움이 됩니다.
GitLab CI / CD 를 사용하는 경우, 당신은 종속성 스캔을 사용하여 알려진 취약점에 대한 종속성을 분석 할 수 있습니다. 전이 종속성 (중첩 종속성이라고도 함)을 포함하여 모든 종속성이 스캔됩니다.
기존 파일
.gitlab-ci.yml에 종속성 검색 템플릿 을 포함하거나 Auto DevOps에서 제공하는 자동 종속성 검색을 암시 적으로 사용하여 종속성 검색을 활용할 수 있습니다.GitLab은 종속성 스캔 보고서를 확인하고 소스와 대상 분기간에 발견 된 취약점을 비교하고 병합 요청에 대한 정보를 보여줍니다.
...
종속성 검색 작업을 실행하려면 기본적으로 권한 모드에서
docker또는kubernetes실행 프로그램이 실행중인 GitLab Runner가 필요합니다. GitLab.com에서 공유 러너를 사용하는 경우 기본적으로 활성화됩니다.
1. 지원되는 언어 및 패키지
언어 (패키지 관리자) | 지원 | 스캔 도구 |
|---|---|---|
Java (Gradle) | yes | |
Java (Maven) | yes | |
yes | ||
PHP (Composer) | yes | |
Python (pip) | yes | |
Python (Pipfile) | not currently (issue) | not available |
Python (poetry) | not currently (issue) | not available |
Ruby (gem) | yes | |
Scala (sbt) | yes | |
Go (Go Modules) | yes (alpha) |
당신의 GitLab 설치의 템플릿으로 제공합니다.
Dependency-Scanning.gitlab-ci.yml11.9 이전의 GitLab 버전의 경우 해당 템플릿에 정의 된대로 작업을 복사하고 사용할 수 있습니다.
.gitlab-ci.yml파일에 다음을 추가
| Code Block |
|---|
include:
- template: Dependency-Scanning.gitlab-ci.yml |
포함 된 템플릿
dependency_scanning은 CI / CD 파이프 라인에 작업을 생성하고 프로젝트의 소스 코드에서 가능한 취약성을 스캔합니다.결과는 나중에 다운로드하여 분석 할 수 있는 종속성 검색 보고서 아티팩트로 저장됩니다. 구현 제한으로 인해 항상 최신 종속성 검사 아티팩트를 사용할 수 있습니다.
2. 종속성 검색 설정 사용자 정의
환경 변수를 통해 종속성 스캔 설정을 변경할 수 있습니다.
.gitlab-ci.yml파일에variables매개변수를 사용하여 전역 종속성 검색 설정을 구성
| Code Block |
|---|
include:
- template: Dependency-Scanning.gitlab-ci.yml
dependency_scanning:
variables:
CI_DEBUG_TRACE: "true" |
환경 변수 | 기술 |
|---|---|
| 공식 기본 이미지를 제공하는 Docker 레지스트리 이름을 대체 (프록시) |
| 공식 기본 이미지의 이름 덮어쓰기 |
| Docker-in-Docker를 비활성화하고 분석기를 개별적으로 실행 |
| 신뢰할 수있는 CA 인증서 번들 |
| 경로를 기반으로 출력에서 취약점을 제외합니다. 쉼표로 구분 된 패턴 목록. 패턴은 glob 또는 파일 또는 폴더 경로( |
3. Docker-in-Docker orchestrator 구성
환경 변수 | 기본 | 기술 |
|---|---|---|
|
| 쉼표로 구분 된 사용자 정의 이미지 목록, 공식 기본 이미지 활성화 |
|
| 공식 기본 이미지의 Docker 태그를 재정의 |
|
| Docker 레지스트리에서 이미지 ( |
| 2분 | Docker 클라이언트 협상의 시간 제한, 시간 초과는 Go 's |
| 5분 | 분석기 이미지를 가져올 때 시간 제한 시간 초과는 Go 's |
| 20분 | 분석기를 실행할 때 시간 제한 시간 초과는 Go 's |
4. 종속성 검색에 사용되는 특정 분석기 구성
환경 변수 | 분석기 | 기본 | 기술 |
|---|---|---|---|
|
|
| 로컬 gemnasium 데이터베이스의 경로 |
|
|
| gemnasium 데이터베이스를 가져 오기위한 저장소 URL |
|
|
| 원격 저장소 데이터베이스의 분기 이름 |
|
|
| 취약한 종속성을 자동으로 치료할 수 있음 |
|
|
| Python 패키지 색인의 기본 URL |
|
|
|
|
|
|
| 스캔 할 핍 요구 사항 파일 |
|
|
| 특정 pip 버전을 강제로 설치하지 않으면 예) |
|
|
| Python pip 종속성을 로드하는 경로 (GitLab 12.2에서 도입) |
|
|
| 파이썬의 버전.2로 설정하면 Python 3.6 대신 Python 2.7을 사용하여 종속성이 설치됨 (GitLab 12.1에서 도입) |
|
|
|
|
|
|
|
|
|
|
| bundler-audit에서 사용하는 권고 데이터베이스의 URL |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 안전하지 않거나 자체 서명 된 SSL (TLS) 인증서를 사용하여 호스트에서 원격 JS 및 노드 취약성 데이터 파일 ( |
5. 종속성 검색을 위해 Docker 비활성화
개별 분석기를 실행하여 Docker에서 Docker가 필요하지 않도록 할 수 있습니다. 이것은 특권 모드에서 실행기를 실행할 필요가 없습니다.
| Code Block |
|---|
include:
- template: Dependency-Scanning.gitlab-ci.yml
dependency_scanning:
variables:
CI_DEBUG_TRACE: "true" |
<analyzer-name>-dependency_scanningCI / CD 파이프 라인에서 실행되는 각 분석기마다 개별 작업이 생성제거함으로써 GitLab은 Linguist 를 사용하여 오케스트레이터 대신 탐지 된 리포지토리 언어에 따라 관련 분석기를 시작.
보안 대시 보드
보안 대시 보드는 그룹, 프로젝트 및 파이프 라인의 모든 보안 취약성에 대한 개요를 얻을 수 있습니다.
취약성을 분석하고 추가 정보를 얻고, 어떤 프로젝트에서 왔는지, 파일에 포함 된 파일 및 다양한 메타 데이터를 확인하여 위험을 분석할 수 있습니다.
취약점을 악용하여 문제를 생성하거나 해제함으로써 이러한 취약점에 대한 조치를 취할 수 있습니다.
보안 대시 보드를 활용하려면 먼저 보안 보고서 중 하나를 구성해야 합니다.
인스턴스, 그룹, 프로젝트 또는 파이프 라인 보안 대시 보드를 사용하려면 아래와 같이 구성해야 합니다.
지원되는 보고서 중 하나 이상으로 그룹 내의 프로젝트를 하나 이상 구성.
구성된 작업은 새
reports구문으로 사용.GitLab Runner 11.5 이상을 사용.
GitLab.com 에서 공유 러너를 사용하고 있다면 이미 구성되어 있음.
1. 파이프 라인 보안
파이프 라인 수준에서 보안 섹션에는 파이프 라인이 실행 된 프로젝트 분기에 존재하는 취약성이 표시됨.
보안 결과를 보려면 Security 탭을 클릭.
...
2. 프로젝트 보안 대시 보드
프로젝트 수준에서 보안 대시 보드는 마지막으로 성공한 파이프 라인의 프로젝트에 대한 최신 보안 보고서를 표시하고 이를 사용하여 default branch에 영향을 미치는 취약성을 찾아 수정.
...
3. 그룹 보안 대시 보드
보안 대시 보드 그룹은 그룹 및 하위 그룹에있는 모든 프로젝트의 취약성에 대한 개요를 제공합니다.
먼저 그룹의 Security 탭 아래에있는 보안 대시 보드로 이동.
대시 보드에 있으면 맨 위에 다음에 대한 일련의 필터가 표시됩니다.
심각성
자신
보고서 유형
계획
필터 오른쪽에 Hide dismissed 토글 버튼이 표시됩니다.
대시보드에는 마지막으로 성공한 프로젝트 파이프 라인에 따라 그룹에서 보안 보고서가 활성화 된 프로젝트만 표시됩니다.
...
하나 이상의 필터를 선택하면 이 페이지의 결과가 필터링됩니다. Hide dismissed 토글 버튼을 비활성화하면 해제 된 취약점도 볼 수 있습니다.
기본 섹션은 그룹의 모든 취약점 목록을 심각도 별로 정렬합니다. 이 목록에서 취약점의 심각성, 이름, 신뢰도 및 프로젝트의 출처를 확인할 수 있습니다.
행 위로 마우스를 가져 가면 수행 할 수있는 조치가 나타납니다.
“More info”`
“Create issue”
“Dismiss vulnerability”
목록 옆에는 프로젝트가 다양한 시점에 얼마나 많은 공개 취약점이 있는지 보여주는 타임 라인 차트가 있습니다. 30 일, 60 일, 90 일 중 기본값을 90으로 필터링 할 수 있습니다.
차트 위에 마우스를 놓으면 특정 시간에 열린 취약점에 대한 자세한 내용을 볼 수 있습니다.
타임 라인 차트 아래에는 발견 된 취약점의 심각도에 따라 그룹화 및 정렬 된 프로젝트 목록이 있습니다.
F : 1 개 이상의 "critical"
D : 1 개 이상의 "high"또는 "unknown"
C : 1 개 이상의 "medium"
B : 1 개 이상 "low"
A : 취약점 0 개
취약성 테스트가 구성되지 않은 프로젝트는 목록에 없습니다. 또한 해제 된 취약점도 포함되지 않습니다.
4. 인스턴스 보안 대시 보드
인스턴스 수준에서 보안 대시 보드에는 추가 한 모든 프로젝트에 존재하는 취약성이 표시됩니다.
그룹 보안 대시 보드 의 모든 기능이 포함됩니다.
페이지 상단의 메뉴 표시 줄에서 인스턴스 보안 대시 보드에 액세스 할 수 있습니다.
More - Security
...
5. 대시 보드에 프로젝트 추가
대시 보드에 프로젝트를 추가하려면
인스턴스 보안 대시 보드 페이지에서 Edit dashboard 버튼을 클릭
Search your projects 필드를 사용하여 하나 이상의 프로젝트를 검색하고 추가
Add projects 버튼을 클릭
추가되면 대시 보드에 선택한 프로젝트에서 발견 된 취약점이 표시됩니다.
...
6. 대시 보드를 최신 상태로 유지
보안 대시 보드는 default branch에 최신 보안 검색 결과의 정보를 표시합니다. 즉, 지점이 업데이트 될 때마다 보안 검색이 수행됩니다.
기본 분기가 자주 업데이트되지 않으면 검색이 자주 실행되지 않고 새로운 취약성이 발견 될 때 보안 대시 보드의 정보가 오래될 수 있습니다.
보안 대시보드의 정보가 정기적으로 업데이트 되도록하려면 매일 보안 검색을 실행 하도록 예약 된 파이프 라인을 구성하면 기본 분기 업데이트 빈도에 관계없이 보안 대시 보드에 표시되는 정보가 업데이트됩니다.
이렇게하면 코드를 변경하지 않아도 보고서가 작성됩니다.