所谓代码安全审查前置, 是把代码安全检查, 从软件开发流程里发布后的被动发现阶段, 移到代码提交前的主动阻断阶段这种情况, 是通过对每一次代码提交, 实施自动化与人工双重审查, 从而在硬编码凭据、敏感信息以及已知漏洞进入代码仓库之前, 就把它们拦截住的安全管理机制。有一起影响深远的代码密钥泄露事件, 给所有拥有软件开发团队的企业敲响了警钟。
有一家在全球都颇具知名度的汽车制造商, 披露了一起特别重大的数据泄露事件, 安全研究人员于公开代码仓库里发现了一个硬编码的访问密钥, 此密钥能够访问车载信息服务系统的后端数据库, 密钥在代码仓库里公开暴露的时间整整长达五年, 在这五年期间大概有二十九万条客户信息有被非法访问的可能性, 事件的起因是该企业把车载信息服务系统的部分源代码上传至公开代码仓库, 开发者觉得这些代码不含有核心商业机密, 所以选择存放在公开平台上。然而, 有开发人员于代码里对数据库的认证密钥进行了硬编码, 该密钥是以明文形式显现在源代码文件之中, 无论是什么人, 皆是能够轻快地将其提取出来并且加以运用的。
这起事件, 暴露出企业软件开发流程, 普遍存在的安全问题。开发人员, 为了方便调试 和测试, 把数据库密码、API密钥、加密证书 和认证令牌等凭据, 直接写入源代码。在项目后期, 这些硬编码凭据, 往往没被清理, 就随着代码, 一起提交到代码仓库。一旦代码被公开, 所有硬编码凭据, 就完全暴露。更为严重的是, 版本控制系统把每次变更历史永久留存, 哪怕开发人员发觉端倪后, 己将密钥从最新版移除, 可历史记录里依旧存有原始文件, 进而使得事后删除基本上无任何效果可言。
企业需从三个层面去构建代码以及密钥的安全防线, 第一层面是要建立起凭据不进入代码的硬性规则, 所有的访问凭据借助环境变量、密钥管理服务亦或是专门的安全凭据管理平台来进行管理, 绝对不允许把它直接写在代码文件里, 第二层面是要部署代码提交之前的自动检测机制, 凭借静态代码分析工具来扫描硬编码凭据、安全漏洞还有敏感信息, 一旦发现立马自动阻止提交并且通知开发者去修正。首先, 第三层面是要强化代码托管平台的访问权限管理, 接着, 把涉及企业内部系统以及业务数据的代码放置于私有仓库里, 最后, 仅仅把确实需要对外公开的项目设定为公开仓库。
用于企业集中管理尽数访问凭据的基础设施是密钥管理平台, 企业应对数据库密码、API密钥、加密密钥以及数字证书等全部访问凭据予以集中存储, 进行定期轮换以及访问审计, 应用程序于运行之际经由密钥管理平台获取凭据, 并非从代码或者配置文件里读取, 密钥应当定期自动轮换, 以此降低单个密钥泄露的损害时长, 开发环境和测试环境运用独立的凭据与生产环境严格隔离。应当设置自动扫描的机制, 这个机制要在代码提交的时候进行, 也要在代码推送的时候进行, 还要在代码发布的时候进行, 与此同时, 也要设置阻断机制, 检测规则库要定期更新, 目的是覆盖最新的凭据格式, 覆盖最新的敏感数据类型。
问：密钥泄露后仅从最新代码中删除是否足够？
答: 不行。版本控制系统会永久性地留存历史提交记录, 况且旧版本当中的密钥还是能够被随便什么人访问到,务必要同时去撤销或者轮换已经泄露的密钥并且要从全部的历史提交里面把密钥数据完全地移除掉。
问：小团队没有资源部署密钥管理平台怎么办？
首先, 要回答的是, 至少应当遵循这样的基本原则, 那就是凭据不能够进入代码当中, 要借助环境变量或者配置文件来对凭据实施管理, 并把配置文件排除在代码提交的范围之外。其次, 使用云服务商所提供的基础密钥管理服务也是成本相对较低的一种选择。
问：公开仓库中的代码也需要安全审查吗？
答: 是要求的。公开仓库所代表的情况是, 任何人都能够去访问全部的代码以及历史记录, 就算这里面的代码自身不包含构成核心的商业机密, 其中具有可能性会嵌入的凭据还有配置信息, 同样是有着导致出现严重后果的可能性的。
问：代码安全培训应覆盖哪些内容？
