Snyk 취약성 스캐닝 도구 사용 방법

소개

Snyk는 개발자 보안 플랫폼으로 설계되었으며 유연성을 염두에 두고 만들어졌습니다. 그 주요 목표는 응용 프로그램 소스 코드, 타사 종속성, 컨테이너 이미지 및 인프라 구성 파일(예: Kubernetes, Terraform 등)에서 취약점을 감지하고 수정하는 데 도움을 주는 것입니다.

Snyk는 네 가지 구성 요소로 나뉩니다:

1. Snyk Code – 응용 프로그램 소스 코드에서 취약점을 찾고 수정하는 데 도움을 줍니다.
2. Snyk Open Source – 응용 프로그램이 의존하는 모든 타사 라이브러리나 종속성의 취약점을 찾고 수정하는 데 도움을 줍니다.
3. Snyk Container – 클러스터에서 사용되는 컨테이너 이미지나 Kubernetes 워크로드의 취약점을 찾고 수정하는 데 도움을 줍니다.
4. Snyk Infrastructure as Code – Kubernetes 매니페스트(테라폼, CloudFormation 및 Azure도 지원됨)에서 구성 오류를 찾고 수정하는 데 도움을 줍니다.

Snyk는 다양한 방식으로 실행할 수 있습니다:

• 명령 줄 인터페이스를 통해 Snyk CLI를 사용합니다. 이는 스크립트 및 다양한 자동화 작업(포함하여 CI/CD 파이프라인) 내에서 실행하는 선호하는 방법입니다.
• 브라우저에서는 Snyk Web UI를 사용합니다. Snyk는 클라우드 기반 플랫폼을 제공하며 여기에서는 스캔 보고서를 조사하고 힌트를 받아들이고 보고된 문제를 해결하는 등의 작업을 수행할 수 있습니다. 또한 GitHub 저장소를 연결하고 웹 인터페이스에서 스캔/감사를 수행할 수도 있습니다.
• IDE 플러그인을 통해. 이렇게하면 즐겨 사용하는 IDE(예: Visual Studio Code)를 사용하여 개발하는 동안 문제를 조기에 발견할 수 있습니다.
• 프로그래밍 방식으로, Snyk API를 통해. Snyk API는 유료 요금제를 사용하는 고객에게 제공되며 Snyk와 프로그래밍 방식으로 통합할 수 있습니다.

Snyk는 무료입니까?

네, 도구는 무료이지만 Snyk API 및 웹 UI의 일부 고급 기능(고급 보고서와 같은)은 제외됩니다. 또한 월별로 수행할 수 있는 테스트 횟수에 제한이 있습니다.

자세한 내용은 요금제를 참조하십시오.

Snyk는 오픈 소스입니까?

네, 도구 및 Snyk CLI는 확실히 오픈 소스입니다. 각 구성 요소 구현에 대한 자세한 내용은 Snyk GitHub 홈페이지에서 확인할 수 있습니다. 클라우드 포털 및 나머지 API 구현과 같은 모든 유료 기능은 오픈 소스가 아닙니다.

Snyk이 사용하는 또 다른 중요한 개념 세트는 Targets(대상)과 Projects(프로젝트)입니다.

Targets는 통합, CLI, UI 또는 API를 통해 Snyk가 스캔한 외부 리소스를 나타냅니다. 예시 타겟으로는 SCM 저장소, Kubernetes 워크로드 등이 있습니다.

반면에 프로젝트는 주어진 타겟에서 Snyk가 스캔하는 항목을 정의합니다. 프로젝트에는 다음이 포함됩니다:

• A scannable item external to Snyk.
• 스캔을 실행하는 방법을 정의하는 구성.

Snyk 핵심 개념에 대해 더 읽어보려면 여기를 참조하십시오.

이 안내서에서는 Snyk CLI를 사용하여 Kubernetes 애플리케이션 공급망(컨테이너 이미지, Kubernetes YAML 매니페스트)에 대한 위험 분석을 수행한 다음, 상황을 해결하기 위한 적절한 조치를 취하는 방법을 배우게 됩니다. 마지막으로, 개발 초기 단계에서 취약점을 검사하기 위해 CI/CD 파이프라인에 Snyk를 통합하는 방법을 배우게 될 것입니다.

목차

• 소개
• 요구 사항
• 단계 1 – Snyk CLI 알아보기
• 단계 2 – Snyk 웹 UI 알아보기
  • Snyk 심각도 수준 이해
  • 보고된 보안 문제에 대한 지원된 개선
• 단계 3 – CI/CD 파이프라인에서 Kubernetes 구성 취약점을 스캔하는 데 Snyk 사용하기
  • GitHub Actions CI/CD 워크플로우 구현
• 단계 4 – Snyk 스캔 결과 조사 및 보고된 문제 수정
  • 컨테이너 이미지 취약점 조사 및 수정
  • Kubernetes Manifest 취약점 조사 및 수정
  • 정기적으로 프로젝트 모니터링
  • 예외 처리
  • IDE용 Snyk
• 단계 5 – Snyk CI/CD 워크플로 자동 트리거
• 단계 6 – Slack 알림 활성화
• 결론
• 추가 자료

