We recently announced support in Fugue for the AWS Well-Architected Framework, a set of recommendations Amazon Web Services provides for designing infrastructure for cloud applications and workloads.
This month, Facebook and Twitch both suffered serious damage at their own hands, and every executive needs to understand what happened and how these types of incidents are preventable.
This week, Fugue announced unified infrastructure as code (IaC) and cloud runtime security. For the first time, cloud engineering and security teams can automate security across the development lifecycle using the same policies.
Cloud security has long been focused squarely on the cloud runtime environment to keep infrastructure free of misconfiguration vulnerabilities that can open the door to hackers and lead to data leaks and breaches. It is reasonable considering most (if not all) cloud-based security incidents result from customer mistakes in the form of cloud resource misconfiguration. Gartner calls this Cloud Security Posture Management, or CSPM.
Today, Sonatype and Fugue have partnered to deliver the tools developers and operations need to address every meaningful cloud attack surface and ensure compliance at every stage of the SDLC with a single unified solution. Read the press release here.
Today we announced Regula, an open source tool for evaluating Terraform infrastructure as code for potential security misconfigurations and compliance violations. Regula uses the open source Open Policy Agent(OPA) policy framework and Rego query language, which have gained significant traction in the Kubernetes community and scale to cloud infrastructure policy assessments as well (Fugue’s SaaS product performs more than 100 million policy evaluations using OPA every day).
For twelve years I’ve held executive management positions at companies making significant use of the cloud. Now I have the privilege of helping lead Fugue, a leading provider of cloud security and compliance solutions. Along the way I’ve found that senior executives—both at technology companies and outside the tech industry—sometimes struggle to understand the security implications of moving to the cloud. It’s common for executives to simply make blanket declarations that the cloud will never be secure enough for them (untrue), or alternatively to hold the belief that the cloud service providers like Amazon, Microsoft and Google take care of all the security issues for you (also untrue).
In the last part of this series, we're going to look at the final stages of the software development life cycle (SDLC)—deployment and operations. As a reminder, in parts one and two, we discussed the overall concept of shifting left for security and compliance, and laid out some best practices for how to do so during the development and testing phases of the SDLC. In this post, we'll cover how using policy as code and baselines allows you to leverage all the work done in the earlier phases to prevent deployment of misconfigurations and ensure that your deployed infrastructure remains functional and compliant over time.
Enterprise cloud adoption is in full swing, therefore cloud security and compliance has become a top priority. Security in the cloud requires different approaches than in the datacenter—and a different mindset. Demonstrating this are movements like DevOps, DevSecOps, and Shift Left, which have begun to transform how Cloud Security Posture Management (CSPM) is done with automation using tools like infrastructure as code and policy as code.
In an earlier blog post, we discussed at a high level how security can shift left regarding cloud infrastructure. In this post, we'll drill in with more detail on how this can be done through the discrete phases of the Software Development Life Cycle (SDLC), beginning with the development phase, and extending through testing, and ultimately all the way to deployment and ongoing operations.