应用安全【免费下载链接】CheatSheetSeriesThe OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics.项目地址https://gitcode.com/gh_mirrors/ch/CheatSheetSeries点击查看免费下载软件几乎从不孤立开发无论使用何种技术栈每一款软件都嵌入在一条软件供应链Software Supply Chain, SSC之中。本指南以 cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.md 为核心骨架系统梳理软件供应链的定义、威胁模型以及覆盖源码、依赖、构建、部署运行时四个环节的缓解措施。读完本文你将能够建立 SSC 威胁分类框架并掌握从访问控制、日志监控、依赖评估与版本固定到代码签名、来源验证provenance、临时隔离构建的完整落地清单文中同时以本仓库自身的 CI/CD 与依赖管理实践作为佐证。一、软件供应链SSC是什么按照 NIST 的界定一个实体的软件供应链可以定义为一系列创建、转换并评估软件制品software artifacts质量与策略符合性的步骤集合。从开发者的视角看这些步骤横跨整个 SDLC软件开发生命周期并通过大量组件与工具完成。与原文档一致下面这些组件与开发者的关联尤其密切并非穷举IDE 与代码编辑器内部自研源代码第三方软件库版本控制系统VCS构建工具Maven、Rake、make、Grunt 等CI/CD 软件Jenkins、CircleCI、TeamCity 等配置管理工具Ansible、Puppet、Chef 等包管理与包生态pip、npm、Composer 等。上述每一个组件都必须被妥善保护。任何单一组件的缺陷——例如一个存在漏洞的第三方依赖、或一个配置不当的 VCS——都可能危及整条供应链。因此想要强化软件供应链安全Software Supply Chain Security, SCSS开发者至少需要理解三件事SSC 是什么、针对它的常见威胁有哪些、以及能够降低 SSC 风险的实践与技术。二、威胁全景四大攻击类别SSC 的广度与复杂性决定了其威胁面同样庞大。已知威胁包括依赖混淆dependency confusion、上游供应商基础设施被攻陷、代码签名证书被盗、CI/CD 系统被利用等。更宏观地看威胁可以依据其试图攻陷的供应链环节归为四类威胁类别攻击目标典型示例源代码威胁Source code threats破坏源代码完整性这些代码随后被构建、部署或被其他项目消费VCS 漏洞利用、向代码库注入恶意或有漏洞代码、从未授权分支构建代码构建环境威胁Build environment threats在不修改底层源代码、不直接利用构建过程本身的前提下篡改软件制品构建缓存投毒、攻陷构建工具所用的高权限账户、发布从不可信来源构建的软件依赖相关威胁Dependency related threats直接与传递依赖的消费过程最常见的是使用了存在漏洞或被攻陷的依赖部署与运行时威胁Deployment and runtime threats利用部署流程或运行时环境攻陷高权限 CI/CD 账户、软件错误配置、部署被篡改的二进制文件威胁行为体的特征同样多样。虽然 SSC 被攻陷常与高度老练的 APT 相关联但这种老练并非攻击 SSC 的必要条件——尤其当攻击目标是安全实践糟糕的实体的 SSC 时。行为体的动机也五花八门一次 SSC 利用可能造成任何组织资产的机密性、完整性或可用性损失从而满足间谍活动、牟利等多种攻击目标。最后必须认识到许多 SSC 威胁具有跨实体传播的能力这源于 SSC 内生的消费者—供应商关系。一旦某个大规模软件供应商无论专有还是开源被攻陷其下游的众多消费实体都可能连锁受害——2020 年的 SolarWinds 事件与 2021 年的 Codecov 事件正是现实中的典型案例。三、缓解措施与安全最佳实践缓解 SSC 相关风险看似艰巨实则未必。即便面对针对上游供应商的复杂攻击单个组织仍可采取合理步骤保卫自身资产——即使其供应商已被攻陷也能缓解风险。SSC 的某些部分可能超出开发团队的直接控制范围但团队仍需尽己所能提升组织内的 SSC 安全水平。以下实践按通用 / 源代码 / 依赖 / 构建 / 部署运行时五个板块展开与 CI_CD_Security_Cheat_Sheet.md、Dependency_Graph_SBOM_Cheat_Sheet.md、Vulnerable_Dependency_Management_Cheat_Sheet.md 等仓库内姊妹篇互为补充。3.1 通用实践以下实践面向多种威胁类型是构建 SSC 安全基线的通用技术。3.1.1 实施强访问控制被攻陷的账户尤其是高权限账户是 SSC 的重大威胁。账户接管能让攻击者实施多种恶意行为包括向合法依赖注入代码、操纵 CI/CD 流水线执行、用恶意制品替换良性制品。因此构建、开发、版本控制等环境必须实施强访问控制。最佳实践包括遵循最小权限与职责分离这两项基本安全原则强制启用MFA多因素认证定期轮换凭据确保凭据绝不以明文形式存储、传输或提交到源代码控制中。关于凭据的集中存储、轮换与动态凭据可进一步参阅仓库内的 Secrets_Management_Cheat_Sheet.md——该文档详细讲解了 HashiCorp Vault、AWS Secrets Manager 等方案的架构模式并提供了 Kubernetes Sidecar 与 Serverless 轮换函数的可运行示例。3.1.2 日志与监控在 SSC 安全中检测性控制detective controls的价值常被低估但它们对发现攻击、促成快速响应至关重要。就 SSC 而言日志尤为关键。SSC 中涉及的所有系统——包括 VCS、构建工具、交付机制、制品仓库、以及负责运行应用的系统——都应配置为记录认证尝试、配置变更及其他有助于识别异常行为或对事件响应至关重要的日志事件。SSC 各环节的日志必须在深度与广度上同时足够以支撑检测与响应。然而仅仅记录日志并不足够。这些日志必须被监控并在必要时被处置。考虑到 SSC 的复杂性优先推荐集中式 SIEM、日志聚合器或类似工具。无论采用何种技术基本目标一致日志数据必须是可行动的actionable。关于 CI/CD 环境下的可见性落地细节日志格式、敏感数据规避、SIEM 告警配置可参考 CI_CD_Security_Cheat_Sheet.md 中的 Visibility and Monitoring 章节。3.1.3 借助安全自动化对于复杂的 SSC安全任务的自动化如扫描、监控、测试至关重要。自动化虽不能替代熟练专业人员的人工评审与操作但能以人工难以企及的规模与一致性发现、有时甚至响应漏洞与潜在攻击。支撑自动化的工具类型包括SAST静态应用安全测试DAST动态应用安全测试SCA软件组成分析容器镜像扫描器等等。具体哪类工具能为组织带来最大价值将因组织特性而显著不同。但无论工具类型与厂商如何都必须认识到这些工具本身也需要被维护、加固并正确配置。否则它们要么无法带来有意义的收益要么反而增加组织的 SSC 风险。同时必须清醒理解这些工具只是整体 SSCS 项目的一个组成部分不能被视为全面解决方案也不应被寄望于发现所有漏洞。3.2 缓解源代码威胁以下实践有助于降低与源代码和开发过程相关的 SSC 风险。3.2.1 同行评审Peer Reviews人工代码评审是降低 SSC 风险的一种重要且相对低成本的技巧评审既能充当检测性控制也能起到威慑作用。评审应在代码被合入源代码控制系统之前进行且应由具备所用技术经验与安全编码流程经验的同行执行。评审应同时关注非故意的安全缺陷可能服务于恶意目的的有意代码。评审结果应被记录在案以备日后复核。3.2.2 版本控制系统的安全配置源代码控制系统的失陷或被滥用一直被公认为重大的 SSC 风险。强化 VCS 的两条途径是前文所述的强访问控制与日志监控此外还应充分利用 VCS 系统特有的安全特性例如 git 的受保护分支protected branches与合并策略merge policies。为管理 SCM 系统配置也有现成工具可用例如由 Legit security 开源的Legitify——它专门用于检测 GitHub 与 GitLab 中的错误配置并协助落地最佳实践例如避免自动合并规则、强制 PR 评审且不可绕过、要求提交签名、启用 MFA、限制 fork 私有仓库等详见 CI_CD_Security_Cheat_Sheet.md 的 Secure SCM Configuration 一节。无论为 VCS 添加何种安全控制都必须牢记秘密绝不应被提交到这些系统中。3.2.3 安全开发平台IDE、开发插件及类似工具能辅助开发流程但与其他软件一样这些组件也可能存在漏洞并成为攻击向量。因此不仅要确保这些工具被安全使用还要加固底层系统开发系统应安装端点安全软件并对其执行威胁评估开发流程中只应使用可信、经过充分验证的软件——不仅包括 IDE 这类核心开发工具也包括任何插件或扩展这些工具应纳入组织的系统资产清单。3.3 缓解依赖威胁下面介绍与安全使用依赖相关的实践与技术。3.3.1 评估供应商在将第三方服务、产品或软件组件纳入 SSC 之前供应商与具体产品都应接受彻底的安全评估——这一要求对开源与专有产品同样适用。分析的形式与深度应随被评估组件的关键性与性质而显著变化。在几乎所有情况下以下信息都很有用组件成熟度、安全历史、以及供应商对过往漏洞的响应方式。对于较大型的供应商或服务考察其是否通过了第三方评估与认证例如针对 FedRAMP、CSA STAR、或 ISO/IEC 27001、ISO/IEC 15408、ISO/IEC 27034 等 ISO 标准开展的评估是有用的数据点但绝不能作为唯一依据。由于开源项目天然透明它提供了额外的评估机会。纳入前建议审视以下问题源自 OpenSSF 的简明指南项目是否积极维护项目在相关社区是否足够流行与知名项目是否足够成熟所评估的产品或版本是否为release 版本而非 alpha、beta 或同类版本考虑到项目复杂度维护者与贡献者数量是否充足项目是否及时更新其依赖项目是否有足够的测试覆盖且测试是否包含与安全相关的规则项目文档是否完善文档中是否包含安全使用该组件的方法项目是否有成熟、文档化的漏洞报告流程且漏洞是否被及时处理项目的预期用途是否与其许可证相符3.3.2 理解并监控软件依赖第三方依赖能极大加速开发但也是现代应用面临的主要风险之一。依赖不仅在纳入应用前要谨慎选择在整个 SDLC 期间也要被仔细监控与维护。为此洞悉应用消费了哪些依赖是至关重要的第一步——SBOM软件物料清单正是实现这一洞察的利器。SBOM 的生产与消费都应自动化最好作为组织 CI/CD 流程的一部分。关于 SBOM 的生成时机、标准格式CycloneDX / SPDX、签名与来源绑定、最小元素清单等落地细节仓库内的 Dependency_Graph_SBOM_Cheat_Sheet.md 给出了非常实用的清单与命令示例。在完成依赖清点后组织还必须持续监控这些依赖的已知漏洞且同样应尽量自动化。可用的工具与数据源包括OWASP Dependency Check或retire.js等扫描工具NVD国家漏洞数据库OSV漏洞数据库CISA KEV 目录已知被利用漏洞目录。关于漏洞被发现后的分级处置有补丁 / 无补丁需等待 / 供应商不修复 / 无法升级需自行 backport 等五种 Case仓库内的 Vulnerable_Dependency_Management_Cheat_Sheet.md 提供了完整的决策树与可运行的 Java 防护代码示例。3.3.3 SAST将 SAST 用于检测自研代码中的潜在安全问题是广泛使用的技术同样地它也可以用于 SSC 中的开源组件。与用于内部代码时一样必须认识到这类工具既会产生误报也会产生漏报。因此SAST 结果未经人工验证不应被直接接受也不应被解读为对项目安全性的全面视图。但只要理解其局限SAST 扫描在分析内部代码与开源代码时都能发挥价值。3.3.4 Lockfile / 版本固定为降低被攻陷或有漏洞的版本被无意拉入应用的可能性应将应用依赖限制在先前已验证为合法且安全的特定版本。这通常借助 lockfile 实现例如 npm 使用的package-lock.json以及 Pipenv 的Pipfile.lock等。落地时还应注意固定版本必须经过已知良好的哈希/校验和比对来验证包完整性并强制使用 lockfile优先使用私有仓库并配置包管理器仅使用单一私有源利用 scoped npm 包、NuGet ID 前缀预留等机制降低依赖混淆风险同时确保.npmrc等控制文件被提交到源代码控制并在 CI/CD 环境中可用详见 CI_CD_Security_Cheat_Sheet.md 的 Dependency Management 一节。3.4 缓解构建威胁本节描述对保障构建相关威胁尤为关键的技术。3.4.1 清点构建工具了解 SSC 中使用的组件是保障其安全的前提这一概念同样适用于构建工具。应自动收集并维护所有构建工具的清单包括版本与任何插件同时持续监控漏洞数据库、供应商安全通告及其他来源以发现与已识别构建工具相关的漏洞。3.4.2 加固构建工具被攻陷的构建工具可被用于实施广泛的利用因此对攻击者极具吸引力。构建过程使用的所有基础设施与工具都必须加固。加固构建环境的技术包括确保构建工具位于适当隔离的网络中使用DLP数据防泄漏及其他工具与技术检测并阻止数据外泄禁用/移除任何未使用的服务使用版本控制系统管理并存储流水线配置。3.4.3 强制代码签名从软件消费者的视角看只接受经过数字签名、并在使用前验证签名的组件是确保组件真实且未被篡改的重要步骤。对于执行代码签名的一方而言必须彻底加固代码签名基础设施否则可能导致签名系统被攻陷进而引发进一步利用包括针对软件消费者的攻击。在 CI/CD 环境中可使用 Sigstore、SignServer 等技术实施代码签名并可引入 in-toto 框架强化端到端完整性参考 CI_CD_Security_Cheat_Sheet.md 的 Integrity Assurance 章节。同时要牢记代码签名及相关技术并非绝对的安全保证签名流程本身也可能被利用。3.4.4 使用私有制品仓库使用私有制品仓库能提升组织对 SSC 内各类制品的控制力。制品在获准进入私有仓库前应经过评审组织还必须确保这些仓库的用途无法被绕过。虽然私有仓库会带来额外维护成本或降低敏捷性但它们——尤其对敏感或关键应用而言——是 SSC 安全的重要组件。3.4.5 对构建脚本与配置使用版本控制VCS 的收益可扩展到源代码之外对 CI/CD 流水线相关的配置与脚本尤其如此。对这些文件强制版本控制可以将评审、合并规则等控制机制融入配置更新流程同时使用 VCS 还能提升可见性使任何变更无论恶意与否都易于被发现。3.4.6 验证来源Provenance/ 确保生成充分元数据确保 SSC 组件来自可信来源且未被篡改是 SSC 安全的重要一环。来源信息provenance——SLSA 1.0 将其定义为关于软件制品的可验证信息描述制品在哪里、何时以及如何被生产——的生产与消费是其中的关键。来源信息应满足以下要求由构建平台而非本地开发系统生成对攻击者而言极难伪造包含将结果精确回溯到构建者所需的一切细节。符合 SLSA 1.0 的来源信息可使用 FRSCA 或 GitHub Actions 的 slsa-github-generator 等构建器生成并使用 SLSA Verifier 进行验证。关于 SBOM/制品与签名/证明的绑定流程build → generate SBOM → compute digests → sign/attest → publishDependency_Graph_SBOM_Cheat_Sheet.md 给出了配套的 GitHub Actions 工作流示例与 Cosign 签名命令。3.4.7 临时、隔离的构建Ephemeral, Isolated Builds构建环境的复用与共享可能让攻击者实施缓存投毒或以其他方式更容易注入恶意代码。构建应在隔离、临时ephemeral的环境中进行可使用 VM 或容器执行构建并确保构建完成后立即销毁该环境。3.4.8 限制参数使用向构建过程传入用户可控参数虽然能提升灵活性但也会增加风险。如果用户可以修改参数以改变构建方式那么拥有足够权限的攻击者同样可以修改参数并可能攻陷构建过程。因此应尽量最小化或消除用户可控的构建参数。3.5 缓解部署与运行时威胁本节概述可用于在部署与运行阶段保护软件的几项技术。3.5.1 扫描最终构建二进制构建过程结束后不应想当然地认为最终产物就是安全的。二进制组成分析binary composition analysis可以帮助检测暴露的秘密、检测未授权组件或内容、验证完整性。这项任务应由供应商与消费者双方共同执行。3.5.2 监控已部署软件的漏洞SSC 安全并不随软件部署而结束已部署软件必须被持续监控与维护以降低风险。新漏洞——无论由更新引入还是新近被发现或被公开——都是软件系统中的持续隐忧。进行此类监控时必须采用整体性方法代码依赖、容器镜像、Web 服务器、操作系统组件等仅是必须考虑清单中的一部分。为支撑监控一份准确且最新的系统组件清单至关重要此外不安全的配置变更也必须被监控并处置。四、仓库自身的供应链安全实践一个可对照的实例本仓库OWASP Cheat Sheet Series 的文档仓库本身就是一个小型的软件供应链其 CI/CD 与依赖管理配置可作为前述理论的现实对照依赖自动更新.github/dependabot.yml 配置了 Dependabot对github-actions、npm、pip、docker四类生态按周自动检查更新并分别分组groups以便统一升级——这正是依赖监控应自动化的直接落地。CI 中的完整性校验.github/workflows/md-link-check.yml 在 push 与 PR 时执行npm run link-check通过markdown-link-check检测文档中的失效链接package.json 还提供了lint-markdownmarkdownlint与lint-terminologytextlint等质量门禁一旦失败即中断流水线。这类扫描结果影响流水线结果的模式正是 3.1.3 所述安全自动化的体现。扫描配置的维护markdown-link-check-config.json 集中管理链接检查的忽略规则与 HTTP 请求头自定义 User-Agent说明安全工具自身的配置也需要被认真维护——呼应了原文档工具本身必须被正确配置的告诫。需要说明的是上述配置面向文档仓库与生产软件的供应链安全场景在规模上有差异但其自动化检查、依赖分组更新、配置纳入版本控制的思路完全一致可迁移到任何项目。五、结论软件供应链安全不是单一产品、单一扫描器或一次性项目就能解决的问题而是一套覆盖源码、依赖、构建、部署与运行时全环节的持续性工程。本指南给出了可立即上手的行动清单从强化访问控制与日志监控做起通过同行评审与 VCS 安全配置保护源代码通过供应商评估、SBOM、SCA 与版本固定管理依赖通过构建工具加固、代码签名、私有制品仓库、来源验证与临时隔离构建守护构建环节最后在部署后持续扫描与监控。团队无需等待上游供应链的完全安全——即使供应商被攻陷充分落实上述分层控制也能显著压缩自身风险敞口。六、继续深入阅读仓库内相关文档Software_Supply_Chain_Security_Cheat_Sheet.md——本文的原始骨架文档CI_CD_Security_Cheat_Sheet.md——CI/CD 流水线自身的十大风险与防护SCM 配置、IAM、秘密管理、依赖链滥用、完整性、可见性Dependency_Graph_SBOM_Cheat_Sheet.md——SBOM 生成、签名、管理及漏洞处置工作流Vulnerable_Dependency_Management_Cheat_Sheet.md——依赖漏洞被检出后的五类处置 Case 与工具选型Secrets_Management_Cheat_Sheet.md——秘密集中管理、轮换与内存安全NPM_Security_Cheat_Sheet.md——npm 生态的 lockfile 强制与依赖安全赞分享应用安全【免费下载链接】CheatSheetSeriesThe OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics.项目地址https://gitcode.com/gh_mirrors/ch/CheatSheetSeries点击查看免费下载相关推荐终极移动应用安全防护指南OWASP Cheat Sheet Series完整实践手册终极移动应用安全防护指南OWASP Cheat Sheet Series完整实践手册 OWASP Cheat Sheet Series是由OWASP开放We应用安全超实用防护手册OWASP Cheat Sheet Series文件上传安全的最佳实践超实用防护手册OWASP Cheat Sheet Series文件上传安全的最佳实践 OWASP Cheat Sheet Series是一个专注于应用安全的开应用安全超强防护体系OWASP Cheat Sheet Series云安全架构的终极实践指南超强防护体系OWASP Cheat Sheet Series云安全架构的终极实践指南 OWASP Cheat Sheet Series是一个专注于提供特定应用应用安全上一篇5个关键步骤配置Mox邮件系统监控告警确保邮件服务稳定运行下一篇免费本地视频字幕提取:87种语言硬字幕一键转SRT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考