필수 조건

이 안내서의 모든 단계를 완료하려면 다음이 필요합니다:

1. A working DOKS cluster running Kubernetes version >=1.21 that you have access to. For additional instructions on configuring a DigitalOcean Kubernetes cluster, see: How to Set Up a DigitalOcean Managed Kubernetes Cluster (DOKS).
2. A DigitalOcean Docker Registry. A free plan is enough to complete this tutorial. Also, make sure it is integrated with your DOKS cluster as explained here.
3. Kubernetes 상호 작용을 위한 Kubectl CLI. 이 지침을 따라 kubectl과 doctl을 사용하여 클러스터에 연결합니다.
4. Snyk 취약점 스캐너와 상호 작용하기 위한 Snyk CLI.
5. A free Snyk cloud account account used to periodically publish scan results for your Kubernetes cluster to a nice dashboard. Also, the Snyk web interface helps you with investigations and risk analysis. Please follow How to Create a Snyk Account documentation page.
6. A Slack workspace you own, and a dedicated Slack app to get notified of vulnerability scan issues reported by Snyk.

단계 1 – Snyk CLI 알아보기

snyk 명령줄 인터페이스를 통해 취약점을 수동으로 스캔할 수 있습니다. Snyk CLI는 다양한 스크립트 및 자동화에 사용할 수 있도록 설계되었습니다. 실제 예로는 Tekton, Jenkins, GitHub Workflows 등 다양한 도구를 사용하여 구현된 CI/CD 파이프라인에서 사용됩니다.

Snyk CLI가 호출되면 즉시 스캔 프로세스가 시작되고 특정 형식으로 문제를 보고합니다. 기본적으로 표준 출력 또는 콘솔을 사용하여 요약 테이블을 출력합니다. Snyk는 JSON, HTML, SARIF 등 다른 형식의 보고서를 생성할 수도 있습니다.

결과를 나중에 스캔 결과를 저장하고 시각화하기 위해 Snyk 클라우드 포털 (또는 웹 UI)로 결과를 전송할 수 있습니다. 이를 위해 --report 플래그를 사용할 수 있습니다.

Snyk CLI는 여러 하위 명령으로 나뉩니다. 각 하위 명령은 특정 기능에 dedic되어 있습니다.

• 오픈 소스 스캐닝 – 현재 프로젝트 종속성을 식별하고 발견된 보안 문제를 보고합니다.
• 코드 스캐닝 – 응용 프로그램 소스 코드에서 발견된 보안 문제를 보고합니다.
• 이미지 스캐닝 – 컨테이너 이미지(예: Docker)에서 발견된 보안 문제를 보고합니다.
• 인프라스트럭처 코드 파일 스캐닝 – Kubernetes, Terraform 등에서 사용되는 구성 파일에서 발견된 보안 문제를 보고합니다.

계속하기 전에 Snyk 웹 UI를 사용하여 무료 계정을 만드십시오. 또한, 몇 가지 명령/하위 명령이 작동하려면 snyk CLI를 클라우드 계정과 인증해야 합니다(예: snyk code test).

A few examples to try with Snyk CLI:

1. 오픈 소스 스캐닝:

# 현재 디렉터리에서 프로젝트 코드를 스캔합니다
snyk test
# 프로젝트 디렉터리에서 특정 경로를 스캔합니다 (`<>` 자리 표시자를 적절히 대체하세요)
snyk test <path/to/dir>

2. 코드 스캐닝:

# 현재 디렉토리에서 프로젝트 코드를 스캔합니다
snyk code test

# 프로젝트 디렉토리에서 특정 경로를 스캔합니다 (`<>` 플레이스홀더를 적절히 대체하세요)
snyk code test <path/to/dir>

3. 이미지 스캔:

# 데비안 도커 이미지를 먼저 끌어와서 스캔합니다
snyk container debian

# Dockerfile을 제공하여 스캐너에 대한 더 많은 컨텍스트를 제공합니다 (`<>` 플레이스홀더를 적절히 대체하세요)
snyk container debian --file=<path/to/dockerfile>

4. 인프라스트럭처 코드 스캔:

# 현재 디렉토리에서 프로젝트 코드를 스캔합니다
snyk iac test

# 프로젝트 디렉토리에서 특정 경로를 스캔합니다 (`<>` 플레이스홀더를 적절히 대체하세요)
snyk iac test <path/to/dir>

# Kustomize 기반 프로젝트를 스캔합니다 (먼저 최종 템플릿을 렌더링한 다음 스캐너로 전달해야 합니다)
kustomize build > kubernetes.yaml
snyk iac test kubernetes.yaml

Snyk CLI는 사용 가능한 모든 옵션에 대한 도움말 페이지를 제공합니다. 아래 명령을 사용하여 주요 도움말 페이지를 출력할 수 있습니다:

snyk --help

출력은 다음과 유사합니다:

Output
CLI commands help
  Snyk CLI scans and monitors your projects for security vulnerabilities and license issues.

  For more information visit the Snyk website https://snyk.io

  For details see the CLI documentation https://docs.snyk.io/features/snyk-cli

