12 Guidance in legacy code

Once you’ve grokked the fundamentals of the secure by design approach, you can start applying the concepts when writing code. This is usually easier when you’re doing greenfield development, but you’ll most likely spend a lot of time working on legacy codebases—codebases that weren’t created with a secure by design mindset. When working on such codebases, it can be difficult to know how to apply the concepts you’ve learned in this book and where to start.

In this chapter, you’ll learn how to identify some problems and pitfalls that we’ve found are common in legacy codebases. Some of them are easy to spot, and others are more subtle. We also provide you with tips and advice on how to rectify them. Some issues require more effort than others, so you need to choose your approach based on your situation. Hopefully this chapter will provide you with enough guidance to make that choice easier.

12.1 Determining where to apply domain primitives in legacy code

12.2 Ambiguous parameter lists

12.2.1 The direct approach

12.2.2 The discovery approach

12.2.3 The new API approach

12.3 Logging unchecked strings

12.3.1 Identifying logging of unchecked strings

12.3.2 Identifying implicit data leakage

12.4 Defensive code constructs

12.4.1 Code that doesn’t trust itself

12.4.2 Contracts and domain primitives to the rescue

12.4.3 Overlenient use of Optional

12.5 DRY misapplied—not focusing on ideas, but on text

12.5.1 A false positive that shouldn’t be DRY’d away

12.5.2 The problem of collecting repeated pieces of code

12.5.3 The good DRY

12.5.4 A false negative

12.6 Insufficient validation in domain types

12.7 Only testing the good enough

12.8 Partial domain primitives

No double money

Summary