Most cloud misconfigurations don’t start in your cloud. They start as infrastructure as code (IaC) that one of your developers wrote, a reviewer approved in a pull request, and your CI/CD pipeline deployed. While Sweet is anchored on shift-right runtime security principles, Sweet IaC Scanning shifts security left. It checks that code in your pipeline against the same policies Sweet applies to your live cloud environment. Every scan ends in a clear decision on the change, and that decision goes to the developer who can act on it. You fix misconfigurations before they’re deployed and keep one consistent view of configuration risk from code to cloud.

Fix Misconfigurations When They Cost You the Least

With IaC, your teams define cloud infrastructure in code instead of configuring it by hand, using tools like Terraform and AWS CloudFormation. Every storage bucket, security group and IAM role exists as code before it exists in your cloud, which makes the pull request the cheapest place to fix a misconfiguration.

There, the fix is a few lines of code, made by the developer who wrote them, with nothing exposed in the meantime. In production, the same misconfiguration is a live exposure, a remediation ticket and a developer pulled back into code they wrote weeks ago. If someone patches the resource in the cloud console instead of in code, the next deployment can quietly bring the misconfiguration back. Scanning your IaC catches the misconfiguration at the source, so you fix it once in code instead of chasing it in your cloud.

Act on IaC Findings Instead of Triaging Them

Detecting misconfigurations in infrastructure code is a well-established practice. The greater challenge is giving your teams the context they need to act on what is found. Standalone IaC scanners typically report findings in CI logs or separate dashboards, using severity models that often differ from the one your security team uses to prioritize cloud risk. Findings are frequently disconnected from the commits that introduced them, and fixes made in code are not linked to the cloud posture issues they prevent. As a result, your security and development teams often work from separate lists that describe the same risk in different terms, which slows prioritization and makes ownership unclear.

Sweet closes that gap in three ways:

• One policy model: your code is checked with the same policies, severities and compliance frameworks Sweet applies to your live cloud.
• A decision on every change: each scan ends with a Block, Warn or Pass recommendation and shows whether the change added or removed risk.
• Clear ownership: every scan is tied to the repository, branch, commit and committer behind the change.

Prioritize Code and Cloud Risk with One Set of Policies

IaC Scanning is part of the same Configurations module you use to evaluate your live cloud environment. The policies, severities, categories and compliance frameworks are identical, meaning that you no longer need to reconcile two severity models or two lists of the same risk. Your developers get findings that match the standard your security team will hold them to in production, which removes the debate over whether a finding matters.

Add Coverage to the CI/CD Tools You Already Use

Sweet IaC Scanning runs as a single job in your CI/CD pipeline. The scanner runs inside your pipeline, so Sweet never needs access to your source code repository. Setup starts in Settings > Integrations > CI/CD IaC, which contains a tile for each supported tool: GitLab, GitHub, AWS CodePipeline, GoCD, Bitbucket and Azure DevOps. Each tile includes step-by-step instructions and generated credentials, so you can extend coverage across every pipeline you run.

See Whether Each Change Strengthens or Weakens Your Posture

The Scans tab, under Configurations > IaC Scanning, lists every pipeline run. Each row shows the repository, the committer, the violations found by severity, a Block, Warn or Pass recommendation and the difference from the previous run. Because each run is tied to its committer, the recommendation goes directly to the developer who can act on it.

In the example below, run 50002 of checkout-service introduced no new violations and resolved 13. You can see that the change reduced your risk without opening a single finding. The run still carries a Block recommendation because violations remain, so you know the work isn’t finished.

Triage IaC Violations with the Context You Already Use

The Violations tab lists every violation by repository, branch, resource, policy, severity, compliance framework and status. You can filter by status and severity, and group violations by repository, resource type or policy. Service owners focus on their own repositories, and your security team sees which policies fail most often across your organization.

Each violation is mapped to the compliance frameworks it affects, such as CIS, PCI-DSS and HIPAA, so your audit preparation starts in the pipeline. Statuses such as Open, In Progress, Under Investigation, False Positive and Resolved let you track each violation from detection to resolution.

Give Your Developers Exactly What They Need to Fix It

Selecting a violation opens a detailed view: a description of the risk, its severity and category, the affected compliance frameworks, and the cloud provider and resource. It also shows exactly where the problem lives in your code: repository, branch, commit, file path and line number. The view highlights the configuration field that failed, shows the full resource configuration and includes a Remediation view.

In the example below, an S3 bucket named receipts has no default server-side encryption. The violation points to the exact field and line in the checkout-service Terraform plan, so the developer who owns the change can go straight to the fix.

What’s Next: From Recommendation to Enforcement in Your Pipeline

We’re extending IaC Scanning with enforcement rules that turn Block, Warn and Pass recommendations into action in your CI/CD pipeline. You’ll be able to stop a misconfigured change before it deploys, using the same policies that already govern your live cloud.

The recommendations you see today lay the groundwork. Every scan adds to a record of what each policy would have stopped. When you turn on enforcement, you’ll be enforcing policies you’ve already tuned to your environment and proven with your developers.

It’s the next step in bringing Sweet’s action-first approach to infrastructure code: catching misconfigurations in your pipeline and stopping them before they ever reach your cloud.

Keep Misconfigurations Out of Your Cloud

To get started, go to Settings > Integrations > CI/CD IaC, select your CI/CD tool and follow the instructions. Your first scan appears under Configurations > IaC Scanning as soon as your pipeline runs. The [IaC Scanning documentation] covers each tab, the recommendation logic and the status model. The result is fewer misconfigurations reaching production, faster fixes from the developers who wrote the code, and a clear decision on every change before it reaches your cloud.

To learn more about Sweet's IaC Scanning, request a customized demo