How to get started
  1. Authenticate by running snyk auth
  2. Test your local project with snyk test
  3. Get alerted for new vulnerabilities with snyk monitor

Available commands
  To learn more about each Snyk CLI command, use the --help option, for example, snyk auth --help or 
  snyk container --help

  snyk auth
    Authenticate Snyk CLI with a Snyk account.

  snyk test
    Test a project for open source vulnerabilities and license issues.

Snyk CLI 명령(또는 하위 명령)마다 연결된 도움말 페이지가 있으며 다음과 같이 액세스할 수 있습니다: snyk [명령] --help.

더 많은 예제를 보려면 공식 snyk CLI 문서 페이지를 방문하세요.

단계 2 – Snyk 웹 UI 알아보기

Snyk 계정을 등록한 후 Snyk에 인증하고 로그인하면 웹 UI가 대시 보드로 열립니다. 설정 단계를 안내하는 위저드가 표시됩니다:

• Snyk에서 모니터링하려는 코드가 있는 위치 식별하기.
• Snyk가 스캔하길 원하는 코드 내의 프로젝트 정의하기.
• Snyk를 해당 프로젝트에 연결하여 스캔하기.
• Snyk 스캔 결과 검토하기.

다음 기능들이 웹 UI를 통해 사용할 수 있습니다:

• 대시 보드 탐색
• 보고서 조사
• 프로젝트 관리
• 통합 관리
• 그룹 또는 조직 구성원 관리
• Snyk 업데이트 보기
• 도움 받기
• 사용자 계정 관리

더 많은 정보를 얻으려면 공식 문서 페이지를 방문하여 Snyk 웹 UI를 확인하십시오.

Snyk 심각도 수준 이해

각 스캔 시, snyk는 잠재적인 보안 위험을 확인하고 각각의 시스템에 미치는 영향을 평가합니다. 취약성에는 위험을 나타내는 심각도 수준이 할당됩니다.

심각도 수준은 다음 중 하나의 값일 수 있습니다:

• 낮음: 응용 프로그램은 일부 데이터를 노출시켜 취약점 매핑이 가능하며, 다른 취약점과 함께 응용 프로그램을 공격하는 데 사용될 수 있습니다.
• 중간: 일부 조건 하에서 공격자가 응용 프로그램의 민감한 데이터에 액세스할 수 있을 수 있습니다.
• 높음: 공격자가 응용 프로그램의 민감한 데이터에 액세스할 수 있을 수 있습니다.
• 중대한: 공격자가 응용 프로그램의 민감한 데이터에 액세스하고 응용 프로그램에서 코드를 실행할 수 있을 수 있습니다.

일반적인 취약성 점수 시스템(CVSS)은 취약성의 심각도 수준을 결정합니다. Snyk는 취약성의 특성과 심각성을 전달하기 위해 CVSS 프레임워크 버전 3.1을 사용합니다.

아래 표는 각 심각성 수준의 매핑을 보여줍니다:

이 가이드에서는 예제 CI/CD 파이프라인에서 기본값으로 중간 수준 임계값을 사용합니다. 일반적으로 높은 및 심각한 문제를 먼저 평가하고 싶겠지만, 경우에 따라 중간 수준도 관심을 가질 필요가 있습니다. 보안과 일반적인 기준으로, 일반적으로 엄격하게 설정하고 싶을 것입니다.

자세한 내용은 공식 문서 페이지를 방문하십시오.

보고된 보안 문제에 대한 지원된 복구

Snyk 웹 UI에서 제공하는 또 다른 유용한 기능은 보안 문제 복구 지원입니다. 이것은 snyk 스캐너에서 발견된 각 보안 문제를 어떻게 해결할지에 대한 권장 사항을 받는 것을 의미합니다. 이는 각 보고된 보안 문제를 수정하는 데 필요한 각 반복 작업을 간소화하고 반복합니다.

아래 그림은 이 과정을 더 잘 설명합니다:

각 보고된 문제에는 해결 지원을 받을 수 있는 버튼이 있습니다.

각 보고된 문제에 대한 주요 절차는 동일합니다. 즉, 세부 정보 표시 버튼을 클릭한 다음 제안된 단계를 취하여 수정을 적용합니다.

단계 3 – CI/CD 파이프라인에서 Kubernetes 구성 취약점을 스캔하는 데 Snyk 사용

CI/CD 파이프라인에 보안 규정 스캐닝 도구를 포함시키고 제품 환경에서 불쾌한 상황을 피하는 방법은 무엇인가요?

모든 것은 소프트웨어 개발이 시작되는 기초 수준에서 시작됩니다. 일반적으로 각 단계마다 전용 환경을 사용하는 것이 좋습니다. 따라서 애플리케이션 코드가 매우 자주 변경되는 개발 초기 단계에서는 전용 개발 환경(보통 하위 환경이라고 함)을 사용해야 합니다. 그런 다음 QA 환경에서 애플리케이션이 점점 더 정제됩니다. 여기서 QA 팀은 수동 및/또는 자동 테스트를 수행합니다. 그 다음으로, 애플리케이션이 QA 팀의 승인을 받으면 스테이징과 같은 상위 환경으로 승급되고 마지막으로 프로덕션으로 승급됩니다. 애플리케이션이 한 환경에서 다른 환경으로 승급되는 이 프로세스에서는 전용 파이프라인이 계속해서 애플리케이션 아티팩트를 스캔하고 심각도를 확인합니다. 심각도가 특정 임계값을 충족하지 않으면 파이프라인이 즉시 실패하고 애플리케이션 아티팩트가 프로덕션으로의 승급이 초기 단계에서 중지됩니다.

