devsecops_DevSecOps：使用自动安全性测试进行开发

devsecops

A key component of DevSecOps and identical to running unit tests to validate code after a build, running automated security testing after an application has been deployed (such as automated penetration tests) can provide us with a tool that identifies security risks. As we’ve seen recently, there’s been a growth of many companies experiencing information being compromised and with the development culture of “move fast and break things”, I expect this trend of successful attacks will continue. Before we look at our options for automating this testing, we want to be aware of its limits, evaluate the requirements, and consider common designs that are useful.

DevSecOps的关键组件与在构建后运行单元测试以验证代码相同，在部署应用程序后运行自动安全测试（例如自动渗透测试）可以为我们提供识别安全风险的工具。 正如我们最近所看到的那样，许多公司都在经历着信息被泄露的增长，并且随着“快速移动并破坏事物”的发展文化，我希望成功攻击的趋势将继续下去。 在查看用于自动化该测试的选项之前，我们希望了解其限制，评估要求并考虑有用的通用设计。

这不能解决零天 (This Does Not Solve Zero Days)

Before we look at how to add this to our build and deployment process, it is worth noting that automated security testing will not solve or prevent zero days. Zero days are unknown vulnerabilities that attackers exploit because they are aware of them, either through their own discovery or through an interaction (such as a financial interaction where a zero day is purchased). In the same manner, new attack techniques like Duqu 2.0’s attack from operative memory may not be detected either even if it’s not a zero day because the technique is unknown before the attack. New techniques and zero days are discovered after the fact sometimes because of a compromise. While this doesn’t mean we should avoid automated security testing, it does mean that we should be aware of the limits that our testing will have – we cannot know what we don’t know.

在我们研究如何将其添加到我们的构建和部署过程之前，值得注意的是，自动化安全测试将无法解决或防止零天。 零日漏洞是攻击者利用的未知漏洞，因为攻击者会通过自己的发现或通过互动（例如购买零日币的金融互动）意识到这些漏洞。 以同样的方式，即使不是零日攻击，也可能无法检测到来自活动内存的新攻击技术（例如Duqu 2.0），因为该技术在攻击之前是未知的。 有时由于折衷，在事后发现新技术和零时差。 虽然这并不意味着我们应该避免自动化安全性测试，但它确实意味着我们应该意识到我们的测试将具有的局限性-我们不知道自己所不知道的。

要求 (Requirements)

Before we can run automated security testing, we have to design a build process across our environments that allow us to execute automated security testing our application and database schema – in other words, our application design must follow from our lower environments of development through production. For an example, if our web application uses 20 procedure for CRUD operations and we want to run penetration tests against these stored procedures, if they’re completely different across environments, we’d have to run these tests in each environment. Will customers or clients enjoy a drastically slowed experience if we’re running penetration tests? More than likely not. However, there may be situations in which we will have to run automated security testing in an environment like production.

在运行自动化安全测试之前，我们必须设计一个跨环境的构建过程，以使我们能够对应用程序和数据库架构执行自动化安全测试-换句话说，我们的应用程序设计必须遵循从开发到生产的整个较低环境。 例如，如果我们的Web应用程序对CRUD操作使用20个过程，并且我们希望针对这些存储过程运行渗透测试，如果它们在环境之间完全不同，则我们必须在每个环境中运行这些测试。 如果我们进行渗透测试，客户或客户会享受大大减慢的体验吗？ 很有可能不会。 但是，在某些情况下，我们将不得不在生产环境中运行自动化安全测试。

When we consider running these tests in our environment, we want to account for some of the following:

当我们考虑在环境中运行这些测试时，我们需要考虑以下因素：

• Ceteris Paribus Design. We want to ensure that our design (application and database schema) match from one environment to another. There may be architectural reasons that they don’t, but if they don’t in anyway, we must note these because our automated security tests may give us inaccurate information
  Ceteris Paribus设计 。 我们要确保我们的设计（应用程序和数据库架构）从一个环境匹配到另一个环境。 可能有一些架构上的原因，他们没有这样做，但是无论如何，我们必须注意这些，因为我们的自动化安全测试可能会给我们提供不准确的信息
