If you didn’t attend our recently concluded DevOps Cloud Days online conference, you missed a learning event that those who did called “fantastic” and “meaningful.” In written feedback, developers, operations staff, and security admins who attended described the presentations as “powerful,” “inspiring” and “excellent.” Fortunately, it wasn’t your last chance to share that fruitful experience with us.

Make no mistake: You can’t overlook software distribution in DevOps. At risk are the reliability, security and speed of your software releases — and your business itself. This is especially true in enterprises that are releasing across numerous edge endpoints or IoT devices. As your releases’ cadence and payload grow, software distribution challenges multiply, particularly at the edge.

Last week, a critical vulnerability identified as CVE-2022-0185 was disclosed, affecting Linux kernel versions 5.1 to 5.16.1. The security vulnerability is an integer underflow in the Filesystem Context module that allows a local attacker to run arbitrary code in the context of the kernel, thus leading to privilege escalation, container environment escape, or denial of service.

Modern software projects are mostly composed of open source code. The question of who really controls this code, and is responsible for detecting and fixing software supply chain security issues, became a significant source of concern after the discovery of the Log4Shell vulnerability.

With software supply chain attacks on the rise, implementing DevSecOps best practices in an air gapped environment is a must. In an effort to secure an organization’s internal network, there is an increasing trend of separating the internal network from the external one. Essentially creating an enclosed and disconnected environment from the public internet. An air gapped solution provides stricter security requirements, but that’s not enough.

JFrog has been hard at work behind the scenes restructuring how we share information with the developer community. We wanted to create a one-stop resource for developers who code in a variety of languages, with a focus on DevOps, DevSecOps, and cloud native technologies. So without further ado … let me introduce you to our new JFrog Community site!

Very recently, the JFrog security research team has disclosed an issue in the H2 database console which was issued a critical CVE – CVE-2021-42392. This issue has the same root cause as the infamous Log4Shell vulnerability in Apache Log4j (JNDI remote class loading). H2 is a very popular open-source Java SQL database offering a lightweight in-memory solution that doesn’t require data to be stored on disk.

Together with the community, JFrog pioneered what we now know as DevOps with a focus on binaries (aka software packages, artifacts or images). A decade ago, no one thought binary management would be a thing — now it’s a standard most companies can’t live without. Back then, we said software universality would be necessary, and now others follow suit. People thought cloud would be a single-vendor decision.

Over the last several years, systems architects have had to make sure their systems are cloud native, with applications that are optimized for scalable cloud technology infrastructure. In today’s environment, you should be asking whether your solutions are cloud nimble as well. For the modern enterprise, cloud computing is now the default model for applications, storage, and compute.

There are many benefits to working with JFrog Artifactory as your private Docker registry, allowing you to store, share and deploy your binary artifacts in a single source of truth. This blog post will focus on using Artifactory in Kubernetes. Specifically, we’ll walk through the steps for configuring Kubernetes to pull images from Artifactory and most importantly – scale up! It will also describe how you can enable cluster-wide authenticated access to Artifactory behind the scenes.