따라서 보안 스캐닝 도구(e.g., snyk)는 개발 초기 단계부터 프로덕션 환경으로 불필요한 아티팩트의 진입을 차단하는 게이트키퍼 역할을 합니다. 마찬가지로, 상위 환경 파이프라인은 snyk를 사용하여 최종 프로덕션 단계로의 애플리케이션 아티팩트의 진입을 허용하거나 금지합니다.

GitHub Actions CI/CD Workflow 구현

이 단계에서는 GitHub 워크플로를 통해 통합된 취약점 스캐닝이 포함된 샘플 CI/CD 파이프라인을 생성하고 테스트하는 방법을 배우게 됩니다. DigitalOcean Kubernetes와 함께 Github Actions를 사용하는 기본 사항을 배우려면 이 튜토리얼을 참조하세요.

다음 섹션에 제공된 파이프라인은 DigitalOcean kubernetes-sample-apps 저장소에서 game-2048-example 애플리케이션을 빌드하고 배포합니다.

고수준 개요에서, kubernetes-sample-apps 저장소에서 제공하는 game-2048 CI/CD 워크플로는 다음 단계로 구성됩니다:

1. 애플리케이션 빌드 및 테스트 단계 – 주요 애플리케이션 아티팩트를 빌드하고 자동화된 테스트를 실행합니다.
2. Snyk 애플리케이션 이미지 스캔 단계 – 애플리케이션 도커 이미지를 알려진 취약점을 스캔합니다. 이는 게이트로 작동하며 최종 파이프라인 상태(통과/실패)가 이 단계에 의존합니다. 실패할 경우 Slack 알림이 전송됩니다.
3. 애플리케이션 이미지 빌드 및 푸시 단계 – 최신 git 커밋 SHA를 사용하여 애플리케이션 이미지를 빌드하고 태깅합니다. 그런 다음 이미지를 DOCR에 푸시합니다.
4. Snyk 인프라스트럭처 코드 (IAC) 스캔 단계 – 애플리케이션과 관련된 Kubernetes YAML 매니페스트에서 알려진 취약점을 스캔합니다. 이 단계에 대한 최종 파이프라인 상태 (통과/실패)는 이 단계에 종속됩니다. 실패하는 경우 Slack 알림도 전송됩니다.
5. 애플리케이션 배포 단계 – 애플리케이션을 Kubernetes (DOKS)에 배포합니다.

다음 다이어그램은 파이프라인에서 각 작업과 해당 작업에 대한 조치를 보여줍니다 (관련된 구성만 표시됨):

특정 보안 규정 수준이 충족되지 않았을 때 파이프라인을 어떻게 실패시키나요?

Snyk CLI는 이 목적을 위해 --severity-threshold라는 플래그를 제공합니다. 이 플래그는 각 스캔 후에 계산된 전체 심각도 수준과 관련이 있습니다. Snyk의 경우, 심각도 수준은 다음 값 중 하나를 취합니다: 낮음, 중간, 높음, 또는 중대한. 조건이 충족되지 않은 경우 심각도 수준 값에 따라 파이프라인을 실패 또는 통과하고 애플리케이션 배포를 중지할 수 있습니다.

아래 그림은이 안내서에서 사용되는 예 CI/CD 파이프라인의 흐름을 보여줍니다:

이 안내서에서 제공하는 snyk CI/CD GitHub 워크플로우를 만들고 테스트하려면 아래 단계를 따르십시오:kubernetes-sample-apps GitHub 저장소에서:

1. kubernetes-sample-apps GitHub 저장소를 포크하세요.
2. 다음 GitHub 암호화된 비밀을 생성하십시오. 복사(kubernetes-sample-apps -> 설정 탭 -> 비밀 -> 액션):
   • DIGITALOCEAN_ACCESS_TOKEN – 디지털오션 계정 토큰을 보유합니다.
   • DOCKER_REGISTRY – 엔드포인트를 포함한 디지털오션 도커 레지스트리 이름을 보유합니다 (예: registry.digitalocean.com/sample-apps).
   • DOKS_CLUSTER – DOKS 클러스터 이름을 보유합니다. 다음 명령을 실행하여 DOKS 클러스터 이름을 가져올 수 있습니다: doctl k8s cluster list --no-header --format Name.
   • SNYK_TOKEN – Snyk 사용자 계정 ID를 보유합니다 – 실행: snyk config get api를 실행하여 ID를 가져옵니다. 그렇게 하지 않으면 사용자 계정 설정 페이지에서 토큰을 검색할 수 있습니다.
   • SLACK_WEBHOOK_URL – Snyk 스캔 알림에 사용되는 Slack 수신 웹훅 URL을 보유합니다.
