Manage security debt and write some documentation!

For most people, writing documentation is boring! But what if I told you that writing technical documentation helps reduce security weaknesses? Writing down some notes also makes you a better baker.  

What is security debt?

Security debt is the accumulation of insecure design choices and vulnerabilities in software. Security debt can result from missing security updates or not identifying and assessing the threats related to the system. Also, hurrying up to finish the project with the idea of ‘fixing the problems later’ causes security debt.

Examples of such security debt include:

• Using end-of-life components
• Using components with known vulnerabilities
• Storing plain-text passwords and keys in source code
• Using default credentials
• Not documenting the assumptions taken about security threats and the usage environment.

The first four examples are relatively simple to find with software composition analysis, static code analysis, or source code reviews. But the last one, not documenting the assumptions taken about threats, is the worst kind of security debt. Let me explain.

Poor documentation can result in security debt

Imagine a project where a customer asks you to build something new. You are trying out different things and creating a proof-of-concept. At this point, the customer, let’s call them Customer A, gets excited and thinks you are nearly ready with the new product. Now you are in a hurry to get your product in working condition. Since the product will be installed in an exceptional customer environment, in a factory network not connected to the internet, you decide to cut some corners regarding security to save time because the risks will be small. You finish the project in time, Customer A is happy, and you move on to do other things.

Next year, another customer, Customer B, approaches your company with something a bit similar to the previous project I just described. Everyone thinks it’s possible to modify the solution created for Customer A to cater to that need. The original project team is not available anymore because they are heavily involved with another project. Surely, the other developers are just as capable of doing the modifications: they have experience, and there will be documentation to help them, right?  

This time, however, the product is connected to the internet. The previous team had not documented that they had based their design choices on using an isolated network environment. Suddenly, the end-of-life component, weak credentials, and open ports matter much more. Remote code execution, lateral movement, ransomware, boom! Customer B is not happy. 

What can you do to manage security debt?

You might not get rid of security debt entirely, but you can reduce it to a manageable level. In your team, you can start including these tasks into the backlog or even acceptance criteria of your development items: 

• Threat model the new features. You can read more about threat modeling from my previous blog post, Threat modeling baking – when bread falls on the buttered side.
• Document the threats and estimated risk levels.
• Write down design and technology choices, especially when there is a particular reason, such as scalability, performance, or working in a unique or isolated environment.
• Perform regular vulnerability scanning on application, operating system, and network levels. Of course, you should patch the vulnerabilities you find.
• Search for vulnerable dependencies from open-source libraries and update those components. Tools such as Github Dependabot, Snyk, or OWASP Dependency Track help in this task.
• Use secure coding practices, such as implementing proper error handling, input validation, and output encoding.

As you can see, many of the above tasks involve documentation and sharing knowledge. Writing documentation does not mean that you need to write a novel. A few selected lines can be quite enough!

There’s also ‘baking debt’ 

I admit I have a shortcoming when regarding documenting my baking. I might modify a recipe I have spotted in a magazine or a cookbook or scale the amounts up or down to get suitable portions. However, I don’t bother writing down the correct amount of ingredients, and I need to figure it out every time. Even worse, I might have scribbled down something unintelligible. Luckily, the threats in baking aren’t that horrible: check my earlier post for examples. 

There is also the case of spinach and feta cheese pie. Around five years ago, I think I must have baked an exceptionally tasty pie because one of my friends still remembers it. However, I have no recollection of where I got the recipe. Now I wanted to bake this delicacy again. But how? 

Spinach and feta cheese pie 

After combining a few recipes I tested the following recipe that borrows ideas from Kotiliesi. I think that putting slightly more spinach would not hurt, though.

Crust:

• 125 g pastry margarine
• 3 dl wheat flour
• 3 tbsp water

Beat the pastry margarine and flour. Add the water and keep mixing until the dough becomes solid. Let the dough cool in the refrigerator while you prepare the filling. 

Filling:

• A small piece of leek
• One glove of garlic
• 150 g frozen spinach
• 170-200 g feta cheese
• 2 dl whipping cream
• 3 eggs
• 1 dl milk 
• Salt and pepper
• Some cooking oil

Melt the frozen spinach and strain the excess water. Heat a bit of oil in a pan and cook the chopped leak and garlic for a few minutes. Add the spinach and season with salt and pepper. Heat until there’s no excess water left. Let the mixture cool.

Bake the pie at 200 ºC for 15 minutes. Enjoy!