[Github] Container Image 취약점 점검 Trivy[1/2]

2022년 11월 openssl 재단에서 엄청난 취약점이 발견되었다는 기사가 많이 나왔다.

 

취약점이 공개되기 이전에는 엄청난 취약점이라고 공포심 조장이 많았는데, 실제 취약점이 공개되고 난 다음에는 영향력도 크지 않고 유효한 취약점이 되기에는 많은 조건이 있기 때문에 사실 그만큼 위험성이 높은것은 아니었다.

KISA 인터넷 보호나라&KrCERT

 

취약점에 대한 기사를 보자마자 우리 회사 Container image에는 해당 취약점이 없을까? 현황 파악을 할 수 있을까? 하는 생각이 많았다.

근데 결론부터 말하면, 현재 회사에서는 개발/배포 과정에서 image에 대한 취약점 점검이 없었어서 취약점 점검을 위한 설계를 하였다.

 

취약점 점검을 위한 툴은 여러가지가 있으나, 내가 고려한 사항은 아래와 같다

1. 오픈소스를 사용할 것 -> 적용해야할 github repo가 많고, 비용이 많이 들기때문에 오픈소스를 먼저 고려하였다.
2. 대중성이 있을것 -> 대중성이 있다는것은 그만큼 취약점을 잘 식별해준다는것다고 생각했기 때문이다.
3. github action 또는 우리 회사 CI/CD pipline에 적용 가능할것 -> 사실 github action을 제공하면 가장 좋을것 같다

Image 취약점 점검 툴 비교

구글링을 해보고, 주변의 지인들 회사를 보면 아래 3가지를 가장 많이 사용하는것 같다.

그리고 나는 아래 사유로 인해 Trivy를 Image 취약점 점검 툴로 선택했다.

1. 가장 대중성이 높다 = 인기가 많다 = 취약점 점검을 잘한다.
2. os, library 나눠서 점검을 해주고 github action을 제공하고 있기 때문에 적용하기가 쉽다.
3. Image 취약점뿐 아니라, secret / k8s misconfiguration도 점검할 수 있고 확장성이 높다.

이름	특장점	비고
Trivy	오픈소스 대중적으로 편의성이 좋고, 성능이 좋다고 알려진 오픈소스 Github Action 제공 OS 패키지, Application 패키지 취약점 점검 가능 라이브러리, 현재 버전, 취약 버전, 설명 제공	DockerFile도 scan 가능 k8s cluster에 대해서도 misconf 점검 가능
Clair	오픈소스 OS 패키지만 점검 가능, Application 패키지 점검 불가 AWS ECR basic scan에서 사용 중 = 검증 된 데이터베이스 Github Action 미제공 → 코드 구현 필요	ECR Basic Scanning에서 사용하고 있음 교차 분석을 위해 다른 Scanning DB 사용
Anchore	오픈소스 OS 패키지만 점검 가능, Application 패키지 점검 가능 GIthub Action 제공

 

Trivy 적용 구조

Trivy는 기본적으로 Image가 있어야 점검할 수 있기에 본래의 ECR로 image push 이전에 imsi repo에서 점검하는것으로 했다.

Trivy 적용 대포 사례를 보니깐 imsi ECR 말고 private repo인 Harbor를 이용하기도 하는데, 굳이?라는 생각에 하지 않았다.

Trivy 적용 구조

Trivy 적용 방법

Github action을 제공하고 있기 때문에 적용하는 방법은 매우 간단하며, 자세한 내용은 아래 github에서 자세하게 확인할 수 있다.

GitHub - aquasecurity/trivy: Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories

      - name: scan image vulnerability
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'image'
          image-ref: '${{ inputs.registry }}/imsi_repo:latest'
          vuln-type: 'os,library'
          ignore-unfixed: true
          severity: 'CRITICAL,HIGH'
          security-checks: 'vuln'
          format: 'json'
          output: 'trivy-result.json'

사실 Trivy에서는 filesystem, image 점검이 가능하다.

image는 말 그대로 image가 있어야하며 해당 image의 패키지를 점검하는것이다.

그리고 filesystem 점검은 image 없이 배포되는 파일의 packege.json을 토대로 점검을 하는것 같다.

 

완전 비교를 해보진 않았지만, 두개의 차이가 있을까?한다. 그래서 Image 점검에 초점에 맞춰서 진행하였다.

 

그리고 Github뿐만 아니라 Bash shell로도 취약점 점검을 할 수 있다. 아래 코드는 Local PC에 Image를 보유하고 있어야한다.

for ECRREPO in $LIST_ECR_REPO
do 
    echo "######### $ECRREPO Scanning Start #########"
    echo "........ $ECRREPO Polling ECR Image ........"
    docker pull ${aws_account}.dkr.ecr.ap-northeast-2.amazonaws.com/${ECRREPO}:latest >& /dev/null
    echo "........ $ECRREPO Image Scan Start ........"
    trivy image ${aws_account}.dkr.ecr.ap-northeast-2.amazonaws.com/${ECRREPO}:latest --security-checks vuln --ignore-unfixed > ${ECRREPO}.txt
    echo "........ $ECRREPO Image Delete ........"
    docker rmi ${BASE}${ECRREPO}:latest >& /dev/null
    echo "........ $ECRREPO Scan Finish ........"
done
echo "GOOD SCAN"

 

Trivy 예외처리 방안

예외처리는 간단하다. github action의 yml 파일이 존재하는 위치에 .trivyignore 파일이 있으면 된다.

Trivy 예외처리 방안

Trivy 결과 확인

Trivy 결과는 위 코드에서 볼 수 있듯이 format으로 결과 포맷을 지정할 수 있다. 그리고 기본값을 table이다.

trivy table 결과 확인

그리고 json 형태로도 결과를 받을 수 있기 때문에 jq를 이용해서 내가 원하는 정보만 뽑아낼 수 있다.

최종적으로는 Github action 하단에 아래와 같이 Summary를 제공하기로 했다!!

- 아래의 Summary 제공은 $GITHUB_STEP_SUMMARY 변수로 데이터를 넣으면 된다.

github action summary

 

최종적으로는 github action에서 docker image build job이 있을 때, Trivy를 이용한다.

그리고 image 취약점 점검을 하고 이를 github action 하단에 summary를 보여준다.

 

이제 남은것은 개발팀에서 이를 보고, Image package를 변경을 독려하고 독촉하는것이다.

 

개발팀이 보면 개발하기도 바쁜데, 왜 갑자기 Image 취약점을 하고/갑자기 package 변경의 영향도를 파악하고 변경해야하는지 불만을 가질 수 있다. 그렇지만, Image의 취약점으로 인해 침해사고를 당한다면? 이를 누가 책임을 질것인가? 취약점 있는 Image를 그대로 서비스 하는것이 올바른가?에 대해 물어본다면 개발팀에서도 Image 취약점 점검을 하는것을 반대할것 강하게 부정할것 같지는 않다.

 

보안팀은 무엇을 하던지, 내부의 인원에게 반대를 많이 부딪힌다.. 그렇다고 안할수도 없고 적절한 근거와 개발 일정/내부 문화에 맞춰서 조금씩 조금씩 사람들의 인식 개선을 하고 고쳐나가야할것 같다!!

 

보안 담당자들 다들 힘내세요!!!