3. 포크된 저장소의 작업 탭으로 이동하여 게임 2048 Snyk CI/CD 예제 워크플로를 선택하십시오:
   
4. 워크플로 실행 버튼을 클릭하고 기본값을 유지하십시오:
   

A new entry should appear in the below list after clicking the Run Workflow green button. Select the running workflow to observe the pipeline progress:

snyk-container-security-check 작업이 실행될 때 파이프라인이 실패하고 중지됩니다. 이것은 기대된 동작입니다. 왜냐하면 워크플로 입력에 사용된 기본 심각도 수준 값인 중간이 기대에 미치지 못하기 때문입니다. 또한 워크플로 실행에 대한 세부 정보가 포함된 Slack 알림을 받아야 합니다:

다음 단계에서는 문제를 해결하고 심각도 수준을 낮추어 파이프라인을 통과시키기 위해 snyk 스캔 보고서를 조사하는 방법을 배우게 됩니다.

단계 4 – Snyk 스캔 결과 조사 및 보고된 문제 수정

심각도 수준 임계값이 충족되지 않을 때, game-2048 GitHub 워크플로우가 실패하고 Slack 알림이 추가 세부 정보와 함께 전송됩니다. 또한 GitHub에 보안 보고서가 게시되어 프로젝트 저장소의 보안 탭에서 액세스할 수 있습니다.

game-2048 워크플로우는 두 가지 보안 확인을 실행합니다:

1. 컨테이너 이미지 보안 확인 – 이를 위해 snyk-container-security-check 작업이 사용됩니다. 사용되는 동등한 snyk 명령은 다음과 같습니다 – snyk container test <GAME-2048-IMAGE>:<TAG> --file=/path/to/game-2048/Dockerfile.
2. 쿠버네티스 매니페스트 구성 오류 확인 – 이를 위해 snyk-iac-security-check 작업이 사용됩니다. 사용되는 동등한 snyk 명령은 다음과 같습니다 – snyk iac test /path/to/project/kubernetes/manifests.

따라서 심각도 수준을 낮추고 워크플로우를 통과하려면:

1. snyk-container-security-check 작업에서 보고된 문제를 조사하고 수정합니다.
2. snyk-iac-security-check 작업에서 보고된 문제를 조사하고 수정합니다.

그 다음에는 각각을 순서대로 해결하는 방법을 배우게 됩니다.

컨테이너 이미지 취약점 조사 및 수정

이 안내서에서 사용된 샘플 파이프라인은 game-2048 컨테이너 이미지와 관련된 Dockerfile을 snyk-container-security-check 작업을 통해 보안 검사를 실행합니다.

snyk-container-security-check 작업은 다음 단계를 실행합니다:

1. 로컬로 game-2048 애플리케이션 Docker 이미지를 빌드합니다. 이 단계는 docker-build-push GitHub 작업을 사용하여 구현됩니다.
2. 애플리케이션 컨테이너 이미지와 Dockerfile에 대한 Snyk 보안 검사를 실행합니다. 이 단계는 snyk container test 명령어를 사용하여 구현됩니다. 스캔 결과는 GitHub SARIF 형식으로 내보냅니다. 보안 수준 임계값은 수동으로 워크플로우를 트리거한 경우 snyk_fail_threshold 입력 매개변수로 설정되거나 워크플로우가 자동으로 실행되는 경우 SNYK_FAIL_THRESHOLD 환경 변수로 설정됩니다.
3. 스캔 결과 (SARIF 형식)는 애플리케이션 저장소의 보안 탭에 공개됩니다. 이 단계는 codeql GitHub 액션을 사용하여 구현됩니다.

아래 스니펙은 snyk-container-security-check 작업의 주요 논리를 보여줍니다:

- name: Build App Image for Snyk container scanning
  uses: docker/build-push-action@v3
  with:
    context: ${{ env.PROJECT_DIR }}
    push: false
    tags: "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}"

- name: Check application container vulnerabilities
  run: |
    snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
      --file=Dockerfile \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-container-scan.sarif
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk report SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-container-scan.sarif
    category: snyk-container-scan

–file=Dockerfile \

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–sarif –sarif-file-output=snyk-container-scan.sarif

보고된 문제를 해결하려면, 먼저 귀하의 kubernetes-sample-apps 저장소 포크의 보안 탭을 확인해야 합니다:

FROM node:18.6.0-slim AS builder
WORKDIR /usr/src/app
COPY . .
RUN npm install --include=dev
이 경우 베이스 도커 이미지에 대한 다수의 취약점이 표시됩니다. 자세한 내용을 보려면 각각을 클릭하여 확장하세요:
조사를 마치고 Snyk에서 제공하는 권장 사항을 확인하려면, 본 워크플로우의 snyk-container-security-check 작업 출력을 조사해야 합니다:
참고:Snyk 컨테이너 테스트는 결과를 SARIF 형식으로 내보낼 수 있지만, 보고서를 Snyk 클라우드 포털에 업로드하는 방법을 알지 못합니다. 반면, snyk container monitor는 결과를 Snyk 클라우드 포털에 업로드할 수 있지만, SARIF를 내보낼 수 없습니다. 따라서이 가이드는 SARIF 내보내기 기능이 있는 snyk container test를 사용합니다. SARIF 출력에 일부 권장 사항이 없는 경우가 있으므로, 작업 콘솔 출력에서도 권장 사항을 찾아야 합니다.
snyk-container-security-check 작업 출력에 따르면, Snyk는 기본 이미지 버전을 node:16-slim에서 node:18.6.0-slim(으)로 업데이트할 것을 권장합니다. 이 변경으로 고위험 문제가 제거되었으며, 다른 보고된 취약점 수도 70에서 44로 감소했습니다. 이는 거의 50%에 가까운 상당한 감소입니다!!!
ENV NODE_ENV=development
RUN npm run build

