So you’re running microservices in containers? Congratulations! This is an important step towards meeting those business needs around delivering applications to the hands of your customers as soon as possible. But how can we mitigate any potential risks associated with faster software deployment? Simple, with Snyk.
AWS GDPR compliance, privacy and personal data protection are one of the most common concerns among cloud teams that run workloads in the AWS Cloud. When thinking about the different mechanisms to protect privacy and gain trust from the users who utilize our services, Compliance is one of the words that comes to mind.
Suppose you’ve been working with container images for more than a minute. In that case, you’re probably familiar with those ubiquitous documents that describe, layer-by-layer, the steps needed to construct an image: Dockerfiles. Did you know that there is a growing set of tools for building OCI compliant images without Dockerfiles?
Shipping your apps in containers gives you the freedom to build upon the work of others. You can pick from a variety of ready-to-use container images that will run nearly any code or framework you have. Snyk Container already helps users manage their parent images and provide guidance when there are better options available — images with few vulnerabilities, or a smaller footprint overall, or both.
In a previous post, we presented a step-by-step tutorial on how to publish Node.js Docker images to GitHub Packages registry using GitHub Actions. In this post, we’ll focus on publishing the Docker image that we build to the public Docker Hub registry. Why is this useful you might ask? The Docker command line application docker has a default registry setting for docker.io which points to the Docker Hub registry.
The National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) have published comprehensive recommendations for strengthening the security of an organization’s Kubernetes system to help companies make their Kubernetes environment more difficult to compromise. This 52-page cybersecurity technical report offers practical guidance for admins to manage Kubernetes securely, focusing on the common three sources for a compromised Kubernetes environment.
In a never-ending game of cat and mouse, threat actors are exploiting, controlling and maintaining persistent access in compromised cloud infrastructure. While cloud practitioners are armed with best-in-class knowledge, support, and security practices, it is statistically impossible to have a common security posture for all cloud instances worldwide. Attackers know this, and use it to their advantage. By applying evolved tactics, techniques and procedures (TTPs), attackers are exploiting edge cases.
Kubernetes version 1.22, the latest release of Kubernetes, comes with bug fixes, enhancements, and new features that make the platform more stable, scalable, and user-friendly. There are a total of 56 improvements with different maturity levels and a considerable number of API removals. In this article, I’ll focus on the security-related changes in Kubernetes as well as a few other significant changes in Kubernetes API and usability.
In any case, by using the MITRE ATT&CK framework to model and implement your cloud IaaS security, you will have a head start on any compliance standard since it guides your cybersecurity and risk teams to follow the best security practices. As it does for all platforms and environments, MITRE came up with an IaaS Matrix to map the specific Tactics, Techniques, and Procedures (TTPs) that advanced threat actors could possibly use in their attacks on Cloud environments.
The CVE-2021-33909, named Sequoia, is a new privilege escalation vulnerability that affects Linux’s file system. It was disclosed in July, 2021, and it was introduced in 2014 on many Linux distros; among which we have Ubuntu (20.04, 20.10 and 21.04), Debian 11, Fedora 34 Workstation and some Red Hat products, too. This vulnerability is caused by an out-of-bounds write found in the Linux kernel’s seq_file in the Filesystem layer.
