What is Lateral Movement? Lateral movement refers to the techniques that a cyber-attacker uses, after gaining initial access, to move deeper into a network in search of sensitive data and other high-value assets. Lateral movement techniques are widely used in sophisticated cyber-attacks such as advanced persistent threats (APTs).

We recently surveyed the Open Policy Agent (OPA) community to gauge use case adoption, pain points and generally help guide the project. The recent survey results reflect how much the community has grown over the past year. This time we received 204 responses from over 150 organizations across North America, Europe, Asia, Australia and Africa. Over 90% of respondents indicated they are in some stage of OPA adoption (e.g., pre-production, production, etc.).

This CVE is a Server Side Request Forgery (SSRF) vulnerability in kube-controller-manager that allows certain authorized users to leak up to 500 bytes of arbitrary information from unprotected endpoints within the master’s host network (such as link-local or loopback services).

Reverse shell is a way that attackers gain access to a victim’s system. In this article, you’ll learn how this attack works and how you can detect it using Falco, a CNCF project, as well as Sysdig Secure. Sometimes, an application vulnerability can be exploited in a way that allows an attacker to establish a reverse shell connection, which grants them interactive access to the system.

Today, we are pleased to announce the expansion of Sysdig’s relationship with IBM to extend cloud security governance with IBM Cloud Pak for Multicloud Management. Through a new OEM agreement, Sysdig Secure and the Sysdig Secure DevOps Platform are now available through IBM and IBM Business Partners. The combined IBM and Sysdig offering delivers centralized cloud visibility, governance and automation with in-depth container security intelligence for Red Hat OpenShift.

In under five years time, Kubernetes has become the default method for deploying and managing cloud applications, a remarkably fast adoption rate for any enterprise technology. Amongst other things, Kubernetes’s power lies in its ability to map compute resources to the needs of services in the current infrastructure paradigm. But how does this tool work when faced with the new infrastructure layer that is blockchain? Can the two technologies be used in conjunction?

New applications and workloads are constantly being added to Kubernetes clusters. Those same apps need to securely communicate with resources outside the cluster behind a firewall or other control point. Firewalls require a consistent IP, but routable IPs are a limited resource that can be quickly depleted if applied to every service.

As one of the engineers on the Gravity team here at Gravitational, I was tasked with adding SELinux support to Gravity 7.0, released back in March. The result of this work is a base Kubernetes cluster policy that confines the services (both Gravity-specific and Kubernetes) and user workloads. In this post, I will explain how I built it, which issues I ran into, and some useful tips I’d like to share. Specifically, we will look at the use of attributes for the common aspects of the policy.