• Lifecycle Order. Order matters when we run our automated security testing. Using an example of penetration tests attempting SQL injection, we want to run these tests on a live development site after we develop and complete our new code. For example, if we ran the tests before we deployed new code, we would be testing old code. We’ll first build our web application to pick up the new code, run our unit tests to validate our code, deploy our web application, and then begin our security tests to check for SQL injection
  生命周期顺序 。 当我们运行自动化安全测试时，订单很重要。 以尝试进行SQL注入的渗透测试为例，我们希望在开发和完成新代码后在实时开发站点上运行这些测试。 例如，如果我们在部署新代码之前运行测试，那么我们将在测试旧代码。 我们将首先构建Web应用程序以获取新代码，运行单元测试以验证我们的代码，部署Web应用程序，然后开始我们的安全测试以检查SQL注入
• Scheduling. Development windows also matter since some penetration tests can consume huge amounts of resources in some cases. We may want to run these tests at the end of the development day, but we have to be careful because unit tests may fail and require fixes that don’t allow us time. The schedule of these tests can affect other developers in our environment, so we have to consider this as a major factor
  排程 。 开发窗口也很重要，因为某些渗透测试在某些情况下会消耗大量资源。 我们可能希望在开发日结束时运行这些测试，但是我们必须要小心，因为单元测试可能会失败，并且需要一些不允许我们花费时间的修复程序。 这些测试的时间表可能会影响我们环境中的其他开发人员，因此我们必须将其视为主要因素
• Limitations. When we run automated security tests to discover weaknesses, we should be aware of what we are testing along with what we are not testing for. Measuring the security of a website as an example runs deeper than simply testing for web or SQL injection, as attackers can use social engineering – something we can’t automate a test for
  局限性 。 当我们运行自动安全性测试以发现弱点时，我们应该知道我们正在测试的内容以及未测试的内容。 举例来说，衡量网站的安全性要比单纯测试Web或SQL注入更为深入，因为攻击者可以使用社会工程学–我们无法自动进行测试
• Reporting and Action Plan. When our automated security testing completes, we should report the findings in a manner for development teams to review. In addition, we must also have a plan of action if our testing identifies a weakness in our application. Some companies may find it appropriate to have a plan of action on the basis of the risk level of the findings, while others may plan for any security risks
  报告和行动计划 。 当我们的自动化安全测试完成时，我们应该以某种方式报告调查结果，以供开发团队进行审查。 此外，如果我们的测试发现我们的应用程序存在缺陷，我们还必须制定一个行动计划。 有些公司可能会根据发现的风险级别制定行动计划，而其他公司可能会计划任何安全风险

通用设计模型 (Common Design Models)

Once we know what we’ll be measuring, we can add automated security testing to our development and release flow. In the below image of a web application, we see a design where we have developers working in different branches that must be merged prior to a build. After the merge and build, our next step involves running unit tests that will ensure our code works correctly and when our code is validated, we deploy our application. Now that our web application is live, we’ll run our penetration tests and generate a report about the risks that we found. This design is only one model of running these tests because in some contexts, we may be able to measure security before we deploy the final product.

一旦知道要测量的内容，就可以在开发和发布流程中添加自动化安全测试。 在Web应用程序的下图中，我们看到一个设计，在该设计中，开发人员在不同的分支中工作，必须在构建之前合并这些分支。 合并和构建之后，我们的下一步涉及运行单元测试，以确保我们的代码正确运行，并且在验证我们的代码后，我们将部署应用程序。 既然我们的W​​eb应用程序已启用，我们将运行渗透测试并生成有关发现的风险的报告。 这种设计只是运行这些测试的一种模型，因为在某些情况下，我们可以在部署最终产品之前测量安全性。

