In The State of Application Security, 2020, Forrester predicts application vulnerabilities will continue to be the most common external attack method. Because of this, organizations are urged to continue testing early in the software development life cycle (SDLC), implementing auto-remediation for security vulnerabilities, and shoring up production protections.
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?
A friend that can’t keep a secret isn’t one you’ll rely on. The same is true for your mission critical CI/CD tool that you have to entrust with credentials for each integrated component. Keeping your secrets safe can be a challenge for CI/CD tools, since they need to connect to such a variety of other services. Each one needs its own password or token that must be kept hidden from prying eyes.
The terms DevSecOps and SecDevOps are often -- but not always -- used interchangeably. So is there any real difference between the two terms or is it all just semantics? Let’s look at how the role of security has changed as the software development life cycle (SDLC) has evolved to explore whether there’s really any difference between these two words.
We’ve had an exciting past six months at Styra, from a Series A funding announcement to tremendous growth in the Open Policy Agent (OPA) community to new enhancements to our commercial product, Styra’s Declarative Authorization Service (DAS). All of this great momentum maps to our overarching vision of unifying authorization and policy for the cloud-native environment.
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.
