FinOps in the CI: Cost Guardrails at Provisioning Time

TanStack Supply Chain Attack: Anatomy of a Three-Stage Breach

How an attacker chained pull_request_target cache poisoning with GitHub Actions memory extraction to publish 84 malicious npm packages — and what you must audit in your own CI/CD pipeline.

Dashboards Are Receipts, Gates Are Guardrails

There is an asymmetry at the heart of cloud cost management: the decisions that create cost happen in pull requests, while the discovery of cost happens 30 days later in the bill. By the time a dashboard shows the overrun, the infrastructure has been provisioned, the resources have been paid for, and the fix is a cleanup project with a ticket backlog.

Provision-time FinOps eliminates this asymmetry. The developer sees the cost during the activity that produces it, with full context, in the tool where they are already making decisions. The available actions are now: accept the cost and merge, or modify the change and re-evaluate — both within the same work session.

This is the difference between a receipt and a guardrail. A dashboard is a receipt. A blocking CI check is a guardrail.

The Two Layers: Static and Runtime

A complete shift-left FinOps toolchain looks at infrastructure from two perspectives:

The Cost Gate Pipeline

The gate runs on every pull request that touches infrastructure code. Static analysis catches macro-level provisioning errors — an m5.large upgraded to an r5.4xlarge — while the runtime layer catches what static analysis cannot see.

Building the Gate: Infracost

Infracost is the workhorse of the static layer. It parses Terraform, OpenTofu, CloudFormation, and AWS CDK manifests, looks up real-time cloud pricing APIs, and computes exactly how much your bill changes if a PR merges. It supports over 1,100 resource types across AWS, Azure, and Google Cloud.

Two properties matter for security-conscious teams:

• No cloud credentials leave your pipeline. Infracost sends only resource-type and pricing-lookup queries to its pricing API — no credentials, secrets, or state data
• Consumption-based costs are modeled explicitly via a usage.yml file (Lambda invocations, S3 requests, data transfer), because static analysis cannot guess runtime usage

The Policy Gate: OPA and Rego

Infracost produces a JSON breakdown with per-resource costs and an aggregate diff.totalMonthlyCost. Open Policy Agent (OPA) evaluates that JSON against Rego policies; conftest is the conventional runner in CI.

Policy 1: Aggregate monthly cap

deny[msg] {
  delta := to_number(input.projects[_].diff.totalMonthlyCost)
  delta > threshold_monthly
  msg := sprintf(
    "Monthly cost delta is $%.2f, which exceeds the $%d limit. Break this into smaller changes or request an exception.",
    [delta, threshold_monthly],
  )
}

Policy 2: Per-resource cap with an exception path

Aggregate caps miss outliers — a single $2,000/mo resource inside a$400 diff is invisible to the total. A per-resource rule catches it, with a documented exception path:

deny[msg] {
  resource := input.projects[i].diff.resources[j]
  cost := to_number(resource.monthlyCost)
  cost > 200
  not has_justification(resource)
  msg := sprintf(
    "Resource %s costs $%.2f/mo. Add a '# cost-justified: <reason>' comment or split the PR.",
    [resource.name, cost],
  )
}

has_justification(resource) {
  startswith(resource.metadata.code_comment, "cost-justified:")
}

The has_justification predicate is the key design decision: exceptions are not bypasses, they become part of the code's audit trail. Every exception is visible in the PR comment history and reviewable.

The Complete Workflow

name: FinOps Cost Gate

on:
  pull_request:
    paths:
      - 'terraform/**'

jobs:
  cost-gate:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      - uses: actions/checkout@v4

      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.9.x

      - name: Configure AWS credentials (read-only)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.PLAN_ROLE_ARN }}
          aws-region: us-east-1

      - name: Terraform plan
        working-directory: terraform
        run: |
          terraform init -input=false
          terraform plan -out=tfplan.binary -input=false
          terraform show -json tfplan.binary > tfplan.json

      - name: Setup Infracost
        uses: infracost/actions/setup@v3
        with:
          api-key: ${{ secrets.INFRACOST_API_KEY }}

      - name: Infracost breakdown
        working-directory: terraform
        run: |
          infracost breakdown \
            --path tfplan.json \
            --format json \
            --out-file ../infracost.json

      - name: Enforce cost policy
        run: conftest test --policy policy/ infracost.json

      - name: Comment cost diff on PR
        if: always()
        uses: infracost/actions/comment@v3
        with:
          path: infracost.json
          behavior: update

