安全研究人员仍然能够找到深藏在持续集成服务中的机密信息，而这个问题早在多年前就为人熟知。
持续集成 (CI) 是一种编码方法论，要求程序员以不同的时间间隔将其开发代码集成回主应用程序。此代码被编译/构建回生产系统的副本，并使用自动化系统对代码进行错误测试。
持续集成的目的是在编代码过程中尽可能轻松地找到 bug，并且在它们嵌入到项目太深之前检测出，否则将导致大量覆写。
而最有名使用也最广泛的持续集成服务就是 Travis CI，它受宠的一个主要原因在于其 GitHub 集成，不过其它服务也存在 GitHub 集成如 Circle CI 和 GitLabCI。
和任何网络应用程序一样，Travis CI 记录所有发生的一切，而其中最重要的就是项目的构建日志，Travis 将开发代码通过“构建 (build)”操作集成到主代码仓库中。
在构建过程中，需要和多种远程服务器和 API 进行交互，可使用密码、SSH 密钥或 API 令牌实现，而且也会被记录在 Travis 持续集成日志中。
老树新芽
多年前，安全研究员意识到可组合使用API 密钥的 Travis 持续集成日志和其它机密，并将这些问题告知企业以获得漏洞奖励金。
除了安全研究人员外，威胁人员也意识到可以这么做，其中一些甚至攻击 Travis 持续集成来搜索大量构建日志并提取其中的机密信息。
Travis 持续集成团队获悉这些攻击活动后更改了其进程。几年来，Travis 持续集成服务一直都在运行多种自动脚本，检测看似密码或API令牌的模式，并以词语[secure]予以替代。
但三年后，漏洞赏金猎人发现尽管多家持续集成服务如 Travis CI、Circle CI 和 GitLab CI 等采取了应对措施，一些构建日志中仍然包含机密信息。通过特殊构造的工具，研究人员在过去数月以来扫描了持续集成构建日志发现了新的敏感信息。他们从 Grammarly、Discourse、某公开的密币程序和他们不愿透露名称的组织机构中发现了机密信息泄露情况。研究人员表示，“总体而言，影响最大的问题是 GitHub 访问令牌泄露问题。”他们督促企业对持续集成构建日志进行审计，查看敏感的令牌信息是否没能通过 Travis CI服务的基本模式过滤程序检测出。
CI构建日志仍使用不活跃的数据包
另外，研究人员还表示，除了机密的访问令牌外，攻击者还能够通过另外以及一种方法从持续集成构建日志中搜索词句如“不在 npm 注册表内”，“无匹配发行版本”以及“无法找到合法gem”，这些都是从 npm、PyPI 或 RubyGems 数据包仓库中找不到库时出现的错误信息。
研究人员表示，攻击者能够通过这种方法获取仍然用在活跃项目中的死数据包的名称。他们之后可以重新注册这些数据包，然后通过恶意库在合法项目中安装后门。
研究人员希望企业能够密切查看构建日志，可能也会找到之前错过的攻击方法。
安全研究团队表示，“这项研究帮助我们更好地了解了持续集成服务所展现的大规模的几乎就在眼前的攻击面。”
原文链接
https://www.zdnet.com/article/ci-build-logs-continue-to-expose-company-secrets/
声明：本文来自代码卫士，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
