Blog Post

<- Back

Terraform Commits, without the stress and noise - it's not wizardry it's code

Michael Schwartz
June 7, 2022

Static Code Scanning vs Full Posture Simulation for IaC

It is well known that IaC (Infrastructure-as-Code) is becoming an increasingly important strategy associated with DevOps and CloudOps practices. Tools such as Terraform and CloudFormation allow software-defined infrastructure to be deployed quickly and repeatedly to the public cloud infrastructure.
As a result of this emerging technology, IaC deployments are not always tested correctly, or sometimes not at all, leading to misconfigurations that reach production environments.
Misconfigurations can range from small to severe, potentially putting an organization at risk of downtime,  data breaches or failure of compliance with regulations.

Static code analysis for IaC
Many teams review IaC by multiple functions (Ops and Sec) manually. However, in the past years, we have seen a proliferation of static code analysis tools that reduce the amount of work needed to verify security-related impacts. (such as Kicks by Checkmarx, Checkov by Bridgecrew, TFsec by Aqua, WIZ CLI, Orca CLI, Snyk, OPA and others ).

Static code analysis is a way for Infrastructure engineers to test their code without actually executing it — this is called a non-run-time environment. Static code analysis tools offer a nice way to find Infrastructure faults and display them to DevOps engineers. Using it, errors can be picked up long before they end up causing havoc when the code is released to our cloud account.
Despite their technological advances, there is a major downside to this method, which is the lack of context. These tools miss the ability to merge the build state with the run-time state. As a result, many issues remain undetected because they only provide a partial picture.

False positives become common as these tools do not understand the cloud posture (relationships between resources).
As an example, A violation was triggered when someone opened port 22 on rule in a security group. A “CRITICAL” alert was triggered however the security group is not attached to any resource, and no actual security violation has been generated. Without taking posture into account, false positives and false negatives are generated. Both of these contribute to noise, as well as missing significant violations.

IaC Static code analysis

Another example might be a critical alert on the fact that an RDS instance has “publicly_accessible” set to true, however, the RDS instance is not exposed to the internet at all as it is located in a private subnet and its security groups allow specific internal IPs.

terraform code scan

Another major pain point for cloud security and operation teams is the unnecessary cycles between them.
A DevOps engineer performed a change that caused a security violation. After the violation is detected, the security team investigate the violation and opens a ticket to the DevOps team that owns the infrastructure. Now the DevOps team is required to analyze who made the change, the impact radius and the actual severity of the alert. If a fix is needed, it is necessary to consider what will happen to all the related resources that utilize the problematic resource, which is a difficult task by itself.

Build resilience, eliminate stress, focus on the work that matters.

Lightlytics eliminates these unnecessary cycles and helps DevOps and Cloud security teams focus on the work that matters, allowing teams to easily adopt the shift-left approach to security (DevSecOps), availability, cost and overall impact analysis of terraform commits.

Our engine covers both build and runtime with the same rules while providing all the necessary context to reduce time and increase confidence.

Foresee the impact of every proposed change on your entire cloud posture and services. simulate changes at the posture level prior to deployment, as we take both build and runtime into consideration, by doing so we eliminate unnecessary noise, false positives, and detect dependencies that are unseen by static code analysis tools, while enforcing custom rules according to the organization’s business logic on top of out of the box best practices.

To determine if a policy has been violated, the engine calculates the entire dependency path, cross region and account dependencies are taken into consideration as well.

IaC Code Simulation

Efficiently understand downstream dependencies to decide how severe the exposure is (resources is going to be exposed on port 22 and will have downstream access to OpenSearch and RDS)

Terraform Security

Build and Runtime are calculated against every commit:

Terraform visualization
The created EC2 will have access to a running RDS
Terraform Impact analysis
The Created EC2 will have access to S3 buckets

With each configuration change, in real-time or in the build phase, Lightlytics provides the full context regarding who made the change, to what, and more importantly - how it affected your existing infrastructure across multiple verticals such as Availability, Security and even cost.

On top of the above Lightlytics is the only tool on the market that is capable of alerting on availability impacts based on current application behavior so in case a change is made to an actively used resource you will get all the data you need as part of the commit.

Terraform Simulation

AWS path simulation

Advantages of shifting left with Lightlytics:

  • 5 min integration to any CI/CD system (Github, Gitlab, Bitbucket, Atlantis, Jenkins and Terraform Cloud).
  • Cloud, Kubernetes, Entitlements, and all their dependencies are managed in one platform.
  • Eliminate availability and security risks when deploying new infrastructure code.
  • Don't waste time on false positives.
  • Cut code review time in half. Ensure that your senior engineers/Team leaders utilize their time more efficiently.
  • Ensure the intended outcome of the change is met before applying the code - this is the end of multiple Terraform apply and destroy attempts until you achieve your desired results. No matter how complex your Terraform code is, Lightlytics will show you in a visual manner whether your Terraform code achieves your goal.
  • Engineers should be able to understand and modify infrastructure with confidence - Currently, the ability to create, modify, and destroy infrastructure belongs to the most qualified DevOps engineers in an organization, but who says this should be the case? Delegate configuration changes to Developers.

Reduce stress and mistakes, sign up for a trial now!

You’d never cross the street without checking both ways first. Never deploy cloud infrastructure without evaluating the risks and building your plan properly.