Detectify's network of ethical hackers found that more than a third of vulnerabilities they reviewed did not have a CVE assigned. (Navy)

Detectify on Thursday reported that 35% of the vulnerabilities reviewed by its private network of ethical hackers did not have a CVE assigned.

The researchers added that while many DevSecOps teams strive to catch coding errors pre-production, 41% of companies believe shifting left is not feasible and an additional 58% say they can only apply it in specific instances.

While shift left only introduces minutes into the development process, the Detectify researchers said it can take hours to resolve severe vulnerabilities in production, thereby increasing risk.

The research coincides with Detectify releasing its Custom Policies Overview, a new tool powered by its elite ethical hackers that promises to let organizations enforce custom security policies across the entire attack surface, improving security posture. The automated solution will let organizations set customizable policies for every asset based on various business conditions, discover violations of corporate policies, and remediate critical vulnerabilities before they become exploitable.

Bud Broomhead, chief executive officer at Viakoo, said there’s some circular reasoning going on here: by using a private group of “elite ethical hackers,” non-public vulnerabilities are being found. Therefore, Broomhead said it’s no surprise that these privately-disclosed vulnerabilities do not have CVE scores that would only come through the public disclosure process. Broomhead said proprietary vulnerability identification and assessment, as highlighted here, will never be the right answer to let security teams find and remediate them across all potential attack surfaces.

“By not being part of the CVE disclosure and CVSS scoring processes, these vulnerabilities are also not covered within CISA’s Known Exploited Vulnerability (KEV) catalog, a major resource and focus for security teams to gain efficiency,” Broomhead said. “Scoring has and will always be a work-in-progress, as shown in the changes from CVSS 2.0 to CVSS 3.0. Further work on vulnerability scoring process and methods should take into account vulnerabilities not disclosed directly through the CVE process.” 

Mike Parkin, senior technical engineer at Vulcan Cyber, added that there are some industry best practices that are designed to minimize threat surfaces even against vulnerabilities that may not be known or documented, such as only allowing access to addresses and ports that are strictly required for operations. As for vulnerabilities that are reported, but don't receive a CVE score, Parkin said that's a question of process: Did it not get a score because it wasn't reported correctly, or simply hasn't been published yet, or did it not get a score because it wasn't considered a valid vulnerability?

“No security process is perfect, including the shift left concept,” Parkin said. “There are always tradeoffs balancing between efficient development, operations, and security. Their approach to policy enforcement here should help and could be a valuable addition to a risk management program.”