使用Snyk漏洞扫描工具

教程
Kubernetes

介绍

Snyk旨在成为一款开发者安全平台，并考虑到灵活性。其主要目标是帮助您检测并修复应用程序源代码、第三方依赖、容器镜像和基础设施配置文件（例如 Kubernetes、Terraform 等）中的漏洞。

Snyk分为四个组件：

  1. Snyk Code – 帮助您查找并修复应用程序源代码中的漏洞。
  2. Snyk Open Source – 帮助您查找并修复应用程序依赖的任何第三方库或依赖项中的漏洞。
  3. Snyk Container – 帮助您查找并修复容器镜像或 Kubernetes 工作负载中的漏洞，这些工作负载用于您的集群。
  4. Snyk Infrastructure as Code – 帮助您查找并修复 Kubernetes 清单（也支持 Terraform、CloudFormation 和 Azure）中的配置错误。

Snyk可以以不同的方式运行：

  • 通过命令行界面使用Snyk CLI。这是在脚本和各种自动化中运行的首选方式，包括CI/CD流水线。
  • 在浏览器中作为。 Snyk还提供基于云的平台，您可以使用它来调查扫描报告、接收提示并采取必要的措施来修复报告的问题等。您还可以连接GitHub存储库并从Web界面执行扫描/审核。
  • 通过。这样，您可以在使用您喜爱的IDE（例如Visual Studio Code）进行开发时尽早发现问题。
  • 通过进行编程。 Snyk API对付费计划的客户可用，并允许您与Snyk进行程序化集成。

Snyk免费吗？

是的，工具是免费的，除了和Web UI的一些高级功能（例如高级报告）。每月您可以执行的测试数量也有限制。

有关更多信息，请参阅<定价计划>。

Snyk是开源的吗？

是的，工具和Snyk CLI肯定是开源的。 您可以访问以查找有关每个组件实现的更多详细信息。 云门户和所有付费功能，例如REST API实现，都不是开源的。

Snyk使用的另一个重要概念是目标和项目。

目标代表Snyk通过集成、CLI、UI或API扫描的外部资源。示例目标包括SCM存储库、Kubernetes工作负载等。

另一方面，项目定义了Snyk在给定目标上扫描的项。一个项目包括：

  • A scannable item external to Snyk.
  • 用于定义如何运行该扫描的配置。

您可以在这里了解更多关于Snyk核心概念的信息。

在本指南中，您将使用Snyk CLI对您的Kubernetes应用程序供应链（容器映像、Kubernetes YAML清单）执行风险分析。然后，您将学习如何采取适当的措施来纠正情况。最后，您将学习如何将Snyk集成到CI/CD流水线中，在开发的早期阶段扫描漏洞。

目录

先决条件

要完成本指南的所有步骤，您将需要：

  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. Kubectl CLI 用于与 Kubernetes 交互。按照这些 说明 使用 kubectl 和 doctl 连接到您的集群。
  4. Snyk CLI 与 Snyk 漏洞扫描仪进行交互。
  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 等。

您可以选择通过 --report 标志将结果推送到 Snyk Cloud Portal（或 Web UI）以便稍后存储和可视化扫描结果。

注意：不强制提交扫描结果到 Snyk 云门户。使用 Snyk 门户的一个重大优势是可见性，因为它为您提供了一个漂亮的仪表板，您可以在其中检查所有扫描报告，并查看 Kubernetes 供应链受到了多少影响。它还在长期内帮助您进行调查和提供补救建议。

Snyk CLI 分为几个子命令。每个子命令都专用于特定功能，例如：

  • 开源扫描 – 识别当前项目依赖项并报告发现的安全问题。
  • 代码扫描 – 报告在您的应用程序源代码中发现的安全问题。
  • 图像扫描 – 报告在容器镜像（例如 Docker）中发现的安全问题。
  • 基础架构即代码文件扫描 – 报告在由 Kubernetes、Terraform 等使用的配置文件中发现的安全问题。

在继续之前，请确保使用 Snyk 网页界面创建一个免费帐户。此外，还需要使用您的云账户对 snyk CLI 进行身份验证，以便某些命令/子命令能够正常工作（例如snyk code test）。

A few examples to try with Snyk CLI:

  1. 开源扫描：