FROM node:18.6.0-slim
RUN npm install http-server -g
RUN mkdir /public
WORKDIR /public
COPY --from=builder /usr/src/app/dist/ ./
EXPOSE 8080
USER 1000
CMD ["http-server"]

이제 포크한 게임 2048 애플리케이션의 Dockerfile을 열고 FROM 지시문을 새 버전(node:18.6.0-slim)을 가리키도록 변경하세요:

#

# 빌드 모드는 NODE_ENV 환경 변수(개발 또는 프로덕션)를 통해 설정할 수 있습니다.

# 프로젝트 package.json 및 webpack.config.js를 참조하세요.

#

마지막으로, 변경 사항을 GitHub 저장소에 커밋하고 워크플로우를 다시 트리거하세요(기본값을 그대로 두세요). 이번에는 snyk-container-security-check 작업이 통과해야 합니다:

프로젝트의 보안 탭으로 이동하면 보고된 문제가 없어야 합니다.

앞으로 기본 이미지 취약점을 줄이기 위해 어떻게 확인하시겠습니까?

1. 가장 좋은 접근 방식은 최소한의 풋프린트를 갖춘 베이스 이미지를 사용하는 것입니다 – 베이스 이미지에 포함된 이진 파일이나 종속성이 적을수록 좋습니다. 또 다른 좋은 관행은 이 가이드의 정기적으로 프로젝트를 모니터링하십시오 섹션에서 설명된대로 프로젝트를 계속 모니터하는 것입니다.
2. 여전히 파이프라인이 실패하는 것을 알 수 있지만, 이번에는 snyk-iac-security-check 단계에서 실패합니다. 이는 응용 프로그램을 배포하는 데 사용되는 Kubernetes 매니페스트에 보안 문제가 있기 때문에 예상대로입니다. 다음 섹션에서는 이 상황을 조사하고 보고된 문제를 수정하기 위해 Snyk 보안 권장 사항을 적용하는 방법을 배우게 됩니다.

Kubernetes 매니페스트 취약점 조사 및 수정

- name: Check for Kubernetes manifests vulnerabilities
  run: |
    snyk iac test \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-iac-scan.sarif \
      --report
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk IAC SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-iac-scan.sarif
    category: snyk-iac-scan

파이프라인은 여전히 실패하며 snyk-iac-security-check 작업에서 중단됩니다. 이는 프로젝트의 보안 요구 사항을 충족시키지 못하는 기본 심각도 수준 값인 medium이 워크플로 입력에 사용되었기 때문에 예상된 결과입니다.

1. snyk-iac-security-check 작업은 Kubernetes 매니페스트 취약점 (또는 구성 오류)을 확인하고 다음 단계를 실행합니다:
2. Snyk 보안 검사는 game-2048-example 프로젝트 디렉터리에서 Kubernetes 매니페스트를 대상으로 합니다. 이 단계는 snyk iac test 명령을 사용하여 구현됩니다. 스캔 결과는 GitHub SARIF 형식으로 내보냅니다. 보안 수준 임계값은 –severity-threshold 인수를 통해 제어됩니다. 이 값은 워크플로가 수동으로 트리거된 경우 snyk_fail_threshold 입력 매개변수로 설정되거나, 워크플로가 자동으로 실행되는 경우 SNYK_FAIL_THRESHOLD 환경 변수로 설정됩니다. 마지막으로 –report 인수도 스캔 결과를 Snyk 클라우드 포털로 전송하는 데 사용됩니다.

스캔 결과 (SARIF 형식)는 애플리케이션 저장소의 보안 탭에 게시됩니다. 이 단계는 codeql GitHub 액션을 사용하여 구현됩니다.

snyk-iac-security-check 작업의 각 단계의 실제 구현이 아래 스니펫에 표시됩니다:

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–target-reference=${{ env.ENVIRONMENT }} \

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: game-2048
spec:
  replicas: 1
  selector:
    matchLabels:
      app: game-2048
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: game-2048
    spec:
      containers:
        - name: backend
          --sarif --sarif-file-output=snyk-iac-scan.sarif \
          image: registry.digitalocean.com/sample-apps/2048-game:latest
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 50Mi
            limits:
              cpu: 200m
              memory: 100Mi
          securityContext:
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - all

보고된 문제를 수정하려면 두 가지 옵션이 있습니다:

• Snyk 클라우드 포털을 사용하여 game-2048 프로젝트에 액세스하여 세부 정보를 확인합니다:
• 게임 2048 앱 저장소의 보안 탭을 사용하여 세부 정보를 확인하십시오:
  
