Add InfraScan analysis workflow

[igor-soldev]

This pull request integrates the InfraScan security, compliance, and cloud cost optimization analysis tool (v1.0.9) into the substation repository. It introduces a new GitHub Actions workflow (Analysis Tools) that can be manually triggered via workflow_dispatch. This allows developers and maintainers to run comprehensive infrastructure security and cost audits on demand, automatically publishing the results as download-ready HTML artifacts.

View Full Web Report

Scanned Areas

• Security Posture & IaC Best Practices — Structural analysis of infrastructure configurations to prevent compliance drift.
• Cost Optimization — Discovery of underutilized, idle, or unoptimized cloud assets.
• Container Vulnerabilities — Automated image scanning to catch supply-chain security threats.

---

Description

This change introduces automated infrastructure scanning using the InfraScan static analysis tool. The workflow targets all defined cloud assets, evaluates them against industry-standard security baselines, assesses container health, and calculates projected resource costs.

Motivation and Context

Implementing InfraScan provides a robust Why for our operational lifecycle: it establishes a definitive shift-left practice. By surface-testing configurations directly within the repository, we catch security flaws and costly configuration errors (such as unattached Elastic IPs or oversized NAT gateways) long before they are deployed to live cloud environments.

---

Key Scan Results

Metric	Status / Value
Repository	substation
Branch	main
Scan Date	2026-06-25 10:33:43 UTC
Resources Scanned	89 (72 priced, 17 unpriced)
Scanner Profile	Comprehensive

Component Breakdown

• Overall Health: Grade A (96.6%) — 28 Total Issues (1 High, 26 Medium, 1 Low)
• Cost Optimization: Grade B (94.9%) — 6 Violations (1 High, 4 Medium, 1 Low)
  • Estimated Savings: $6 – $42/mo (representing 10.3%–70.1% of the $60/mo total infra cost).
• IaC Security: Grade B (94.9%) — 22 Violations (22 Medium)
• Container Security: Grade A (100%) — 0 Affected Images / 0 Vulnerabilities

---

Recommendations

• Remediate Idle Cost Elements: Address the High priority cost violation on the eip (Elastic IP) which can guarantee an immediate, high-confidence saving of $4/mo. Review the utilization metrics for the nat_gateway to safely claim an additional saving of up to $34/mo.
• Strengthen IaC Configurations: Resolve the 22 Medium severity security violations discovered within the infrastructure code to close active perimeter gaps and achieve a perfect 100% security baseline.
• Monitor AppConfig Resources: Manually evaluate the configuration of resources currently marked as unpriced (e.g., appconfig_application, appconfig_deployment_strategy), as they are excluded from the automated cost estimation module.

---

Value Provided by InfraScan

• Immediate Financial ROI: Pinpoints precise cost leaks (such as idle EIPs and NAT Gateways), stripping up to 70.1% off unnecessary operational overhead.
• Proactive Security Gateways: Delivers predictable grading criteria (A-F) that developers can monitor to avoid introducing critical vulnerabilities.
• Complete Asset Visibility: Maps and tracks all 89 infrastructure resources automatically across each run, including secondary app configurations.

---

How Has This Been Tested?

The GitHub Actions workflow has been executed within the repository using the workflow_dispatch trigger. It completed successfully, created the infrascan-reports directory, ran the static analyzer, and correctly exported the resulting HTML document as a structured pipeline artifact.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[greptile-apps]

Greptile Summary

This PR adds a new manually-triggered GitHub Actions workflow that runs the third-party soldevelo/infrascan tool and uploads an HTML report as an artifact. The change deviates from the repository's established CI security posture in several ways that need to be addressed before merging.

• All three actions (actions/checkout@v4, soldevelo/infrascan@v1.0.9, actions/upload-artifact@v4) use mutable version tags instead of pinned commit SHAs; every other workflow in this repo pins to SHAs, and the v1.0.9 tag for soldevelo/infrascan does not appear to exist in the upstream repository yet.
• No permissions block is declared at the workflow or job level, so the job inherits default token permissions rather than the minimal contents: read used elsewhere in the repo.

