Over in the TechWell Hub, I was recently asked by a fellow community member, “Is there value in having traditional testers do security testing in addition to the testing taking place from our security group?” I thought it was a great question, and it deserves a more detailed response.
For many organizations, traditional software and testing groups are separated from the IT security group. The first is just concerned with functionality, while the latter cares only about security. In many cases this results in adversarial relationships, which almost always leads to some challenges for software development teams:
- Late-stage identification of vulnerabilities, usually before a production release
- Spreadsheets of generalized security vulnerabilities for an application
- Slow mitigation of vulnerabilities
- Increased time to deliver new features or fixes to production
This is where most professionals recommend organizations attempt to “shift security left.” By shifting security testing efforts earlier in the lifecycle, developers can identify issues sooner in development, which leads to faster mitigation of vulnerabilities, fewer last-minute surprises before a release, decreased time between releases, and reduced exploitability of existing defects.
Unfortunately, shifting security left is easier said than done. Development and testing teams often lack application security expertise, and staffing and budgetary concerns limit IT security’s capacity to do more frequent testing and ability to embed security analysts in software development teams.
Having traditional testers perform some security testing efforts earlier is a great way of achieving a balanced approach to shifting left while being mindful of staffing and budgetary challenges. It also provides some great advantages.
Training testers and providing them with access to security testing technologies enables them to use automation to perform both static application security testing (SAST) and dynamic application security testing (DAST) earlier in the software development lifecycle. By using your existing testers to shift left, they will perform testing more often and be able to recognize new features and code changes with actual test results. Eventually, the entire team will mature and adopt more secure development practices.
Testers looking at these results tend to have an advantage over the segregated IT security team as well because they have context around the features, design, and implementation that a general security analyst lacks. By understanding user behaviors, workflows, architecture, and data flows, testers have a greater grasp on the risks and threats to the application.
This allows them to determine just what the real impact and likelihood of an exploit is, making them able to prioritize real issues above the noise of information warnings. Isolated security teams often perform a scan but can’t provide additional understanding beyond what the tool tells them because they don’t have the breadth and depth of knowledge into just how the application works.
By having your testers perform security testing, your team will have a better understanding of your application’s risk profile, and the product owner will be able to truly prioritize security fixes in with functionality.
This is a repost of my article on Techwell Insights.
