微服务平台安全性提升_让我们提升软件安全性

微服务平台安全性提升

We’ve all heard, “Software is eating the world.” But, today let’s talk about a corollary: “Software bugs are the root of all evil.” Software developers certainly will be nodding their heads in agreement, but all of us from Luddites to gadget lovers need to consider how important it is to minimize the number of software bugs living in the wild, particularly when it comes to our online security and — as software continues to eat away — our physical safety, too. When software is key to the operation of our cars, highways, energy production, communications, personal memory storage, and entertainment, any bug that allows a bad actor to cause disruption is important to remove.

我们都听说过，“软件正在吞噬整个世界。” 但是，今天让我们谈论一个必然结果：“软件错误是万恶之源。” 软件开发人员当然会同意他们的意见，但是从Luddite到电子产品爱好者，我们所有人都需要考虑将生存在野外的软件错误的数量减少到最低程度的重要性，尤其是在涉及我们的在线安全性时-软件继续蚕食着我们的人身安全。 当软件对我们的汽车，高速公路，能源生产，通信，个人存储存储和娱乐活动至关重要时，必须消除任何可导致不良行为者造成破坏的错误。

There’s a whole segment of cybersecurity dedicated to trying to protect us from these bugs called Application Security, or AppSec.

整个网络安全领域致力于尝试保护我们免受这些错误的侵害，称为应用程序安全性( App Security)或AppSec 。

Let’s dig into this a bit more. Looking at Momentum Cyber’s 2020 CYBERscape, it breaks AppSec companies into two categories: WAF & Application Security and Application Security Testing.

让我们进一步研究一下。 回顾Momentum Cyber​​的2020 CYBERscape ，它将AppSec公司分为两类：WAF和应用程序安全以及应用程序安全测试。

I think a good way to look at the two groups are as companies that help identify bugs when software is being developed versus companies that help identify bugs when software is in production.

我认为看待这两组的一个好方法是，在开发软件时帮助发现错误的公司与在软件生产时帮助发现错误的公司。

When software is being developed, bugs can be identified and fixed before the release. If bugs causing security vulnerabilities make it into the wild and are then identified, these vulnerabilities have to be mitigated using additional tools and methodologies until new versions of the software are released.

开发软件时，可以在发布之前识别并修复错误。 如果导致安全漏洞的bug泛滥成灾，然后加以识别，则必须使用其他工具和方法来缓解这些漏洞，直到发布新版本的软件为止。

In an environment where office operations are becoming more distributed and virtual, we can no longer rely on many of the perimeter-based vulnerability mitigation methods of the past. When mitigation becomes more difficult, the best way to ensure safe and secure operations in today’s environment is to fix the problems in software during its development — before it’s released.

在办公室运营变得越来越分散和虚拟化的环境中，我们不再能够依赖过去的许多基于外围的漏洞缓解方法。 当缓解变得更加困难时，确保在当今环境中安全可靠运行的最佳方法是在软件开发过程中(在软件发布之前)解决问题。

It’s important to clarify that this discussion has expanded to cover much more than just application security. Typically, application security focuses on software applications running on the web, in the cloud, or on your laptop or mobile phone. Identifying and fixing software bugs before they are released covers a much broader topic of general software testing, which includes any type of software — web applications, desktop software, mobile apps, firmware, industrial control software, etc.

重要的是要澄清，此讨论已扩展到不仅涵盖应用程序安全性。 通常，应用程序安全性集中于在Web，云，便携式计算机或移动电话上运行的软件应用程序。 在软件错误发布之前对其进行识别和修复涵盖了通用软件测试的更广泛主题，其中包括任何类型的软件-Web应用程序，桌面软件，移动应用程序，固件，工业控制软件等。

Given the broad topic of software testing, let’s look at how testing fits into the modern Software Development Life Cycle (SDLC), and more specifically, how security-related testing fits in. Within the SDLC, there is the Code-Build-Test-Deploy iterative cycle. During this cycle, many types of testing tools and methodologies can be used:

给出了广泛的软件测试主题，让我们看一下测试如何适合现代软件开发生命周期 (SDLC)，更具体地说，是与安全性相关的测试如何适合。SDLC中包含代码构建-测试-部署迭代周期。 在此周期中，可以使用多种类型的测试工具和方法：

• Automated integration testing tools
  自动化集成测试工具
• Unit testing
  单元测试
• Behavior-driven or Test-driven software development
  行为驱动或测试驱动的软件开发
• Performance testing tools
  性能测试工具
