Docker 이미지 및 코드 종속성을 위한 보안 스캔 인프라

F5 에코시스템 | 2020년 9월 21일

올해 초, 저희 팀은 PCI-DSS 및 SOC-2 규정 준수를 위해 기존 보안 도구와 소프트웨어 개발 및 테스트 관행을 강화해 달라는 요청을 받았습니다. 특히 강화가 필요했던 핵심 영역 중 하나는 K8s 기반 마이크로서비스와 몇몇 모놀리식 서비스에 대한 취약점 스캔이었습니다. 이에 따라 DevOps 팀은 소프트웨어 취약점 스캔을 구현하기 위해 여러 상용 도구와 오픈 소스 솔루션 중에서 적합한 것을 선택해야 했습니다. 이러한 도구는 모두 매우 유사한 작업을 수행합니다. 즉, 종속성(프로젝트 라이브러리 또는 OS 패키지)을 스캔하고 NIST의 NVD와 같은 취약점 데이터베이스와 대조합니다.

직접 구축할 것인가, 구매할 것인가?

자체 취약점 스캔 솔루션을 구축하는 데 사용할 수 있는 오픈 소스 도구가 몇 가지 있습니다. 또는 기본 스캔 기능에 더해 업무를 더욱 편리하게 해주는 추가 기능을 제공하는 상용 제품을 사용할 수도 있습니다. 예를 들면 다음과 같습니다:

프로젝트의 취약점을 빠르게 파악할 수 있는 유용한 대시보드
알림(이메일, Slack 등)
Git 저장소와의 통합(GitHub, GitLab)
다른 서비스와의 통합(Docker 레지스트리, Kubernetes)
프로젝트 관리 도구와의 통합(예: Jira)
취약한 종속성을 수정하기 위한 병합 요청 자동 생성
팀, 프로젝트 및 RBAC 지원

대부분의 상용 솔루션은 오탐과 미탐을 줄이고 더 유의미한 결과를 제공하기 위해 공개 취약점 데이터베이스를 자체 취약점 데이터베이스로 보완합니다. 하지만 이러한 상용 도구는 개발자 수가 늘어날수록 비용이 크게 증가합니다. 따라서 상용 솔루션을 구매하는 것과 기존 오픈 소스 도구를 활용해 자체 솔루션을 구축하는 것 중 어느 쪽이 더 나은지 고려해야 합니다.

처음에는 주어진 시간 제약을 고려할 때 상용 도구가 우리의 요구에 가장 적합하다고 판단했습니다. 하지만 업계 선도적인 상용 제품을 3개월 동안 배포하고 테스트한 결과, golang 지원 부족, 잘못된 종속성 선택 및 정상적으로 종료되지 않는 문제, 처음부터 빌드한 컨테이너와 일부 베이스 이미지를 사용해 빌드한 컨테이너 간의 문제 등 여러 어려움에 직면했습니다. 결국 해당 제품의 사용을 포기하고, 이용 가능한 오픈 소스 기술을 활용해 자체 도구를 구축하기로 했습니다.

이 글에서는 오픈 소스를 선택할 경우 탄탄하게 시작할 수 있는 기반을 제공해 드리겠습니다. 또한 글 마지막에는 바로 시작할 수 있도록 저희 오픈 소스 저장소 링크도 안내해 두었습니다!

무엇을 스캔해야 할까요?

기본적으로 취약점을 검사해야 할 대상은 두 가지입니다:

프로젝트의 코드 종속성(yarn.lock, Gopkg.lock 등)
Docker 이미지의 OS 종속성(Debian 패키지, Alpine 패키지 등)

향후 라이선스 검사나 정적 코드 분석과 같은 기능을 추가할 수 있지만, 이는 이 글에서 다루는 범위를 벗어납니다.

언제 스캔해야 할까요?

먼저 코드 또는 Docker 이미지 변경으로 인해 새로운 취약점이 발생하지 않도록 해야 하므로, 모든 병합 요청을 병합하기 전에 스캔하는 것이 좋습니다.

하지만 시간이 지나면서 새로운 취약점이 나타날 수 있으므로 주기적으로 검사해야 합니다. 또한 심각도도 달라질 수 있습니다. 처음에는 무시했던 낮은 심각도의 취약점이 새로운 공격 벡터나 익스플로잇이 발견됨에 따라 시간이 지나면서 치명적인 수준으로 바뀔 수 있습니다. 상용 도구는 마지막 검사 결과를 기억하고 새로운 취약점이 발견되면 알려 주지만, 오픈 소스 솔루션에서는 프로젝트의 master 브랜치를 기준으로 검사를 다시 실행하기만 하면 됩니다.

