StackSage

Most AWS cost and security audits fail for the same reason: they don’t survive contact with reality.

Teams run a tool, get a long list of “issues,” and then the report gets ignored. Not because people don’t care, because the report is either too noisy to trust, too invasive to approve, or too hard to act on quickly.

StackSage exists to fix that failure mode: make audits actionable, explainable, and privacy-first by default.

The problem StackSage is built around

In the real world, AWS audits break down in three predictable ways:

1. Trust breaks
   If a finding can’t be defended (“Is this snapshot really stale?” “Is this instance actually idle?”), teams hesitate, and hesitation turns into inaction.

2. Security friction blocks adoption
   A lot of tools require shipping broad inventory to a SaaS or granting expansive permissions. Security teams slow-roll or deny it. Engineers then fall back to spreadsheets and guesswork.

3. Prioritization is unclear
   Cost wins and security risks get mixed together without a clear story. Leaders can’t decide what matters this week.

The StackSage story (how the approach evolved)

StackSage started with a simple constraint: run inside the customer’s boundary.

Instead of asking customers to pipe AWS data into another dashboard, StackSage runs in their own GitHub Actions runner (from a private GHCR image) using a customer-controlled read-only IAM role. The output is local artifacts they already trust operationally: an HTML report plus machine-readable JSON/CSV.

Once that execution model was working, the focus shifted to the next bottleneck: truthfulness.

StackSage leaned hard into “evidence-grade” findings:

• Every finding carries structured evidence and standardized reason_codes

• The report makes it clear what’s measured, heuristic, no data, access denied, or skipped

• If the system can’t prove something, it avoids calling it (restraint > noise)

Then came a practical insight from how audits are actually consumed: people don’t want a single blob of output.

So StackSage added:

• A one-page summary.md “account brief” to share quickly

• A clearer separation between financial findings (savings opportunities) and security posture findings (IAM hygiene, exposure, audit logging)

And because distribution matters for pilots, StackSage also added an offline-verifiable license mechanism for the private image, so customers can adopt it without SaaS credential sharing and without guessy enforcement.

What StackSage is today

StackSage is an audit workflow that:

• Runs in GitHub Actions (customer-runner execution)

• Uses a customer-controlled read-only role

• Produces artifacts you can share internally

• Surfaces both:

  • Cost waste (prioritized by estimated savings where possible)

  • Security posture signals (IAM posture, public exposure, audit logging baselines)

• Keeps “why” visible through evidence and provenance

The philosophy: restraint and proof

StackSage is built around a simple belief:

The most valuable detector isn’t the one that finds the most things.
It’s the one that’s the least wrong.

That means fewer false positives, clearer explanations, and explicit handling of unknowns.

Where it’s going

The roadmap is straightforward: keep tightening the loop from detection → remediation → verified win—without breaking privacy-first guardrails.

If this resonates

If you’ve ever ignored an AWS audit report because it felt noisy, risky, or un-actionable, StackSage is built for that moment.

Try the sample report: https://stacksageai.com/demo-report