• 어차피, 보고된 문제를 해결하는 방법에 대한 권장 사항을 받게 될 것입니다.
• 이 가이드에서는 보고된 보안 문제를 조사하기 위해 Snyk 클라우드 포털을 사용할 것입니다. 먼저 프로젝트 목록에서 game-2048-example 항목을 클릭한 다음 kustomize/resources/deployment.yaml 파일을 선택하십시오:

그런 다음, 왼쪽의 Severity 하위 메뉴에서 Medium 확인란을 선택하여 중간 수준 문제만 표시하십시오:

그런 다음 각 보고된 문제 카드를 검토하고 세부 정보를 확인할 수 있습니다. 계속해서 Container is running without root user control 카드에서 Show more details 버튼을 클릭하십시오. 현재 문제에 대한 자세한 정보와 해결 방법에 대한 중요한 힌트를 받게 될 것입니다:

A few final checks can be performed as well on the Kubernetes side to verify if the reported issues were fixed:

1. 각 카드에서 모든 정보를 수집한 후에는 리포지토리의 deployment.yaml 파일을 편집할 수 있습니다( game-2048-example/kustomize/resources 하위 폴더에 위치함). 수정 사항은 이미 적용되어 있으며, 파일에서 마지막 줄의 주석을 해제하면 됩니다. 최종 deployment.yaml 파일은 다음과 같아야 합니다:
2. readOnlyRootFilesystem – 컨테이너 이미지를 읽기 전용으로 실행합니다 (kubectl exec를 사용하여 컨테이너 내의 파일을 변경할 수 없음).

allowPrivilegeEscalation – allowPrivilegeEscalation을 false로 설정하면 컨테이너의 자식 프로세스가 부모보다 더 많은 권한을 얻지 못하도록 보장합니다.

capabilities.drop – 컨테이너를 보안성 높게 만들기 위해 실행에 필요한 최소한의 권한만 제공해야 합니다. 실제로는 기본적으로 모든 것을 삭제한 다음 필요한 기능을 점진적으로 추가합니다. 컨테이너 기능에 대해 더 알아보려면 여기를 참조하세요 here.

마지막으로, deployment.yaml 파일에 대한 변경 사항을 커밋하고 주요 브랜치로 푸시하세요. 수동으로 워크플로를 트리거한 후 이번에는 성공적으로 완료되어야 합니다:

또한 snyk 스캔 작업에서 녹색 Slack 알림을 수신해야 합니다. Snyk 포털 링크로 이동하여 최근 수정한 문제가 사라졌는지 확인하세요 – 중간 수준의 문제가 보고되지 않아야 합니다.

게임 2048 배포가 읽기 전용(불변) 파일 시스템인지 확인하려면 게임 2048 응용 프로그램에서 사용하는 index.html 파일에 쓰기를 시도합니다:

kubectl exec -it deployment/game-2048 -n game-2048 -- /bin/bash -c "echo > /public/index.html"

출력은 다음과 유사합니다:

출력
/bin/bash: /public/index.html: 읽기 전용 파일 시스템
명령은 종료 코드 1으로 종료되었습니다

게임 2048 배포가 읽기 전용(불변) 파일 시스템인지 확인하려면 게임 2048 응용 프로그램에서 사용하는 index.html 파일에 쓰기를 시도합니다:

출력은 다음과 유사합니다:

snyk-container-security-check:
    runs-on: ubuntu-latest
    needs: build-and-test-application

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      ...

      - name: Check application container vulnerabilities
        run: |
          snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile \
            --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
            --target-name=${{ env.PROJECT_NAME }} \
            --target-reference=${{ env.ENVIRONMENT }} \
            --sarif-file-output=snyk-container-scan.sarif
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

      - name: Monitor the application container using Snyk
        run: |
          snyk container monitor "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      
      ...

컨테이너가 루트가 아닌 사용자로 실행되는지 확인하십시오 (0이 아닌 정수 번호를 출력해야 함 – 예: 1000):

kubectl exec -it deployment/game-2048 -n game-2048 -- id -u

컨테이너가 루트가 아닌 사용자로 실행되는지 확인하십시오 (0이 아닌 정수 번호를 출력해야 함 – 예: 1000):

모든 확인이 통과되면 필요한 보안 권장 사항이 성공적으로 적용되었습니다.

build-and-test-application:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: npm install, build, and test
        run: |
          npm install
          npm run build --if-present
          npm test
        working-directory: ${{ env.PROJECT_DIR }}

      - name: Snyk code test and monitoring
        run: |
          snyk test ${{ env.PROJECT_DIR }}
          snyk monitor ${{ env.PROJECT_DIR }}
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

정기적으로 프로젝트를 모니터링하십시오

지금까지 구현한 취약성 스캔 자동화는 좋은 시작점이지만 완벽하지는 않습니다. 왜냐하면?

현재 접근 방식의 한 가지 문제는 이미 환경에 배포한 자산에 대한 새로운 문제가 언제 보고되는지 알 수 없다는 것입니다. 다시 말해, 보안 위험을 평가하고 CI/CD 자동화가 실행될 때 한 번에 문제를 해결하기 위한 조치를 취했습니다.

