我们在零售商中建立安全的发展。一个大项目的经验

不久前,我们在俄罗斯最大的零售公司之一中基于我们的应用程序代码分析器完成了安全的开发流程。我们必须承认,这种经历是困难的,长期的,并且为工具本身的开发以及我们的开发团队执行此类项目的能力提供了强有力的突破。我们希望在一系列文章中与您分享这种经验,包括实践中如何发生,我们踩到什么耙子,如何摆脱困境,最终给客户和我们带来什么。总的来说,让我们谈谈实现本身的实质。今天,我们将重点关注零售商门户和移动应用程序的安全开发。







首先,关于项目。我们已经在一家大型贸易公司中建立了一个安全的开发流程,在该公司中,IT部门拥有大量员工,并且被划分为许多相互关联程度最低的区域。按照惯例,这些区域可以分为3个主要组。第一个是一个很大的群体,是收银软件,它主要用Java语言编写(占项目的90%)。就代码量而言,第二个最广泛的系统组是SAP应用程序。最后,第三块是门户和移动应用程序的“大杂烩”:公司客户的各种外部站点,这些站点的移动应用程序以及内部资源-零售商员工的移动应用程序和Web门户。



项目的客户-信息安全部门-以相当标准的方式为所有三个小组制定了一般任务:“我们希望在输出时减少漏洞,并确保公司内部所有系统的安全开发”。但是实际上,在每个特定部门,一切看上去都与其他同事截然不同,因为在实施安全开发的每个步骤中,我们必须做出一百万种不同的折衷方案。有些细微差别有助于建立流程,相反,其他细微差别则干预了这一过程。最后,我们仍然设法为大多数项目创建或多或少的通用方法。



我们尽可能简化了这种方法:扫描所有开发人员最相关的代码。如果我们用Gitflow来表示,除SAP之外,所有项目组都在Gitflow中有开发分支,则按计划扫描主要开发分支。



但是,一如既往,任何规则都有例外:由于多种原因,无法将通用方法“按原样”应用于所有地方。首先,由于我们希望在必要时能够对某些编程语言进行最深入的分析,因此我们的工具(代码分析器)有几个局限性。因此,在Java的情况下,分析字节码比源代码要深得多。因此,扫描Java项目需要预先组装字节码,然后才将其发送以进行分析。对于C ++,Objective C和iOS应用程序,在构建阶段将分析器内置到该过程中。我们还必须考虑所有项目开发人员的各种个人要求。下面,我们将描述如何构建门户和移动应用程序的过程。



门户和移动应用



似乎所有这些应用程序都组合到一个逻辑组中,但实际上它们是一团糟。有超过120个门户(!)。该公司非常庞大,拥有许多业务,行政和技术部门,每个部门都不时决定自己需要自己的门户和移动应用程序。该门户网站和应用程序已创建,使用了一段时间,然后安全地放弃了。结果,在最初阶段,我们不得不为客户进行盘点,因为即使这些应用程序的开发人员也没有一个代码库清单。例如,为了管理该组中的存储库,开发人员使用了两个具有不同管理员的GitLab。此外,在门户网站和移动应用程序中,很大一部分项目是使用外部开发来实施的。因此,当发布时间临近时,承包商经常将新版本的源代码几乎通过闪存驱动器传输给公司。结果,该公司拥有各种应用程序的动物园,并且其代码完全混乱。我们必须列出所有项目,找到负责这些项目的所有人员-技术所有者,团队负责人,然后与主要客户达成一致-信息安全部门,我们将分析其中的哪个。



结果,我们选择了生产系统和支持的软件进行分析,而根本没有涉及归档系统。许多内部应用程序被认为是不重要的,因为它们不会对公司造成任何财务损失,因此没有被选择进行分析。例如,一个仓库或装载机内包装工的管理系统。他们中没有任何一家公司容易受到外部客户的攻击,内部员工之一对他们的黑客入侵只会给许多部门带来轻微的内部不便。



IS服务已将针对漏洞的代码分析引入作为该软件组和开发人员的优先任务,以构建集成到开发周期中的便捷验证过程。



按照标准方案整合



两个不同版本的GitLab在门户和移动应用程序组中用作版本控制系统。





设置与GitLab的集成



并非所有应用程序都使用CI / CD,如果不是,则必须坚持使用CI / CD。因为如果您要真正自动化检查代码是否存在漏洞的过程(而不仅仅是手动上载链接以进行分析),以便系统本身将其下载到存储库中并将其结果提供给必要的专家,那么您就必须安装安装运行程序。在这种情况下,赛跑者是自动联系版本控制系统,下载源代码并将其发送到Solar appScreener进行分析的代理。



门户和移动应用程序组的开发人员希望将安全开发组织为半自动化过程,以便扫描代码中的漏洞,而无需他们参与。如果安全人员认为漏洞很关键,则可以验证安全漏洞的分析结果,并将任务分配给Jira中的开发人员,或者将其发送给开发人员进行澄清。开发人员将决定是否需要紧急修复此漏洞。并且,如果有必要,他们将计划在哪些发行版中包含这些修补程序。



Jira主要用作错误跟踪器,代码分析器会自动向其中提供有关所发现漏洞的信息。





Jira集成设置



在极少数情况下,团队负责人会自己查看爬网结果并手动在Jira中启动任务。





在Jira中创建任务



我们还在法规中将此类案例注册为单独的功能。通常,在某些项目中,所有修复都以Slack或Telegram进行了讨论,并且任务是实时设置的。



结果,在Solar appScreener实施之后的安全开发过程开始看起来像这样:每天检查门户网站是否有主要开发分支代码的更改。如果主要的,最相关的分支在24小时之内没有更新,那么什么也不会发生。如果已更新,则将该分支发送到该存储库的相应项目进行分析。 GitLab中的存储库对应于代码分析器中的特定项目,并且在那里扫描了主分支。此后,安全员检查了分析结果,对其进行了验证,然后开始在Jira中进行更正。





在Jira中创建的分析结果和漏洞修复任务



通常,我们从关键的漏洞开始修复漏洞,这些漏洞需要紧急消除。当此类漏洞结束时,团队继续修复代码中发现的新错误。例如,在第三阶段,在关闭一些技术债务的框架内,旧的遗留漏洞也被消除了。



非标为标



乍看之下,这不是很复杂的过程有两个严重的局限性。首先,要分析Android应用程序(即用Java编写),我们需要一个程序集。其次,iOS需要在其上安装我们的代理的macOS机器,并且存在允许我们构建应用程序的环境。我们处理Android应用程序的方法非常简单:我们将各部分写入开发人员已经可用的脚本中,这些脚本也根据计划启动。我们的脚本部分已经开始以最广泛的配置构建项目,然后将其发送到Solar appScreener进行分析。为了检查iOS应用程序,我们在Mac机器上安装了MacOS代理,该Mac代理会汇编代码并将代码发送到分析仪,以通过GitLab CI进行扫描。此外,与其他类型的软件一样,安全人员审查了分析结果,对其进行了验证,并将修复问题提交给Jira。



我们还将门户和移动应用程序称为用Java编写的任何项目-我们以类似的方式收集和分析了它们。



在那些没有CI / CD的项目中,这是我们的先决条件,我们简单地说:“伙计们,如果您要分析,请手动收集它,然后将其自己加载到扫描仪中。如果您没有类似Java或JVM的语言-Scala,Kotlin和其他语言,则只需从链接将代码上传到存储库,一切都会好起来的。



项目的复杂性



从上面可以看到,在此应用程序堆栈中,主要问题是许多项目中缺少CI / CD。开发人员经常手动进行构建。我们开始将分析器与C#中的Sharepoint门户集成。现在C#或多或少已经切换到Linux系统,尽管还不十分成熟。当项目进行得如火如荼时,该语言仍适用于Windows,因此我们必须在Windows上为GitLab安装代理。这是一个真正的挑战,因为我们的专家已经习惯了使用Linux命令。需要特殊的解决方案,例如,在某些情况下,有必要指定exe文件的完整路径,在某些情况下则不是,必须屏蔽某些内容,等等。在与Sharepoint集成后,PHP中的移动应用程序项目小组说:他们也没有跑步者,他们想使用C#-ovsky。我也不得不为他们重复操作。



概要



结果,尽管技术,团队和流程如此多样化,我们还是设法将本案例的主要案例归纳为多个管道,在适当的情况下自动执行并实施它们。在我们的示例中,我们能够确保:



  • 我们正在实施的解决方案已经过时,可以提供在完全不同的部署环境中构建DevSecOps流程所需的灵活性。灵活性是通过大量的内置和自定义集成来实现的,如果没有这些集成,则实现的人工成本将显着增加或无法实现。
  • . 3-4 ;
  • DevSecOps DevOps , , . win-win - .


回想一下:这是有关在大型零售商中建立安全开发流程的系列文章的第一部分。在下一篇文章中,我们将揭示SAP应用程序系列中该项目的实施细节。



您是否有实施类似项目的经验?如果您在评论中与我们分享您实施安全开发实践的案例,我们将非常高兴!



作者:Ivan Staroselsky,信息系统运营和自动化部主管



All Articles