This chapter argues that security must be woven into the delivery pipeline so it is exercised on every change, just like other quality checks. Rather than performing occasional, heavyweight penetration tests, teams should automate security feedback across build, test, and deploy stages, ensuring consistent execution and preventing steps from being skipped. The result is rapid insight into security posture and earlier discovery of flaws. The chapter then shows how to apply this mindset to day-to-day development practices, from unit-level design to pipeline-wide safeguards.
Designing with a security lens begins at the unit test level. Beyond verifying intended behavior, developers should test normal, boundary, invalid, and extreme inputs to catch unintended behavior where vulnerabilities lurk. A worked example of an email address domain primitive demonstrates crafting explicit domain rules, validating length before parsing to avoid performance pitfalls, and rejecting malicious payloads (for example, SQL/XSS-like inputs). The chapter also addresses feature toggles: toggles change system behavior and can accidentally expose unfinished, unauthenticated features in production. The guidance is to write automated tests for every toggle, minimize their number, verify all meaningful combinations, protect and audit runtime controls, and add these tests to the pipeline.
At the pipeline level, “security tests are just tests.” The chapter outlines application-focused and infrastructure-focused checks, integrates security scanners and dependency analyzers, and recommends using infrastructure as code to make environment changes reproducible, reviewable, and testable in preproduction mirrors. It highlights availability as a security concern, advocating headroom estimation, load/DoS simulations, and awareness of “domain DoS” where legitimate rules are abused at scale. Finally, it shows how misconfiguration—unintentional, intentional side effects, or misunderstood defaults—causes security issues, and urges automated verification of configuration hot spots (such as HTTP headers, TLS, parsers, authentication) and of framework defaults, with all such tests running continuously in the delivery pipeline.
Figure 8.1. Example of a delivery pipeline
Figure 8.2. Feature toggles let you switch between features or turn them on and off.
Figure 8.3. Security tests are no different than other tests.
Figure 8.4. Denial of service attack (DDoS, but more commonly referred to as DoS attack)
Figure 8.5. Underlying causes for security flaws induced by configuration
Summary
- By dividing tests into normal testing, boundary testing, invalid input testing, and extreme input testing, you can include security in your unit test suites.
- Regular expressions can be sensitive to inefficient backtracking and, therefore, you should check the length of input before sending it to the regular expression engine.
- Feature toggles can cause security vulnerabilities, but you can mitigate those vulnerabilities by verifying the toggle mechanisms using automated tests.
- A good rule of thumb is to create a test for every toggle you add, and you should test all possible combinations of them.
- You should watch out for the combinatory complexity that large numbers of toggles can lead to. The best way to avoid this is by keeping the number of toggles as small as possible.
- The toggle mechanism itself can be subject to auditing and record keeping.
- Incorporating automated security tests into your build pipeline can give you the ability to run a mini penetration test as often as you like.
- Availability is an important security aspect that needs to be considered in every system.
- Simulating DoS attacks helps in understanding weaknesses in the overall design.
- A domain DoS attack is extremely difficult to protect against because it’s only the intent that distinguishes it from regular usage.
- Many security problems are caused by misconfiguration, and the cause for faulty configuration can be either unintentional changes, intentional changes, or misunderstood configuration.
- Configuration hot spots are good indicators for finding areas in your configuration where testing is most critical.
- It’s important to know the default behavior of the tools you use and asserting that behavior with tests.
Secure by Design ebook for free
