Fix Cloud issues in IaC (integrated IaC)

The Fix Cloud issues in IaC feature is available for Integrated IaC only, and supports AWS.
The "Fix Cloud issues in IaC" feature enables users to fix Cloud issues directly in the IaC source code that was used to deploy the misconfigured Cloud resources, by linking a Cloud issue to the underlying IaC template via a SCM source code link.
Many Snyk customers use IaC to deploy and manage Cloud resources. However, organizations may still deploy misconfigured IaC templates, which results in misconfigured Cloud resources, and therefore Snyk Cloud issues. This can be due to a number of factors, such as pipelines that aren’t configured to block deployments even if cloud misconfigurations are found.
To remediate these Cloud issues today, security teams need to manually determine which teams own the resources that were incorrectly deployed, and then developers in turn need to manually find the appropriate IaC templates that were used. This can be a very time consuming process.
This feature eliminates these manual steps, and provides a user with a link to the underlying IaC template that needs to be fixed.

How does the feature work?

Snyk delivers this capability by “mapping” Cloud resources to the source IaC templates where possible. We do this by leveraging information contained in Terraform state files, such as resource IDs, which enable us to map Cloud resources to Terraform state, and Terraform state to IaC source code.
Snyk accesses Terraform state files via CLI, which should be integrated into your deployment pipeline. Snyk does NOT send the .tfstate file to the Snyk Platform, given the potential for sensitive information. Instead, we obtain the minimum amount of data necessary for resource mapping, such as resource IDs, and we include this information in a mapping artifact that is sent to the Snyk Platform. All other configuration data is not included in a mapping artifact.
Snyk generates resource mappings from Cloud resources to IaC source templates by analyzing mapping artifacts, Cloud resources, and IaC resources when Cloud environments are scanned.


You should have the following:
  • Access to a Snyk service account and API token
  • Access to a Snyk Organization with Snyk Cloud and integrated IaC
  • Deploy cloud resources to AWS with Terraform via CI/CD
  • Use Terraform version 0.11 or later

Getting started

Step 1: Onboard IaC and Cloud environments to Snyk

Please onboard IaC (integrated) environments via the Snyk CLI workflow (snyk iac test --report), and onboard relevant AWS environments via Snyk Cloud.
snyk iac test must be run from the root folder of the cloned git repository - not a subdirectory. If using GitLab or Azure DevOps, please add a target-reference option so Snyk can generate an SCM link:
snyk iac test --report --target-reference=$(git branch --show-current)
These AWS environments should include resources deployed with Terraform via your CI/CD tool.

Step 2: Configure CI/CD pipeline script

Configure a CI/CD script to:
  • Pull down the Terraform state via terraform state pull
  • Install the Snyk CLI, and run snyk iac capture with relevant options.
We have sample CI/CD scripts for your reference here:

GitHub Actions example

Set the following environment variables in GitHub as encrypted repository secrets:
  • AWS_ACCESS_KEY_ID - used for terraform apply and terraform state pull
  • AWS_SECRET_ACCESS_KEY - used for terraform apply and terraform state pull
  • SNYK_TOKEN - the Snyk service account's API token
  • SNYK_ORG_ID - the Snyk Organization ID
name: continuous-delivery
- main
runs-on: ubuntu-latest
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
- uses: actions/[email protected]
- uses: hashicorp/setup-[email protected]
terraform_wrapper: false
- uses: snyk/actions/[email protected]
- run: terraform init
- name: terraform plan
run: terraform plan -input=false
# Always report misconfigurations and continue with job
- name: snyk iac test
run: snyk iac test --org=${{ secrets.SNYK_ORG_ID }} --report || true
- name: terraform apply
run: terraform apply -auto-approve -input=false
- name: capture terraform state
run: terraform state pull | snyk iac capture --org=${{ secrets.SNYK_ORG_ID }} --stdin

CircleCI example

Set the following environment variables in CircleCI:
  • AWS_ACCESS_KEY_ID - used for terraform apply and terraform state pull
  • AWS_SECRET_ACCESS_KEY - used for terraform apply and terraform state pull
  • SNYK_TOKEN - the Snyk service account's API token
  • SNYK_ORG_ID - the Snyk Organization ID
version: 2.1
terraform: circleci/[email protected]
snyk: snyk/[email protected]
image: ubuntu-2204:current
resource_class: medium
- checkout
- terraform/install:
terraform_version: 1.4.2
- snyk/install
- terraform/plan
- run:
name: snyk iac test
command: snyk iac test --org=$SNYK_ORG_ID --report || true
- terraform/apply
- run:
name: capture terraform state
command: terraform state pull | snyk iac capture --org=$SNYK_ORG_ID --stdin
- delivery

Step 3: Run the pipeline!

By running your CI/CD pipeline to pull Terraform state and run snyk iac capture, Snyk will generate a mapping artifact with a minimal amount of information from the Terraform state file, and send it to Snyk.
When a mapping artifact is created or updated, Snyk executes a mapping run by analyzing IaC resources, Cloud resources, and mapping artifacts across a Snyk organization, and generates resource mappings that include connections between Cloud and IaC resources.

Step 4: Wait a few minutes, and check the Cloud Issues UI

Please wait a few minutes so that Snyk can finish the Cloud environment scan, complete the mapping run, and update resource mappings.
For supported resource types, relevant Cloud Issues should now include mapped IaC resources within the “IaC” tab. Each IaC resource includes information on the resource name, IaC template location, and where available, a link to the SCM tool.
The IaC tab in a Cloud issue shows mapped IaC resource information.
The IaC tab in a Cloud issue shows mapped IaC resource information.

Supported resource types

  • aws_api_gateway_deployment
  • aws_api_gateway_resource
  • aws_api_gateway_rest_api
  • aws_cloudtrail
  • aws_cloudwatch_log_group
  • aws_db_instance
  • aws_db_subnet_group
  • aws_default_security_group
  • aws_default_vpc
  • aws_dynamodb_table
  • aws_ebs_volume
  • aws_eip
  • aws_flow_log
  • aws_iam_access_key
  • aws_iam_group
  • aws_iam_group_policy
  • aws_iam_group_policy_attachment
  • aws_iam_instance_profile
  • aws_iam_policy
  • aws_iam_policy_attachment
  • aws_iam_role
  • aws_iam_role_policy
  • aws_iam_role_policy_attachment
  • aws_iam_user
  • aws_iam_user_policy
  • aws_iam_user_policy_attachment
  • aws_instance
  • aws_internet_gateway
  • aws_kms_key
  • aws_lambda_function
  • aws_lambda_permission
  • aws_network_acl
  • aws_network_interface
  • aws_rds_cluster
  • aws_rds_global_cluster
  • aws_route_table
  • aws_route_table_association
  • aws_s3_account_public_access_block
  • aws_s3_bucket
  • aws_s3_bucket_acl
  • aws_s3_bucket_logging
  • aws_s3_bucket_policy
  • aws_s3_bucket_public_access_block
  • aws_s3_bucket_server_side_encryption_configuration
  • aws_security_group
  • aws_security_group_rule
  • aws_sns_topic
  • aws_subnet aws_vpc