Software Supply Chain Security / 软件供应链安全¶
Introduction / 介绍¶
No piece of software is developed in a vacuum; regardless of the technologies used to develop it, software is embedded in a Software Supply Chain (SSC). According to NIST, an entity's SSC can be defined as "a collection of steps that create, transform, and assess the quality and policy conformance of software artifacts". From a developer's perspective, these steps span the entire SDLC and are accomplished using a wide range of components and tools. Common examples (by no means exhaustive) of components that are especially relevant from a developer's perspective include:
没有任何软件是在真空中开发的；无论用于开发它的技术是什么，软件都嵌入在软件供应链（SSC）中。根据NIST的定义，实体的软件供应链可以定义为“创建、转换和评估软件工件质量和策略合规性的步骤集合”。从开发者的角度来看，这些步骤贯穿整个软件开发生命周期（SDLC），并使用各种组件和工具来完成。以下是一些（但绝非详尽）特别与开发者视角相关的组件示例：
- IDEs and code editors
中文：集成开发环境（IDE）和代码编辑器 - Internally developed source code
中文：内部开发源代码 - Third-party software libraries
中文：第三方软件库 - Version control systems (VCS)
中文：版本控制系统（VCS） - Build tools (Maven, Rake, make, Grunt, etc.)
中文：构建工具（Maven、Rake、make、Grunt等） - CI/CD software (Jenkins, CircleCI, TeamCity, etc.)
中文：CI/CD软件（Jenkins、CircleCI、TeamCity等） - Configuration management tools (Ansible, Puppet, Chef, etc.)
中文：配置管理工具（Ansible、Puppet、Chef等） - Package management software and ecosystems (pip, npm, Composer, etc.)
中文：软件包管理软件和生态系统（pip、npm、Composer等）
Each of these components must be secured; a flaw in a single component, such as a vulnerable third-party dependency or misconfigured VCS, can put an entire SSC in jeopardy. Thus, in order to strengthen Software Supply Chain Security (SCSS), developers should possess a general understanding of what the SSC is, common threats against it, and practices and techniques that can be applied to reduce SSC risk.
这些组件中的每一个都必须得到保护；单个组件的漏洞，例如易受攻击的第三方依赖项或配置不当的版本控制系统（VCS），可能会使整个软件供应链（SSC）处于危险之中。因此，为了加强软件供应链安全（SCSS），开发者应该具备对SSC的一般理解，了解针对它的常见威胁，以及可以应用以降低SSC风险的实践和技术。
Overview of Threat Landscape / 威胁态势概述¶
Given the breadth and complexity of the SSC, it is unsurprising that the threat landscape for SSC is similarly expansive. Threats include dependency confusion, compromise of an upstream providers infrastructure, theft of code signing certificates, and CI/CD system exploits. More broadly, threats may be grouped into four categories based upon what component of the supply chain they seek to compromise (Google supply-chain threat categories, SLSA 1.0 threats):
鉴于SSC的广度和复杂性，SSC的威胁态势同样广泛。这些威胁包括依赖项混淆、上游提供商基础设施的妥协、代码签名证书的盗窃以及CI/CD系统的利用。更广泛地说，根据它们试图破坏供应链的哪个组件，威胁可以分为四个类别（Google供应链威胁类别，SLSA 1.0威胁）：
- Source code threats. These type of threats focus on violating the integrity of a source code which is then built and and deployed or potentially consumed by other software projects. Threats in this category include VCS exploits, the introduction of malicious or vulnerable code into a codebase, or building code from an unauthorized branch.
中文：源代码威胁。这类威胁侧重于违反源代码的完整性，然后构建并部署或可能被其他软件项目消费。这类威胁包括VCS利用、将恶意或易受攻击的代码引入代码库，或从未经授权的分支构建代码。 - Build environment threats. These threats modify a software artifact but without altering the underlying source code or exploiting the build process itself. Examples include build cache poisoning, compromising a privileged account used by the build tool, or publishing software built from an untrusted source.
中文：构建环境威胁。这类威胁修改软件工件，但不会更改底层源代码或利用构建过程本身。例如，包括构建缓存投毒、利用构建工具的特权账户，或发布来自不受信任来源的软件。 - Dependency related threats. Threats that result from the consumption of both direct and transitive software dependencies. The most common threat is using a vulnerable or compromised dependency.
中文：依赖项相关威胁。这些威胁源于直接和间接软件依赖项的消费。最常见的威胁是使用易受攻击或已泄露的依赖项。 - Deployment and runtime threats. These threats exploit either the deployment process or runtime environment. Common examples include compromising a privilege CI/CD account, software misconfigurations, and deployment of compromised binaries.
中文：部署和运行时威胁。这些威胁利用部署过程或运行时环境。常见示例包括破坏特权CI/CD账户、软件配置错误和部署受损害的二进制文件。
The characteristics of threat actors seeking to exploit the SSC are similarly diverse. Although SSC compromise is often associated with highly sophisticated threat actors, such sophistication is not inherently necessary for attacking the SSC, especially if the attack focuses on compromising the SSC of entities with poor security practices. Threat actor motive also varies widely. A SSC exploit can result in loss of confidentiality, integrity, and/or availability of any organization's assets and thus fulfill a wide range of attacker goals such as espionage or financial gain.
寻求利用SSC的威胁行为者的特征也各不相同。尽管SSC妥协通常与高度复杂的威胁行为者相关联，但这种复杂性并非攻击SSC的内在必要条件，特别是如果攻击的重点是破坏安全实践较差实体的SSC。威胁行为者的动机也各不相同。SSC利用可能导致任何组织的资产机密性、完整性和/或可用性丢失，从而满足广泛的攻击者目标，如间谍活动或经济利益。
Finally, it must be recognized that many SSC threats have the capability to propagate across many entities. This is due to the consumer-supplier relationship that is integral to an SSC. For example, if a large-scale software supplier, whether proprietary or open-source, is compromised, many downstream consuming entities could also be impacted as a result. The 2020 SolarWinds and 2021 Codecov incidents are excellent real-world examples of this.
最后，必须认识到许多SSC威胁具有跨多个实体传播的能力。这是由于SSC中不可或缺的消费者-供应商关系所致。例如，如果一个大规模的软件供应商，无论是专有还是开源，遭到破坏，许多下游消费实体也可能受到影响。2020年SolarWinds和2021年Codecov事件是这一点的绝佳现实例子。
Mitigations and Security Best Practices / 缓解措施和安全最佳实践¶
Mitigating SSC related risk can seem daunting, yet it need not be. Even for sophisticated attacks that may focus on compromising upstream suppliers, individual organization can take reasonable steps to defend its own assets and mitigate risk even if its supplier is compromised. Although some parts of SSCS may remain outside direct control of development teams, those teams must still do their part to improve SSCS in their organization; the guidance below is intended as starting point for developers to do just that.
缓解与SSC相关的风险可能看起来令人畏惧，但实际上并非如此。即使对于可能专注于破坏上游供应商的复杂攻击，单个组织也可以采取合理的步骤来保护自己的资产并减轻风险，即使其供应商遭到破坏。尽管SSCS的一些部分可能仍然超出开发团队的直接控制，但那些团队仍然需要尽其所能来改善其组织中的SSCS；以下指导旨在为开发者提供一个起点。
General / 通用¶
The practices described below are general techniques that can be used to mitigate risk related to a wide variety of threat types.
以下描述的实践是一般技术，可用于减轻与各种威胁类型相关的风险。
Implement Strong Access Control / 实施强访问控制¶
Compromised accounts, particularly privileged ones, represents a significant threats to SSCs. Account takeover can allow an attacker can perform a variety of malicious acts including injecting code into legitimate dependencies, manipulating CI/CD pipeline execution, and replacing a benign artifact with a malicious one. Strong access control for build, development, version control, and similar environments is thus critical. Best practices include adhering to the basic security principles of least privileges and separation of duties, enforcing MFA, rotating credentials, and ensuring credentials are never stored or transmitted in clear text or committed to source control.
被破坏的账户，尤其是特权账户，对SSC构成了重大威胁。账户接管允许攻击者执行各种恶意行为，包括向合法依赖项注入代码、操纵CI/CD管道执行以及用恶意工件替换良性工件。因此，对构建、开发、版本控制和类似环境的强访问控制至关重要。最佳实践包括遵守最小权限和职责分离的基本安全原则、强制执行多因素认证、轮换凭证以及确保凭证永远不会以明文形式存储或传输，也不会提交到源控制。
Logging and Monitoring / 记录和监控¶
When considering SSCS, the importance of detective controls should not be overlooked; these controls are essential for detecting attacks and enabling prompt respond. In the context of SSCS, logging is critical. All systems involved in the SSC, including VCS, build tools, delivery mechanisms, artifact repositories, and the systems responsible for running applications should be configured to log authentication attempts, configuration changes, and other events that could assist in identifying anomalous behavior or that could prove crucial for incident response efforts. Logs throughout the SSC must be sufficient in both depth and breadth to support detection and response
在考虑SSCS时，不应忽视检测控制的重要性；这些控制对于检测攻击和实现快速响应至关重要。在SSCS的背景下，日志记录至关重要。SSC中涉及的所有系统，包括VCS、构建工具、交付机制、工件存储库以及负责运行应用程序的系统，应配置为记录身份验证尝试、配置更改和其他有助于识别异常行为或对事件响应努力至关重要的其他事件。SSC中的日志记录必须在深度和广度上足够充分，以支持检测和响应。
However, logging events is not sufficient. These logs must be monitored, and, if necessary, acted upon. A centralized SIEM, log aggregator, or similar tool is preferred, especially given the complexity of SSCs. Regardless of the technology used, the basic objective remains the same: log data should be actionable.
然而，仅记录事件是不够的。这些日志必须被监控，并在必要时采取行动。一个集中的SIEM、日志聚合器或类似工具是首选，尤其是在SSCs的复杂性面前。无论使用哪种技术，基本目标保持不变：日志数据应该是可操作的。
Leverage Security Automation / 利用安全自动化¶
For complex SSCs, automation of security tasks, such as scanning, monitoring, and testing is critical. Such automation, while not a replacement for manual reviews and other actions performed by skilled professionals, is capable of detecting, and in some cases responding to, vulnerabilities and potential attacks with a scale and consistency that is hard to achieve through manual human intervention. Types of tools that support automation include SAST, DAST, SCA, container image scanners and more. The exact tools most capable of delivering value to an organization will vary significantly based on the characteristics of the organization. However, regardless of the type of tools and vendors used, it is important to acknowledge that these tools themselves must be mainlined, secured, and configured correctly. Failure to do so could actually increase SSC risk for an organization, or at the very least, fail to bring meaningful benefit to the organization. Finally, it must be clearly understood that these tools are but one component of an overall SSCS program; they cannot be considered a comprehensive solution or be relied on to identify all vulnerabilities.
对于复杂的SSCs，自动化安全任务，如扫描、监控和测试是至关重要的。这种自动化虽然不能替代熟练专业人员进行的手动审查和其他行动，但能够以手动干预难以达到的规模和一致性检测并响应漏洞和潜在的攻击。支持自动化的工具类型包括SAST、DAST、SCA、容器镜像扫描器等。最能够为组织带来价值的工具将根据组织的特征而有很大差异。然而，无论使用哪种工具和供应商，重要的是要认识到这些工具本身必须被整合、安全配置并正确配置。未能做到这一点实际上可能会增加组织的SSC风险，或者至少无法为组织带来有意义的益处。最后，必须清楚地理解这些工具只是整体SSCS计划的一个组成部分；它们不能被视为全面的解决方案，也不能依赖于它们来识别所有漏洞。
Mitigating Source Code Threats / 缓解源代码威胁¶
The practices described below can help reduce SSC risk associated with source code and development.
以下描述的实践可以帮助降低与源代码和开发相关的SSC风险。
Peer Reviews / 同行评审¶
Manual code reviews are an important, relatively low cost technique for reducing SSC risk; these reviews can act as both detective controls and deterrents. Reviews should be performed by peers possessing both experience in the technology being used and secure coding processes and should occur before code is merged within a source control systems (Google source safeguards). The reviews should look for both unintentional security flaws as well as intentional code that could serve malicious purposes. The results of the review should be documented for later review if needed.
手动代码审查是降低SSC风险的重要、相对低成本的技巧；这些审查可以充当检测控制和威慑。审查应由具备所使用技术经验和安全编码流程的同行进行，应在代码合并到源控制系统中之前进行(Google源保护)。审查应寻找无意中的安全漏洞以及可能被用于恶意目的的故意代码。审查的结果应记录下来，以备后续审查。
Secure Config of Version Control Systems / 版本控制系统的安全配置¶
Compromise or abuse of the source control system is consistently recognized as a significant SSC risk (Google supply-chain threat categories, SLSA 1.0 threats). The general security best practices of strong access control and logging and monitoring are two methods to help secure VCS. Security features specific to the VCS system, such as protected branches and merge policies in git, should also be leveraged. You can find a wide variety of recommended policies in this documentation. There are tools available to help manage configuration of SCM systems, such as Legitify, an open-source tool by Legit security. Legitify is designed to detect misconfigurations in GitHub and GitLab and assist with the implementation of best practices. Regardless of any security controls added a VCS, it must be remember that secrets should never be committed to these systems.
源代码控制系统的妥协或滥用一直被视为重要的SSC风险（谷歌供应链威胁类别，SLSA 1.0威胁）。强大的访问控制和日志监控等通用安全最佳实践是帮助保护版本控制系统（VCS）的两种方法。VCS系统特有的安全功能，如git中的受保护分支和合并策略，也应得到利用。您可以在此文档中找到各种推荐策略。有工具可以帮助管理SCM系统的配置，例如Legitify，这是Legit安全的一个开源工具。Legitify旨在检测GitHub和GitLab中的配置错误，并协助实施最佳实践。无论在VCS中添加了哪些安全控制，都必须记住，机密信息绝不应提交到这些系统中。
Secure Development Platform / 安全开发平台¶
IDEs, development plugins, and similar tools can help assist the development process. However, like all pieces of software, these components can have vulnerabilities and become an attack vector. Thus, it is important to take steps not only to ensure these tools are used securely, but also to secure the underlying system. The development system should have endpoint security software installed and should have threat assessments performed against it (ESF developer practices). Only trusted, well-vetted software should be used in the development process; this includes not only "core" development tools such as IDEs, but also any plugins or extensions. Additionally, these tools should be included as part of an organization's system inventory.
集成开发环境（IDE）、开发插件和类似工具可以帮助辅助开发过程。然而，像所有软件组件一样，这些组件可能存在漏洞并成为攻击向量。因此，不仅需要确保这些工具安全使用，还需要保护底层系统。开发系统应安装端点安全软件，并对其进行威胁评估（ESF开发者实践）。开发过程中应仅使用经过充分审查的信任软件；这不仅包括“核心”开发工具，如IDE，还包括任何插件或扩展。此外，这些工具应作为组织系统清单的一部分。
Mitigating Dependency Threats / 缓解依赖威胁¶
Best practices and techniques related to secure use of dependencies are described below.
以下描述了与安全使用依赖项相关的最佳实践和技术。
Assess Suppliers / 评估供应商¶
Before incorporating a third-party service, product, or software component into the SSC, the vendor and specific offering should both be thoroughly assessed for security. This applies to both open-source and proprietary offerings. The form and extent of the analysis will vary substantially in accordance with both the criticality and nature of the component being considered. Component maturity, security history, and the vendor's response to past vulnerabilities are useful information in nearly any case. For larger vendors or service offerings, determining whether or not a solution has been evaluated against third-party assessments and certifications, such as those performed against FedRAMP, CSA, or various ISO standards (ISO/IEC 27001, ISO/IEC 15408, ISO/IEC 27034), can be a useful data point, but must not be relied on exclusively.
在将第三方服务、产品或软件组件纳入SSC之前，应彻底评估供应商和具体产品在安全性方面的表现。这适用于开源和专有产品。分析的形式和范围将根据考虑组件的关键性和性质而大幅变化。组件成熟度、安全历史和供应商对过去漏洞的反应是几乎所有情况下有用的信息。对于大型供应商或服务产品，确定解决方案是否经过第三方评估和认证，如FedRAMP、CSA或各种ISO标准（ISO/IEC 27001、ISO/IEC 15408、ISO/IEC 27034），可能是一个有用的数据点，但不能完全依赖。
Due to its transparent nature, open-source projects offer additional assessment opportunities. Questions to consider include (OpenSSF component evaluation):
由于其透明性，开源项目提供了额外的评估机会。需要考虑的问题包括（OpenSSF组件评估）：
- Is the project actively maintained?
中文：项目是否得到积极维护？ - Is the project sufficiently popular and well-known in the applicable community?
中文：项目在适用社区中是否足够受欢迎和知名？ - Is the project sufficiently mature?
中文：项目是否足够成熟？ - Is the product or version being evaluated a "release" version, e.g. not an alpha, beta, or comparable versions?
中文：正在评估的产品或版本是否为“发布”版本，例如不是alpha、beta或类似版本？ - Given the complexity of the project, does the project have a sufficient number of maintainers and contributors?
中文：鉴于项目的复杂性，项目是否有足够的维护者和贡献者？ - Does the project keep its dependencies updated?
中文：项目是否保持其依赖项更新？ - Does the project have sufficient test coverage and do the tests include security relevant rules?
中文：项目是否有足够的测试覆盖率，并且测试是否包括与安全相关的规则？ - Is the project well-documented and does the document include guidance on how to use the component securely?
中文：项目是否得到良好的文档记录，并且文档是否包含如何安全使用组件的指导？ - Does the project have an established and documented process for reporting vulnerabilities and are these vulnerabilities addressed in a timely manner?
中文：项目是否有建立并记录的漏洞报告流程，并且这些漏洞是否得到及时处理？ - Is the intended usage of the project consistent with the project's license?
中文：项目的预期使用是否与项目的许可证一致？
Understand and Monitor Software Dependencies / 理解和监控软件依赖项¶
While third-party software dependencies can greatly accelerate the development process, they are also one of the leading risks associated with modern applications. Dependencies must not only be carefully selected before they are incorporated into an application, but also carefully monitored and maintained throughout the SDLC. In order achieve this, having insight into the various dependencies consumed by software is a crucial first step. To facilitate this, SBOMs may be used. Both production and consumption of these SBOMs should be automated, preferably as part of the organization's CI/CD process.
虽然第三方软件依赖项可以极大地加快开发过程，但它们也是现代应用程序的主要风险之一。在将依赖项纳入应用程序之前，必须仔细选择依赖项，并在整个SDLC中仔细监控和维护。为了实现这一点，了解软件所消耗的各种依赖项是一个关键的第一步。为此，可以使用SBOMs。这些SBOMs的生产和消费应尽可能自动化，最好作为组织CI/CD流程的一部分。
Once the organization has inventoried dependencies, it must also monitor them for known vulnerabilities. This should also be automated as much as possible; tools such as OWASP Dependency Check or retire.js can assist in this process. Additionally, sources such as the NVD, OSVDB, or CISA KEV catalog may also be monitored for known vulnerabilities related to dependencies used in the organization's SSC.
一旦组织已列出依赖项，它还必须监控它们以发现已知漏洞。这应尽可能自动化；例如，OWASP依赖项检查或retire.js等工具可以帮助这个过程。此外，还可以监控NVD、OSVDB或CISA KEV目录等来源，以发现与组织SSC中使用的依赖项相关的已知漏洞。
SAST¶
Although using SAST to detect potential security in custom developed code is a widely used security technique, it can also be used on OSS components within the SSC (ESF developer practices). As when using SAST on internally developed code, one must recognize that these tools can produce both false positives and false negatives. Thus, SAST results must not be accepted without manual verification and should not be interpreted as providing a comprehensive view of the project's security. However, as long as their limitations are understood, SAST scans can prove useful when analyzing both internally developed or OSS code.
虽然使用SAST检测自定义开发代码中的潜在安全问题是广泛使用的安全技术，但它也可以用于SSC中的开源软件组件(ESF开发者实践)。就像在内部开发代码上使用SAST一样，必须认识到这些工具可以产生误报和漏报。因此，SAST结果不能未经人工验证就接受，也不应被视为提供项目安全性的全面视图。然而，只要理解其局限性，SAST扫描在分析内部开发或开源代码时仍然是有用的。
Lockfile/Version Pinning¶
To reduce the likelihood that a compromised or vulnerable version is unwittingly pulled into an application, one should limit the applications dependencies to a specific version that has been previously verified as legitimate and secure. This is commonly accomplished using lockfiles such as the package-lock.json file used by npm.
为了降低无意中将受损害或易受攻击的版本拉入应用程序的可能性，应将应用程序的依赖项限制在之前已验证为合法和安全的特定版本。这通常通过使用如npm使用的package-lock.json文件之类的lockfiles来完成。
Build Threats / 构建威胁¶
The section below describes techniques that are especially relevant for securing build related threats.
以下部分描述了特别适用于保护构建相关威胁的技术。
Inventory Build Tools / 构建工具清单¶
Knowing the components used in the SSC is essential to the security of that SSC. This concept extends to build tools. An inventory of all build tools, including versions and any plugins, should be automatically collected and mainlined, One must also monitor vulnerability databases, vendor security advisories and other sources for any vulnerabilities related to the identified build tools.
了解SSC中使用的组件对于该SSC的安全性至关重要。这一概念也适用于构建工具。应自动收集并整合所有构建工具的清单，包括版本和任何插件。还必须监控漏洞数据库、供应商安全公告和其他来源，以识别与已识别构建工具相关的任何漏洞。
Harden Build Tools / 强化构建工具¶
Compromised build tools can enable a wide range of exploits and thus represent an appealing target for attackers. As such, all infrastructure and tools used in build process must be hardened to mitigate risk. Techniques for hardening build environments include (ESF developer practices):
被破坏的构建工具可以启用各种攻击，因此对攻击者来说是一个有吸引力的目标。因此，必须强化构建过程中使用的所有基础设施和工具，以减轻风险。强化构建环境的技术包括 (ESF开发者实践)：
- Ensure build tools are located in an appropriately segregated networks.
中文：确保构建工具位于适当隔离的网络中。 - Use DLP and other tools and techniques to detect and prevent exfiltration.
中文：使用DLP和其他工具和技术来检测和防止数据泄露。 - Disable/remove any unused services.
中文：禁用/删除任何未使用的服务。 - Use version control systems to manage and store pipeline configurations.
中文：使用版本控制系统来管理和存储管道配置。
Enforce Code Signing / 强制代码签名¶
From a the perspective of software consumers, only accepting components which have been digitally signed and validating the signature before utilizing the software is an important task step in ensuring the component is authentic and has not been tampered with. For those performing code signing, it is imperative that the code signing infrastructure is thoroughly hardened. Failure to do so can result in compromise of the code signing system and lead further exploits, including those targeting consumers of the software.
从软件消费者的角度来看，仅接受经过数字签名的组件，并在使用软件之前验证签名，是确保组件真实且未被篡改的重要步骤。对于执行代码签名的人员来说，确保代码签名基础设施得到充分加固至关重要。未能做到这一点可能导致代码签名系统被破坏，并导致进一步的攻击，包括针对软件消费者的攻击。
Use Private Artifact Repository / 使用私有工件存储库¶
Using a private artifact repository increases the control an organization has over the various artifacts that are used within the SSC. Artifacts should be reviewed before being allowed in the private repository and organizations must ensure that usage of these repositories cannot be bypassed. Although usage of private repositories can introduce extra maintenance or reduce agility, they can also be an important component of SSCS, especially for sensitive or critical applications.
使用私有工件存储库可以增加组织对SSC中使用的各种工件的控制。在允许工件进入私有存储库之前，应对其进行审查，并且组织必须确保无法绕过这些存储库的使用。尽管私有存储库的使用可能会引入额外的维护或降低敏捷性，但它们也可以是SSCS的重要组成部分，特别是对于敏感或关键应用程序。
Use Source Control for Build Scripts and Config / 使用源控制进行构建脚本和配置¶
The benefits of VCSs can be realized for items beyond source control; this is especially true for config and scripts related to CI/CD pipelines. Enforcing version control for these files allows one to incorporate reviews, merge rules, and like controls into the config update process. Using VCS also increase visibility, allowing one easy visibility into any changes introduced, whether malicious or benign (ESF developer practices).
VCS的好处不仅限于源控制；这对于与CI/CD管道相关的配置和脚本尤其如此。强制对这些文件的版本控制可以将审查、合并规则等控制纳入配置更新过程。使用VCS还可以提高可见性，使人们能够轻松地看到引入的任何更改，无论是有意还是无意的（ESF开发者实践）。
Verify Provenance/Ensure Sufficient Metadata is Generated¶
Having assurance that an SSC component comes from a trusted source and has not been tampered with is a important part of SSCS. Generation and consumption of provenance, defined in SLSA 1.0 as "the verifiable information about software artifacts describing where, when and how something was produced" is an important part of this. The provenance should be generated by the build platform (as opposed to a local development system), be very difficult for attackers to forge, and contain all details necessary to accurately link the result back to the builder (SLSA 1.0 provenance requirements). SLSA 1.0 compliant provenance can be generated using builders such as FRSCA or Github Actions and verified using SLSA Verifier
确保SSC组件来自可信来源且未被篡改是SSCS的重要组成部分。生成和消费来源，根据SLSA 1.0定义为“关于软件工件的可验证信息，描述了某物在哪里、何时以及如何被生产”，是这一部分的重要组成部分。来源应由构建平台（而不是本地开发系统）生成，对攻击者来说非常难以伪造，并包含所有必要的细节，以便准确地将结果链接回构建者（SLSA 1.0来源要求）。可以使用FRSCA或GitHub Actions等构建者生成符合SLSA 1.0的来源，并使用SLSA验证器进行验证。
Ephemeral, Isolated Builds / 临时、隔离的构建¶
Reuse and sharing of build environments may allow attackers to perform cache poising or otherwise more readily inject malicious code. Builds should be performed in isolated, temporary ("ephemeral") environments. This can be achieved using technologies such as VMs or containers for builds and ensuring the environment is immediately destroyed afterward.
构建环境的重用和共享可能会使攻击者执行缓存投毒或其他更易于注入恶意代码的操作。构建应在隔离的、临时的（"临时性"）环境中进行。这可以通过使用虚拟机或容器等技术来实现构建，并确保环境在之后立即被销毁。
Limit use of Parameters / 限制参数的使用¶
Although passing user controllable parameters to a build process can increase flexibility, it also increases risk. If parameters can be modified by users in order to alter how a build is performed, an attacker with sufficient permission will also be able to modify the parameters and potentially compromise the build process (Google build safeguards). One should thus make an effort to minimize or eliminate any user controllable build parameters.
虽然将用户可控参数传递给构建过程可以增加灵活性，但也增加了风险。如果参数可以被用户修改以改变构建的执行方式，那么拥有足够权限的攻击者也可以修改参数，并可能危害构建过程（Google构建保护）。因此，应努力最小化或消除任何用户可控的构建参数。
Deployment and Runtime Threats / 部署和运行时威胁¶
The section below outlines a couple of techniques that can be used to protect software during the deployment and runtime phases.
以下部分概述了一些可以在部署和运行时阶段保护软件的技术。
Scan Final Build Binary / 扫描最终构建的二进制文件¶
Once the build process has finished, one should not simply assume that the final result is secure. Binary composition analysis can help detect exposed secrets, detect unauthorized components or content, and verify integrity (ESF developer practices). This task should be performed by both suppliers and consumers.
一旦构建过程完成，不应简单地假设最终结果是安全的。二进制组成分析可以帮助检测暴露的秘密、检测未经授权的组件或内容，并验证完整性（ESF开发者实践）。这项任务应由供应商和消费者共同完成。
Monitor Deployed Software for Vulnerabilities / 监控已部署软件中的漏洞¶
SSCS does not end with the deployment of the software; the deployed software must be monitored and maintained to reduce risk. New vulnerabilities, whether introduced due to an update or simply newly discovered (or made public), are a continual concern in software systems (Google supply-chain threat categories). When performing this monitoring, a wholistic approached must be used; code dependencies, container images, web servers, and operating system components are just a sampling of items that must be consider. To support this monitoring, an accurate and up-to-date inventory of system components is critical. Additionally, insecure configuration changes must be monitored and acted upon.
SSCS 并不随着软件的部署而结束；已部署的软件必须被监控和维护以降低风险。无论是由于更新引入还是新发现（或公开）的新漏洞，都是软件系统中持续关注的问题（谷歌供应链威胁类别）。在执行此监控时，必须采用全面的方法；代码依赖项、容器镜像、Web 服务器和操作系统组件只是必须考虑的项目样本。为了支持此监控，系统组件的准确且最新的清单至关重要。此外，必须监控不安全的配置更改并采取行动。