IT teams need to prioritize software patch efforts better

Cybersecurity teams need to do a better job prioritizing which vulnerabilities they want application developers to fix. A global survey of 1,224 security, development, and IT operations professionals published today by JFrog, a provider of a continuous integration/continuous delivery (CI/CD) platform for building software, finds that 60% of respondents typically only spend four days or more remediating application vulnerabilities in a given month.

The trouble is most of that time is arguably spent remediating vulnerabilities that are either not included in the software libraries that are actually running, or the application itself doesn’t ever connect to the internet. More troubling still, after analyzing 212 vulnerabilities JFrog security researchers downgraded the severity of 85% of the vulnerabilities rated as critical and 73% of ones rated as high.

The same researchers also found that 74% of the reported common vulnerabilities and exposures (CVEs) with high and critical Common Vulnerability Scoring System (CVSS) scores assigned to the top 100 Docker Hub community images weren’t exploitable.

Vulnerability report overload

One of the dirty secrets of IT is that application developers don’t tend to take the vulnerability reports generated by cybersecurity teams all that seriously. Cybersecurity teams have been sharing long lists of vulnerabilities with application development teams for years, but many of these teams discover that when they investigate these alerts it’s often another instance of a cybersecurity team calling wolf where none exists.

Of course, inevitably there will be that instance where a development team will ignore an alert that proves catastrophic. If cybersecurity teams want to make sure their alerts are not being ignored, they need to realize that application development teams don’t have an infinite amount of time available to build and deploy software patches. They are still required to write new code no matter how many vulnerabilities a cybersecurity team thinks they have uncovered. The most critical thing for any cybersecurity team is to make sure they prioritize patch requests based on not just how severe a vulnerability might be, but also the degree to which it is actually exploitable.

Inconsistent code scans

Achieving that goal, naturally, means working more collaboratively with application development teams within the context of a DevSecOps workflow to scan code both before and after an application is deployed. In fact, the JFrog survey notes code scans are often applied inconsistently from one organization to the next. A total of 42% said it’s best to perform security scans as code is being written versus 41% that prefer to perform scans on new software packages before installing them. A total of 41% of respondents said runtime is the least desirable place to run scans. More than half (56%) said their organization applies security scans at both the code and binary scanning levels.

There are, of course, a lot of patches to, for example, operating systems that a cybersecurity team should be able to apply themselves without breaking any applications. If the application does break, rolling back that patch should be relatively straightforward. Patching applications, however, is another matter altogether. Cybersecurity teams that attempt to patch a custom application are taking on responsibility for a task that will likely end badly.

Of course, there may come a day when there are no more vulnerabilities in software, but so long as software is written by humans or generated by machines that have been trained using software written by humans, there will always be both known and unknown vulnerabilities that will need to be thoughtfully addressed.