View article in it’s entirety on securityboulevard.com
From Michael Vizard at SecurityBoulevard: “The first phase of DevSecOps was marked by getting more cybersecurity tools into the hands of developers. This next phase will be defined by integrated DevSecOps workflows created to address the unique attributes of cloud-native applications built microservices, Hannigan said.
As each microservice is constructed it becomes instantly possible to understand the security implications using a set of graph-based tools that not only discover the microservices but also surface all the potential security issues an organization consciously needs to approve. The core issue cybersecurity teams are contending with today is that given all the dependencies that exist between microservices, it’s not possible to know whether a microservice that has just been deployed has implicitly given any existing microservices permission to access data in ways that no one in the IT organization can easily see or comprehend.
Much of the current focus on DevSecOps is being driven by incidents involving, for example, S3 buckets on the Amazon Web Services (AWS) public cloud involving ports that have been left open due to misconfigurations that occurred when developers employed tools such as Terraform to automate the provisioning of infrastructure. When most application workloads were deployed in an on-premises IT environment, most infrastructure security issues were addressed by an internal cybersecurity team. Now that infrastructure is managed as code in the cloud by the developer, that review process has been effectively eliminated.”