A question that comes up every now and then is whether it’s possible to compose policies based on dynamic attributes provided with the request when querying Open Policy Agent (OPA) for decisions. Could we for example provide a group, team or role name as part of the input and have OPA evaluate all policies provided for that group, team or role, but no additional policies other than those? Imagine you have several teams in an organization, each of them with their own responsibilities.

We’re pleased to announce support for viewing all of your Snyk Infrastructure as Code (Snyk IaC) configuration issues in the reporting functionality of the Snyk platform.

Writing secure code in a way that prevents code injection might seem like an ordinary task, but there are many pitfalls along the way. For example, the fact that you (a developer) follow best security practices doesn’t mean that others are doing the same. You’re likely using open source packages in your application. How do you know if those were developed securely? What if insecure code like eval() exists there? Let’s dive into it.

CloudCasa™, a simple, scalable, cloud-native data protection service that supports all leading Kubernetes distributions and managed services, is now generally available through the SUSE Rancher™ Apps & Marketplace. With increasing adoption of cloud database services, CloudCasa adds cloud database support starting with Amazon RDS to its Kubernetes data protection service – addressing both Kubernetes and RDS support in a single data protection service.

Kubernetes secrets are the nativere sources for storing and managing sensitive data, like passwords, cloud access keys, or authentication tokens. You need to distribute this information across your Kubernetes clusters and protect it at the same time. When sending your password to each node in your cluster, it’s critical to ensure that only authorized entities—users, services, or workloads—are able to access it.

While it’s relatively easy to buy modern security tools, the culture of a company can have an enormous impact on the successful rollout of new security processes. In fact, one of the greatest hurdles for implementing a DevSecOps approach to application security is company-wide adoption.

Databases are the Holy Grail for hackers, and as such, must be protected with utmost care. This is the first in a series of articles in which we’ll give an overview of best practices for securing your databases. We’re starting with one of the most popular open-source databases, PostgreSQL, and will go over several levels of security you’d need to think about.