Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Transparency in vulnerability disclosure plays a crucial role in effective risk management, regardless of software development models. The Common Vulnerabilities and Exposures (CVE) database serves as a valuable resource, offering insights into known weaknesses even when fixes are unavailable. This empowers organizations to make informed decisions about prioritizing mitigation strategies and protecting their systems.

Welcome to our December edition of the “What’s New in Sysdig” blog series. We decided to do a year in review for this monthly recap as we wanted to focus on a few key highlights the company went through the past 12 months. As we look at the past year, the landscape of cloud security has seen its challenges and evolution.

This week’s news of Cisco’s intent to acquire Isovalent sends an important message to the cloud security ecosystem: network security is no longer an afterthought in the cloud-native world. It’s now a critical component of any robust security posture for cloud-native applications. This move not only validates the work of the Isovalent team in evangelizing this essential category but also underscores the vision Tigera has pioneered since 2016 with Project Calico.

In the rapidly evolving world of container orchestration, developers have come to rely on Kubernetes to manage containerized applications. However, as Kubernetes adoption increases among organizations, ensuring the security of Kubernetes environments becomes essential. One particularly significant aspect to consider is vulnerability prioritization. It’s essential to understand that chasing after the highest CVSS scoring vulnerabilities might not always align with real-world threats.

This is part two in our series on building honeypots with Falco, vcluster, and other assorted open source tools. For the previous installment, see Building honeypots with vcluster and Falco: Episode I.

The surge of cloud-native applications has propelled Kubernetes into the forefront, revolutionizing how we manage and deploy workloads. However, this exponential growth has also increased the security challenges, and attack surface, DevOps and Security teams must address. As we discussed in a previous blog post, traditional network security measures fall short when presented with Kubernetes’ dynamic nature, demanding a paradigm shift towards more adaptable solutions.

In my previous blog post, What you can’t do with Kubernetes network policies (unless you use Calico): Policies to all namespaces or pods, I talked about this use case from the list of nine things you cannot implement using basic Kubernetes network policy — policies to all namespaces or pods. In this blog post, we’ll be focusing on the next use case — advanced policy querying and reachability tooling.

In the fast-paced environment of cloud-native apps, security and seamless connections are a priority. Many DevOps and SecOps professionals use Kubernetes native features to handle their container security, keeping a tight grip on access and secrets to improve security posture. The integration between AWS AssumeRole and JFrog Access in Amazon Elastic Kubernetes Services (EKS), enhances enterprise security by automating secrets management.

One recurrent point in our first interaction with Kubernetes users is the difficulty of implementing security controls on their Kubernetes clusters where tenant or workload isolation is required during rollout or runtime. This happens due to one of the following reasons: Calico provides several features and capabilities to cover each one of the above points with Policy Recommendation, Policy Board, and Dynamic Service and Threat Graph.