• Lint tools (often built into integrated development environments [IDEs])
  Lint工具(通常内置于集成开发环境[IDE]中)

To handle running all the different types of testing along with the many build and deployment processes, development teams piece together a network of tools to attempt to create a seamless, automated process that can be run in an iterative fashion. When successful, the iterative process will provide feedback of the testing results to developers as quickly as possible directly into their IDE or their centralized bug-tracking tool.

为了处理所有不同类型的测试以及许多构建和部署过程，开发团队将工具网络拼凑在一起，以尝试创建一个可以迭代运行的无缝自动化过程。 成功后，迭代过程将尽快将测试结果的反馈直接提供给开发人员，使其直接进入开发人员的IDE或集中式错误跟踪工具中。

In more recent years, security testing tools have been added into this mix. Several subcategories of security testing tools are run at different stages in the SDLC:

近年来，安全测试工具已添加到此组合中。 安全测试工具的几个子类别在SDLC的不同阶段运行：

• Static analysis security testing (SAST): These tools scan code looking for patterns that have been identified as risky or have the potential to cause security vulnerabilities.

  静态分析安全性测试(SAST)：这些工具扫描代码以查找已被识别为有风险或有可能导致安全漏洞的模式。

• Dynamic application security testing (DAST): These tools run code to attempt to find security vulnerabilities. Often, these tools focus more on web applications and less on desktop software and firmware — but the concepts apply to all types of software.

  动态应用程序安全测试(DAST)：这些工具运行代码以尝试查找安全漏洞。 这些工具通常更多地侧重于Web应用程序，而侧重于桌面软件和固件，但这些概念适用于所有类型的软件。

• Interactive application security testing (IAST): These tools iteratively combine SAST and DAST techniques together. Again, these tools mostly focus on web application testing.

  交互式应用程序安全测试(IAST)：这些工具将SAST和DAST技术迭代结合在一起。 同样，这些工具主要集中在Web应用程序测试上。

• Database security scanning: As the name suggests, these tools scan databases in search for configuration and design weaknesses that can lead to security vulnerabilities.

  数据库安全扫描：顾名思义，这些工具会扫描数据库以搜索可能导致安全漏洞的配置和设计弱点。

• Penetration testing: Efforts typically run once software has been released into a testing or even a production environment where a mix of human-based and automated scanning efforts attempt to uncover security vulnerabilities. This often takes a more holistic testing view, often attacking the software and the infrastructure/environment it’s running on in the test.

  渗透测试：通常，一旦将软件发布到测试甚至生产环境中，就会进行努力，在此环境中，基于人的扫描和自动扫描的混合尝试会发现安全漏洞。 这通常需要更全面的测试视图，经常会攻击测试中运行的软件及其基础架构/环境。

Security testing is still relatively new and, therefore, is often not effectively integrated into the network of tools teams use to streamline and automate the SDLC. In addition, because security testing is so heavily oriented around automated scanning and automated weakness checks, these tools notoriously generate massive amounts of results, often not applicable within the context of the software. In addition, the different types of tools will often identify the same issues multiple times. As if these weaknesses were not enough to cause development teams to throw up their hands in frustration, organizations often wait until the end of the development cycle to run security tests. This violates today’s philosophies of integrating testing into the continuous iteration generally found in teams following agile methodologies.

安全测试还是一个相对较新的技术，因此，通常无法有效地集成到团队用来简化和自动化SDLC的工具网络中。 此外，由于安全测试的重点是自动扫描和自动漏洞检查，因此众所周知，这些工具会产生大量结果，通常不适用于软件环境。 此外，不同类型的工具通常会多次标识相同的问题。 似乎这些弱点不足以使开发团队感到沮丧，组织通常会等到开发周期结束才能运行安全测试。 这违反了当今将测试集成到遵循敏捷方法的团队中的连续迭代中的哲学。

These challenges scream for tools and processes that help better integrate security testing into the SDLC. Playing off the overused term “DevOps,” the industry has started using the soon-to-be even more cliché term “DevSecOps.” DevSecOps describes not only integrating the effort of managing and automating the SDLC, deployment, and management of the production system into one team, but also adding the responsibility of managing and integrating security testing and monitoring into the same team. The good news is that Gartner has created a great diagram showing how this works and the tools that may be used at each step in the process. It’s called the DevSecOps Toolchain.

