从您的组织内部开始为良好的安全做法奠定基础。
组建安全和隐私权团队
组建一个专门的安全和隐私权团队，并为该组织安排一位领导者。
- 组建安全团队。
- 确保有至少 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 安全团队联系。
- 宣传良好的安全做法。主动评估为您的设备提供服务、组件和/或代码的硬件和软件供应商的安全做法。让供应商负责维持良好的安全态势。