Confidence Score: 2/5

Not safe to merge as-is — the workflow runs a third-party action whose referenced tag does not appear to exist and is not pinned to a commit SHA, directly contradicting how every other workflow in the repo is hardened.

The new workflow introduces a third-party action (soldevelo/infrascan) pinned only to a mutable version tag that cannot be found in the upstream repository, alongside two first-party actions (actions/checkout, actions/upload-artifact) that are similarly unpinned. Every existing workflow in this repository pins all actions to a full commit SHA. The job also runs with no declared permissions, leaving it with whatever the repository default grants rather than the minimal contents: read scope the other workflows use. These gaps mean the next execution could run unintended or unverified code with unrestricted access to the runner environment.

.github/workflows/analysis-tools.yml requires SHA pinning for all three actions and an explicit permissions block before it is safe to merge.

Security Review

• Unpinned third-party action (soldevelo/infrascan@v1.0.9): The action is referenced by a mutable tag rather than a commit SHA. An upstream maintainer could silently repoint the tag to execute arbitrary code inside the runner, with access to the repository checkout and the job's GITHUB_TOKEN.
• Unpinned first-party actions: actions/checkout@v4 and actions/upload-artifact@v4 are also unpinned, contradicting the repo's existing SHA-pinning pattern in all other workflows.
• Missing permissions block: No least-privilege permission scope is declared; the job may run with write permissions it does not need.
• Unverified tag existence: The v1.0.9 tag referenced for soldevelo/infrascan was not found in the public upstream repository, raising the possibility that a future-created tag could contain untrusted code.

Important Files Changed

Filename	Overview
.github/workflows/analysis-tools.yml	New workflow adding soldevelo/infrascan scanning via workflow_dispatch; all three actions are pinned to mutable version tags rather than commit SHAs (violating the repo's established pattern), no permissions block is defined, and the referenced v1.0.9 tag may not yet exist.

_{Reviews (1): Last reviewed commit: "Add InfraScan analysis workflow" | Re-trigger Greptile}

[greptile-apps]

Unpinned third-party action — supply chain risk

Every other workflow in this repository pins actions to an immutable commit SHA (e.g., actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11), not a mutable version tag. soldevelo/infrascan@v1.0.9 is a mutable tag that the upstream maintainer can silently repoint to arbitrary code; if the tag is moved, the next run executes whatever new code it points to with full access to the repository checkout and any secrets available to the job. Additionally, research into the public SolDevelo/InfraScan repository found no evidence that a v1.0.9 tag has been published — only v1.0.5 and v1.0.8 are known to exist — so this workflow may currently fail on every dispatch. Pin all three actions to a specific commit SHA and record the tag in a comment (e.g., soldevelo/infrascan@<SHA> # v1.0.9), and verify that the tag exists before merging.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Missing permissions block

All other workflows in this repository declare an explicit permissions block at the workflow or job level (e.g., permissions: read-all in scorecard.yml, permissions: contents: read in code.yml). Without it, this job inherits the repository's default token permissions, which may be broader than needed for a read-only scanning workflow. Add a minimal permissions block — at minimum permissions: contents: read — to follow the principle of least privilege and match the rest of the repo's patterns.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

actions/checkout and actions/upload-artifact are unpinned

Consistent with the finding on soldevelo/infrascan, actions/checkout@v4 (line 20) and actions/upload-artifact@v4 (line 31) are also pinned to mutable version tags rather than commit SHAs. The existing workflows use actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1 and actions/upload-artifact@4cec3d8aa04e39d1a68397de0c4cd6fb9dce8ec1 # v4.6.1. Pin all three actions in this file to commit SHAs to match the repo's established supply-chain security posture.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!