国家为什么需要开源软件：从数字主权到供应链韧性

预计阅读时间：7 分钟

国家采用开源软件，不只是为了节省许可证费用。更关键的问题是：公共数字基础设施能否被审计、能否在供应商退出后继续维护、能否快速修复供应链风险，以及本国开发者是否真正掌握关键系统。开源代码提供了回答这些问题的条件，但它不会自动带来安全、自主或低成本。

开源解决的不是“免费”，而是控制权

闭源软件通常把代码、升级节奏、数据格式和支持能力绑定在供应商手中。对普通企业来说，这可能只是采购风险；对政府、医疗、能源、交通等公共系统来说，它会变成长期治理风险。

开源软件至少提供三种重要能力：

可检查：监管机构和独立团队可以审计代码、构建过程与依赖关系。
可接管：原维护者停止服务后，具备能力的组织仍可修复、分叉和重新发布。
可协作：不同部门、地区和企业可以共同维护通用组件，减少重复建设。

这里需要区分“代码可见”和“真正自主”。如果一个机构没有构建脚本、测试环境、签名密钥管理流程和稳定的维护团队，即使拿到源码，也很难在事故发生时接管系统。数字主权不是把仓库下载到本地，而是拥有持续构建、验证、部署和维护的能力。

国家级需求放大了软件供应链问题

现代应用通常依赖数百甚至数千个开源组件。风险可能来自漏洞，也可能来自维护者账号被盗、恶意版本发布、依赖突然停止维护，或者构建产物与公开源码不一致。

因此，公共部门不能只规定“优先采购开源软件”，还需要建立可执行的供应链要求：

交付软件物料清单（SBOM），明确组件、版本和许可证。
固定依赖版本，并记录升级审批过程。
对构建产物签名，保存来源证明和构建日志。
持续扫描已知漏洞，而不是只在上线前检查一次。
为关键依赖设置维护责任人、替代方案和退出计划。

审计也不意味着代码公开后自然会有人检查。高价值基础设施需要预算支持的审计、模糊测试、渗透测试和漏洞响应机制。

可以这样实践：给项目建立最小供应链清单

下面是一个可改造的最小示例。它使用 Syft 生成 SPDX 格式的 SBOM，再用 Grype 扫描漏洞。运行前需要安装 Docker，并把 my-service:1.0.0 替换为你的镜像名称。

#!/usr/bin/env bash
set -euo pipefail

IMAGE="${1:-my-service:1.0.0}"
mkdir -p artifacts

docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v "$PWD/artifacts:/out" \
  anchore/syft:latest "$IMAGE" \
  -o spdx-json=/out/sbom.spdx.json

docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  anchore/grype:latest "$IMAGE" \
  --fail-on high

printf 'SBOM written to artifacts/sbom.spdx.json\n'

保存为 check-supply-chain.sh 后运行：

chmod +x check-supply-chain.sh
./check-supply-chain.sh registry.example.gov/my-service:1.0.0

实际采购或交付流程还可以要求供应商提交一份机器可读的维护声明：

service: citizen-portal
owner: digital-services-team
source_repository: https://git.example.gov/public/citizen-portal
sbom: artifacts/sbom.spdx.json
release_policy:
  signed_artifacts: true
  reproducible_build_target: true
  vulnerability_sla:
    critical: 24h
    high: 7d
continuity:
  internal_build_documented: true
  secondary_maintainer: platform-team
  data_export_format: json

这份 YAML 不是通用标准，而是一种可以这样实践的项目模板。重点是把“可接管”“可验证”等抽象要求转换成能检查的交付物。

开放生态也需要长期投入

国家支持开源，不应只表现为使用开源项目。大量关键组件由少数维护者承担，他们未必有足够资金处理安全报告、发布版本和维护基础设施。公共资金可以投入安全审计、长期维护合同、开发者培训和上游贡献，但应避免只建立一个无人协作的内部分叉。

更稳妥的路径是优先向上游提交修复，在确有合规或安全差异时维护少量补丁，并明确补丁回归上游或退出分叉的计划。这样既保留本地控制权，也不会切断全球社区带来的审查和创新。

采用前应检查什么

评估一个关键开源项目时，可以重点询问：许可证是否允许预期用途；维护者和发布流程是否稳定；能否从源码重复构建；是否提供 SBOM、签名和漏洞披露渠道；组织内部是否有人能独立部署与修复；数据能否以开放格式导出；上游停止维护时由谁接手。

开源软件对国家的价值，最终不在于“无需付费”，而在于减少不可替代的外部依赖，并让公共数字系统具备可审计、可迁移、可共同维护的基础。要把这种可能性变成现实，还需要人才、制度、预算和持续参与。