自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
组织和运营安全性
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
从您的组织内部开始为良好的安全做法奠定基础。
组建安全和隐私权团队
组建一个专门的安全和隐私权团队,并为该组织安排一位领导者。
- 组建安全团队。
- 确保有至少 1 名员工负责安全、隐私权和事件响应。
- 为这个团队指定任务和职责范围。
- 为以下人员制定组织结构图和职位描述:安全经理、安全工程师、事件管理员。
- 雇用员工或外部承包商来担任这些角色。
- 定义安全开发生命周期 (SDL)。您的 SDL 应涵盖以下方面:
- 产品的安全要求。
- 风险分析和威胁建模。
- 对应用和代码的静态和动态分析。
- 产品的最终安全审核流程。
- 事件响应。
- 评估组织风险。创建风险评估并制定计划以消除或化解这些风险。
创建验证流程
评审现有内部构建验证和批准流程中的问题。
- 指出当前构建验证流程中可能导致在 build 中引入潜在有害应用 (PHA) 的所有问题。
- 确保制定了代码审核和批准流程,即使是对 AOSP 的内部补丁也是如此。
- 通过在以下方面实施控制来提高 build 完整性:
- 跟踪更改。跟踪软件工程师;保留更改日志。
- 评估风险。评估应用使用的权限;需要对代码更改进行手动审核。
- 监控。评估对特权代码所做的更改。
源代码更改跟踪
监控源代码或第三方应用/二进制文件/SDK 的意外修改行为。
- 评估合作伙伴关系。按照以下步骤评估与技术合作伙伴进行合作的风险:
- 针对如何评估与特定供应商合作的风险制定标准。
- 制作一个表单,询问供应商如何解决事件并管理安全性和隐私权。
- 通过定期审核验证他们的声明。
- 跟踪更改。记录哪些公司和员工修改了源代码并定期进行审核,以确保只进行适当的更改。
- 保留记录。记录哪些公司将第三方二进制文件添加到您的 build 中,并记录这些应用执行的功能及其收集的数据。
- 计划更新。确保您的供应商按照要求在产品的整个生命周期内提供软件更新。不可预见的漏洞可能需要供应商提供支持才能解决。
验证源代码完整性和起源
检查并验证原始设备制造商 (ODM)、无线下载更新 (OTA) 或运营商提供的源代码。
- 管理签名证书。
- 将密钥存储在硬件安全模块 (HSM) 或安全云服务中(不要共享它们)。
- 确保控制和审核对签名证书的访问权限。
- 要求在构建系统中完成所有代码签名。
- 撤消丢失的密钥。
- 根据最佳实践生成密钥。
- 分析新代码。使用安全代码分析工具测试新添加的代码,检查是否引入了新漏洞。此外,还要分析整体功能以检测新漏洞的表现形式。
- 在发布前进行审核。在将源代码和第三方应用推送到生产环境之前,查找其中的安全漏洞。例如:
- 要求应用使用安全通信。
- 遵循最小权限原则并授予应用运行所需的最小权限集。
- 确保通过安全通道存储和传输数据。
- 确保服务依赖项保持最新状态。
- 将安全补丁程序应用于 SDK 和开源库。
事件响应
Android 相信可以借助强大的安全社区发现问题。您应该为外部各方创建并公布一种方法,方便相应人员可以就设备特有的安全问题与您联系。
- 建立联系。创建一个电子邮件地址(例如 security@your-company.com)或制作一个网站,并清晰地说明如何报告与您的产品相关的潜在安全问题(示例)。
- 建立漏洞奖励计划 (VRP)。只要提交的内容有效,就可以获得金钱奖励,以此鼓励外部安全研究人员提交影响您的产品的安全漏洞报告(示例)。我们建议为研究人员提供在行业内具有竞争力的奖励,例如,报告“严重”漏洞奖励 5,000 美元,报告严重程度为“高”的漏洞奖励 2,500 美元。
- 向上游贡献更改。如果您发现某个安全问题会影响 Android 平台或多个设备制造商的设备,请通过提交安全 bug 报告与 Android 安全团队联系。
- 宣传良好的安全做法。主动评估为您的设备提供服务、组件和/或代码的硬件和软件供应商的安全做法。让供应商负责维持良好的安全态势。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[null,null,["最后更新时间 (UTC):2025-07-27。"],[],[],null,["# Organizational and operational security\n\nThe foundation of good security practices start in your organization.\n\n### Create a security and privacy team\n\nCreate a dedicated security and privacy team and establish a leader for this\norganization.\n\n- **Build a security team.**\n - Ensure at least one employee is responsible for security, privacy, and incident response.\n - Define a mission and scope for this team.\n - Develop an org chart and job descriptions for: Security Manager, Security Engineer, Incident Manager.\n - Hire employees or external contractors to fill these roles.\n- **Define a security development lifecycle (SDL)** . Your SDL should cover these areas:\n - Security requirements for products.\n - Risk analysis and threat modeling.\n - [Static and dynamic\n analysis](/docs/security/test/fuzz-sanitize) of apps and code.\n - Final security review processes for products.\n - Incident response.\n- **Assess organizational risk**. Create a risk assessment and develop plans to eliminate or mitigate those risks.\n\n### Build verification process\n\nEvaluate gaps in your existing internal build verification and approval\nprocesses.\n\n- Identify any gaps in your current build verification process that could lead to the introduction of a [Potentially Harmful Application (PHA)](https://developers.google.com/android/play-protect/phacategories) into your build.\n- Ensure you have a code review and approval process, even for in-house patches to [AOSP](https://android.googlesource.com/).\n- Improve build integrity by implementing controls in these areas:\n - **Track changes**. Track software engineers; keep change logs.\n - **Assess risk**. Assess permissions used by an app; require manual review of code changes.\n - **Monitor**. Evaluate changes made to privileged code.\n\n### Source code change tracking\n\nMonitor for unintentional modifications of source code or third-party\napps / binaries / SDKs.\n\n- **Assess partnerships** . Assess the risk of working with a technical partner using the following steps:\n - Establish criteria for how to assess the risk of working with a specific supplier.\n - Create a form that asks the supplier how they resolve incidents and manage security and privacy.\n - Verify their claims with a periodic audit.\n- **Track changes**. Record which companies and employees modify source code and conduct periodic audits to ensure only appropriate changes take place.\n- **Keep records**. Record which companies add third-party binaries to your build and document what function those apps perform and what data they collect.\n- **Plan updates**. Ensure that your suppliers are required to provide software updates for the full life of your product. Unforeseen vulnerabilities might require support from vendors to address.\n\n### Validate source code integrity and pedigree\n\nInspect and validate source code supplied by an original device manufacturer\n(ODM), Over-the-air update (OTA), or carrier.\n\n- **Manage signing certificates** .\n - Store keys in a hardware security module (HSM) or secure cloud service (don't share them).\n - Ensure access to signing certificates is controlled and audited.\n - Require all code signing be done in your build system.\n - Revoke lost keys.\n - Generate keys using best practices.\n- **Analyze new code**. Test newly added code with security code analysis tools to check for the introduction of new vulnerabilities. In addition, analyze overall functionality to detect expression of new vulnerabilities.\n- **Review before publishing** . Look for security vulnerabilities in source code and third-party apps before you push them into production. For example:\n - Require apps to use secure communication.\n - Follow the principle of least privilege and grant the minimum set of permissions needed for the app to operate.\n - Ensure data is stored and transferred over secure channels.\n - Keep service dependencies up-to-date.\n - Apply security patches to SDKs and open source libraries.\n\nIncident response\n-----------------\n\nAndroid believes in the power of a strong security community to help find\nissues. You should create and publicize a way for external parties to contact\nyou about device-specific security issues.\n\n- **Establish contact** . Create an email address, such as security@\u003cvar translate=\"no\"\u003eyour-company\u003c/var\u003e.com or a website with clear instructions for reporting potential security issues associated with your product ([example](https://security.samsungmobile.com/securityReporting.smsb)).\n- **Establish a Vulnerabiity Rewards Program (VRP)** . Encourage external security researchers to submit security vulnerability reports impacting your products by offering monetary rewards for valid submissions ([example](https://www.google.com/about/appsecurity/android-rewards/)). We recommend rewarding researchers with industry competitive rewards, such as $5,000 for Critical severity vulnerabilities and $2,500 for High severity vulnerabilities.\n- **Contribute changes upstream** . If you become aware of a security issue affecting the Android platform or devices from multiple device manufacturers, contact the Android Security Team by filing a [security bug report](https://g.co/AndroidSecurityReport).\n- **Promote good security practices**. Proactively assess the security practices of hardware and software vendors who provide services, components, and/or code for your devices. Hold vendors accountable for maintaining a good security posture."]]