Skip to main content

How risk-driven policies can help free DevOps from AppSec friction

Devops
(Image credit: Image Credit: Profit_Image / Shutterstock)

Application development has escalated in volume over the years, but no more so than in the last 16 months. In that time, our dependency on the digital world - for work, schooling, and everyday life - has grown exponentially as we endeavored to maintain social distancing. Under such demand, development teams have been under great pressure to churn out applications at a faster rate than ever before; not only to meet our needs but to also survive in today’s competitive market. 

Simultaneously, cybercriminals have developed novel attack strategies while also intensifying their focus, making it crucial to scrutinize applications for security vulnerabilities. Unfortunately, however, there appears to be a disconnect between what is believed to be true and what is done when it comes to security. 

On one hand, Application Security (AppSec) is deemed a top investment priority. Indeed, a recent study revealed that 58 percent of organizations agree with this. A further 43 percent recognize that shifting security further left and investing in tools integrations is pivotal to improving their AppSec programs. Yet, the scales continue to tip in favor of speed as opposed to safety: A staggering 79 percent of organizations admit to pushing application changes with known vulnerabilities. For more than half of the organizations surveyed, this decision was made largely because they had to meet critical deadlines. So, how can developers find the right balance between meeting time-to-market objectives and mitigating risk?

Efforts to facilitate speed while maintaining security 

In an effort to accelerate development velocity, teams have begun adopting cloud-native architectures alongside agile development practices and DevOps or GitOps automation. Although it does fulfill the objective of speed, it also gives rise to considerable software complexity, a heightened risk of vulnerabilities and thus, of cybersecurity incidents. This has incited development teams to take action and address the risk. 

Many have deployed AppSec security resources and automated testing tools for vulnerability assessment, as well as implemented developer security training programs. To be clear, the study showed 71 percent of respondents reporting the use of AppSec tools on more than 50 percent of their code base, with 69 percent rating the effectiveness of their program as an eight or higher on a scale of one to ten. Moreover, over the last few years, security teams have adapted their working model by shifting further left to spot and remediate issues earlier on in the development process to prevent longer delays later down the line. 

In theory, these are all excellent steps towards robust security without compromising speed of development. However, in practice, modern application security programs are a complex mix of manual and automated tools and practices. In the vast majority of cases, manual triage and prioritization by development and security analysts are still required. In this way, introducing a new set of challenges that they must overcome.

Challenges of building an effective application security program 

Regardless of good intentions and ongoing investments, it is clear that many organizations, particularly those with large application portfolios, are struggling to implement and operate effective AppSec programs. While developers understand integration and automation of security testing to be critical in the development workflow, it is not always apparent how this is done. This added friction only serves to slow down development velocity, bringing teams back to square one. 

The fact of the matter is, AppSec strategies are failing to keep up with the advancements of development strategies. For one, there appears to be an excess of both the number of testing tools and scans as well as findings. The proliferation of tools in use is proving overwhelming for most teams. In addition, each scan produces, hundreds, if not thousands, of findings that need to be filtered through. Even though only a small percentage of the findings may present enough risk to require immediate attention, identifying and prioritizing high-priority vulnerabilities is a significant burden. 

Then there is the issue of lengthy scan cycles. Most build pipelines only require a few seconds to a few minutes to run, but an AppSec tool scan could take hours. This is then made worse in two ways. The first is when further tests and analysis are supplemented to the process - be it SAST, SCA etc. The second are poorly aligned risk models. In other words, when little consideration is given to assessing the risk profiles of various applications to efficiently prioritize the implementation of security measures. The lack of clear policies detailing when to use certain assessment tools, means high-risk applications get away with insufficient scrutiny, while resources and time are wasted on low-risk application changes. 

Finally, development teams are simply facing a barrage of exploits. In fact, despite the use of multiple AppSec tools, 81 percent of organizations still report that they have had applications exploited, with 60 percent reporting that they have had applications exploited by OWASP Top-10 vulnerabilities within the previous 12 months. So, what’s next?

Next steps 

Time pressures have demanded that security teams ‘shift left’. Yet, as these challenges demonstrate, it is not enough to integrate security testing tools and call it a day; such an approach just won’t scale to meet today’s demands. 

Rather, organizations must modernize and explore a new AppSec model: one that takes a more considered approach. To put it simply, organizations must factor in individual application risk profiles to their strategy. It is only then that developers can determine where more stringent controls need to be applied, where it is possible to ease off on testing, when to introduce automated controls and when a team member might have to administer changes manually. Ideally, automated rule sets should help in governing how each risk is managed as well. 

It is this alignment between risk profiles and security policies that will facilitate faster checks that are compatible with the upturn in velocity and scale of recent technological advances.

Boris Cipot, senior security engineer, Synopsys Software Integrity Group

Boris Cipot is a senior sales engineer at Synopsys. He helps companies of all shapes and sizes to create secure software. Boris joined Synopsys when Black Duck Software was acquired in 2017. He specializes in open source software security, robotics, and artificial intelligence. He has also worked in the cybersecurity field since 2003 in anti-malware software at F-Secure and Avira.