8 Leveraging your delivery pipeline for security

 

This chapter covers

    • Security-style unit tests
    • A security perspective on feature toggles
    • Writing automated security tests
    • Why availability tests are important
    • How misconfiguration causes security issues

    Most developers agree that testing should be an integral part of the development process. This way, the perils of having a separate bug-fixing phase after development is avoided. Methodologies such as test-driven development (TDD) and behavior-driven development (BDD) have made it the de facto standard to execute thousands of tests each time a change is integrated. But for some reason, perhaps because security is an afterthought for many people, this only seems to apply to nonsecurity tests. In our opinion, this doesn’t make sense. Security tests are no different than regular tests and should be executed as frequently. This doesn’t mean you need a penetration test at every commit.1  Instead, you need a different mindset, where security concerns are seamlessly integrated into the delivery pipeline and exercised every time a change is made—and that’s what this chapter is about.

    1 A test performed on a system to uncover possible security weaknesses; see https://www.owasp.org/index.php/Web_Application_Penetration_Testing.

    8.1 Using a delivery pipeline

    8.2 Securing your design using unit tests

    8.2.1 Understanding the domain rules

    8.2.2 Testing normal behavior

    8.2.3 Testing boundary behavior

    8.2.4 Testing with invalid input

    Testing with input that causes eventual harm

    8.2.5 Testing the extreme

    8.3 Verifying feature toggles

    8.3.1 The perils of slippery toggles

    8.3.2 Feature toggling as a development tool

    8.3.3 Taming the toggles

    8.3.4 Dealing with combinatory complexity

    8.3.5 Toggles are subject to auditing

    8.4 Automated security tests

    8.4.1 Security tests are only tests

    8.4.2 Working with security tests

    8.4.3 Leveraging infrastructure as code

    8.4.4 Putting it into practice

    8.5 Testing for availability