Operations | Monitoring | ITSM | DevOps | Cloud

Tl;dr: Log4j is a mess, if you’re chasing down the applications, services and servers that use Java; consider the suggestions below to make zero day patching easier.

If you run an interactive website or application, JavaScript security is a top priority. There’s a huge array of things that can go wrong, from programmatic errors and insecure user inputs to malicious attacks. While JavaScript error monitoring can help you catch many of these issues, understanding common JavaScript security risks and following best practices is just as important.

Apache Log4j, an open-source logging software used in everything from online games to enterprise software and cloud data centers, has a severe security vulnerability that has security teams all over the world working frantically to correct it. The internet has been on high alert as hackers increase their efforts to target vulnerable systems, owing to its broad use.

If you are currently running the Robot Operating System 2 (ROS 2), this piece is especially relevant to the security of your robots. A few weeks ago, a group of security researchers reported 13 security vulnerabilities affecting some of the most used implementations of DDS, the default middleware used by ROS 2.

On December 9, 2021, a critical vulnerability in the popular Log4j Java logging library was disclosed and nicknamed Log4Shell. The vulnerability is tracked as CVE-2021-44228 and is a remote code execution vulnerability that can give an attacker full control of any impacted system. In this blog post, we will: We will also look at how to leverage Datadog to protect your infrastructure and applications.

It seems that every few weeks, we are alerted to a new significant security issue within one of the plethoras of code elements that are widely used. The same pundits discuss the same range of concerns with open-sourced code each time. The list of “usual suspects” is long, and I know I could add at least 20 additional “reasons” to this list without thinking about it too hard. I’m not sure that open-sourced code is riskier than proprietary developed code. There I said it.

By now, you’re probably assessing your level of exposure — or are in the middle of remediating — the recently disclosed vulnerability known as Log4Shell. We recently introduced a native integration with Snyk, a leading provider of developer security solutions, to help you address zero-day vulnerabilities. Once enabled, Snyk scans your code and its dependencies, and alerts you about security vulnerabilities, including Log4j. All current versions of Log4j 2 up to 2.14.1 are vulnerable.

Over the last few days, there have been a tremendous amount of posts about the Log4j 2 vulnerability, with Wired going so far as claiming that, “the internet is on fire.” Tl;dr: LogDNA is not exposed to risk from the Log4Shell vulnerability in Log4j 2 at this time. If that’s all you came for, you can stop reading here. If you want to learn more about the vulnerability and how LogDNA protects you from risks like these, grab a cup of coffee and read on.