在此过程中，经常有人问我们一个问题：如何在开发中实现静态分析器，以便
一切正常。
我们已经讨论了为什么需要使用静态分析仪来进行安全开发。 如果您选择静态分析器或已经计划实现它，那么本文将非常有用。 如何设置流程，以便最终解决在代码中发现的漏洞？ 在本文中，我们将尝试帮助您解决此问题。
会发生什么？
以稳定修复漏洞的方式实施分析仪并不是一件容易的事。 根据经验，可以说这需要几个星期到几个月。 如果您要在一家大型公司中使用该分析仪，请准备好进行一系列批准。 毕竟，这些都是需要分析的数百个代码库，还有数十个具有自己开发订单的团队。
要添加新的开发阶段-静态分析，您将必须研究每个团队的流程是如何工作的，并提供一个对每个人都方便的解决方案。 在小型公司中，既定的开发顺序可能根本不存在。 分析仪的实施可以成为构建过程的借口。 为了使集成更轻松，我们建议您找出哪个分析仪具有此功能。
有哪些集成选项？
通常，分析仪采用非图形界面（CLI，REST）以集成到任何流程中。 有些分析仪具有现成的集成功能：构建工具和开发环境，版本控制系统（Git，SVN），CI / CD服务器（Jenkins，TeamCity，TFS），项目管理系统（Jira）和用户管理（Active Directory）。 对您的公司越有用，设置所有内容就越容易。
您如何建立流程？
考虑一下标准情况：涉及的部门是信息安全，发布管理和开发。 通常，分析仪实施的客户是信息安全（IS）。 任务是就谁，何时何地做什么达成共识。 我们区分以下步骤：
开始分析，处理分析结果，创建修复漏洞的请求，修复漏洞，检查更正 。 更详细地考虑每个步骤。
步骤1.运行分析
您可以手动或自动运行分析。 方法各有利弊。
手动地他本人记得分析仪，他自己下载了代码，然后去看了看结果。
如果公司中有大约十二个项目，并且委派了一名安全员来监视安全性，则可能发生这种情况。 如果大约有一百个项目，则需要配置自动化。
自动化的确定分析代码的频率和时间。 例如，在进入生产性环境之前，根据给定的时间表（一周一次）或每次更改之后。
如果该应用程序很少更新，但是您还需要监视其安全性，请在进行任何更改时配置分析。
如果有很多人在编写代码，则创建了许多分支，经常涌入更改-最好经常进行分析，但不要干扰开发。 例如，在与主分支创建合并请求时或此分支上的任务状态更改时。 与版本控制系统或项目管理系统集成将为您提供帮助。 与CI / CD集成将使分析成为构建步骤之一。
设置时间表，以便您有时间处理结果。
步骤2.处理分析结果
不要指示开发人员立即修复发现的所有漏洞。 让安全人员首先对其进行验证。 第一次分析的结果似乎很糟糕：数十个关键，数百个不太关键的漏洞以及数千个误报。 在这里做什么？ 我们建议逐步修复漏洞。 最终目标是要在旧代码和新代码中都没有漏洞。 在初始阶段，请验证关键（仍然对它们不安全）和新漏洞（更易于修复新代码）。
使用过滤器。 按严重性，语言，文件和目录对漏洞进行排序。 更高级的工具将仅在新代码中向您显示漏洞，在第三方库中隐藏漏洞。 筛选器已应用，但仍有许多漏洞吗？
查看最可能的漏洞。 有分析仪评估误报的可能性。 如果存在许多漏洞，并且每个人的关键程度都差不多，请使用此指标过滤结果。 因此，您可以快速处理最可能的漏洞（请参见下面的屏幕截图）。
使用验证状态。 为了捕获验证结果，通常分析人员会提供该漏洞的状态：确认或拒绝为误报。 通常，应在重新扫描期间保留所做的工作。
步骤3.创建漏洞修复请求
如果开发人员开始分析其代码并立即修复漏洞，那么您当然无需创建不必要的请求。
如果安全员查看并验证结果，则通常需要设置一项任务来进一步纠正已确认的漏洞。 我们反复面对这样一个事实，就是在这一步骤中出现了困难。
索取表格有些公司的阶段大型任务固定在项目管理系统中（例如，Jira）。 对于子任务和错误，例如，使用了GitLab问题，只有团队负责人及其团队有权访问。 碰巧如果没有在项目管理系统中创建单独的任务，就不可能进行组装。 分析器可以集成，您可以在界面中立即创建必要的查询。
通常在同一家拥有众多开发小组的公司中，每个小组都有自己的执行工作任务的程序。 您需要适应所有人。 出现问题：
- 分配一个单独的项目来修复漏洞或在现有漏洞中创建任务是否值得？
- 漏洞是熟悉的错误还是新实体？
- 为每个漏洞创建单独的任务还是将相似的漏洞分组？
- 作为问题的描述，我应该给出什么：指向分析器界面中漏洞的链接或代码中的位置，并简要描述问题？
- 开发人员是否需要访问结果-只需发送带有“请参阅 第257页”就足够了吗？
当然，这取决于团队中流程的调整方式，使用的错误跟踪系统。
如果代码是由承包商编写的，而承包商对其内部系统的访问最少，则适合使用带有PDF报告的方案。 通常，您可以选择自己感兴趣的漏洞进行报告，然后立即将其从分析器界面发送到所需的地址。
如果公司不能不为具有一定资源量的特定类型任务创建项目就无法执行单个步骤，那么您应该为系统寻找一种集成工具。 最灵活的集成将为您生成任务说明（它们甚至不会忘记版本控制系统中源代码的链接），并使您能够填写所有必填字段。 选择任务类型，指定父项，艺术家，甚至发行版本。
人工成本及条款如果团队决定对每项任务的人工成本进行评估，则修复漏洞的任务也需要执行相同的操作。 在开发过程中，开发人员将验证漏洞。 有时在此步骤中，事实证明该漏洞是虚假的或无法利用。
但通常来说，资源仍然不足以立即修复所有漏洞。 因此，也有必要协调其优先事项。
这些任务由人工成本和优先级确定-然后负责发布日期的人员（可能是项目经理或同一团队负责人）决定要修复的内容和时间。 首先，如果不是所有漏洞都已修复，建议您使用分析器不要推迟发布。
步骤4.修复漏洞
如何适当地分配资源：结交新人或委托已经从事开发工作的人是一个预算问题。 有一件事是真的：如果公司为分析仪的安装分配了资源，则需要为修复漏洞付出准备。 一种可能的方法是花费时间来解决漏洞，以解决技术债务问题。
有两种方案：在开发过程中或在安全人员的要求下立即进行纠正。 在开发过程中修复漏洞是理想的方案。 立即发现-立即纠正。 开发人员在请求与主分支合并之前先扫描其功能分支。 这也可以通过集成来自动化：与开发环境，构建工具，版本控制系统或CI / CD。
另一种情况是在所有更改之后分析主开发分支。 安全员或团队负责人将审查结果并创建修复漏洞的任务。 这种情况比较耗时。 开发人员输入的是源代码，更正任务和分析结果。 对于开发人员而言，修复漏洞的任务与修复漏洞没有太大区别。
步骤5.验证修复
您需要确保该漏洞已真正修复，并且没有出现新漏洞。 有更正后的代码的分析结果。 寻找什么？ 漏洞的文件和行号？ 还是按漏洞名称搜索？ 这是可能的。 但是，如果更改了代码，则与该漏洞的界限可能会发生变化，并且仍然可能多次出现一个漏洞。 一些分析器可能显示“已修复”漏洞。 同意，因此您可以更快地检查漏洞修复（请参见屏幕截图）。
例子
这是两种可能的情况。
场景1
团队使用Git进行版本控制，使用Jira进行项目和任务管理。 Jenkins配置构建计划。 例如，分支机构每天有一次更改。 作为附加步骤，指示了分析仪的启动。
安全员审查主分支（主分支或开发）的分析结果，而开发人员则审查其功能分支。
如果有必要，开发人员可以修复漏洞。 如果分析仪可以按需过滤漏洞：仅显示新漏洞或不显示第三方库中的漏洞，在特定目录或文件中显示漏洞-开发人员将能够快速查看他感兴趣的结果。 因此，校正的可能性更高。
安全员检查主分支的分析结果。 通过与Jira集成，安全员可以从分析器界面创建漏洞管理任务。 接下来是期限和优先级的协调。
修复漏洞后，新代码通过了所有内部开发阶段（团队负责人的审查，用户测试和回归测试），安全人员必须确保该漏洞不再存在。 作者关闭已完成的任务。
方案2
公司代码由一组承包商编写。 Timlid通过电子邮件与开发人员进行交互，并使用GitLab进行版本控制。 承包商无权访问内部项目管理系统（Jira）。
安全官或团队负责人本人将审查主要开发部门的分析结果。 承包商无权使用分析仪。 如果存在需要修复的漏洞，安全人员将包含分析结果的PDF报告发送给团队负责人或立即发送给开发人员。
从该报告中，开发人员可以找到漏洞的位置，其组成以及如何修复。 对于与不安全数据流（例如，SQL注入）相关的漏洞，分发方案将被卸载到报表中是很有价值的：从数据源到它们在函数/方法调用中的使用（请参见屏幕截图）。
修复漏洞后，团队负责人通知安全人员，现在该检查重新扫描的结果了。
还有什么重要的？
建立信息安全与发展之间的互动。 双方有兴趣修复漏洞很重要。 好吧，这不仅是要求，而且是现场交流。
不要忽略用户角色。 好的分析人员应具有区分权利的能力。 承包商不太可能需要管理员权限或内部系统分析的结果。 编辑结果-更改关键性和状态-足以让安全员和团队领导。 最低特权原则尚未取消。
如果公司规模较大并使用用户管理系统（例如Active Directory），请考虑具有现成集成的工具。 您将能够重用公司中接受的角色和组，并赋予他们必要的权利。
结论
选择分析仪后，为仍然需要正确实施这一事实做准备。 不要害怕与参与者会面和协调：您在过程中了解得越多，结果就越有用。 重要的是，不仅要批准工作方案，还要开始遵循工作方案。
发布者：Solar appScreener首席分析师Elizaveta Kharlamova