The search for good cybersecurity talent is a struggle facing companies across the industry — a problem that is only likely to get worse over the next few years.

According to a report from CNBC in March, there are nearly 3 million open positions globally for security professionals. The hiring shortage is expected to grow as the factors putting organizations at risk converge: not enough students engaged in cybersecurity education, more jobs opening with increased digitization of services, and the rising risk of costly hacks from complex threat actors. This is placing added pressure on companies to recruit.  

The future of application security
When does SCA replace SAST or DAST?
Organizations fail to remediate app security vulnerabilities

In the current environment within the software industry, security professionals are already vastly outnumbered within their organizations, at a ratio of 1 security pro to 10 IT/DevOps to 100 developers. Given this disparity, they are unable to be the sole owners of security concerns, spread thin as they are on bigger-picture issues within their organizations. 

With no outside solution in sight, companies have in recent years been looking inward by shifting the ownership of vulnerability management more and more towards developers. This shift has led to more investment in their developers, who are on the front lines in the battle in the form of both training and the adoption of application security testing tools that help keep their software secure.

Shifting responsibility for security ownership  
Historically, developers were in charge of writing software and security was tasked with checking to see if it was secure. This dynamic is no longer viable given the workload for security and the sheer scale of software being produced.

Instead, we have seen the steady shift of responsibility for security transferred on to developers within their organizations. In a recent study of developers in North America and Western Europe conducted by WhiteSource, 52 percent of those surveyed responded that either developers or their team leaders were the owners of security within the organization. Only 28 percent said that the security professionals were the owners, while another 21 percent pointed to the DevOps team.

Security is now becoming a more significant priority for developers in their approach to development, with 58 percent stating that it is a top priority for them. 

These changing attitudes do not come in a vacuum, but as part of an effort by organizations to provide their developers with the tools and training they need to efficiently handle vulnerability management. 

In the survey, 36 percent of respondents answered that their company provides them with training that helps them to code better. While others reported lower levels of satisfaction with the training that they were receiving, either because of usefulness or frequency, only 1 percent told the survey that their employer did not provide any training. This tells us that we are moving in the right direction on this front, even if there is room for improvement.

On the technology front, we see even more promise with 68 percent of developers reporting that they use at least one of the popular AppSec technologies such as SAST, DAST, SCA, IAST, and RASP, which help developers to test their code throughout the SDLC. These tools can scan the product’s code and issue alerts to developers about potential vulnerabilities in their code.

As those who are positioned at the earliest stages of the SDLC, the point at which it is easiest to remediate vulnerabilities in the code, it makes good sense that developers should be the ones to use these tools. Adoption of these tools by developers who can test early and often throughout development helps to reduce the need for security teams to perform scans before a release and send back a mountain of alerts to be verified and remediated. 

The fact that these tools use automation is likely a key component in their widespread use by developers, since they reduce the amount of manual interaction required and are thus less of a drain on their time.

Developers are ill-equipped for remediation
Even with the advantages that developers gain from better training and tooling, there is still one area where they are still lagging behind: remediating issues.

Research in this survey, and previous reports, indicates that developers are spending considerable amounts of time on their remediation activities. While 42 percent stated that they spend between 2 and 12 hours a month on remediations, another 33 percent said that they spend 12 to 36 hours. Interestingly, our research shows that only 3.8 of these hours are spent on the actual work of remediating. The rest is spent researching, consulting, and generally trying to figure out how to get started.

Part of the problem here may lie in the types of tools that developers are using. 

As developers have transitioned to take on more responsibility for security, the tools that they use have been slow to adapt to the needs of the new audience. These technologies are good at alerting teams to the presence of vulnerabilities, but they are not doing enough to help them efficiently implement the fix. While alerting may have been sufficient for security teams, developers need tools that go a step further. 

What developers need moving forward are tools that are designed for how they work and shorten the distance from receiving alerts to completing the remediation. Looking at the trend of companies putting in the resources to help their developers work more efficiently with their vulnerability detection, we can assume that the desire is there. 

Now that organizations are ensuring that developers are addressing security in the early stages of development, they will also take steps to empower developers to manage the extensive lists of alerts that they are handling. This means finding effective ways of prioritizing security issues and enabling easy remediation processes. 

Hopefully, the tools will continue to evolve, meeting developers’ needs to make this process an easier lift for all.