As previously predicted to unfold, at approximately 7:35 PM GMT, 28th of December 2021, another security vulnerability impacting the Log4j logging library was published as CVE-2021-44832. This new CVE-2021-44832 security vulnerability is affecting versions up to 2.17.0, which was previously thought to be fixed. This vulnerability is similar in nature to CVE-2021-4104 which affected the 1.x branch of Log4j.

The last week has been a wild ride for just about everyone in the technology world due to the public disclosure of the Log4Shell vulnerability. As a developer security company, Snyk has built our business around proactive automation to identify and fix security issues in applications. To say we’ve been busy this week would be an understatement.

No matter how you slice it, the use of containers and Kubernetes continues to swell. And recent high profile vulnerabilities-that-shall-not-be-named have shown us how important container security is for an overall application security program. Protecting your own code, your dependencies, and the containerized services you use are all a must.

With great automation, comes great risk. The advent of infrastructure as code brought about automation for the tedium of deploying, provisioning, and managing resources in public clouds with declarative scripts. However, this automation increased the importance of creating secure IaC scripts or configurations with cloud infrastructure misconfigurations being cited as the biggest area of increased concern (58%) from 2020 to 2021 in the 2021 Snyk Cloud Native Application Security report.

More than 90% of organizations rely on open source software, a reliance that introduces a significant amount of security and legal risk via either direct or transitive open source dependencies. To overcome this challenge, Software Composition Analysis (SCA) solutions are playing an increasingly important role in helping organizations successfully identify and mitigate potential security issues.

Starting in early 2021, Snyk Code and became available as a freemium offering for Snyk users. Snyk Code helps developers quickly and accurately find, prioritize, and fix security flaws in proprietary code. With detailed remediation guidance at every stage of the software development lifecycle (SDLC), from the developer’s environment (IDE) to continuous integration and development (CI/CD) pipelines, Snyk Code revolutionizes static application security testing (SAST).

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.

Today (Dec.10, 2021), a new, critical Log4j vulnerability was disclosed: Log4Shell. This vulnerability within the popular Java logging framework was published as CVE-2021-44228, categorized as Critical with a CVSS score of 10 (the highest score possible). The vulnerability was discovered by Chen Zhaojun from Alibaba’s Cloud Security team. All current versions of log4j2 up to 2.14.1 are vulnerable. You can remediate this vulnerability by updating to version 2.15.0 or later.

In January of 2021, CodeCov suffered a supply chain attack that exposed client environment variables. In the following months, the specifics of the breach and its technical applications have been thoroughly examined by the application security community to determine what went wrong and how to combat similar attacks in the future. But another interesting outcome of the breach were the insights into a slightly less glamorous topic: responsible disclosure.

We’re happy to announce the open beta of C/C++ security scanning in Snyk Open Source, enabling development and security teams to find and fix known security vulnerabilities in their C/C++ open source code and libraries! Used across various industry verticals and prominent within the gaming, hardware/IoT, and communications industries, C/C++ continues to have a major impact on software development and the technology space as a whole.

In a previous blog post, we took a look at Java’s custom serialization platform and what the security implications are. And more recently, I wrote about how improvements in Java 17 can help you prevent insecure deserialization. However, nowadays, people aren’t as dependent on Java’s custom serialization, opting instead to use JSON. JSON is the most widespread format for data serialization, it is human readable and not specific to Java.