GitLab 컨테이너 스캐닝은 컨테이너화된 애플리케이션의 보안과 무결성을 유지하는 데 필수적인 도구입니다. 조직이 소프트웨어 배포를 위해 컨테이너화를 채택하는 방향으로 나아가면서 이 기술을 숙지하고 활용하는 것은 더욱 중요해집니다.
본 문서에서는 GitLab 컨테이너 스캐닝의 작동 방식, 지원되는 컨테이너 형식, 그리고 모범 사례와 실제 사례를 통해 프로젝트 설정을 용이하게 하는 방법을 심층적으로 다룹니다. 모범 사례를 강조한 이 가이드를 통해 GitLab 컨테이너 스캐닝에 대한 이해를 높여 원활한 워크플로우와 안전한 개발 프로세스를 보장할 수 있습니다.

GitLab 컨테이너 스캐닝 이해하기
GitLab 컨테이너 스캐닝을 이해하는 것은 GitLab을 사용하여 컨테이너화된 애플리케이션을 보호하려는 경우나 다른 방법을 통해 이를 시도하려는 경우 핵심입니다. 는 GitLab을 사용하거나 컨테이너화 플랫폼을 사용하는 경우 핵심적인 역할을 합니다. GitLab 컨테이너 스캐닝은 보안 점검 역할을 수행하며, 소프트웨어 내 각 구성 요소에 공격자가 악용할 수 있는 취약점이 있는지 확인합니다. 마치 빌딩 블록에 대한 바이러스 검사처럼 작동합니다!
이 검사는 컨테이너 내에 포함된 소프트웨어를 면밀히 조사하여 존재할 수 있는 문제나 잠재적 위험을 탐지하는 과정을 포함합니다. 이 단계는 현대 소프트웨어 개발에 있어 매우 중요합니다. 컨테이너는 일반적으로 여러 출처의 서로 다른 구성 요소로 이루어지며, 애플리케이션 내 무결성을 유지하기 위해 모든 구성 요소가 보안 표준을 준수해야 합니다.
GitLab 컨테이너 스캐닝은 컨테이너화된 소프트웨어 애플리케이션에 필수적인 보호 기능을 제공함으로써 소프트웨어 개발에 매우 유용합니다. 취약점을 조기에 식별하면 시스템을 안전하게 유지할 수 있어 개발자와 이해관계자 모두에게 안심을 줍니다.
GitLab 컨테이너 스캐닝 작동 방식
GitLab 컨테이너 스캐닝은 컨테이너 이미지 내 취약점을 자동으로 식별하고 해결하여, 이미지 내 모든 취약점이 신속하고 안정적으로 처리되었음을 보장합니다. 작동 방식에 대한 자세한 내용은 다음과 같습니다.
GitLab 컨테이너 스캐닝은 CI/CD(지속적 통합/지속적 배포) 파이프라인과 쉽게 통합될 수 있어, 스캐닝 프로세스가 단순히 독립적인 이벤트가 아닌 각 빌드 및 푸시의 필수적인 부분이 됩니다. 이를 통해 보안 검사가 일회성 작업이 아닌 개발 과정의 지속적인 일부가 될 수 있습니다.
취약점 데이터베이스 활용
이 도구는 알려진 취약점 데이터베이스와 구성 요소를 교차 참조하여 컨테이너 내에서 사용되는 소프트웨어 패키지나 라이브러리의 취약점을 탐지합니다. 이를 통해 해당 요소 내에 존재할 수 있는 위협을 쉽게 식별할 있습니다.
보고서 생성
GitLab Container Scanning은 완료 시 발견된 취약점과 그 심각도 범주를 요약하고 필요한 경우 수정 또는 완화 전략을 제안하는 포괄적인 보고서를 생성합니다.
자동화된 대응
GitLab Container Scanning은 설정된 방식에 따라 자동화된 대응을 구성할 수 있도록 지원합니다. 개발팀이 해결할 이슈 생성부터, 심각한 취약점이 발견될 경우 CI/CD 파이프라인 중단까지 포함될 수 있습니다. 이를 통해 보안 취약점이 있는 코드가 프로덕션 환경으로 유출되는 것을 방지합니다.
보완 조치 및 지속적 모니터링
당사의 지속적 모니터링 도구는 업데이트가 적용될 때마다 컨테이너 업데이트를 지속적으로 스캔하고, 변경 사항이 구현되면서 발생할 수 있는 취약점을 자동으로 확인하며, 시간이 지남에 따라 발생하는 새로운 취약점에 대한 지속적인 보호를 보장함으로써 지속적인 보완 조치를 지원합니다.
GitLab에서 지원하는 컨테이너 형식
GitLab의 컨테이너 스캐닝 지원이 특정 컨테이너 형식을 의미할 때, 이는 해당 컨테이너 내 데이터의 특정 구조와 배열을 조사하는 것을 의미합니다. Trivy 및 Grype 스캐닝 도구는 다양한 리눅스 배포판에 걸쳐 광범위한 지원을 제공하므로 여러 환경에서 취약점을 신속하게 식별할 수 있습니다.
오픈소스 스캐닝 도구:
- Trivy (컨테이너 및 운영체제용 오픈소스 취약점 스캐너): Trivy는 컨테이너와 운영체제에 특화된 검증된 오픈소스 취약점 스캐너로, 다양한 리눅스 배포판 전반에 걸친 취약점을 식별하기 위한 가볍지만 철저한 스캔 기능을 제공합니다.
- Grype: Grype는 컨테이너 이미지에 대한 정확한 취약점 데이터를 제공합니다. 분석 도구로서 Grype는 정확하면서도 실행 가능한 취약점 데이터로 보안 위협을 철저히 검토하여 Trivy를 보완합니다.
지원되는 리눅스 배포판
컨테이너 형식과 배포판의 차이를 이해하는 것은 매우 중요합니다. 컨테이너는 컨테이너 내에 데이터를 저장하는 반면, 배포판은 GitLab의 Trivy 및 Grype 서비스가 지원하는 다양한 Linux OS 변형을 의미합니다. GitLab은 인상적인 배포판 목록을 지원합니다. 간략한 요약은 다음과 같습니다:
- Alma Linux: Trivy로 스캔됨
- Alpine Linux: Grype와 Trivy 모두 지원
- Amazon Linux: Grype와 Trivy 모두 지원
- BusyBox: Grype로 스캔됨
- CentOS: Grype와 Trivy 모두 지원됨
- CBL-Mariner: Trivy를 사용하여 스캔됨
- Debian: Grype와 Trivy 모두 지원됨
- Distroless: Grype와 Trivy 모두 지원됨
- Oracle Linux: Grype와 Trivy 모두 지원
- Photon OS: Trivy로 스캔됨
- Red Hat (RHEL): Grype와 Trivy 모두 지원
- Rocky Linux: Trivy를 사용하여 스캔됨
- SUSE: Trivy로 스캔됨
- Ubuntu: Grype와 Trivy 모두 지원됨
광범위한 배포판 지원의 중요성
GitLab Container Scanning은 컨테이너화된 애플리케이션이 개발자들 사이에서 인기를 얻으면서 다양한 배포판 지원의 중요성이 점점 더 커지고 있음을 잘 알고 있습니다. 개발자들은 성능, 보안, 호환성 또는 개인적 선호도에 따라 서로 다른 Linux 배포판을 선택하는 경우가 많습니다. GitLab Container Scanning은 여러 배포판을 동시에 지원함으로써 개발자가 선택한 환경에 관계없이 애플리케이션 보안을 지속적으로 유지할 수 있도록 보장합니다. 이는 컨테이너화된 워크로드에 대한 포괄적인 보안을 제공하겠다는 우리의 약속을 더욱 공고히 합니다.
컨테이너 스캐닝을 위한 GitLab 설정 방법?
컨테이너 스캐닝을 위한 GitLab 구현은 컨테이너화된 애플리케이션에 대한 자동 취약점 스캐닝을 용이하게 하는 효율적인 프로세스입니다. 이를 달성하는 일반적인 개요는 다음과 같습니다:
1. 자동 병합 요청을 통한 컨테이너 스캔 활성화
GitLab 14.9에서는 자동화된 병합 요청을 통해 컨테이너 스캔을 간편하고 빠르게 활성화할 수 있습니다. 방법은 다음과 같습니다:
- 원하는 프로젝트로 이동합니다.
- 보안(Secure) 보안 구성(Security Configuration)으로 이동합니다.
- 컨테이너 스캔 행에서 병합 요청으로 구성 선택.
활성화되면 이 프로세스는 컨테이너 스캔을 활성화하는 데 필요한 변경 사항이 포함된 자동 병합 요청을 생성합니다. 병합 전에 검토하기만 하면 컨테이너 스캔 구성이 완료됩니다.
2. .gitlab-ci.yml 파일을 통한 구성:
컨테이너 스캐닝을 수동으로 구성하려면 관련 템플릿을 .gitlab-ci.yml 파일에 추가해야 합니다:
include: - template: Security/Container-Scanning.gitlab-ci.yml
이 템플릿은 CI/CD 파이프라인에 container_scanning 작업을 추가하여 Docker 이미지의 취약점을 스캔하고 결과를 container-scanning 보고서 아티팩트로 저장합니다.
Docker 이미지를 빌드하고 스캔하는 .gitlab-ci.yml 파일의 예시는 다음과 같습니다.
include: - template: Jobs/Build.gitlab-ci.yml - template: Security/Container-Scanning.gitlab-ci.yml container_scanning: variables: CS_DEFAULT_BRANCH_IMAGE: $CI_REGISTRY_IMAGE/$CI_DEFAULT_BRANCH:$CI_COMMIT_SHA
3. 컨테이너 스캔 설정 사용자 지정
GitLab에서는 향상된 출력 및 특정 레지스트리와의 인증부터 더 세분화된 결과 제공에 이르기까지 특정 요구 사항에 맞게 컨테이너 스캔 방식을 조정할 수 있습니다.
예를 들어, 상세 출력을 활성화하려면 .gitlab-ci.yml 파일을 다음과 같이 수정하세요:
include: - template: Security/Container-Scanning.gitlab-ci.yml variables: SECURE_LOG_LEVEL: 'debug'
4. 원격 레지스트리의 이미지 스캔:
다음과 같은 구성을 사용하여 프로젝트 이외의 레지스트리에 위치한 이미지도 스캔할 수 있습니다:
include: - template: Security/Container-Scanning.gitlab-ci.yml container_scanning: variables: CS_IMAGE: example.com/user/image:tag
GitLab 컨테이너 스캐닝 설정은 자동화된 머지 요청부터 수동 구성까지 직관적이고 사용자 친화적인 경험입니다. GitLab은 강력한 스캐닝 도구를 통해 보안 검사를 개발자의 개발 워크플로에 통합하여, 현대적이고 안전한 소프트웨어 개발에 필수적인 요소로 자리매김했습니다.
GitLab 컨테이너 스캐닝 모범 사례
1. 스캐닝 도구 정기 업데이트
Trivy 및 Grype와 같은 스캐닝 도구는 새로운 취약점이 발생하자마자 이를 탐지하고 지원되는 배포판의 변경 사항과 호환성을 유지하기 위해 최신 상태로 유지하는 것이 중요합니다. 정기적인 업데이트를 통해 이를 보장할 수 있습니다.
2. 개발 초기 단계에서 스캐닝 통합하기
컨테이너 스캐닝을 개발 주기에 일찍 도입할수록 취약점을 더 빨리 식별하고 해결할 수 있습니다. GitLab 컨테이너 스캐닝을 지속적 통합(CI) (CI) 파이프라인에 포함시키면 코드 푸시 시마다 스캔이 자동으로 수행되어 개발 워크플로의 일부가 되고, 취약점 식별 및 해결 속도를 높이는 데 기여합니다.
3. 필요에 맞게 스캔 맞춤 설정하기
모든 프로젝트에 동일한 스캔이 필요한 것은 아닙니다. 프로젝트 요구 사항에 따라 스캔을 맞춤 설정하면(상세 수준, 특정 레지스트리 대상 지정, 변수 설정 등) 스캔 속도가 훨씬 빨라지고 효율성이 높아집니다. .gitlab-ci.yml 파일 내의 사용자 지정 기능을 활용하여 스캔을 정확하게 미세 조정하세요.
4. 스캔 보고서를 정기적으로 검토하고 조치하기
스캔을 실행하는 것만으로는 충분하지 않습니다. 발견된 사항을 검토하고 신속하게 처리해야 합니다. 컨테이너 스캔 보고서 아티팩트를 정기적으로 검토하고 체계적인 수정 조치를 병행하면 취약점을 신속하게 식별하고 적절하게 처리할 수 있습니다. 기존 개발 프로세스에 수정 워크플로를 통합하면 이 중요한 수정 작업에 도움이 될 수 있습니다.
GitLab 컨테이너 스캐닝을 통한 수정 워크플로
GitLab 컨테이너 스캐닝의 수정 워크플로는 컨테이너 이미지 취약점을 식별하고 효율적이며 체계적으로 해결하기 위해 설계된 여러 단계를 포함합니다. 일반적인 워크플로는 다음과 같습니다:
- 취약점 확인: GitLab은 컨테이너 스캐닝 기능과 Trivy 또는 Grype를 통한 보안 스캐닝을 제공합니다. 취약점이 발견되면 이 단계의 일환으로 모든 취약점을 상세히 기술한 포괄적인 보고서가 생성됩니다.
- 결과 분석: 이 단계에서는 컨테이너 스캐닝 보고서의 결과를 심층 검토하여 즉각적인 조치가 필요한 취약점의 심각도, 유형 및 원인을 상세히 파악해야 합니다. 즉각적인 해결이 필요한 문제를 우선순위로 지정합니다.
- 수정 작업 우선순위 지정: 이 평가를 바탕으로 문제를 적절히 우선순위화해야 합니다. 높은 우선순위 문제는 애플리케이션에 즉각적인 위협을 가하는 취약점에 집중하는 경향이 있으며, 영향도와 악용 용이성 같은 요소도 고려될 수 있습니다.
- 보완 계획 수립: 취약점 우선순위화 후 각 취약점을 해결하기 위한 효과적인 보완 계획을 수립해야 합니다. 이 계획에는 각 취약점을 효과적으로 완화하기 위한 조치들이 포함됩니다. 업데이트 설치, 수정 또는 변경, 코드 부분의 직접적인 수정 등이 포함될 수 있습니다.
- 수정 사항 적용: 계획을 수립한 후에는 GitLab 병합 요청을 통해 영향을 받는 코드베이스에 영향을 미치는 코드, 구성 설정 또는 종속성을 수정하는 시정 조치를 수행해야 합니다. 개발자, 보안 팀 및 기타 주요 관계자 간의 협력이 이 과정을 성공적으로 수행하는 데 종종 필수적입니다.
- 수정 사항 테스트: 수정 사항 적용 후에는 취약점을 성공적으로 해결하면서 새로운 문제를 생성하지 않았는지 확인하기 위한 추가 검증 작업이 필수적입니다. 컨테이너 이미지를 재스캔하거나 추가 테스트를 수행하면 수정 작업이 취약점을 성공적으로 제거했는지, 보안 구멍을 생성하지 않았는지 확인하는 데 도움이 될 수 있습니다.&
- 모니터링 및 지속적 개선: 수정 작업은 단번에 이루어지지 않습니다. 지속적인 모니터링, 스캔 및 수정을 통해 장기적인 실행 가능성을 보장해야 합니다. 반복적 접근 방식을 채택하면 장기적인 실행 가능성을 확보할 수 있습니다.
실제 사례 및 사용 사례
1. 금융
금융 애플리케이션의 보안은 최우선 과제입니다. 취약점 탐지를 위한 기존 방식은 적시 탐지에 종종 한계가 있습니다. 금융 앱의 지속적 통합/지속적 배포 파이프라인에 GitLab Container Scanning을 추가하면 실시간 검사 및 수정 작업이 가능해져, 전반적인 보안을 강화할 뿐만 아니라 업계 전반에 걸쳐 신뢰와 규정 준수를 촉진하는 훨씬 더 강력한 솔루션이 구현됩니다.
2. 의료
의료 시스템은 엄격한 규제 지침에 따라 보호해야 하는 민감한 데이터를 처리하지만, 수동 검사는 종종 번거롭고 오류가 발생하기 쉽습니다. 취약점 평가 및 지속적인 규정 준수 보고 프로세스의 일환으로 GitLab Container Scanning을 채택함으로써, 의료 기관은 GitLab Container Scanning을 간소화하여 침해로부터 스스로를 보호하는 동시에 보고 프로세스를 이전보다 훨씬 덜 복잡하게 만들 수 있습니다.
3. 기술 스타트업
기술 스타트업은 빠른 개발과 보안 기준 유지 사이의 균형을 맞추는 데 종종 어려움을 겪습니다. GitLab 컨테이너 스캐닝은 두 프로세스를 조화시키는 데 도움이 될 수 있습니다. 컨테이너화된 애플리케이션에 대한 지속적인 취약점 스캐닝은 보안 보호와 함께 더 빠른 개발 주기를 가능하게 하여, 스타트업이 강력한 보안 태세를 유지하면서도 혁신할 수 있는 민첩성을 제공합니다.
결론
GitLab 컨테이너 스캐닝은 현대 개발 환경에서 매우 중요한 부분이 되었으며, 조직이 컨테이너화된 애플리케이션 내 취약점을 빠르고 안정적으로 탐지할 수 있는 간단한 수단을 제공합니다. 개발 파이프라인에 원활하게 통합되고 개발 프로세스 초기에 취약점에 대한 가시성을 제공함으로써, 조직은 개발 프로세스에 보안을 구축하고 전반적인 보안 태세를 강화하면서 위험을 완화할 수 있습니다.
GitLab 컨테이너 스캐닝은 효과적인 DevSecOps 전략의 필수 요소로, 지속적인 보안 개선 환경을 조성합니다. 이 소중한 자산은 규정 준수나 고객 데이터 보호부터 애자일 개발 주기 유지, 산업이나 사용 사례 전반에 걸친 다양한 보안 요구 사항 충족에 이르기까지 혁신의 최전선에서 보안이 유지되도록 보장합니다.
GitLab 컨테이너 스캐닝 FAQ
GitLab 컨테이너 스캐닝은 CI/CD 과정에서 컨테이너 이미지에 대한 취약점 검사를 수행합니다. Trivy와 같은 스캐너를 사용하여 이미지가 프로덕션에 배포되기 전에 기본 OS 패키지에서 애플리케이션 종속성에 이르기까지 각 레이어를 검사합니다. GitLab의 컨테이너 스캐닝 CI 템플릿을 포함하거나 원클릭 머지 요청을 통해 활성화할 수 있습니다.
결과는 JSON 아티팩트 형태로 표시되며, 파이프라인의 보안 탭에서 위험한 CVE 및 만료된 OS 버전을 표시합니다.
기본 이미지와 OS 패키지의 알려진 CVE를 탐지하며, 활성화된 경우 언어별 라이브러리 결함(예: Java 또는 Python 패키지)도 감지합니다. 또한 보안 업데이트를 더 이상 받지 않는 지원 종료 운영 체제도 표시합니다. 기본 Trivy 스캐너는 NVD, 배포판 보안 추적기, GitLab 자체 권고 데이터베이스와 같은 권고 출처에서 정보를 가져와 취약점을 식별하고 CVSS 점수 및 악용 가능성에 따라 분류합니다.
GitLab의 내장 템플릿을 .gitlab-ci.yml.
include:ninclude:
- template: Jobs/Container-Scanning.gitlab-ci.yml
또는 프로젝트의 보안 > 보안 구성으로 이동하여 병합 요청으로 구성하기를 클릭한 후 병합하세요. 그러면 필요한 작업이 파이프라인에 삽입됩니다. Docker 이미지를 빌드하여 프로젝트 레지스트리에 푸시하는 경우 추가 스크립팅이 필요하지 않습니다.
파이프라인 실행 후 빌드 > 파이프라인을 열고 해당 실행을 선택한 다음 보안 탭을 선택하세요. 각 발견 사항의 심각도, CVSS 점수, 악용 가능성(EPSS) 및 수정 지침을 확인할 수 있습니다. 원본 스캔 보고서(gl-container-scanning-report.json)와 CycloneDX SBOM(gl-sbom-report.cdx.json)은 작업 아티팩트에서 확인할 수 있습니다.
Ultimate 티어에서는 병합 요청에 인라인 결과가 표시되며 기본 브랜치에 통합된 취약점 보고서도 확인할 수 있습니다.
예. 각 취약점 항목에는 문제점, 영향 및 패키지 업그레이드나 구성 변경과 같은 권장 수정 단계를 설명하는 설명이 포함됩니다. Ultimate 티어에서는 GitLab이 자동 수정 패치(Dockerfile 또는 패키지 매니페스트를 수정된 버전으로 업데이트하는 머지 요청)까지 생성할 수 있습니다.
리포지토리 루트에 vulnerability-allowlist.yml 파일을 생성하세요. 오탐으로 확인된 CVE ID(전역 또는 이미지별)를 나열합니다. 그러면 GitLab은 향후 스캔 보고서에서 해당 CVE를 제외하고 작업 로그에 '승인됨'으로 표시합니다. 이렇게 하면 보안 탭이 실제 위험에 집중할 수 있으며 진정한 문제를 숨기지 않습니다.

