我们的漏洞管理方法
Atlassian 处理安全漏洞的方法
Atlassian 认识到，安全漏洞在某种程度上是任何软件开发过程中固有的组成部分。不过，我们一直致力于降低自有产品和服务中漏洞的严重程度和发生频率。
为此，我们将自动流程和手动流程相结合，制定了一种多管齐下的漏洞管理方法。在我们看来，这是一种最为有效的方法，可以限制漏洞“从指缝间溜走”长时间逍遥法外的可能性。
本文概述了我们如何管理产品和基础设施中的漏洞，以及如何通过整合最新的工具、方法和思维来不断改进我们的漏洞处理方法，确保这种方法在未来依然有效。
漏洞识别与解决过程概述
无论哪一种漏洞，我们都有一个有条不紊的流程来进行识别、跟踪和解决。
持续资产发现和归属
持续内部资产发现 - 我们使用内部构建系统，通过 AWsConfig 清点所有 EC2 和负载均衡器 AWS Asset，并将其归属于正确的负责人。我们保留一年价值的资产，总额为 5000 万至 6000 万。
识别漏洞
我们使用一系列出类拔萃的漏洞检测工具，这些工具定期在我们的产品和基础架构中运行，以自动扫描和识别漏洞。这包括 Atlassian Cloud 和 Data Center 产品、Docker 应用镜像、内部、移动和第三方应用，以及我们部署于本地和云端的基础架构。这些工具会自动扫描和识别存在的漏洞，包括：
- 基于主机的扫描 – 目前我们使用 Assetnote 对外部边界执行持续安全扫描，并使用 Tenable.io 同时对内部和外部进行持续扫描。这些工具用于识别在我们环境中运行的开放端口、服务和应用，以及网络主机上的漏洞。
- 容器镜像扫描 – 我们使用 Docker 容器来部署各种应用。一旦将容器镜像部署到我们的生产环境或预生产环境，我们便会对其进行安全扫描。为此，我们使用了一款名为 Snyk 的工具。本页稍后将提供更多详细信息。
- 开源依赖项扫描 – 我们使用 Snyk 来识别开源代码或第三方代码中可能存在的所有漏洞。本文稍后将提供更多详细信息。
- AWS 配置监控—我们在 Atlassian AWS 云环境中部署和集成 Lacework，以根据既定的基线为我们的 AWS 环境提供持续配置监控。
我们不断地审核可用的最新工具，如果认为它们能增强我们的漏洞检测能力，就会将其添加到我们使用的套件中。
除了运行自动化扫描外，我们还利用一系列其他手段来识别漏洞。其中包括：
缺陷赏金计划 – 通过 Bugcrowd 运行我们的缺陷赏金计划。通过 Bugcrowd，我们能够借助这个可信专家社区中数万名网络安全研究人员的力量，不断测试我们的产品，并报告发现的任何漏洞。我们的缺陷赏金计划在 2018 年和 2019 年被评为业界最佳。
客户和用户报告 – 我们产品的用户可以随时通过 Atlassian 支持报告遇到的任何缺陷。接到报告后，我们会与他们联系以收集所有必要的详细信息，从而在内部标记并修复漏洞（需要进行验证，以确保漏洞是真实的，而不是误报）。这也包括 Atlassian 员工，他们可以直接与安全团队联系或提交支持工作单，报告他们在我们产品中观察到的任何问题（无论是外部还是内部）。
外部渗透测试 - 我们邀请专业安全咨询机构对高风险产品和基础设施进行白盒和代码辅助渗透测试。有关更多详细信息，请参见“我们的外部安全测试方法”。
Atlassian 产品安全团队 - 我们会完成定向代码审查（包括手动和工具辅助），并与我们的产品开发团队密切合作，以加强他们在代码送达我们之前自行检测和解决漏洞的能力。
Atlassian 红色团队 – 我们在内部设立一个红色团队，负责模拟试图识别和利用我们系统、流程和环境中漏洞的对手，确保尽快识别和解决这些漏洞。
跟踪和解决漏洞
我们使用内部开单和上报系统来跟踪我们发现并打算修复的所有漏洞。具体而言，不论漏洞是通过某一款扫描工具还是上述其他手段识别的，我们都会为每个漏洞创建一个专门的请求单，并分配给相关产品团队寻求解决方案。我们在安全缺陷修复政策中发布的服务级别目标 (SLO) 修复方案会针对每个漏洞进行跟踪。
我们的安全团队负责监督此流程，并与产品和基础架构团队合作，确保漏洞的准确性并回答修复问题。
漏洞修复程序开发出来后会经过全面测试。然后，就我们的云产品而言，它会整合到我们的 CI/CD 管道以进行部署。对于 Data Center 产品，修复程序会被纳入新版本，并根据我们的标准发布节奏与其他修复程序一起定期部署。当后续重新扫描找不到漏洞时，扫描工具的漏洞工作单将自动关闭。当修复程序可供客户使用时，产品、基础架构或安全团队成员会关闭手动发现的漏洞工作单。
在开发过程中预防漏洞
容器镜像扫描
Atlassian 的大部分应用程序是使用 Docker 容器镜像来部署的。Docker 容器提供了一个封装的独立环境，包含相关的系统库、工具、配置设置和任何其他所需的依赖项，可以让我们的产品在运行时能够无视具体的机器配置参数。容器实际上提供了一个抽象层，将软件代码与底层基础设施分离，使我们的产品能够在不同的机器上毫无问题地运行。
容器能够部署可在各种不同环境中使用的代码，让开发人员和客户受益匪浅，但若其镜像中包含过时的或其他不安全的库或组件，它们可能会沦为安全漏洞的根源。
为了解决这个问题，Atlassian 集成了一个事件驱动的容器安全扫描流程，该流程通过我们的 Micros 部署平台对部署到生产环境中的任何容器的进行部署监控。此外，开发人员还可以将扫描流程集成到我们开发环境中部署的任何容器的 CI/CD 管道中。为此，我们使用 Snyk 容器引擎。Snyk 提供了一套工具，可对我们开发人员部署的任何容器镜像进行深入检查。这包括对这些镜像进行详细分析，以确定它们包含的各种组件，并确定哪些存在已知的漏洞。
开源依赖项
尽管发现和修复自己代码中的漏洞很重要，但我们的产品和服务也依赖于众多第三方库。因此，了解我们正在使用哪些库，并确保更新为最新的安全缺陷修复程序，这也同样重要。我们使用名为 Snyk 的工具来帮助我们解决这个问题。Snyk 提供的扫描程序可以识别我们任何软件版本中的依赖项，再将这些库与已知安全漏洞的数据库进行比对。
根据此页面上述的漏洞管理流程，任何识别到的漏洞都会由正式的 Jira 工作单自动提交给相关的产品团队。
用于帮助应对漏洞的其他举措
到目前为止，本文大体描述了我们在“后端”采取的漏洞管理步骤，即我们为解决产品或平台中识别的漏洞所采取的措施。不过，我们也一直致力于从源头开始降低漏洞的发生频率。为此，我们在开发过程的“前端”融入了一些独特举措，以确保我们的产品从设计之初就以安全为重。
产品安全工程师
如果不阐述我们产品安全工程师在消除缺陷和设计更好工具方面发挥的关键作用，那么关于漏洞管理的讨论就不会完整。
我们的产品安全工程师将对新报告的漏洞进行初步分类，并与我们的产品工程团队合作，确定问题的最佳修复方案。我们的产品安全工程师遍布全球，他们是应用程序安全领域的学科专家，可以根据需要与我们的产品工程师进行高效协作。
对于所分配的产品，安全工程师同时发挥主动和被动安全保障作用，包括但不限于：
- 查看和分析最新的威胁模型，了解新生和紧迫的风险
- 审查和分析新功能的安全性
- 执行手动代码审查
- 执行渗透测试
- 执行平台和架构审查
- 跟踪与项目有关的重要活动，并在必要时提供指导
- 分类、归档、奖励并确保及时解决通过我们缺陷赏金计划报告的问题
- 编写新的自动化并且维护现有的自动化和工具，以最大限度地增大覆盖面和提高效率
安全记分卡
利用从本文所述的系统中收集的数据，我们能够在团队和产品之间相互进行基准测试，从而主动识别需要改进的地方。
总结
Atlassian 采用一种多管齐下的方法来管理我们产品和平台中的漏洞，结合使用自动化扫描工具、缺陷赏金计划，以及各种不断改进的其他机制，确保我们能够尽快识别和解决出现的漏洞，并尽可能从源头开始减少漏洞出现的频率。
想要深入了解？
想要深入了解？
本文提及了诸多其他资源，您也可以另外查阅这些资源来获取有关我们漏洞管理方法的更多信息，或者更广泛地了解安全性。
- Atlassian Trust Center
- Atlassian 安全漏洞修复政策
- 外部安全测试方法
- 持续交付
- 安全公告
- Atlassian 缺陷赏金计划
在此页面上，当我们提到漏洞时，它可与“缺陷”(bug) 互换使用，后者是我们另外一篇关于安全测试方法的文章中使用的术语。