The notorious Log4Shell vulnerability CVE-2021-45046, has put Log4j in the spotlight, and grabbed the entire Java community’s attention over the last couple of weeks. Maintainers of Java projects that use Log4j have most probably addressed the issue. Meanwhile, non-java developers are enjoying relative peace of mind, knowing that they are unaffected by one of the major vulnerabilities found in recent years. Unfortunately, this is an incorrect assumption.

A third Log4j2 vulnerability was disclosed the night between Dec 17 and 18 by the Apache security team, and was given the ID of CVE-2021-45105. According to the security advisory, 2.16.0, which fixed the two previous vulnerabilities, is susceptible to a DoS attack caused by a Stack-Overflow in Context Lookups in the configuration file’s layout patterns. What is this CVE about? What can you do to fix it? How does it differ from the previous CVEs?

As security and development teams rushed to assess the now-notorious Log4Shell vulnerability published December 10 (CVE-2021-44228), another, more minor vulnerability was discovered in Log4j — CVE-2021-45046. To understand the newly-discovered vulnerability, it is important to get the full picture and background on the original Log4j issue.

A newly published critical vulnerability in Apache’s widely popular Log4j Java library, CVE-2021-44228 (CVSS score 10) was published over the weekend, causing a lot of concern.

Software development organizations are investing more and more resources in their vulnerability management programs. According to Gartner’s forecast, in 2021 enterprise security spending was expected to break records and grow 12.4% to reach 150.4 billion. But how do organizations know if they’re spending their security resources wisely? The answer can only be found by crunching the numbers.

Vulnerability management is becoming increasingly important to companies due to the rising threat of cyber security attacks and regulations like PCI DSS, HIPAA, NIST 800-731 and more. Vulnerability management is a comprehensive process implemented to continuously identify, evaluate, classify, remediate, and report on security vulnerabilities.

Infrastructure as code (IaC) promises to make developers more agile, but it’s not without risk. Learn more about what IaC is, its benefits, and best practices for how to use this technology securely.

Over the past few years organizations have been shifting security tools and practices left to ensure that application security is addressed from the earliest stages of the software development life cycle (SDLC). These efforts also increasingly cover open source components, which comprise up to 80% of our software products.

The SolarWinds attack in late 2020 exposed the data of more than 18,000 businesses and governmental departments – many of which are gatekeepers for the country’s most vital infrastructure. While attacks against the software supply chain aren’t new, they are increasing exponentially.

As organizations look for solutions that enable them to create a software bill of materials (SBOM) to ensure they’re meeting new governmental mandates for protecting the software supply chain, it’s important to understand the difference between solutions based on reporting vs. remediation. The primary focus of any SBOM solution should be on open source code. The use of open source continues to expand exponentially. Open source components comprise 60%-80% of today’s applications.