这些挑战催生了有助于更好地将安全测试集成到SDLC中的工具和流程。 从过度使用的术语“ DevOps”开始，该行业开始使用即将变得更加陈词滥调的术语“ DevSecOps”。 DevSecOps描述的不仅是将管理和自动化SDLC，部署和生产系统的管理工作整合到一个团队中，而且还增加了将安全测试和监视管理和集成到同一团队中的责任。 好消息是，Gartner创建了一个很棒的图表，显示了它的工作方式以及该过程中每个步骤可以使用的工具。 它称为DevSecOps工具链 。

The diagram shows where in the process each of the different types of security testing tools and methodologies fit.

该图显示了过程中每种不同类型的安全测试工具和方法所适合的位置。

With so many types of security testing at different stages in the SDLC, the importance of having tools to help orchestrate and centralize this type of testing becomes clear. In today’s agile development projects, not using a build tool like Maven or Gradle or a continuous integration(CI)/continuous deployment (CD) tool like Jenkins to help automate the process would be considered crazy. Similarly, no team following a truly integrated and automated DevSecOps process should be without tools that orchestrate and centralize the management of the security testing processes.

由于SDLC中处于不同阶段的安全测试类型众多，因此拥有工具来协调和集中化此类测试的重要性就变得显而易见。 在当今的敏捷开发项目中，不使用Maven或Gradle之类的构建工具或使用Jenkins之类的持续集成(CI)/连续部署(CD)工具来帮助实现流程自动化的做法是疯狂的。 同样，任何遵循真正集成和自动化的DevSecOps流程的团队都不应缺少协调和集中化安全测试流程管理的工具。

You wouldn’t develop without using build tools to orchestrate the process. Why do security testing without a tool to manage it all?

如果不使用构建工具来协调流程，您将无法开发。 为什么没有工具进行全部管理的安全性测试？

This type of tool should handle orchestrating security testing and automate importing test results or production operation feedback all into one central repository. It should then correlate results; remove duplicates when the same problem is found using multiple testing techniques; prioritize the results so that only the most important can be the developers’ primary focus; and, finally, integrate with issue tracking, build, and IDE tools to quickly feed the prioritized insight to the developers in near real time. The faster and easier it is in feeding prioritized testing results back to the developers, the faster the team can go, thereby enabling more bugs to be fixed and increasing the security of the produced software.

这种类型的工具应处理协调的安全测试，并自动将测试结果或生产操作反馈全部导入一个中央存储库。 然后应将结果关联起来； 当使用多种测试技术发现相同问题时，删除重复项； 优先考虑结果，以便只有最重要的才能成为开发人员的主要重点； 最后，与问题跟踪，构建和IDE工具集成，以将实时的优先洞察力几乎实时地反馈给开发人员。 将优先的测试结果反馈给开发人员的速度越快越容易，团队可以越快越好，从而可以修复更多的错误并提高生产软件的安全性。

So, what is this tool? Can one get this capability from existing software test automation frameworks and tools? Maybe. But, software test automation tools often fall into a few buckets:

那么，这个工具是什么？ 可以从现有的软件测试自动化框架和工具中获得这种功能吗？ 也许。 但是，软件测试自动化工具通常分为以下几类：

• Unit testing frameworks: These frameworks, Like Mocha or Mockito, mostly focus on early SDLC testing. They help make unit testing and test-driven development (TDD) methodologies go quickly.

  单元测试框架：这些框架(如Mocha或Mockito )主要集中在早期的SDLC测试上。 它们有助于使单元测试和测试驱动开发(TDD)方法学快速发展。

• Functional testing framework: Selenium is the open source 800-pound gorilla in this space. Most tools focused on automated functional testing are web oriented and user interface oriented.

  功能测试框架： Selenium是该领域中的开源800磅大猩猩。 专注于自动化功能测试的大多数工具都是面向Web和面向用户界面的。

• Performance testing frameworks: While the previous two categories are solidly functional testing oriented, this category of tools tests how your software and infrastructure scale. Again, these tools (for example, JMeter, LoadRunner, and LoadNinja) are often web oriented.

  性能测试框架：尽管前两类都是以功能测试为导向的，但是这类工具可以测试软件和基础架构的扩展方式。 同样，这些工具(例如JMeter ， LoadRunner和LoadNinja )通常是面向Web的。

These categories generally focus on just one part of the SDLC. It’s not common to find a tool that will combine test results from both unit tests and automated functional tests, and the same tool certainly wouldn’t additionally combine manual test results or feedback from linting tools all into a centrally managed repository. Because security testing tools operate at many points throughout the SDLC, there is a needed ability to combine results from many tools, and the three categories of tools listed above are not well positioned to do this.