The IAM role for planning is read-only and scoped to the target account — the gate can inspect, never mutate. The PR check is enforced as required via branch protection, so a cost violation blocks the merge like a failed test would.

The Runtime Layer: OpenCost and Kubecost

Static checks cannot predict what happens inside an elastic orchestration layer where costs change with traffic. For that, run OpenCost inside your clusters.

OpenCost is the open standard: a cloud-agnostic, community-driven API that standardizes cost metrics across platforms. Kubecost implements the OpenCost specification, providing real-time cost allocation at the namespace, deployment, and pod level, plus budget alerts when spending crosses thresholds.

The two layers work together. If your Infracost gate shows a microservice costs $200/month based on its declared CPU requests, but OpenCost telemetry shows real-world memory utilization never crossing 5%, you have found a downsizing target — with the numbers to justify it.

The Three-Phase Adoption Path

Don't enable hard-deny on day one. The pipeline has to earn trust first:

1. Advisory. Cost estimates appear on every PR, nothing is ever blocked. Teams learn the tooling and the cost language
2. Warning. OPA policies evaluate but violations only produce comments. Thresholds get calibrated against real-world deltas
3. Hard-deny. Merges block on policy violations; exceptions require explicit FinOps approval via the cost-justified path

Tuning Thresholds

Thresholds are calibration, not guesswork. Analyze two to four weeks of Infracost data first:

• The median PR increases monthly costs by $50–$500
• Set the aggregate threshold at approximately the 90th percentile of observed deltas — for most platform teams that lands between $300 and$1,000/month
• Set the warning threshold higher still ($2,000–$5,000) and the hard-deny threshold at the level that clearly indicates a provisioning mistake ($5,000–$15,000)
• Keep per-resource caps as the complement — they catch outliers that aggregate aggregation lets through

The Results Worth Measuring

A production reference implementation reports:

The +47 seconds per PR is negligible next to typical review latency — the gate costs less than a comment thread and prevents more than a budget review.

Beyond Terraform: Where the Same Pattern Applies

The gate pattern is not Terraform-specific. The same shape works wherever infrastructure is declared:

• OpenTofu and CloudFormation — Infracost parses both natively, so the identical pipeline works without Terraform
• Kubernetes manifests — OPA Gatekeeper at admission time catches direct kubectl apply changes that bypass the PR gate entirely
• GitLab CI / Jenkins — the conftest step is tool-agnostic; only the workflow wrapper changes
• AI coding agents — Infracost ships agent skills (iac-generation, scan, price-lookup) so agents generating infrastructure code check cost policies while they work, before the PR even exists

The unifying principle: cost policy lives as code next to the infrastructure it governs, evaluated in the same pipeline that reviews the change.

Caveats

• Static analysis cannot predict elastic costs. Pair the PR gate with OpenCost; never rely on one layer alone
• Consumption-based resources need usage.yml modeling or estimates will be systematically wrong
• Thresholds need calibration. Set them from data, review quarterly, and expect to tune after false-positive feedback
• The patterns are complementary, not substitutive: the PR gate prevents waste from merging, admission policies catch direct cluster changes, dashboards serve executive reporting, and provider budget alerts are the backstop
• Start advisory. A hard gate installed without trust generation creates shadow workflows, not cost discipline

Further Reading

• Terraform for AWS Infrastructure: A Beginner's Guide — the IaC workflow the gate analyzes
• Open Source Infrastructure Stack in Production 2026 — where cost governance fits in the stack
• Kubernetes GitOps with ArgoCD — the deployment pipeline the cost gate guards
• Grafana for Infrastructure Observability — dashboards for the runtime cost data
• Scaling Self-Hosted Cloud Applications — the scaling patterns whose cost the gate makes visible