容器和基础设施安全扫描

近年来最著名的黑客事件之一是SolarWinds事件。SolarWinds是一家提供网络和基础设施监控系统管理工具的软件公司。攻击者设法在Orion软件中植入了一个后门，并将其推送到超过30,000个客户系统中，通过这个后门攻破了这些系统。受害者包括美国国土安全部和财政部（Oladimeji S., Kerner S. M., 2021）。

SolarWinds攻击被认为是一起软件供应链攻击，这对于安装了受感染版本的Orion客户来说是事实。但针对Orion的攻击远比单纯的感染依赖更新更为复杂；攻击者成功进入SolarWinds的网络，并在SolarWinds的构建服务器上安装了一种名为Sunspot的恶意软件。Sunspot通过替换源文件将后门Sunburst嵌入到Orion的构建中，而且没有产生任何构建失败或其他可疑输出（Eckels S., Smith J., & Ballenthin W., 2020）。

此次攻击展示了如果你的网络被入侵，内部攻击是多么致命，且显示了保护整个软件生产链条的重要性——不仅仅是代码、依赖关系和开发环境。构建服务器及所有参与软件生产的系统必须保持安全。

容器扫描

容器在今天的基础设施中扮演着重要角色。与传统的虚拟机（VM）相比，容器具有很多优势，但也有一些劣势。容器需要新的操作文化，而现有的流程和实践可能不完全适用（参见Souppaya M., Morello J., & Scarfone K., 2017）。

容器由许多不同的层组成，像软件依赖关系一样，这些层也可能引入漏洞。为检测这些漏洞，可以使用所谓的容器漏洞分析（CVA），也称为容器安全分析（CSA）。GitHub本身没有内置的CVA工具，但几乎所有相关的解决方案都能很好地与GitHub集成。

一个非常流行的开源容器镜像和文件系统漏洞扫描器是Anchore的grype（https://github.com/anchore/grype/）。它非常容易集成到GitHub Actions工作流中：

- name: Anchore Container Scan
  uses: anchore/scan-action@v3.2.0
  with:
    image: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
    debug: true

另一个CVA扫描器是Clair（https://github.com/quay/clair），它也是一个开源解决方案，用于对Docker和Open Container Initiative（OCI）容器进行静态漏洞分析。Clair可以作为容器运行，并将扫描结果存储在Postgres数据库中。详细文档请见：https://quay.github.io/clair/

此外，还有一些商业容器扫描器，通常是更全面安全平台的一部分。例如，Aqua的Container Security（https://www.aquasec.com/products/container-security/）。Aqua平台（https://www.aquasec.com/aqua-cloud-native-security-platform/）是一个为容器化、无服务器和基于虚拟机的应用程序设计的云原生安全平台。Aqua既可以作为SaaS服务，也可以作为自托管版使用。

另一个例子是WhiteSource（https://www.whitesourcesoftware.com/solution-for-containers/）。他们在GitHub市场提供了GP Security Scan Action，用于在将镜像推送到GitHub Packages之前扫描镜像（https://github.com/marketplace/actions/gp-security-scan）。

这两者都是非常好的解决方案，但由于它们价格较高且与GitHub的高级安全功能有较大重叠，因此在这里不再详细介绍。

基础设施策略

并非所有与基础设施相关的内容都是容器，尤其是在云环境中，安全性需要考虑的方面远不止这些。

如果你使用云服务提供商，值得关注他们的安全产品。例如，Microsoft Azure 提供了 Microsoft Defender for Cloud，这是一款云安全姿态管理（CSPM）工具，旨在保护跨多云和混合环境的工作负载，并发现云配置中的弱点（https://azure.microsoft.com/en-us/services/defender-for-cloud）。它支持 Microsoft Azure、AWS、Google Cloud Platform 和本地工作负载（使用 Azure Arc）。Microsoft Defender for Cloud 中的一些功能对 Microsoft Azure 用户免费，但并非所有功能都免费。

Microsoft Azure 还提供了 Azure Policy（https://docs.microsoft.com/en-us/azure/governance/policy/），这是一项帮助你执行标准和评估合规性的服务。它允许你将某些规则定义为策略定义，并按需评估这些策略。以下是一个在 GitHub Action 工作流中每天早上8点执行的示例：

on:
  schedule:
    - cron: '0 8 * * *'
jobs:
  assess-policy-compliance:
    runs-on: ubuntu-latest
    steps:
      - name: Login to Azure
        uses: azure/login@v1
        with:
          creds: ${{secrets.AZURE_CREDENTIALS}}
      - name: Check for resource compliance
        uses: azure/policy-compliance-scan@v0
        with:
          scopes: |
            /subscriptions/<subscription id>
            /subscriptions/<...>

结合 AI 驱动的安全信息和事件管理（SIEM）系统 Microsoft Sentinel（https://azure.microsoft.com/en-us/services/microsoft-sentinel），这是一个非常强大的安全工具链。但是否适合你，取决于你的具体设置。如果你的主要云服务提供商不是 Azure，那么你选择 CSPM 和 SIEM 的决策可能会完全不同，AWS Security Hub 可能会对你更有意义。

一个很好的开源工具来保障基础设施即代码（IaC）安全的是 Checkov（https://github.com/bridgecrewio/checkov）。它是一款静态代码分析工具，用于扫描使用 Terraform、Terraform plan、CloudFormation、AWS Serverless Application Model（SAM）、Kubernetes、Dockerfile、Serverless 或 ARM 模板配置的云基础设施，并检测安全和合规性错误配置。它包含了 1,000 多个针对不同平台的内置策略。它在 GitHub 中的使用非常简单，只需要在你的工作流中使用 Checkov GitHub Action（https://github.com/marketplace/actions/checkov-github-action），并指向包含你基础设施代码的目录：

- name: Checkov GitHub Action
  uses: bridgecrewio/checkov-action@master
  with:
    directory: .
    output_format: sarif

此操作支持 SARIF 输出，并可以与 GitHub 的高级安全集成：

- name: Upload SARIF file
  uses: github/codeql-action/upload-sarif@v1
  with:
    sarif_file: results.sarif
  if: always()

运行结果将在 Security | Code scanning alerts 下显示（见图15.1）：

Figure 1. 图15.1 – 在 GitHub 中查看 Checkov 结果

Checkov 非常适合检查你的基础设施即代码（IaC），但它不能检查你的基础设施是否有变化。不过，如果你使用像 Terraform 或 ARM 这样的解决方案，可以定期在工作流中运行验证，以确保基础设施没有发生意外更改。