Global conferences such as RSA 2017 and the OWASP AppSec have convinced product engineering groups that “Security in DevOps” is the need of the hour. Security scanning tools & aggregation platform vendors are beating the drums on how their platforms bake security into the development pipeline by integrating with continuous integration (CI) and defect tracking tools used by engineering teams.
Interestingly, Engineering & Security have ‘by default’ been the usual suspects in building security into the development pipeline. QA never figures in the mix as it is assumed that their sole focus is on verifying product functionality and usability. More often, QA’s angle to security is from a feature’s security verification standpoint. For example, QA would ensure that security enhancements, like a token-based authentication developed by engineering as a feature, is verified, but would not perform checks on its threat vectors.
In order to achieve the proverbial “shift left security” there is a need to integrate security as part of the Quality Assurance ecosystem, taking advantage of QA’s tight integration with engineering.
The first change in paradigm towards this would be to position security vulnerabilities as defects. These defects can then be prioritized based on the criticality of the vulnerability and the potential damage that it can cause. In a DevOps environment, builds are continuously tested and any defects identified by QA are automated by employing test automation frameworks.
Security teams can bring efficiency in their testing schedules (aka reassign saved bandwidth) by leveraging QA's expertise in automation. Any defects found by security can be scripted and automated by QA. In many cases, a large part of automation scripts created by QA can be beefed up with security payloads, thereby reducing the effort of creating security automation scripts from scratch. Over a period of time, these scripts would act as a repository of security regression scenarios that can be run against every build of the application.
Additionally, since functional use cases are drafted at the requirements stage, security teams can augment efforts by creating associated security abuse cases. An abuse case aims at mirroring the way attackers would view the application by mapping out risks/threats that the application would face from a security perspective. The co-involvement of security and QA teams at the requirements stage in designing security test cases along with functional ones will help in building security-minded QA teams.
This practice (according to research findings) brings down the cost of fixing defects by identifying them in the requirements gathering phase, as opposed to post-release remediation which could potentially result in significant design overhaul and regression defects.
Fortifying applications is a daunting task, nevertheless not an impossible one. An effective way to secure applications is not by stopping with one-time baseline pen-tests for identifying security flaws, but to keep “shifting left” with each passing iteration of release to ensure that from conception to production, every phase of SDLC is secure.