# 从当前目录扫描项目代码
snyk test
# 从项目目录中扫描特定路径（请确保相应地替换`<>`占位符）
snyk test <path/to/dir>
  1. 代码扫描:
# 从当前目录扫描项目代码
snyk code test

# 从项目目录中的特定路径扫描（确保相应地替换 `<>` 占位符）
snyk code test <path/to/dir>
  1. 图像扫描：
# 先拉取debian docker镜像再进行扫描
snyk container debian

# 通过提供Dockerfile为扫描器提供更多上下文信息（确保相应地替换 `<>` 占位符）
snyk container debian --file=<path/to/dockerfile>
  1. 基础架构即代码扫描：
# 从当前目录扫描项目代码
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 [command] --help 访问。

请访问官方 snyk CLI 文档页面 获取更多示例。

步骤2 – 了解 Snyk Web UI

在您 注册 Snyk 账户、进行身份验证并登录到 Snyk 后，Web UI 将打开至仪表板，并提供向您展示设置步骤的向导：

  • 确定您想要在 Snyk 中监视的代码位置。
  • 定义您代码中要让 Snyk 扫描的项目。
  • 将 Snyk 连接到相关项目以扫描它们。
  • 审查您的 Snyk 扫描结果。

以下功能可通过 Web UI 访问：

请访问官方文档页面了解有关 Snyk Web UI 的更多信息。

了解 Snyk 严重级别

在每次扫描中，snyk 会验证您的资源是否存在潜在的安全风险以及每个风险如何影响您的系统。严重级别会应用于漏洞，以指示该漏洞在应用程序中的风险。

严重级别可以采用以下值之一：

  • 低：应用程序可能会暴露一些数据，允许进行漏洞映射，这可以与其他漏洞一起用于攻击应用程序。
  • 中：在某些条件下，可能允许攻击者访问您应用程序的敏感数据。
  • 高：可能允许攻击者访问您应用程序的敏感数据。
  • 临界：可能允许攻击者访问您应用程序的敏感数据并在其上运行代码。

常见漏洞评分系统（CVSS）确定漏洞的严重程度。Snyk使用CVSS框架版本3.1来传达漏洞的特性和严重程度。

下表显示了每个严重级别的映射：

Severity level CVSS score
Low 0.0 – 3.9
Medium 4.0 – 6.9
High 7.0 – 8.9
Critical 9.0 – 10.10

在本指南中，中等级别阈值被用作示例CI/CD管道的默认值。通常，您会希望首先评估高和严重的问题，但在某些情况下，中等级别也需要一些关注。在安全方面，作为一个经验法则，您通常会希望非常严格。

请访问官方文档页面了解更多关于严重级别的信息。

报告的安全问题的辅助修复

Snyk web UI提供的另一个有用功能是安全问题的修复辅助。这意味着您会收到有关如何修复每个由snyk扫描器发现的安全问题的建议。这非常重要，因为它简化了修复每个报告的安全问题所需执行的每个迭代的过程，并闭合了这个循环。

下图更好地说明了这个过程：

对于每个报告的问题，都有一个按钮，您可以单击该按钮并获得纠正辅助：

每个报告的主要流程都是相同的。这意味着，您单击显示详细信息按钮，然后采取建议的步骤来应用修复。

步骤 3 – 使用 Snyk 在 CI/CD 流水线中扫描 Kubernetes 配置漏洞

将安全合规性扫描工具嵌入到您的 CI/CD 流水线中，如何使您受益，并避免在生产环境中出现不愉快的情况？

一切都始于基础层，软件开发的起点。一般来说，您会希望为每个阶段使用专用的环境。因此，在开发的早期阶段，当应用程序代码经常更改时，您应该使用专用的开发环境（通常称为下游环境）。然后，应用程序在QA环境中变得越来越精细，在这里QA团队执行手动和/或自动化测试。接下来，如果应用程序获得了QA团队的批准，它就会晋升到上游环境，比如预发布环境，最终进入生产环境。在这个过程中，当应用程序从一个环境晋升到另一个环境时，一个专用的流水线会运行，不断扫描应用程序构件并检查严重程度。如果严重程度不符合特定阈值，流水线会立即失败，并且应用程序构件在早期阶段停止晋升到生产环境。

