Due to the recently discovered Log4Shell vulnerability, and to support the tremendous effort being mounted by the community to address it, we are happy to announce that we are increasing the free test limit in Snyk Open Source! This means that any developer, no matter the company or project, can now use Snyk Open Source to find and fix Log4Shell with double the number of free tests, whether it’s within your IDE, your Git repositories, CI environments, or using the Snyk CLI.

Overnight, it was disclosed by Apache that Log4j version 2.16 is also vulnerable by way of a Denial of Service attack with the impact being a full application crash, the severity for this is classified as High (7.5). Snyk is currently not aware of any fully-fledged PoCs or exploits in circulation. CVE-2021-45105 has been issued, and a new fixed version (2.17) has been published by Apache which we recommend upgrading to.

Since 2019, Snyk and Dynatrace have partnered with a shared mission of securing the entire software development lifecycle (SDLC) and accelerating digital transformation. As many agile organizations migrate their workloads to the cloud, it’s tempting for teams to let security take a back-seat until all the pieces of the infrastructure puzzle are in place.

At Snyk we have some general points of principle that we use to help guide our security thinking and decision making. Firstly, it is always important to understand from whom we are protecting, as it has implications for how we need to act. As an example of this, if our artefact is a web server, then we need to protect it against untrusted users. Whilst if our artefact is encryption software, then we clearly need to protect it even from users with physical access to the system.

If you’re in tech at all, you’ve likely heard of the Log4Shell exploit taking over the Intertubes. If you’re not a Java developer (or developer of any sort), you may be left scratching your head as to just what’s going on. This post is split into two parts: an explanation of Log4Shell for non-developers and an overview of the Log4Shell vulnerability for non-Java developers.

Speak with any customer in tech and the word Kubernetes will surely find its way into the conversation at some point or another. In terms of orchestration, automating deployments, scaling, managing containerized applications to meet growing customer demand, Kubernetes provides users with extensibility and flexibility.

Even if you tried VERY hard to enjoy a quiet weekend, chances are that this plan was interrupted at least once by the new Log4Shell zero-day vulnerability that was disclosed on Friday (December 10, 2021). The new vulnerability was found in the open source Java library log4j-core which is a component of one of the most popular Java logging frameworks, Log4J.

By now, you already know of — and are probably in the midst of remediating — the vulnerability that has come to be known as Log4Shell and identified as CVE-2021-44228. This is the vulnerability which security researchers disclosed on Friday (10 December 2021) for Apache’s Log4j logging framework. In this article, we’ll explore a few key Log4j facts as well as actions you can take to protect yourself and your company.

When DevOps emerged more than ten years ago, the main focus was to bridge the gaps between dev and ops teams. This was achieved by introducing automation to the processes of designing, building, testing, and deploying applications. But as development teams continue to deliver faster and more frequently, security teams find it difficult to keep up. Often, they become the bottleneck in the delivery pipeline.