Manufacturing is one of those industries that seems like a natural fit for vulnerability management, in part because these companies can be such easy targets for cyber criminals. Manufacturers in many cases operate far-flung, global facilities including factories, warehouses, and other distribution points. Increasingly, these different facilities are connected as companies look to modernize their operations through digital transformation.

Just as the move to DevOps required a cultural shift, incorporating security into a DevSecOps initiative typically requires a delicate dance between developer and security teams. The two groups historically haven’t seen eye to eye and view one another with distrust.

As the frequency of new products released rises and as the attack surface keeps growing, most companies are faced with a common problem – a growing vulnerability workload. Their vulnerability scanners report countless vulnerabilities and there is simply not enough resources or time to fix all of these vulnerabilities, leaving their networks vulnerable and exploitable.

Software composition analysis (SCA) tools provide automated visibility throughout the software development life cycle (SDLC) for more efficient risk management, security, and license compliance. As organizations accelerate their digital initiatives, they rely on development teams both internally and externally to build the applications that will help them move forward. But applications are also a popular target for criminals.

In this second of a five-part series of posts on why strong vulnerability management is so vital for cybersecurity programs, we look at the need for effective vulnerability management in the healthcare sector. Like financial services, healthcare is a highly-regulated industry and it’s also among the most common targets of cybercriminals.

If you find yourself baffled by the influx of events and newly discovered vulnerabilities affecting the popular Apache Log4j Java logging library, this post is for you. This post aims to survey the entire flow of events since the first discovery of CVE-2021-44228, AKA Log4Shell, to the present date, explain the important aspects of each related vulnerability, as well as provide practical remediation and mitigation advice.

By now, we’re all likely tired of talking about Log4j and nodding our heads over Zoom when we all discuss the ramifications of exploitation of this small, but very pervasive and powerful vulnerability. At the risk of adding another layer of complexity to the information we have learned about Log4j, I think we are remiss not to mention IT-OT (Information Technology-Operational Technology) convergence and how it could be an enabler for Log4j to impact our critical infrastructure.

Most enterprises, as well as small organizations globally are now painfully familiar with the Log4j2 vulnerability (CVE-2021-44228). It has taken over the lives of all cybersecurity professionals and it appears it is here to stay for a while. Most enterprises are scrambling for solutions, applying patches if they can find the vulnerability, and trying to implement mitigation strategies. But unfortunately what security teams are doing to tackle the Log4j beast is not always enough.

It’s not just about the big name companies who are vulnerable to the Apache Log4j2 vulnerability (CVE-2021-44228). Tech small businesses – which offer customers digital products but which often have tight budgets and understaffed security teams – are an important story when it comes to the implications for Log4j exploits. Research now finds that almost all environments have vulnerable Log4j libraries.

The popularity of the Log4j library, coupled with the ease of exploitability and severe potential impact, means Log4Shell’s blast radius is enormous – that’s old news by now. However, what’s being revealed these last few days is not just how popular it is, but how deeply rooted it is in the software we use – and this depth is creating some unique challenges in detecting it.