这些类别通常只关注SDLC的一部分。 很难找到一种将单元测试和自动化功能测试的测试结果相结合的工具，并且同一工具当然也不会另外将手动测试结果或来自皮棉工具的反馈都组合到一个集中管理的存储库中。 由于安全测试工具在SDLC的许多地方都在运行，因此需要一种将许多工具的结果组合在一起的能力，并且上面列出的三类工具并不适合这样做。

Then, do tools like this exist? As it turns out, Gartner defined a category of tools last year called Application Security Orchestration and Correlation (ASOC). While that is a bit of a mouthful, it does describe a nascent set of companies working on the types of security testing problems described above. These companies focus on this extremely important keystone capability — orchestrating and streamlining the development processes needed to reduce software bugs that lead to cyber risk and reduced physical safety.

然后，是否存在这样的工具？ 事实证明，Gartner去年定义了一种工具类别，称为“应用程序安全编排和相关性(ASOC)”。 虽然这有点令人mouth舌，但它确实描述了一组致力于上述类型的安全测试问题的新生公司。 这些公司专注于这一极其重要的基石功能-编排和简化所需的开发流程，以减少导致网络风险和物理安全性降低的软件错误。

At the cyber-focused startup foundry where I work, DataTribe, our bet is on Code Dx. It offers a solution that integrates with, by far, the most tools in the ecosystem. In addition, its platform focuses on orchestration, integration, and prioritization in a way that maximizes the speed of the feedback loop from security test results and bug discoveries back to the developer who needs to fix them.

在我工作的专注于网络的新兴铸造工厂DataTribe中 ，我们的赌注是Code Dx 。 它提供了一种解决方案，可以与到目前为止生态系统中的大多数工具集成。 此外，它的平台专注于编排，集成和优先级排序，以最大程度地加快从安全测试结果和错误发现到需要修复它们的开发人员的反馈循环的速度。

Also, a very cool benefit of using tools like this is that they allow organizations to more easily track security improving actions in the SDLC. These actions can be summarized in reports and dashboards for each development project. Unlike functional bugs, where customer satisfaction and feedback is a good measurement for whether software has too many bugs, organizations don’t want to wait for a breach or some other cataclysmic event to see if security bugs have been well mitigated. Proof of security testing best practices and adherence to industry compliance models are often demanded up front by executives and industry. As an example, by consolidating all security testing results, Code Dx provides a centralized system of record on all security testing, analyses, and bug-fixing activities with reports that show the security posture of each development project in an organization. So, not only does the platform enable development teams to reduce software security bugs, it provides a great solution for proving they’ve been reduced.

同样，使用此类工具的一个非常酷的好处是，它们使组织可以更轻松地在SDLC中跟踪安全改进措施。 可以在每个开发项目的报告和仪表板中总结这些操作。 与功能性错误不同，在功能性错误中，客户满意度和反馈是衡量软件是否存在过多错误的良好度量，组织不希望等待漏洞或其他灾难性事件来查看安全性错误是否已得到很好的缓解。 高管和行业通常经常需要安全测试最佳实践的证明以及对行业合规性模型的遵守。 例如，通过合并所有安全测试结果，Code Dx提供了一个集中的记录系统，记录了所有安全测试，分析和错误修复活动，并显示了组织中每个开发项目的安全状况的报告。 因此，该平台不仅使开发团队能够减少软件安全漏洞，而且还提供了一个证明已被减少的绝佳解决方案。

With everything becoming software, software bugs clearly are the root of most cybersecurity vulnerabilities in the wild. In today’s highly decentralized environment, the only way to mitigate these vulnerabilities is through fixing the bugs. It’s time for organizations that build software — big or small, regulated or not — to move to the next level of software development maturity and properly implement an automated, well-managed DevSecOps process.

随着一切都变成软件，软件漏洞显然是野外大多数网络安全漏洞的根源。 在当今高度分散的环境中，减轻这些漏洞的唯一方法是修复错误。 现在是时候构建软件的组织(无论大小，是否受管制)都可以升级到软件开发成熟度的下一个层次，并正确实施自动化，管理良好的DevSecOps流程。

Leo is the chief innovation officer at DataTribe, a cyber and data science startup foundry “Where the world’s best come to build dominant companies.”

Leo是 网络和数据科学初创企业 DataTribe 的首席创新官， “世界上最好的地方就是在这里建立主导公司。”

翻译自: https://medium.com/thawtspot/lets-level-up-software-security-7766935ada40

微服务平台安全性提升