In some cases, we may be able to combine our security testing with our unit testing. In this model we’re looking at our code specifically, not looking at our final product. This is an important point because the underlying assumption of this model is that we can evaluate the code to find weaknesses instead of testing the final product. Both may come with strengths and weaknesses and some stricter companies may prefer to use both of these techniques – running a code analyzer and running penetration tests after the final product is produced. Due to software library complexity, such as various software libraries used in software, it can be difficult to detect possible interactions ahead of time where penetration testing may be able to identify. However, this is only a concern in some situations: some software applications use few libraries or limit how their libraries are used within their application, making the below model appropriate.

在某些情况下，我们可以将我们的安全测试与单元测试结合起来。 在此模型中，我们专门查看代码，而不查看最终产品。 这一点很重要，因为此模型的基本假设是我们可以评估代码以发现弱点，而不用测试最终产品。 两者都有优势和劣势，一些更严格的公司可能更喜欢同时使用这两种技术-运行代码分析器并在最终产品生产后进行渗透测试。 由于软件库的复杂性（例如软件中使用的各种软件库），可能难以提前检测渗透测试能够识别的可能交互。 但是，这仅在某些情况下是一个问题：某些软件应用程序使用的库很少或限制了它们在应用程序中的使用方式，从而使以下模型合适。

I’ve seen appropriate situations where both models were combined: security code tests would run during the unit test step and following the deployment, penetrations tests would run. This adds cost in terms of time and provided we have the development window for this, it can add a more robust development build and release flow.

我已经看到了将两种模型组合在一起的适当情况：安全代码测试将在单元测试步骤中运行，而在部署之后，渗透测试将运行。 这增加了时间成本，并且只要我们有相应的开发窗口，它就可以添加更强大的开发构建和发布流程。

警告：保持测试安全 (Warning: Keep Testing Secure)

As the we know the answer to “what is the first rule of battle?” is “never reveal your position” we should consider how this applies to the security of our automated security testing. If our testing was compromised or discovered by the wrong actor, it would immediately reveal our position. Attackers would love to know what you automatically test for because for every strategy there is a counter strategy and this will never cease to be true. I would be extremely cautious about where these tests are run. We want to be careful about allowing even internal talent to have access to what is being tested – even if they can see a report of the possible weaknesses.

正如我们所知道的，“什么是战斗的首要规则”的答案。 “永远不要泄露您的位置”，我们应该考虑这如何适用于我们的自动化安全测试的安全性。 如果我们的测试被错误的参与者破坏或发现，它将立即显示我们的立场。 攻击者很想知道您要自动测试的内容，因为对于每种策略而言，都有一个对策，而且这种情况永远不会停止。 对于这些测试的运行位置，我将非常谨慎。 我们甚至在允许内部人才访问正在测试的内容时也要小心，即使他们可以看到有关可能存在的缺陷的报告。

结论 (Conclusion)

Although a key component to DevSecOps, automated security testing does not answer possible security compromises like zero days or unknown development techniques, it can reduce the risks of some attacks which we see frequently that involve code injection, weak authentication, misconfiguration, etc. For an attacker, we have to realize that these are “easy attacks” and the purpose of our tests is to give attackers a barrier to jump over. In some cases, the work to jump over these won’t be worth the results and they’ll find other more valuable targets.

尽管自动安全测试是DevSecOps的关键组成部分，它并不能解决零日漏洞或未知的开发技术等可能的安全威胁，但它可以降低一些我们经常看到的攻击的风险，这些攻击涉及代码注入，身份验证弱，配置错误等。攻击者，我们必须意识到这是“轻松攻击”，我们测试的目的是为攻击者提供一个越过障碍的屏障。 在某些情况下，跳过这些工作将是不值得的，他们会找到其他更有价值的目标。

目录 (Table of contents)

翻译自: https://www.sqlshack.com/devsecops-developing-with-automated-security-testing/

devsecops