因此，安全扫描工具（例如，snyk）充当门卫，阻止不需要的构件从开发的早期阶段进入您的生产环境。同样，上游环境的流水线使用snyk来允许或禁止应用程序构件进入最终的生产阶段。

GitHub操作CI/CD工作流实施

在这一步中，您将学习如何通过GitHub工作流创建和测试一个集成了漏洞扫描的样例CI/CD流水线。要了解如何使用GitHub Actions与DigitalOcean Kubernetes的基础知识，请参考这个教程。

以下部分提供的流水线构建并部署了来自DigitalOcean kubernetes-sample-apps存储库的game-2048-example应用程序。

在高层概述中，kubernetes-sample-apps存储库中提供的game-2048 CI/CD工作流由以下阶段组成：

  1. 应用程序构建和测试阶段 – 构建主要应用程序构件并运行自动化测试。
  2. Snyk应用程序镜像扫描阶段 – 扫描应用程序 Docker 镜像以检测已知漏洞。它充当一个门，最终的流水线状态（通过/失败）取决于此步骤。如果失败，将发送Slack通知。
  3. 应用程序镜像构建和推送阶段 – 使用最新的 git 提交 SHA 构建并标记应用程序镜像。然后，将镜像推送到 DOCR。
  4. Snyk基础设施即代码（IAC）扫描阶段 – 扫描与应用程序相关的Kubernetes YAML清单中已知的漏洞。充当一个门禁，最终的流水线状态（通过/失败）取决于此步骤。如果失败，还会发送Slack通知。
  5. 应用程序部署阶段 – 将应用程序部署到Kubernetes（DOKS）。

下图说明了管道中每个作业以及与操作相关的步骤（仅显示相关配置）：

注：

  • 对于基于kustomize的项目，最好渲染最终清单以捕获和扫描所有内容（包括远程资源）。另一方面，很难识别哪个Kubernetes资源需要修补。这是因为生成的清单文件由要应用的所有资源组成。这就是kustomize的工作方式 – 它从每个叠加层收集所有配置片段，并将它们应用于基本构建最终的复合体。
  • 您还可以告诉Snyk扫描您存储kustomize配置的整个文件夹。这样，更容易确定在存储库中需要修复哪个资源。通过kustomize使用的远程资源需要在上游进行修复。此外，通过kustomize生成的Kubernetes秘密和ConfigMaps未被捕获。

如果某个特定的安全合规性水平未达到，您如何使流水线失败？

Snyk CLI为此提供了一个名为--severity-threshold的标志。该标志与每次扫描后计算的总体严重程度水平相关联。在Snyk的情况下，严重程度水平采用以下值之一：低、中、高或临界。您可以根据严重程度水平的值失败或通过管道，并在不满足条件时停止应用程序部署。

下图说明了本指南中使用的示例CI/CD管道的流程：

请按照以下步骤创建并测试在kubernetes-sample-apps GitHub存储库中提供的snyk CI/CD GitHub工作流：

  1. 分叉kubernetes-sample-apps GitHub存储库。
  2. 创建以下的 GitHub 加密密钥 用于您的 kubernetes-sample-apps 复制品（设置选项卡 -> 秘密 -> 操作）：
    • DIGITALOCEAN_ACCESS_TOKEN – 存储您的 DigitalOcean 帐户令牌。
    • DOCKER_REGISTRY – 存储您的 DigitalOcean Docker 注册表名称，包括端点（例如 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 – 存储您的 Slack 入站 Webhook URL 用于 Snyk 扫描通知。
  3. 导航至您的分支存储库的操作选项卡，并选择Game 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任务运行时，流水线将失败并停止。这是预期的，因为工作流程输入中使用的默认严重程度级别值为medium，不符合预期。您还应该收到关于工作流程运行的 Slack 通知的详细信息：

在接下来的步骤中，您将学习如何调查snyk扫描报告以修复问题、降低严重程度级别并通过流水线。

步骤4 – 调查 Snyk 扫描结果并修复报告的问题

每当未达到严重性级别阈值时，game-2048 GitHub 工作流将失败，并发送 Slack 通知附带额外详情。您还会收到发布到 GitHub 并在项目仓库的 Security 标签中可访问的安全报告。

