Security is Everybody's Job - Part 6 - The Second Way

For this and more, check out my book, Alice and Bob Learn Application Security and my online training academy, We Hack Purple!

The previous article in this series is here. If you are lost reading this article, read the whole series from the start. :-D This is a long post, sit tight!

The Second Way of DevOps is fast feedback. In security, when we see this we should all be thinking the same thing: Pushing Left. We want to start security at the beginning of the system development life cycle (SDLC) and ensure we are there (providing feedback) the whole way through!

Fast feedback loops means getting important information to the right people, quickly and regularly. One of the main reasons that Waterfall projects failed in the past was the lack of timely feedback; no one wants to find out twelve months after they made a mistake, then they can't fix it.

The goal of security activities in a DevOps environment must be to shorten and amplify feedback loops so security flaws (design issues) and bugs (code issues) are fixed as early as possible, when it's faster, cheaper and easier to do a better job. These DevOps people are really onto something!

Let's go over several ideas of how to achieve this.

• Activities to create fast feedback loops.
• Automate as much as humanly possible. Inside or outside the pipeline, automation is key.
• Whenever possible integrate your tools to the Dev and Ops team's tools. For instance, so that the issues found by your IAST tool are turned into tickets in the developer's bug tracking system.
• When you have a Pentest done check all your other apps for things in the report, then add create unit tests to look for these things
• Rename insecure functions or libraries as “insecure” with a wrapper, so programmers see immediately that there is an issue.
• Add security sprints to your project schedule (to fix all security bugs in backlog)
• Asking the Dev and Ops what they are concerned about (in relation to security), so you can fix any problems the security team might be causing them
• Add important security tests that are quick to the pipeline. For instance, scan for secrets in the code that is being checked in. That is an important test!
• If an important security tests fail in the pipeline, the continuous integration server must break the build. Just like quality tests. This is loud feedback.
• Create a second pipeline that doesn't release any code, but runs all the long and slow security tests, then have the security team review the results after and turn the important things into tickets for the Devs.
• Tune all security tools as much as possible and validate all results so that the feedback you are giving is accurate. There is no point of sending lots of feedback if half of it is wrong.
• Work with developers to create negative unit tests (sometimes known as abuse tests). Create copies of regular unit tests, rename them with "Abuse" at the end, then add malicious payloads and ensure that your app fails gracefully and handles bad input well.
• Have reports from your security tools automatically send their results to a vulnerability management tool such as Defect Dojo or Thread Fix to keep metrics and use them to improve all of your work. You need feedback too.

Be creative. Any way that you can get feedback faster to other teams is a huge win for your team too!

For this and more, check out my book, Alice and Bob Learn Application Security and my online training academy, We Hack Purple!