The new network access analysis is a graph-based module that enables identifies when resources are potentially reachable from the public internet. The analysis is performed by combining AWS security group definitions with the Bridgecrew Resource Graph.

All cloud providers and most popular configuration services now offer inline tagging as a means of standardizing resource inventories and applying consistent management policies across all resource types.

Our users requested a better way to visualize how their resources performed in the last 30 days. They are interested to see how the addition of resources or policies affected heir overall posture.

Operating a large scale cloud environment makes it practically impossible to keep track on every running resource. Gaining quick visibility to the latest configuration specs on running resources requires navigating through tedious cloud console pages or worse, inventory exports into spreadsheets.

As a cloud infrastructure team your aren't only responsible for the deployed cloud resources in your environment, you need to constantly keep an eye on the new resources provisioned by developers from other teams.

To enable more comprehensive coverage while scanning for misconfigurations based on external modules, Bridgecrew now supports external module scanning as well as full variable rendering. What this means is that whenever your Terraform files will rely on modules or variables, Bridgecrew will build a full dependency graph of those modules and variables, render the correct values and evaluate them against the baseline.

If you're using Terraform Cloud to operate and manage your cloud provisioning lifecycle, you're probably aware of the benefits of predictable deployment outcomes. One important pillar of that process is ensuring security and compliance standards are met on every resource block.

There are endless options to provision and configure resources in the public cloud. While cloud provider consoles and SDKs register changes in standard logging solutions like AWS CloudTrail or Google's StackDriver, it's becoming increasingly difficult to use these logs to keep track of meaningful configuration changes. IaC introduces an additional layer of complexity by storing configuration changes in git logs and state files.

Fixing misconfigured cloud resources isn't just about replacing configuration variables. Before changing existing configurations, we should make sure we know how those configurations are currently being used throughout our IaC dependencies.

It's been a long time since we upgraded the experience of our native Incidents filters.