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.

Just like you’d find all the ingredients on a package of food, a software bill of materials is a list of all the components contained in a software product. Vendors typically create these bills to describe what the components are. In addition, a Software Bill of Materials also includes information about these components’ dependencies and their hierarchical relationships.

Given the holiday season, I suppose it’s timely to label the recent Log4j vulnerability as the “vulnerability gift that just keeps on giving.” A quick scan of the headlines is all one must do to understand my sarcasm: Cyberscoop reports that The US Cybersecurity and Infrastructure Security Agency (CISA) warns that the Log4j vulnerability will likely affect hundreds of millions of devices and that the vuln “is one of the most serious…if not the most serious” seen by t

The ability to effectively manage vulnerabilities in an efficient and strategic manner is critical for companies. The ongoing practice of identifying, classifying, prioritizing, and fixing software vulnerabilities should be a key component of the development process. If it’s not, teams might turn out applications that contain vulnerabilities with consequences ranging from mild annoyances to disastrous security breaches.

The dust refuses to settle over the Apache Log4j2 vulnerability (CVE-2021-44228) commonly known as Log4Shell. Rezilion is closely monitoring the situation and in this blog post, we will provide relevant information and updates that have surfaced since Log4Shell entered the IT world by storm. If you want a deeper understanding of the vulnerability itself, you can refer to our previous blog post around the topic.

By Yotam Perkal, Vulnerability Research Lead, Rezilion It has been hard to miss the recent warnings about the newly discovered remote code execution (RCE) vulnerability CVE-2021-44228, also known as Log4Shell. The vulnerability, originally disclosed on November 24th by Chen Zhaojun of Alibaba Cloud Security Team, is already being actively exploited in the wild. Why is this vulnerability such a big deal?

Like waistlines after a large holiday meal, legacy programming code can become bloated with useless lines of code resulting in features that are unnecessarily long or slow, due to a large amount of memory and RAM. Useless code might be libraries that contain new code and repetitive code from older versions of software, or service binaries.

In the software development process, knowing exactly which vulnerabilities to focus on and which to downplay, or ignore because they pose no significant threat, is vital for increasing efficiency and applying fixes quickly and effectively. Security can be tricky in a DevOps environment, because if it’s applied too stringently, can keep products from being released in a timely manner. If it’s treated too passively, risks can quickly accumulate.

DevSecOps is a hot term that many security leaders and executives are talking about. However, this process of embedding security into every stage of the software development life cycle (SDLC) is, like many technology undertakings, also subject to a number of misconceptions and myths. To successfully implement a DevSecOps program within an organization, it is important to enter into the effort with eyes wide open, and to understand that some of what you have heard about it might be wrong.