하지만 그 동안 새로운 문제가 보고되고, 귀하의 응용 프로그램이 다시 취약해질 수도 있습니다. Snyk는 모니터링 기능을 통해 이러한 상황을 극복할 수 있도록 도와줍니다. Snyk의 모니터링 기능은 계속해서 공개되는 새로운 취약점을 해결하는 데 도움을 줍니다. Snyk Slack 통합 기능(다음 단계 6 – Slack 알림 활성화에서 설명함)과 결합하면 프로덕션 환경에서 응용 프로그램에 영향을 줄 수 있는 새로 공개된 문제를 즉시 해결할 수 있습니다.

이 기능을 활용하려면 CI/CD 파이프라인의 배포 단계 전에 snyk monitor 명령을 사용하기만 하면 됩니다. 구문은 snyk test 명령과 매우 유사합니다(snyk CLI의 멋진 점 중 하나는 균일성을 염두에 두고 설계되었습니다). snyk monitor 명령은 스냅샷을 Snyk 클라우드 포털로 보내고, 거기서 프로젝트의 새로 공개된 취약점에 대해 알림을 받게 됩니다.

A more efficient approach is where you integrate vulnerability scan tools directly in your favorite IDE (or Integrated Development Environment). This way, you can detect and fix security issues ahead of time in the software development cycle.

GitHub 워크플로 자동화 관점에서, 취약점 테스트 후 snyk-container-security-check 작업에서 응용 프로그램 컨테이너를 모니터링할 수 있습니다. 아래 코드 조각은 이 가이드에서 사용된 파이프라인의 실제 구현을 보여줍니다(일부 단계는 명확성을 위해 생략되었습니다):

1. –file=${{ env.PROJECT_DIR }}/Dockerfile \
2. –severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
3. –target-name=${{ env.PROJECT_NAME }} \
4. –target-reference=${{ env.ENVIRONMENT }} \

–sarif-file-output=snyk-container-scan.sarif

–file=${{ env.PROJECT_DIR }}/Dockerfile

위의 코드 조각은 Snyk를 사용하여 애플리케이션 컨테이너 모니터링이라는 추가 단계를 보여줍니다. 여기서 실제 snyk 컨테이너 모니터가 실행됩니다.

snyk 모니터 명령이 실행된 후 Snyk 웹 UI에 로그인하여 프로젝트의 최신 스냅샷과 이력을 볼 수 있습니다:

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

빌드 및 테스트 애플리케이션 작업에서도 응용 프로그램 소스 코드를 테스트하고 모니터링할 수 있습니다. 아래 코드 조각은 이 가이드에서 사용된 GitHub 워크플로우의 예제 구현을 보여줍니다:

다음으로 프로젝트에 대해 새로 발견된 취약점에 대한 Slack 알림을 정기적으로 받게 됩니다.

예외 처리

팀에서 무시해도 안전하다고 생각하는 문제로 인해 최종 보고서가 영향을 받지 않길 원하는 상황이 있습니다. Snyk는 예외를 관리하고 이 상황을 극복하기 위한 내장 기능을 제공합니다.

이 기능에 대해 더 읽을 수 있습니다 여기.

IDE용 Snyk

Snyk는 다음과 같은 다양한 IDE를 지원합니다:

Eclipse 플러그인.

JetBrains 플러그인.

• Visual Studio 확장.
• Visual Studio Code 확장.
• 위의 플러그인은 개발 초기에 문제를 감지하고 수정하는 데 도움을 줍니다. 이로써 프로덕션 시스템에서의 당황, 비용 및 보안 결함을 제거할 수 있습니다. 또한 장기적으로 반복 및 인간의 노력을 줄이는 데 도움이 됩니다. 예를 들어, CI/CD 자동화에서 보고된 각 보안 문제마다 코드를 수정하고 변경 사항을 커밋하고 CI/CD 자동화를 다시 기다려야 하며 실패한 경우 반복해야 합니다.
• 공식 문서에서는 이러한 기능에 대해 더 자세히 읽을 수 있습니다 IDE용 Snyk 페이지에서.
• 단계 5 – Snyk CI/CD 워크플로우 자동으로 트리거하기
• 주요 브랜치에 대한 각 커밋이나 PR에 대해 워크플로우를 자동으로 트리거하도록 설정할 수 있습니다. 다음 줄을 game-2048-snyk.yaml 파일의 맨 위에 주석 처리 해제하십시오:
• 파일을 편집한 후 변경 사항을 주요 브랜치에 커밋하면 준비가 끝납니다.
• 단계 6 – Slack 알림 활성화
• Snyk를 설정하여 프로젝트에서 발견된 새 취약점 및 사용 가능한 새 업그레이드 또는 패치에 대한 Slack 알림을 보낼 수 있습니다.
• 설정하려면 Slack 웹훅을 생성해야 합니다. 들어오는 웹훅을 통해 또는 자체 Slack 앱을 만들어서 할 수 있습니다. Slack 웹훅 URL을 생성한 후 ‘조직 관리’ 설정으로 이동하여 URL을 입력하고 연결 버튼을 클릭하십시오: