One of the common advice when trying to improve security at scale is to invest in QA. In this article, we are going to cover some aspects of it.
If you are looking for more application security-related content, make sure you check our previous article on Building Blocks.
Add some negative test cases
The simplest and most common advice around adding security using QA is to get your dev[ops] teams to write some negative test cases.
For example, let say you have a login page. Your test cases will most likely include:
- I can access the login page
- I can log in with a correct email address and password
- I cannot log in with an incorrect email address
- I cannot log in with an incorrect password and a correct email address
- I cannot log in with an empty password
- I cannot log in with a NULL password (think LDAP backend)
- …
These very simple test cases will ensure that you don’t have a terrible vulnerability in your login functionality. Furthermore, it’s very quick to do!
These test cases will also most likely be owned by the dev[ops] teams so they don’t incur any overhead for the security team.
Get your QA team to do some testing
Another way to get your QA team involved is to teach them some “hacking 101”. This can be very simple:
- They go through their usual tests using a proxy like ZAP or Burp
- Once they are done, they just click scan.
- They can then either look at the results or forward them to you.
You can imagine writing a very simple Burp extension to get those results directly to you or to an application that will do the triage for you.
The more time you will invest in teaching “hacking 101”, the more return on investment you will get. Even if you only really need to teach detection, it’s always a good thing to add a bit of exploitation to spice things up.
Just invest in QA!
If you check how much time it takes for a fix to go from git to your production environment, you will get an idea of the bottlenecks (security may be one). If this process takes too long (think a few days), you most likely have a QA issue: people are afraid to make changes.
The time you measured is the minimum time it will take to get a fix to production (unless it’s an emergency fix). If dev[ops] teams are afraid of changes, a lot of bad things happen:
- They don’t update libraries.
- They don’t update the underlying OS.
- They move to micro-services only to avoid making the changes they are afraid of.
- …
This is why as a security team, it can be worth investing in QA just for the sake of making deployment faster. If your dev[ops] teams are afraid of making changes, they will be afraid of fixing even the simplest bug. Making changes should be easy, predictable and boring. And to make changes easy, predictable and boring, you need good coverage. That’s why you should invest in QA.
