The challenge for Day Twelve is – Read about security testing and discuss where it best fits in an SDLC.
This was an interesting challenge, as most people will agree that it’s important to perform security tests over an application, but when is the “best” time to test?
To dig deeper we will need to briefly compare some different Software Development Life Cycles:
In traditional waterfall models, testing often happens after all development has been completed and just prior to release.
This can prove to be a costly exercise if a serious flaw has been found. It requires testers to climb through the entire application from top to bottom, then report their findings to the developers to rework. This can cause a perceived bottleneck and be a source of friction within a team – not to mention push up the development hours for re-work and push up the cost of the build.
In agile, we break up the development into smaller chunks called sprints (usually 2 weeks to a month long) and the general idea is to release a small piece of functionality every sprint.
This allows testers to pick issues up early, and developers to remedy these issues rapidly. Having a smaller target to test means tests can generally be completed faster, and (in my opinion) more accurately than taking on the entire application at once.
Confucius says “the man who moves a mountain begins by carrying away small stones”
Wow, didn’t expect philosophy in a software testing blog did you?
So when should we test for security?
One relevant catch cry from my time with the NZ Navy was that “security is everyone’s responsibility” – when a development team adopts this approach from initial customer contact right through to release and ongoing support then the whole team “owns” security and makes it a priority rather than an afterthought.
Since starting my career in testing, I’ve only ever worked in Agile (scrum in particular) so I can only really comment on that flavour of SDLC.
Security needs to be considered right from the very start when discussing requirements with the customer.
Dissect what implications the design will have on security.
- Who is accessing the application, how are they using it, and for what purpose?
- Will users require different access levels/privileges? How is this assigned and protected?
- What data will the user be required to upload or download? How and where is this stored? How is it transported?
- Is the software subject to compliance? How does this affect the security requirements?
This will help guide what needs testing later on in development, and help to advise the developers to design the software with security in mind.
Once security concerns have been identified at the requirements phase, these items can be hunted down as soon as new code hits the floor. Source code analysis, pair reviewing, and UI testing are good options here.
It’s important to check these prior to release and again after release. Ideally your application will be released to a development environment which is a clone of the live environment, that way you can identify problems before they have a chance to roam free in the wild.
Some Continuous Integration / Continuous Development pipelines (like Jenkins or TeamCity) will allow automated checks to be included in the release, this is a good opportunity to run some automated security tests/scans for known vulnerabilities – but don’t rely on them to catch everything.
Another important point to consider is that security testing can’t necessarily be done in isolation. If another application interacts with your application, how does this affect the security of your application. Whenever a change is introduced, or something new added, the application’s security implications should be tested.
To sum up, security testing should be considered:
- When defining requirements
- When code is written and committed
- Post and Prior release
- When any changes or additions are made
…so basically all the time.
Thanks for reading my post and following my progress through the 30 Days of Security Testing.
Feel like joining in? Sign into the WeTest Slack group and get involved!