软件完整性保护方案之Sigstore

背景

SolarWinds Orion 软件更新包在2020年底被黑客植入后门,此次攻击事件波及范围极大,包括美国政府部门、关键基础设施以及多家全球500强企业,影响难以估计。如果用户能确认软件来源是可信的 SolarWinds 官方,这次事件可能可以避免。

为了确认软件的来源和构建方式,实现完整性保护,Linux基金会联合Red Hat、Google 和 Purdue 在 2021年3月推出了 Sigstore 代码签名项目,该项目致力于让开发人员签署发布时无感和让用户轻松验证。

Sigstore 在发布后快速发展,多个社区将 Sigstore 加入集成计划。2021年11月,Sigstore 加入了 OpenSSF(开源安全基金会),并且也受到了 Github 的青睐,12月份 Github Actions 集成了 Sigstore 对容器镜像的签名能力。2022年初,Shopify 发布了使用 Sigstore 改进 RubyGems 签名的 RFC。5月份,Kubernetes 在 1.24 版本中使用 Sigstore 无缝验证签名。

什么是Sigstore

Sigstore 是一款制品签名、验证的自动化工具,其优势在于对组件的自动化签名和验证实现,公开可审计日志服务的构建,和开源生态的支持。

软件完整性保护方案之Sigstore

Sigstore 由 Fulcio,Rekor 和 Cosign 三个主要组件组成。

Fulcio,证书颁发机构,根据 OIDC 身份颁发证书,且只能签署少于 20 分钟的短期证书。OIDC 是基于 OAuth 2.0 的认证+授权协议,用于用户身份认证,安全的暴露用户数据给第三方,可使用 Github、Google 等账号为 Fulcio 提供认证。

Rekor,完全公开日志,使用 Trillian (提供仅增加日志模式的功能,是 Certificate Transparency 思想的概括和扩展)作为防篡改的日志服务,记录验证签名有效性的证据,提供基于 RESTful API的用于存储和验证签名的服务。

Cosign,签名客户端,为容器镜像或制品(artifact,如可执行文件)提供签名、验证和存储支持。签名会写入到如下支持的 OCI 注册表(Oracle云基础设施容器注册表,是一种由 Oracle 管理的 Docker 注册表服务,可以安全的存储和共享容器映像。可用 Docker 命令和 API 轻松推送和拉取 Docker 映像。),并且容器镜像和制品也可以存储在注册表中。

  • AWS Elastic Container Registry
  • GCP’s Artifact Registry and Container Registry
  • Docker Hub
  • Azure Container Registry
  • JFrog Artifactory Container Registry
  • The CNCF distribution/distribution Registry
  • GitLab Container Registry
  • GitHub Container Registry
  • The CNCF Harbor Registry
  • Digital Ocean Container Registry
  • Sonatype Nexus Container Registry
  • Alibaba Cloud Container Registry

Sigstore 中各组件的工作流程如下图:

软件完整性保护方案之Sigstore
  1. 开发人员通过 OIDC(Google、Github、Mircosoft 等账号)进行身份认证
  2. 认证通过后,Fulcio 给开发者颁发关联邮箱身份的短期证书,也同步给 Rekor
  3. 开发人员使用对应的短期密钥对制品进行签名,并发布制品,会将签名和验证证据同步给 Rekor
  4. 使用者在使用制品前可以通过 Cosign 使用 Rekor 数据验证签名的有效性
  5. 监督者通过 Rekor 的日志对证书的颁发记录进行审计

Sigstore为什么能保障安全

Sigstore 可以有效保证从获取 OIDC 身份到用户使用过程的安全性。

从签名的有效性来说,Fulcio 基于 OIDC 身份生成短期证书,Cosign 生成临时密钥为容器镜像或制品签名,证书和密钥的有效期都较短,极大减少了泄露的风险。

从签名的真实性来说,Cosign 会将生成的签名和相关的验证证据存入防篡改且公开的 Rekor,并且通过 Rekor 中的数据对签名进行验证,保证签名是真实的可靠的。

与常规的哈希值校验相比,Sigstore 的优势在于签名记录不可改变,完全公开防篡改的日志保证了验证成功的制品就是签名的开发者发布的制品。

相比同类的完整性保护方案,sigstore解决的问题场景更通用、实现方案更完备,一些类似的解决方案包括:

  • Tekton Chains,一款收集 CI/CD 行为信息用于安全审计的供应链安全工具。但它只有做审计的用途,并没有签名验证的能力。
  • Open Science Chain 利用联盟区块链安全地存储包含来源的不可变数据,实现对其真实性的独立验证。不足也是提供了审计的数据,还需要再开发验证数据的工具。
  • in-toto 提供了一个包含软件供应链顺序和每个步骤的授权人员在内的框架来保护软件供应链的完整性。它需要项目所有者创建一个包含步骤和授权人员在内的框架,前期过程复杂,sigstore是基于in-toto的扩展。

如何使用sigstore

Github Actions

在 GitHub Actions工作流程中,增加对容器镜像签名的流程就能实现签署容器镜像并将其存储在 GitHub Packages。

jobs:
  build:
    steps:
      # ... build steps here
      - uses: sigstore/cosign-installer@main
      - name: Write signing key to disk (only needed for `cosign sign --key`)
        run: echo "${{ secrets.SIGNING_SECRET }}" > cosign.key
      - name: Sign container image
        run: |
          cosign sign --key cosign.key 
            ghcr.io/your-org/your-repo:some-tag        
        env:
          COSIGN_PASSWORD: ""

