This is how prioritization can save us from the shortage of cybersecurity professionals

It is no secret that the technology sector has a labor problem. As demand for new products and services continues to rise, we are simply not producing enough qualified developers to keep up. Just ask any company where their greatest pain point is and they will have hiring somewhere towards the top of that list.

This shortage is felt especially acutely when it comes to security professionals that understand both how code is written, and how to keep it secure. A 2018 report from the Enterprise Strategy Group (ESG) found that 51 percent of respondents reported shortages of cybersecurity skills as an area of concern. These concerns have been on the rise in recent years, spiking from a reported 23 percent in 2014 citing cybersecurity skills as a problem, up to the latest 51 percent statistic from this year.

The timing for a drop in the supply of experienced security workers could not be worse, coinciding with rising numbers of reported vulnerabilities. According to an IBM X-Force report, these known vulnerabilities have jumped from 10,530 in 2016 to 15,562 in 2017. Security teams are being overwhelmed with alerts. A study from the International Data Corporation (IDC) showed that 37 percent of cyber security teams are forced to deal with over 10,000 alerts a month.

Considering that security departments are one of the smaller groups in a company (holding to the 1:10:100 ratio that is fairly standard throughout much of the industry), they are under considerable pressure to keep up with addressing vulnerabilities. More often than not, many of these issues go unremediated, and teams are left uncertain as to whether they are missing the known vulnerabilities that could have a much more detrimental impact on their product.

Catching The Low Hanging Fruit Of Known Vulnerabilities In Open Source Security

Many of these known vulnerabilities can be found in the open source components which make up 60-80 percent of the code base in modern applications. Developers love them because they are able to gain the benefit of functions for their code without the need to reinvent the wheel by writing the features themselves.

The problem is that hackers also love open source components because they are reusable. A popular open source component can be used by thousands of developers in a wide range of organizations. Therefore, when a new vulnerability is reported by a researcher and published on one of the many security advisories and databases like the National Vulnerability Database (NVD) with the information on what is vulnerable and how to exploit it, it can feel like a free lunch for hackers.

The challenge for security teams in keeping their open source usage secure is in maintaining visibility and governance over the open source components in their development environment and products. Manually tracking when new vulnerabilities are discovered and matching them with open source components that you are using in your own products is far from practical, especially at scale and the fast paced DevOps model.

In light of the risk posed by known vulnerabilities to these essential open source components and the sheer number of alerts that security and development teams have to contend with, the question is how can organizations manage the workload with their existing resources?

Advanced Software Composition Analysis (SCA) tools provide organizations with the automated tools that can which open source components they are using, prevent open source components with known vulnerabilities from making it into the proprietary code, alert them when a new vulnerability is discovered that affects their product, and provide them with actionable insights to help them prioritize their remediation operations when necessary.

Know Your Code And Prioritize Based on Impact Analysis

When organizations do not have the resources to burn, it is essential that they plan their operations based on which vulnerabilities are the most pressing.

According to our research into Java components, 70 percent of vulnerable functionalities are ineffective, meaning that they do not have an impact on the proprietary code. When a developer takes an open source component from site like GitHub to utilize a specific feature from a functionality, they will normally take the entire component "as is", plugging it into their code.

What is important to understand is that there are multiple functionalities within a component, some of which may contain a vulnerability. However, if the developer’s proprietary code is not making calls to the vulnerable functionality, then their product is not directly at risk, and therefore should be a lower priority.

The issue is though that security tools will identify the component with the one vulnerable function as vulnerable, thus issuing an alert that will need to be addressed by a developer. From the developer’s perspective, this can be a very frustrating experience as they end up spending their time on alerts which should not be a high priority.

Over the long run, this reduces their confidence in the alerting system, causes friction with the security team that is pleading with the developers to remediate alerts, and leaves more risky alerts unaddressed.

This is why understanding which functionalities are effective can play such an important role in prioritizing alerts. By reducing the scope of alerts by 70 percent, teams are able to more easily reach the 30 percent of effective vulnerable functionalities that are putting their product at risk, helping a small team take on the challenge of keeping their code secure.

Photo Credit: Alexander Kirch/Shutterstock

Rami Sass is CEO and Co-Founder of WhiteSource , the leading open source security and compliance management platform. Rami is an experienced entrepreneur and executive with vast experience in defining innovative products, leading technology groups and growing companies from seed level to business maturity.