Snyk 컨테이너 특정 CI/CD 전략

파이프라인에 Snyk 컨테이너를 구현하기 가장 좋은 시기는 컨테이너 이미지가 빌드된 후, 즉 docker build와 동등한 작업을 실행한 후이며, 이미지가 레지스트리(docker push)로 푸시되거나 실행 중인 인프라(helm install, kubectl apply 등)에 배포되기 전입니다.

일반적으로 컨테이너 빌드-테스트-배포 파이프라인을 실행하는 방법은 빌드 에이전트에서 Docker 데몬을 사용할 수 있는지 여부에 따라 달라집니다.

Docker 데몬을 사용할 수 있는 경우 파이프라인 실행

다음과 같은 상황에서 Snyk이 도움이 될 수 있습니다.

• Jenkins와 같은 빌드 도구를 Docker가 기본적으로 설치된 호스트에서 직접 실행하고 있습니다.

• 파이프라인 작업이 Docker 소켓[/var/run/docker.sock]이 호스트에 바인딩 마운트된 컨테이너 내에서 실행됩니다.

• Docker-inside-Docker 설정을 실행하고 있습니다.

Snyk은 다음과 같이 도움을 줄 수 있습니다.

• snyk container test $IMAGE_NAME을 실행하면 Snyk은 로컬 데몬 저장소에서 해당 이미지를 찾고, 이미지가 없으면 업스트림 레지스트리에서 이미지를 다운로드하기 위해 docker pull과 동등한 작업을 사용합니다.

• 레지스트리 인증의 경우 Snyk은 이미 docker login과 같은 것으로 구성한 자격 증명을 사용합니다.

• 명령줄에서 --file=Dockerfile을 지정하여 이미지 취약점 결과를 이미지를 빌드한 Dockerfile에 연결하여 인라인 수정 권고 및 대체 기본 이미지 제안을 받을 수 있습니다.

Docker 데몬을 사용할 수 없는 경우 파이프라인 실행

다음과 같은 상황에서 Snyk이 도움이 될 수 있습니다.

• 각 빌드 작업을 컨테이너화하지만 보안 및 성능상의 이유로 Docker 소켓을 마운트하지 않습니다.

• 파이프라인 작업이 호스트 또는 클러스터 전체에 분할되어 있으며 중앙 볼륨 또는 중간 레지스트리/객체 저장소를 통해 아티팩트가 전달되는 데 의존합니다.

• OCI 규격 컨테이너 이미지만 사용하는 생태계에서만 작업합니다.

Snyk은 다음과 같이 도움을 줄 수 있습니다.

• snyk container test docker-archive:archive.tar 또는 snyk container test oci-archive:archive.tar를 실행하여 Docker 데몬에 의존하지 않고 Docker 또는 OCI 형식으로 tar 형식 컨테이너 이미지에 대한 Snyk 취약점 결과를 얻습니다.

• tar 아카이브는 빌드 프로세스에서 docker save와 동등한 작업을 사용하여 생성하여 공유 볼륨 또는 객체 저장소에 저장할 수 있습니다. 이는 다른 종속성 없이 Snyk 바이너리를 실행하는 빌드 에이전트 컨테이너에서 액세스할 수 있습니다.

컨테이너 이미지 통합을 위한 권장 사항

• CI 중에 컨테이너 이미지와 통합하는 방법에 관계없이 Snyk 오픈소스(애플리케이션 SCA) 테스트와 별도의 빌드 단계로 Snyk 컨테이너 스캔을 실행하십시오. 이렇게 하면 빌드 실패를 컨테이너 또는 OS 계층 또는 애플리케이션 계층 내의 취약점으로 격리할 수 있습니다. 또한 컨테이너화된 빌드 작업을 더 쉽게 수행할 수 있습니다.

• --fail-on 및 --severity-threshold와 같은 CLI 옵션을 사용하여 빌드 작업의 실패 상태를 사용자 지정하십시오. 더 고급 테스트의 경우 --json을 사용하여 전체 취약점 보고서를 포함하는 JSON 파일을 생성하고 JSON 데이터를 기반으로 자체 빌드 실패 상태를 설정할 수 있습니다.

• --exclude-base-image-vulns를 전달하여 컨테이너의 기본 이미지(즉, Dockerfile의 FROM 줄에 지정한 이미지)에서 발생하는 취약점이 아닌 사용자 계층에서 도입된 취약점만 보고하십시오.

• snyk container test 다음에 snyk container monitor를 실행하거나 플러그인 설정에서 모니터 확인란을 선택하여 Snyk UI 내에서 컨테이너의 자재 명세서 기록을 유지하고 매일 새로운 취약점을 사전에 모니터링하십시오. 이는 새 릴리스를 프로덕션 환경으로 푸시할 때 유용합니다. --project-name을 사용하여 릴리스에 대한 고유 식별자를 지정하여 프로덕션 컨테이너가 빌드 프로세스의 다른 컨테이너와 별도로 추적되도록 할 수 있습니다.