도구 선택

사용할 수 있는 오픈 소스 도구는 많지만, 사용하기 쉽고 활발히 개발되고 있으며 여러 프로젝트와 OS 유형을 스캔할 수 있다는 점에서 Trivy를 선택했습니다.

Trivy는 컨테이너 및 기타 아티팩트를 위한 간단하면서도 포괄적인 취약점 스캐너입니다. 소프트웨어 취약점이란 소프트웨어나 운영 체제에 존재하는 오류, 결함 또는 약점을 의미합니다. Trivy는 OS 패키지(Alpine, RHEL, CentOS 등)와 애플리케이션 종속성(Bundler, Composer, npm, yarn 등)의 취약점을 탐지합니다. Trivy는 사용하기도 쉽습니다. 바이너리만 설치하면 바로 스캔할 수 있습니다! 스캔하려면 컨테이너 이미지 이름과 같은 대상만 지정하면 됩니다.

간편하게 설치한 후 빌드된 Docker 이미지나 프로젝트 루트를 대상으로 로컬에서 실행할 수 있습니다. 또한 JSON 및 표 형식 등 다양한 출력 형식을 지원합니다:

안타깝게도 Trivy로 스캔할 수 없는 프로젝트(예: Golang)가 있어, 코드의 상당 부분이 Golang으로 작성된 관계로 OWASP Dependency-Check에 의존해야 했습니다.

Dependency-Check는 프로젝트의 종속성에 포함된 공개적으로 알려진 취약점을 탐지하는 소프트웨어 구성 분석(SCA) 도구입니다. 이 도구는 특정 종속성에 해당하는 공통 플랫폼 열거(CPE) 식별자가 있는지 확인합니다. 식별자가 발견되면 관련 CVE 항목으로 연결되는 보고서를 생성합니다.

보고서가 포함된 HTML 페이지와 JUnit 및 JSON 형식의 출력(그 외 몇 가지 형식도 포함)을 생성할 수 있습니다.

보고서 및 대시보드

이제 좀 더 흥미로운 내용에 가까워지고 있습니다 😊

DevOps 및 SRE 팀에서 이미 Elasticsearch + Kibana + Fluentd 를 사용하고 있었기 때문에, 기존 인프라를 활용해 보안 스캔의 JSON 출력을 분석하는 것이 자연스러운 선택이었습니다.

신뢰할 수 없는 인프라(CI 러너)에서 안전하게 보호된 Elasticsearch로 데이터를 전송할 방법만 찾으면 되었습니다. 이를 위해 중간에 메시지 큐를 두기로 했습니다. Fluentd에는 Amazon SQS에서 메시지를 읽는 in_sqs 플러그인이 있고 사용법도 간단하므로, 최종 아키텍처는 다음과 같습니다:

보안 스캔 아키텍처

데이터가 Elasticsearch에 도달하면 Kibana로 몇 가지 대시보드를 손쉽게 만들거나 Discover를 사용해 취약점을 조회하고 필요에 따라 모든 세부 정보를 확인할 수 있습니다.

취약점 개요

심각한 취약점 검색

취약점 해결

이제 스캔 기능과 보기 좋은 대시보드도 마련했는데, 다음에는 무엇을 해야 할까요? 개발자들이 이러한 대시보드를 정기적으로 확인할 것이라고 기대할 수는 없습니다. 그래서 심각도가 높음 이상인 문제가 발견되고 수정 방법이 제공되는 경우 CI가 실패하도록 하기로 했습니다. 이렇게 하면 개발자와 프로젝트 소유자가 책임을 지게 됩니다.

당연히 일부 CVE를 허용 목록에 추가하거나 프로젝트별로 이 기본 동작을 재정의할 수 있는 옵션이 필요했습니다. 그래서 Trivy 실행을 래핑하고 그 동작과 출력을 처리하는 자체 스캔 도구에서 사용할 보안 스캔 프로필 저장소를 만들었습니다.

이제 모든 개발자는 이 저장소에 병합 요청을 제출하여 예외 적용을 요청할 수 있습니다. kibana 프로젝트의 프로필 예시는 다음과 같습니다: