数字代理商越来越关注他们正在开发的基础架构的安全性，并且也开始致力于确保应用程序的安全性。 您可能已经了解了提供信息安全性的漏洞，工具和方法的多样性和严重性。 但是，忽略或确保应用程序安全性如何影响自定义开发流程本身？
文章内容：我们将不会重复一百次为什么安全如此重要，存在哪些漏洞或在另一场战斗中红队如何击败蓝队。 这是一个简短的故事，内容涉及为什么我们要向自定义开发中添加安全性以及我们如何做到这一点。
该文章适用于谁？对于项目经理，技术总监，团队负责人以及与应用程序开发流程的组织有联系的每个人，本文可能都感兴趣。
免责声明：本文不是灵丹妙药，而是作者的个人观点（AGIMA信息安全负责人Alexey Klinov）。
一切如何开始
AGIMA长期参与质量控制程序和质量检查部门的全面开发。 我们所有的产品都经过大量内部检查：
- 在产品开发的每个阶段/冲刺之后使用清单；
- 我们通过自动测试网络涵盖关键业务功能；
- 我们尝试使用单元测试尽可能地覆盖代码。
- 我们使用符合标准的代码分析器（例如，对于PHP，它是PSR 0-4，等等）；
- 我们进行负载测试没有失败。
有关我们流程的更多详细信息，请参见
本文 。 但是，为什么我们决定添加另一个测试领域？
按客户许多客户自己搜索漏洞：他们使用仪器扫描仪或进行笔测试。 无论哪种方式，我们的代码和整个项目通常都会受到客户的各种检查。
支票的数量增加了，有关仪器扫描和笔测结果的报告也越来越多。 研究，复制，批准和修复漏洞会占用大量内部资源，并且可能会延迟数周。
当其他人正在开发项目时有时项目是从另一个承包商继承的。 他们可以处于预售状态，并且处于“战斗中”状态。 这项工作的责任已经在我们身上了，奇怪的是，漏洞和漏洞的整个“手推车”也已经存在。
我们建议在此方面拥有自己的专业知识，将更加高效，更便宜。
怎么了？
在开发时，我们专注于应用程序的质量，调试的速度和成本。 以代码分析的形式添加漏洞的其他元素，多条测试线或员工将影响这些指标。 鉴于业务利润率低，这对于定制开发至关重要。 同时，为了优化成本，产品安全控制方法应该是通用的，并应用于所有项目。 但是客户通常不会说“使我们与那里的那些人使用相同的应用程序，只有绿色”。 客户不仅想要他们的设计，而且想要功能。 此外，每个业务部门都有其自己的需求：在金融部门，医药和零售领域的应用需求是不同的。 每个项目的团队和技术可能会非常不同。
显然，产品安全控制可提高其质量。 但是安全性分析将如何影响项目的成本和时间安排？通过将代码的其他修订版本添加到估算中，与其他类型的测试一样，我们最初会使项目变得更加昂贵并增加了开发时间。 但是，这笔预算仍然必须花费，只是减少系统性和痛苦。 实际上，输出时的产品更加“清洁”，这减少了技术债务的水平，无需在笔测试后花费大量时间和资源进行精炼，因此，缩短了产品投入生产的时间。
展望未来，在我们的案例中，考虑到整个项目周期，实施安全性分析的成本更低，速度更快。 在某些项目中，成本降低了20％，其中包括减少了本地化漏洞的时间，甚至在代码审查小组领导之前就消除了这些漏洞。
决定寻找在我们的开发过程中实现信息安全的最佳方法。
第一步
我们对提高应用程序安全性的观点：
WAF和DDoS保护是产品上的附加保护层。 为了我们的目的，我们需要一个用于漏洞的代码分析器和一个笔测试。
小方块选择启动分析仪后，我们排除了付费的昂贵产品。 我们在
SonarQube （具有共享软件版本的分析仪）停了
下来 。 还有一个
云版本 ，但是免费版本使项目完全打开，在我们看来，这是不可接受的。
因此，要开始-SonarQube社区版。 它支持15种语言，包括Java，JavaScript，C＃，PHP和Python。 该解决方案的部署速度非常快，并且不会引起任何特殊问题，这将通过详细的
指南来帮助实现 。
便捷的权利区分系统：您可以建立访问每个项目的矩阵。
SonarQube使您可以观察项目的动态并存储分析历史。 我们自己可以为每个项目设置
质量阈值 ，这使我们可以优化不同项目的分析。
我们在多个项目上测试了该产品：
- 在当前项目中可能会发现一些明显的漏洞。
- 实施时间极短。
- 我们确保在CI的框架内返回代码以进行修订，以指示潜在的漏洞。
我们认为这足以满足我们的要求。
接下来是什么？
对于我们自己，我们确定了三种方法，这些方法根据项目和客户需求而有所不同：
- 完全集成到开发过程中（CI / CD）。
- 检查点的安全审核。
- 情境审核或一次性安全审核。
完全集成到开发过程中我们将解决方案集成到了GitLab中。 使用GitLab CI / CD来自动启动检查。 这需要免费的
Sonar GitLab插件插件 。 系统会通知开发人员验证失败的提交，并添加描述问题区域（漏洞类型，修复建议等）的注释。
其中一个项目实现了与Bitbucket和Bamboo的集成。 在这种情况下，需要付费
的竹子 Sonar和Bitbucket Server的Sonar插件。 测试操作完成后，客户已准备好支付额外费用，该解决方案非常适合技术堆栈。
理想的选择是在截止日期，预算和客户允许我们将安全流程集成到使用代码的日常周期中。 实际上，事实证明，此方法与频繁发布的项目的长期开发和支持有关。
检查点安全审核对于我们来说，这种方法最适合于很少发布（例如，每季度发布一次）的项目。 功能或产品要求在操作过程中可能会发生变化。 如果您不断查看代码的每一行以确保安全性，那么我们将在这些产品上花费很多额外的时间，我们和客户以后会拒绝这些产品。
我们与控制点有什么关系：
- MVP发展中的逻辑里程碑。
- 发布包含关键用户交互功能的产品特定版本。
- 特定的发行版，冲刺或一组冲刺，还具有与用户进行交互的关键功能。
在关键项目上，我们开始在断点处将集成分析与安全审核相结合。 因此，我们确定了在开发过程中可能不会引起注意的漏洞。
使用这种方法，当产品投入商业运营时，我们减少了调试的迭代次数。 我们正在准备一个更正和改进的通用库，其中包括功能错误，信息安全漏洞和基础架构要求。
我们在有和没有控制点的情况下，通过集成的IS验证程序收集了时间成本统计信息。 我们仅在生产环境中评估了调试和发布活动。
使用全面的方法，平均而言，需要两次调试。 它们的总持续时间约为总开发时间的15-20％。
将第三方连接到信息安全验证时，平均可以获得两次功能调试的迭代和三次调试信息安全漏洞/基础架构要求的迭代。 总计，这仅占我们开发时间的〜45％，不包括第三方花费的时间。
情境或一次性安全审核对于简单的项目，我们决定在最终发布之前对整个代码库进行一次一次性检查，以应用该方法。 降落足以在释放前检查一次。 在流程中实施代码扫描或对此类项目进行中间检查既昂贵又毫无意义。
此外，开始对从其他开发商转交给我们的项目进行情况审核。 在继续进行开发之前，我们将产品的现有技术债务降至最低。 之后，我们确定在项目的进一步开发中将使用哪种安全控制方法。
这是因为扫描了一个项目，该项目几年未经过完整的错误和安全性审核：
超过700个漏洞工件！ 当然，如果您滤除所有误报和次要伪影，而仅留下阻碍和严重问题，那么情况就不会那么糟糕了。 但这是技术债务的包,，无论如何都需要处理！
我们对漏洞进行排名并编制路线图，其中指出需要消除多少次迭代的关键漏洞。 这取决于它们所影响的代码，使用这些漏洞可以获取哪些数据。 攻击者利用特定漏洞的可能性有多大。
对于这种情况，我们花费了200多个工时来“筛选”并消除发现的漏洞，然后才开始进行全面的产品开发。 有时有必要解决这种情况，因为无知的代价更高。
我们不止于此：
- 为大多数项目添加了分析。
- 安全控制工具由Rostelecom-Solar的appScreener进行了补充。
- 为关键项目添加了手动审核和笔测试。
- 根据对应用程序安全性的影响，介绍了已实现功能的标准和关键程度组。
那接下来呢？在定制开发流程中实现信息安全的努力使我们受益：
- 我们为自己和客户降低声誉风险，从而最大程度地降低了入侵我们应用程序的可能性。
- 在第三方组织进行渗透测试之后，我们几乎已经消除了调试应用程序的漫长阶段。
- 我们已经提高了员工在信息安全领域的能力，并计划继续朝这个方向发展：培养新的安全领导者，丰富我们的知识库，完善我们的方法并尝试新方法。
- 与提供定制开发服务且没有信息安全能力的其他公司相比，我们获得了卓越的竞争优势。
我们越努力提高信息安全性，我们就越看到增长点：不仅在程序检查中添加了对TOP-10 OWASP和CWE / SANS的检查，还包括加快对安全公告的跟踪或教导我们的CI使用安全指南我们的框架。
我们已经举行了首个IB活动（
Rostelecom-Solar商务晚宴-AGIMA ），已经撰写了这篇文章，并计划像我们当时对自适应设计所做的那样，继续将新的实践推向我们的市场（请参阅
Adaptoz或我们的
自适应词典）设计 ，于2013年发布）-这种趋势始于我们，现在已经成为事实上的标准。 我们希望在信息安全方面也做同样的事情，因为“当您教别人时，您就会学习自己”。