game-2048 工作流执行两个安全检查：

  1. 容器镜像安全检查 – 使用 snyk-container-security-check 任务进行此检查。所使用的等效 snyk 命令是 – snyk container test <GAME-2048-IMAGE>:<TAG> --file=/path/to/game-2048/Dockerfile。
  2. Kubernetes 清单配置检查 – 使用 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. 运行Snyk安全检查以检查应用程序容器镜像和Dockerfile。此步骤使用snyk container test命令实现。扫描结果以GitHub SARIF格式导出。安全级别阈值通过–severity-threshold参数进行控制 – 如果工作流程是手动触发的，则将其设置为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 }} \

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

–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
在这种情况下，您会看到基本Docker镜像的一堆漏洞。单击每个以展开并查看更多详细信息：
为了完成调查并查看Snyk提供的建议，您需要检查主工作流程中snyk-container-security-check作业的输出：
注意：Snyk容器测试提供了将结果导出为SARIF格式的可能性，但它不知道如何将报告上传到Snyk云门户。另一方面，snyk容器监视器提供了将结果上传到Snyk云门户的可能性，但它无法导出SARIF。因此，本指南使用带有SARIF导出功能的snyk容器测试。遗憾的是，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"]

现在，打开你的 fork 的 game-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文件：

接下来，在左侧的严重程度子菜单中选中Medium复选框，以仅显示中等级别的问题：

然后，您可以检查每个报告的问题卡并查看详细信息。继续点击Container is running without root user control卡上的显示更多细节按钮-您将收到有关当前问题的更多详细信息以及有关如何解决它的重要提示：

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应用程序使用的index.html文件写入内容来检查游戏2048部署是否具有只读（不可变）文件系统：

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

输出类似于：

输出
/bin/bash: /public/index.html: 只读文件系统
命令以退出代码 1 终止

通过向游戏2048应用程序使用的index.html文件写入内容来检查游戏2048部署是否具有只读（不可变）文件系统：

输出类似于：

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 }}
      
      ...

检查容器是否以非root用户身份运行（应打印一个非零的整数 – 例如，1000）：

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

检查容器是否以非root用户身份运行（应打印一个非零的整数 – 例如，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 monitor 命令之后，您可以登录 Snyk Web UI 查看项目的最新快照和历史记录：

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

您还可以在构建和测试应用程序作业中测试和监视应用程序源代码。下面的片段显示了本指南中使用的 GitHub 工作流的示例实现：

接下来，您将定期收到关于项目新披露漏洞的 Slack 通知：

处理异常

在某些情况下，您可能不希望最终报告受到团队认为可以安全忽略的某些问题的影响。Snyk 提供了内置功能来管理异常并解决这种情况。

你可以在这里阅读更多有关这个功能的信息。

Snyk for IDEs

Snyk支持多种IDE，例如：

Eclipse插件。

JetBrains插件。

  • Visual Studio扩展。
  • Visual Studio Code扩展。
  • 以上插件将帮助您在开发的早期阶段检测和修复问题，从而消除生产系统中的 frustr, cost和安全漏洞。此外，它还有助于减少长期的迭代和人力投入。例如，对于您的CI/CD自动化报告的每个安全问题，您需要返回并修复代码中的问题，提交更改，等待CI/CD自动化再次运行，然后在失败的情况下重复。
  • 您可以从官方文档中了解有关这些功能的更多信息，详情请参阅Snyk for IDEs页面。
  • 步骤 5 – 自动触发 Snyk CI/CD 工作流程
  • 您可以通过取消注释 game-2048-snyk.yaml 文件顶部的以下行来设置工作流程在每次提交或 PR 到主分支时自动触发：
  • 编辑文件后，将更改提交到主分支，然后您就可以开始了。
  • 步骤 6 – 启用 Slack 通知
  • 您可以设置 Snyk 发送 Slack 提醒，通知您项目中发现的新漏洞以及可用的新升级或补丁。
  • 要设置它，您需要生成一个 Slack webhook。您可以通过 Incoming WebHooks 或创建自己的 Slack App 来完成此操作。生成 Slack Webhook URL 后，转到您的“管理组织”设置，输入 URL，然后单击 Connect 按钮：

Source:
https://www.digitalocean.com/community/developer-center/using-the-snyk-vulnerability-scanning-tool