A few weeks ago, Forrester Research released its 2022 State of Application Security Report. This year’s report has big implications for how engineering and security leaders can move forward to make sure that their applications and APIs are more secure.
Forrester once again cited that applications were the most common entry point for external attackers, with software vulnerabilities listed at number one and web application exploits at number three. However, surprisingly, it wasn’t the unknown risks that stuck out in this report. Instead, it was the fact that the way teams are delivering secure software is changing.
For example:
Development teams are now getting involved in purchasing decisions with more security leaders reporting that development teams are both final decision-makers for application security tooling, and budget holders.
Dynamic security testing =! Prod. 87% of organizations plan to implement dynamic security testing (DAST) for applications and APIs in the pre-release delivery cycle.
Security teams are collaborating with engineering to create security champions that ensure that security is considered throughout development.
The message is clear – “shifting left” is no longer a buzzword. Teams are implementing a new model of security and making it work.
Building a Security Approach that Works for Developers
So your organization wants to shift left.
“How do I do that?” is not an uncommon question.
This is a complex topic that requires teams to rethink process, culture, and tooling. But when it comes to tooling decisions, the 2021 Forrester Report on Application Security, gave teams strong guidance on selecting tooling for faster remediations.
The research showed that combining static application security testing (SAST) and dynamic application security testing (DAST) scans results in findings remediated 24.5 days faster than the average, while combining SAST and SCA scans results in remediations taking place six days faster.
This has huge implications for security teams that are now faced with new threats every day. And, it has huge implications for development teams that are pushing breakneck deployment speeds that cannot be slowed down with unplanned rework from security issues. Combining tooling is a win across organizations.
The Need for Unified Tooling
For the engineering leaders we speak with, one concern that often comes up is how to make security tooling work together for a seamless developer experience. Asking developers to click into a different UI for each type of security tool is a non-starter.
If we are implementing security tooling in the development lifecycle, it needs to fit natively where developers are already working and provide developers with a holistic understanding of what needs to be done when security issues arise.
Not only does this equate to big productivity gains for the individual developer who, armed with security information, can fix issues without context switching, it is also hugely beneficial for engineering organizations that can have security included in software delivery without sacrificing velocity.
DAST + SAST: Another Huge Step for Developer Productivity
In April, we delivered our Snyk SAST integration to provide developers with fast fixes to top priority application and API security issues. And today, we are excited to announce our latest SAST integration - GitHub CodeQL.
This integration will correlate StackHawk DAST findings with GitHub CodeQL SAST findings. In doing so, CodeQL users will be able to validate which SAST findings are exploitable and are therefore top priorities for immediate remediation. In the StackHawk platform, users will be directed to the specific line of code they need to address and patch the security issue.
For security users, these integrations will mean no more manual correlation of findings from different tools, creating tickets, and coaching developers through how to find, recreate, and fix the issue. Instead security teams can be strategic leaders, guiding the organization in how to think about risk, and building secure applications from the get go.
For developers who spend an average of 8 hours fixing a single security issue, this equals huge time savings. Developers are notified at the merge if new issues exist and are publicly exploitable. Then they are given exact guidance on how to fix it.
If you are interested in learning more, register for our GitHub CodeQL Webinar slated for August 16 at 10 AM. Our Head of Product, Lauren Nagel, will be walking you through how to deploy and use the new integration to make security testing an efficient part of the developer workflow.