用户可以在部署前拉取镜像时验证其签名。

cosign verify --key cosign.pub ghcr.io/your-org/your-repo:some-tag

Kubernetes

Kubernetes 在 1.24 版本中采用了 Sigstore 对容器镜像或制品进行签名和验签。

使用如下命令会在 kubernetes secret 中存储私钥、公钥和解密私钥的密码,当使用 cosign verify 验证镜像签名,会使用储存在 kubernetes secret 中的密码自动解密私钥。

cosign generate-key-pair k8s://[NAMESPACE]/[NAME]

独立使用

Rekor 组件提供了自定义部署的方式,Cosign 只是一个签名、验签工具,企业用户可以自行搭建一套用来管理公司内部的代码,并且还可以通过公共的 Rekor 为内部员工使用的开源组件做引入前的验证,减少开源软件造成的漏洞引入。

开发者们可以使用 Cosign 工具来对自己的制品进行签名,减少自己的开源产品被攻击者利用的风险。

# 生成密钥对
cosign generate-key-pair
# 签署容器镜像并将签名存储在注册表
cosign sign --key cosign.key dlorenc/demo
# 查找容器镜像的签名,并使用公钥验证
cosign verify --key cosign.pub dlorenc/demo
# 签署制品(artifact)
# 默认情况下,签名作为base64编码字符串输出
cosign sign-blob --key cosign.key artifact
# 输出:MEQCIAU4wPBpl/U5Vtdx/eJFgR0nICiiNCgyWPWarupH0onwAiAv5ycIKgztxHNVG7bzUjqHuvK2gsc4MWxwDgtDh0JINw==
# 验证制品
cosign verify-blob --key cosign.pub --signature MEQCIAU4wPBpl/U5Vtdx/eJFgR0nICiiNCgyWPWarupH0onwAiAv5ycIKgztxHNVG7bzUjqHuvK2gsc4MWxwDgtDh0JINw== artifact

展望

Sigstore 实现了自动化对组件进行数字签名和验证的能力,同时也解决了从获取身份到用户使用过程中的信任难题,能够很大程度上降低开发者使用成本。

可以预见未来会有更多的开源软件生态集成sigstore,Chainguard等公司也在做基于sigstore的商业解决方案,软件供应链的完整性保护将变得更加普遍。

但是,安全没有银弹。获取的 OIDC 身份不能完全信任、Sigstore 本身的安全问题、Fulcio 的根密钥安全性仍然是潜在的风险点。

参考链接

https://www.sigstore.dev/

https://github.com/google/trillian

(0)
上一篇 2023年8月9日 下午8:30
下一篇 2023年8月9日 下午8:35

相关推荐

  • 前沿 | 国外开源软件安全治理模式研究及工作建议

    开源软件是指软件源代码可以被共享和公共使用的软件。在人们享受开源软件的便捷性和广泛性同时,一旦发生开源软件安全漏洞,其危害程度大、波及范围广,将造成较大安全隐患,从而使对开源软件的治理成为一项重要内容。本文在分析开源软件安全风险的基础上,对国外开源软件安全治理模式进行研究,对我国开源软件安全治理工作存在的不足展开反思,基于以上研究,就如何更好地保障我国开源软…

    2023年8月24日
    0
  • 确保供应链的网络弹性的方法

    在数字化的现代时代,供应链网络攻击的威胁日益严重,对各行各业和各个规模的组织构成了即将到来且隐蔽的威胁。去年,供应链攻击占所有违规行为的19%,显示出其惊人的威力。进入2023年,像三月份臭名昭著的3CX黑客攻击这样的重大事件进一步证明了加强供应链网络安全的必要性。 那么,是什么让供应链成为攻击者的诱人目标呢?云技术的增长和数字化先导战略的采用使得供应链变得…

    2023年8月31日
    0
  • 剖析美国政府视角下的ICT供应链安全

    2018 年 11 月 15 日,美国国土安全部(DHS)宣布成立了信息和通信技术 (ICT) 供应链风险管理(SCRM)工作组,这个工作组是由美国多个政府部门、IT行业企业代表及通信行业企业代表联合成立的。该组织对外宣传的目标是识别和管理全球 ICT 供应链的风险。 之后该组织非常活跃,2024 年 2 月 6 日,该组织刚刚宣布将工作组延长两年。我们翻阅…

    2024年3月25日
    0
  • CSO 们关注的软件供应链安全十个关键问题

    写在前面 自从和几个小伙伴一起创办墨菲安全以来,有一年半多的时间了,创业对于我来说,很有意思的一个地方,就是有机会可以和各行各业很多非常有意思的人一起交流,在这个交流的过程中能够不断的提升自己的认知,以我自己创业之前的经历来说,我接触的大多都是互联网和互联网安全这个圈子的人,而现在有很多机会去接触到更多行业的客户和合作伙伴,可以有机会去了解不同行业的业务、安…

    2023年8月9日
    0
  • 使用 SBOM 查找 Amazon EKS 集群上运行的易受攻击的容器映像

    前言 当你在当地的杂货店购买包装好的食品时,你可能会检查上面列出的成分列表,以了解其中含有什么,确保你不会不经意地摄入你不希望吃的成分或已知对健康有不良影响的成分。但当你购买或使用软件产品时,你是否也有这样的思考方式?你是否清楚地了解构成该软件的各个组件,并知道其中是否有任何已知的漏洞?如今的典型软件应用都是使用许多开源软件库和可重复使用的第三方代码构建的。…

    2023年8月11日
    0