Add InfraScan CI workflow for IaC security and cost auditing

[igor-soldev]

Summary

This PR introduces a new GitHub Actions workflow integrating InfraScan, an open-source Infrastructure as Code (IaC) security and cost auditing tool by SolDevelo.

The workflow automatically executes on every push and pull_request, providing the engineering team with clear visibility into code-level cloud waste, security vulnerabilities, and infrastructure posture shifts before changes hit production.

An initial comprehensive baseline scan has been run over the codebase, scanning 518 infrastructure resources.

🔗 View Full Interactive Audit Report

📊 Baseline Infrastructure Metrics

• Overall Health Grade: B (91.9%) – 521 total issues detected
• Cost Optimization: B (93.1%) – 88 violations (4 High impact)
• IaC Security: C (82.7%) – 433 violations (433 Medium)
• Container Security: A (100%) – 0 vulnerabilities detected

💰 Cost Savings Potential

• Estimated Savings: $198 – $382 / mo
• Total Budget Impact: Trimming down these inefficiencies can save between 20.3% – 39.2% of our scanned total infrastructure monthly cost ($975/mo).

🔍 Key Areas for Improvement

• Cost Allocation (88 findings): The tool flagged 4 high-impact cost optimization opportunities (such as unmanaged resources, old generation instance types, or missing lifecycle bounds) that can significantly slash down monthly drift.
• IaC Security Policy (433 findings): Adherence to security defaults scored a C Grade. The report details exactly which files and blocks to harden to clear out these medium-severity security findings.

🛠️ Changes Implemented

• Added .github/workflows/infrascan.yml utilizing soldevelo/infrascan@v1.0.9.
• Set scan profiling to comprehensive for deeply inspecting structural definitions.
• Configured automated storage and upload of the resulting HTML report as a zipped workflow artifact with a standard 14-day retention cycle.

[igor-soldev]

Hi @hanazuki ,

Thanks for taking a look at the PR.

I noticed it was closed without any comments, so I was wondering if you could share the reason behind that decision.

Was the concern related to the proposed infrastructure optimization findings, or is it more that you don't want an additional CI/CD tool integrated into the repository?

If it's the latter, I completely understand. My intention wasn't necessarily to enforce a new workflow, but rather to demonstrate the value of automated infrastructure auditing. The optimization suggestions themselves (security, cost, and configuration insights) could still be useful even without integrating the GitHub Action.

I'd really appreciate any feedback, as it will help me better understand what wasn't a good fit for this repository.

Thanks!

[sorah]

At least we don’t consider tools valuable as spamming PRs for introduction considered agressive marketing strategy. Also the recent increased risk of supply chain security, we need to take a closer look on every dependency we use. The risk is even higher if it brought by someone outside of the team.