articles: translate Security Best Practices for your Project into zh-hans

_articles/zh-hans/security-best-practices-for-your-project.md

@@ -0,0 +1,84 @@
+---
+lang: zh-hans
+untranslated: true
+title: 项目安全最佳实践
+description: 从多因素认证和代码扫描，到安全的依赖管理和私人漏洞报告，通过这些必要安全实践建立信任，为项目长远发展保驾护航。
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+抛开缺陷（bug）和新特性不谈，一个项目能否长久发展，不仅取决于其实用性，更在于它能否赢得用户的信任。而强有力的安全措施，正是维系这份信任的关键。以下是一些可以显著提高项目安全性的重要举措。
+
+## 确保所有特权贡献者都启用了多因素认证
+
+### 一旦恶意攻击者成功冒充特权贡献者，后果将不堪设想。
+
+获得特殊访问权限后，攻击者便可以篡改代码使其执行恶意操作（例如挖掘加密货币），或向项目用户的基础设施分发恶意软件，抑或访问私有代码仓库（repository）以窃取知识产权及敏感数据（包括其他服务的凭证）。 
+
+多因素认证（Multi-Factor Authentication）为账户安全增加了一道防线。一经启用，除了用户名和口令（password），您还需要额外提供一种您独有的身份认证信息，才能完成登录。
+
+## 将代码安全纳入开发流程
+
+### 比起投入生产环境后才发现代码中的安全漏洞，在流程早期就检测到的话，修复成本要低得多。
+
+使用静态应用安全测试（Static Application Security Testing）工具来检测您代码中的安全漏洞。这类工具在代码层面运行，无需执行环境，因此可以在开发初期就使用，也可以在构建阶段或代码审查阶段无缝集成到您平时的开发流程中。
+
+这就像有位安全专家在您编写代码时检查您的代码仓库，帮您发现那些看似平常、实则暗藏风险的常见安全漏洞。
+
+如何选择适合您的静态应用安全测试工具？
+
+* 查看许可证：有些工具对开源项目免费，例如 GitHub CodeQL 或 SemGrep。
+* 检查是否支持您使用的所有语言。
+* 优先选择能轻松与您使用的其他工具和现有流程集成的工具。例如，将警报信息直接显示在现有代码审查流程或工具中，就比切换到另一个工具来查看要好。
+* 注意误报率！您一定不希望被无缘无故地拖慢进度！
+* 关注不同工具的特殊功能：有些工具非常强大，支持污点追踪（如 GitHub CodeQL），有些则可以提供 AI 生成的修复建议，还有些能让您更轻松地编写自定义规则。
+
+## 莫将秘密公之于众
+
+### API 密钥、令牌、口令等敏感信息有时会被不小心提交到仓库中。
+
+想象这样一个场景：您维护着一个由全球开发者贡献的热门开源项目。有一天，一位贡献者无意中将某第三方服务的 API 密钥提交到了仓库。几天后，有人发现了这些密钥，并通过它们非法访问了该服务。服务被攻陷，用户遭遇业务中断，项目名誉受损。作为维护者，您面临艰巨的任务：撤销泄露的密钥，调研攻击者还可能利用这些密钥作出哪些恶意行为，通知受影响的用户并修复问题。
+
+正是为了避免这样的事故，才有了机密扫描方案，帮您检测代码中的敏感信息。像 GitHub Secret Scanning 和 Truffle Security 的 Trufflehog 这样的工具可以避免您将敏感信息推送到远程分支，防患于未然，还有一些工具则可以自动撤销已泄露的信息。
+
+## 检查和更新依赖项
+
+### 项目中的依赖项可能存在漏洞，从而危及整个项目的安全，而手动更新耗时费力。
+
+想象一下，一个项目建立于某个基础坚实且被广泛使用的库上，该库后来发现了一个重大安全问题，但项目开发者对此却毫不知情。攻击者利用了这一点，潜入并窃取了项目用户们暴露无遗的敏感数据。这并非危言耸听，这正是 2017 年臭名昭著的 Equifax 数据泄露事件的情况：他们在收到 Apache Struts 存在高危漏洞的通知后未能及时更新依赖项，最终导致 1.44 亿用户数据被攻击者盗走。
+
+想要避免类似悲剧，可以使用软件成分分析工具（Software Composition Analysis）工具，如 Dependabot 和 Renovate，它们会自动检查项目依赖项中是否有已经发布在公开数据库（如 NVD 或 GitHub Advisory Database）上的已知漏洞，并自动创建拉取请求来将其更新到安全版本。保持依赖项在最新安全版本，可以保护项目免受潜在风险的威胁。
+
+## 通过保护分支避免不必要的更改
+
+### 不限制对主分支的访问权限，可能导致意外或恶意的改动，从而引入漏洞或破坏项目稳定性。
+
+一位初来乍到的贡献者获得了主分支的写入权限，结果不小心推送了未经测试的更改，一个严重的安全漏洞随之暴露。为防止此类问题，分支保护规则会确保未经审查或未通过指定状态检查的改动不会被合并到重要的分支上。有了这道额外安全保障，您的项目将会更加安全可靠，永远保持最高质量。
+
+## 建立漏洞报告接收机制
+
+### 方便用户报告缺陷固然是好事，但关键问题在于：如果该缺陷涉及安全问题，如何让用户安全地报告，而不使项目招致攻击？
+
+想象一下，一位安全研究员发现了您项目中的漏洞，但由于找不到一个明确或安全的方法来报告，无奈之下，他可能就会创建一个公开的议题（issue）或在社交媒体上公开讨论该漏洞。即便他们是出于好意并提供了修复方案，但只要他们是通过公开的拉取请求来修复，其他人就会在更改合并之前看到它。这会导致在您还没来得及修复该漏洞时，就将其暴露给恶意攻击者，从而可能招致零日攻击，危及项目和用户。
+
+### 安全策略
+
+为避免这种情况，请发布安全策略（security policy）。安全策略一般定义在 `SECURITY.md` 文件中，用于详细说明报告安全问题的步骤，创建透明的协调披露流程，并明确项目团队处理所报告的问题之责任。安全策略可以简单到这样一句话："请不要在公开议题或拉取请求中公布漏洞细节，请发送私密邮件到 security@example.com"，当然也可以包含更多细节，比如用户何时能收到回复。任何有助于提高披露流程有效性和效率的内容都可以纳入其中。
+
+### 私人漏洞报告
+
+在一些平台上，您可以通过私密议题来进一步简化并强化漏洞管理流程，从接收到发布。在 GitLab 上，这可以通过保密议题（confidential issue）来实现。而在 GitHub 上，这称为私人漏洞报告（Private Vulnerability Reporting）。私人漏洞报告让维护者能够在 GitHub 平台内完成接收和处理漏洞报告的整个过程。GitHub 会自动创建私有复刻（fork）用于修复漏洞，并起草安全公告。所有这些都将保密，直到您决定披露问题并发布修复。随后，安全公告将会发布，通知所有用户，并通过他们的软件成分分析工具保护他们。
+
+## 结论：您的几小步，用户安全的一大步
+
+这些步骤对您来说可能很简单或很基础，却能在很大程度上提高项目的安全性，为用户筑起一道抵御最常见的威胁的坚实防线。
+
+## 贡献者
+
+### 非常感谢所有为本文分享经验和建议的维护者！
+
+本文由 [@nanzggits](https://github.com/nanzggits) 和 [@xcorail](https://github.com/xcorail) 撰写，并得到以下贡献者的支持：
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) 等众多同仁！