“Experience is merely the name men gave to their mistakes.”
– The Picture of Dorian Gray
In 2020, there were 3,950 breaches:
Also in 2020, 67% organisations reported that the volume of cybersecurity incidents has significantly increased since 2019. 64% said the same about severity. Another 51% stated that they were significantly disrupted by a cyber attack in the previous two years.
By the end of 2020, global losses from cybercrime totaled over $1 trillion, a greater than 50% increase over 2018.
All these facts prove that today, organisations are vulnerable to an expanding threat landscape, so they can’t afford to be blasé about security. Software organisations in particular must be extra careful about the security of their products. And yet, security vulnerabilities continue to persist in the Software Development Lifecycle (SDLC), with a majority of applications (76%) containing security flaws. The reason? There are several:
The fact is, the old approach to security, where it was bolted on later to speed up time-to-market, is now inadequate and even dangerous. This approach results in code that leaves the final application vulnerable to cyber attacks and data breaches.
Instead, software orgs must shift left by including security QA testing earlier in the SDLC. With this new, proactive approach, security is baked in from the outset, so vulnerabilities are found and fixed faster. This makes the code - and therefore, the final application - more robust, market-ready and useful. To meet these goals, training QA testers to focus on security is absolutely vital.
Traditionally, QA testing focused on whether the software application is performing the functions as expected.
This focus on functional appropriateness was adequate in the old days, when the SDLC was usually based on a simple Waterfall model with uncomplicated processes, long release cycles, and little or no cybercrime. This is not enough today.
Unlike QA testing, AST (or simply security testing) is about identifying vulnerabilities in the software that could be exploited by bad actors to carry out malicious actions against the application and organisation. These vulnerabilities include SQL injections, cross-site scripting (XSS), cross-site request forgery, hard-coded passwords, buffer overflows, weak encryption, and more.
Vulnerabilities such as these are analysed, tested, and remediated by security researchers around the world on a continual basis, with the information gleaned made public for the benefit of the broader internet community. Refer to the OWASP Foundation for the latest information of vulnerabilities that must be factored into any security testing regime.
Different types of security testing have evolved to keep pace with the evolution of different types of security threats. The need for comprehensively skilled security testers is high and knowing the different facets of testing can assist when evaluating and implementing your hiring process. Included in the overall Security Testing process are the following:
Today, it’s vital to consider security and security-related defects as a QA issue. Software quality and software security should not be seen as separate areas, but as two sides of the same coin. And along with thus duality is the necessity for them to both commence early on in the process, i.e., for effective security testing, one must initiate it from the beginning of the SDLC.
One crucial reason for this is that software with quality defects is also likely to contain security vulnerabilities. Both affect code quality, which then causes the application to behave in unpredictable ways (which translates to poor performance), and also affects the User Experience (UX) and usefulness of the final product.
And worst of all, buggy software that annoys the end user could very well become a “magical portal” for an attacker to exploit, and cause untold damage and chaos.
Another reason to bring security and QA together is that leaving security testing for the end phases of SDLC increases the risk that any vulnerabilities will either:
On the other hand, closer collaboration between development, QA, and security testing allows the organisation to successfully shift left, and leverage advantages such as:
You’ve rolled out a successful cohesion of security and QA Testing early on in the SDLC, and now there is just one more thing to ensure after having made your security fixes. Are we sure the fix works as expected and the issue won’t re-appear in the next releases?
Implementing security regression testing in your SDLC identifies whether the specified or intended security features are implemented correctly across your future software releases, both in terms of properties and functionalities.
As with any cycle, all stops along the way are equally important to get right prior to producing an end product worthy of a price tag and the delivery to a satisfied - and secure - client.
It is hard to overstate the essentiality of QA and security testing as a cohesive process. It’s also obvious that application security solutions are essential to identify security issues. But these solutions are only as good as the people who use them.
Moreover, security testing is not only about resource guides, automation, playbooks or checklists. It also requires skilled people who:
To meet these goals, security training is absolutely essential. This training should equip QA teams about secure coding techniques and best practices, so they can help the dev team create software that’s secure from the start. It should help them develop the skills required for the org to shift left, and adopt a more proactive attitude to application security and security testing. At the very least, the training should focus on all these areas:
SecureFlag’s practical hands-on training is perfect for QA testers tasked with writing security testing. At a broader level, it also helps orgs strengthen their shift left philosophy, and entrench security testing into every phase of the SDLC.
Testers learn how to identify and remediate critical security issues before they find their way into the live product - through 100% hands-on exercises presented in a real-world simulated environment. These features are SecureFlag’s key USPs. The Integrated Development Environment (IDE) is created on-demand, and can be accessed through a familiar web browser. There’s no need to install any additional software, so the candidate can get started on their learning journey quickly by simply selecting the exercise code.
The training is individualised with individual learning paths to match the learner’s skills and knowledge level. On completing a learning path, they gain a certificate which they need to maintain by taking refresher exercises during the year. This ensures that their knowledge is always up-to-date. Plus, they can see the progress of their learning in tangible form, which further cements their learning.
SecureFlag’s unique tailored, hands-on approach equips candidates with the expertise required to effectively sniff out critical vulnerabilities during testing. This directly increases the application quality, which has a positive effect on the organisation’s reputation, financial position, and even their compliance posture.
The platform provides metrics that enable supervisors to initiate ongoing improvements. It also maintains automated records of candidates’ training status, which can be used as evidence for review and compliance.
For more information about SecureFlag’s industry-leading practical secure coding training platform, contact us today.