Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | B2B SaaS |
| Cloud Environment | AWS (multi-account) |
| Workloads | EKS and ECS containerized services |
| Code & CI/CD | GitHub for SCM, GitHub Actions for CI/CD |
| Existing Code Security | GitHub-native checks on top tier, a few OSS scanners |
| Container Registry | Images built in Actions, deployed to EKS/ECS |
| Team Size | Small platform team, AppSec shared across engineering |
| Compliance | SOC 2, moving toward customer-driven security reviews |
| Focus Area | Code Security + CSPM |
The Situation: GitHub-Native, but Security Spread Thin
This team lived entirely in GitHub. Source in GitHub repositories, every build and deploy through GitHub Actions, images pushed to a registry and deployed to EKS and ECS. GitHub is a strong platform, and the team had turned on the native security features they had access to. But two realities created a gap.
First, the most useful native scanning capabilities were gated behind the highest licensing tier, applied per seat across the whole engineering org. For a growing team, turning everything on everywhere was a real budget line, so coverage was partial — on for some repositories, off for others.
Second, even where native scanning was on, it did not connect to anything downstream. A dependency CVE flagged in a repo had no relationship to the EKS workload that actually ran that code, or to the IAM role that workload assumed. Findings were a list in one place; the running cloud estate was a separate world. The team was triaging code findings and cloud findings as two unrelated backlogs.
The Core Tension
A fully GitHub-native workflow with real engineering discipline, but security scanning that was partial (tier-gated), fragmented (several tools), and disconnected from the cloud the code actually ran in.
Where the Gaps Were
Tier-Gated Scanning Meant Partial Coverage
Advanced code scanning sat behind the top SCM tier, charged per seat. The team could not justify it across every seat and every repo, so scanning was uneven — strongest on the few repos someone had configured, absent on the rest. Security coverage that depends on which repos someone remembered to turn on is coverage with holes in it.
Several Tools, No Unified View
Alongside native checks, the team had bolted on a couple of open-source scanners for the gaps. Each had its own output, its own false-positive profile, and its own place to look. There was no single, deduplicated, severity-ranked view of code risk across all repositories — so the real work of prioritizing happened in people’s heads.
Secrets Coverage Was Shallow
The built-in and open-source secret checks caught the common patterns but missed the team’s internal service tokens and custom-format keys. And nothing was scanning the full commit history — so secrets committed long ago, then “removed,” were still sitting in history, still live, and invisible to the current checks.
Container Images Shipped Unscanned
GitHub Actions built the images that ran on EKS and ECS. The source might be clean, but the built image pulls a base image and resolves dependencies at build time — and none of that was scanned before the image reached the registry. Vulnerable base layers flowed straight to production.
Code Risk and Cloud Posture Never Met
The subtlest gap: a Terraform file with an over-permissive IAM role is a code finding; the role it creates is a cloud finding; nothing connected the two. For a team on EKS/ECS across multiple AWS accounts, there was no way to trace a code finding to the workload and role it became at runtime.
How Cloudanix Addresses This
Direct GitHub Integration — PR Findings Without Rewiring
Cloudanix connects to GitHub at the repository level. For the core scanning — SAST, SCA, secrets — no Actions workflow changes are required. Once connected, every pull request is automatically analyzed and findings post as inline annotations on the changed line, inside the review, where developers already work:
- SAST: vulnerability-pattern and semantic analysis of changed source — injection, auth weaknesses, insecure data handling, language-specific anti-patterns.
- SCA: dependency scanning across manifests and lockfiles for direct and transitive CVEs, with upgrade-path guidance.
- Secrets Detection: thousands of built-in patterns plus bring-your-own-pattern support, scanning the entire commit history on connection and new commits at PR time.
Repository Misconfiguration Checks (GitHub)
Beyond scanning files, Cloudanix surfaces repository misconfigurations on GitHub — the branch-protection gaps, over-broad access, and risky repo settings that are part of your supply chain exposure but invisible to a code scanner. This repo-posture layer is a GitHub-native capability and complements the file-level findings.
Container Image Scanning in the Actions Pipeline
For the image build step in GitHub Actions, Cloudanix scans the built image before it reaches your registry — OS and base-image CVEs, build-time dependency vulnerabilities, configuration issues (running as root, unnecessary capabilities), and provenance. A critical finding here can fail the build so a vulnerable image never deploys to EKS or ECS.
IaC Scanning for Terraform and Kubernetes Manifests
Terraform, CloudFormation, and Kubernetes manifests in your repos are scanned alongside application code for IaC security issues — over-permissive IAM, unencrypted storage, public exposure, missing logging — at pull-request time. The misconfiguration is caught in review, not discovered in a CSPM scan after it is already live.
One Security Layer, Any SCM Tier
Cloudanix runs as an independent security layer on top of GitHub regardless of your plan. You get the full suite — SAST, SCA, secrets, IaC, image scanning — without upgrading your SCM tier per seat, without migrating repos, and without restructuring your Actions workflows.
Unified, Deduplicated Findings
Every finding across every connected repository lands in one severity-ranked, deduplicated view, traceable to the exact PR and line that introduced it — replacing the mental cross-referencing across native checks and OSS scanners with a single prioritized list.
Severity That Reflects Real Exposure, Not Just Rule Class
A long list of “critical” findings is only useful if the ranking is trustworthy. Because Cloudanix scores findings against where the code actually runs — whether the workload is internet-facing, what its IAM role can reach, and whether a sensitive data store sits behind it — the top of the queue reflects genuine exploitability rather than a generic rule class. For a team that previously had partial native scanning producing undifferentiated “critical” labels, this is the difference between a backlog nobody trusts and a short list of the few issues that actually matter this week. Exploitability-aware prioritization also means the long tail of present-but-unreachable dependency CVEs stops crowding out the handful of reachable, exposed ones.
Remediation Guidance Built Into Every Finding
Each finding carries actionable context rather than just an identifier: for an SCA finding, which version to upgrade to and whether the change is breaking; for a SAST finding, the risky pattern and the secure alternative; for a secret, where it is, when it was introduced, and the rotation steps; for an IaC finding, the corrected configuration. Selective AI-generated fixes handle the safe, well-understood cases, while higher-blast-radius changes fall back to clear manual guidance. For a small platform team supporting many engineers, that guidance removes the research step between “finding received” and “fix merged.”
The Connection: Code Security Meets Cloud Posture
Running CSPM and code security on the same platform is where this team got leverage. Cloudanix’s unified asset graph connects code-level findings to the cloud resources they become:
- A Terraform file with an over-permissive IAM role → the actual role in AWS → the EKS/ECS workload that uses it → the data it can reach.
- A dependency CVE in source → the image built in Actions → the service running it → that service’s network exposure.
That correlation is what two separate tools cannot produce. When code and cloud risk live on one graph, the team sees attack paths that cross from repo to runtime — not isolated findings. The mechanics are in how code-to-cloud correlation works.
Code-to-runtime context applies when the code, image, and runtime layers are connected for a given service — it is not automatic for every repository the moment it is onboarded. For this team’s EKS and ECS services, where the pipeline builds a known image that runs as a known workload, that chain resolves cleanly: a dependency CVE in a repo is traced to the image built in Actions, the workload running that image, the role it assumes, and the data it can reach.
Why This Matters for a GitHub-Native Team
It is worth being explicit about why a GitHub-native shop benefits from a layer on top of GitHub rather than simply buying up to the top SCM tier. Three reasons recurred for this team:
- Cost that scales with risk, not seats. Tier-gated native scanning is priced per seat across the whole org, whether or not every seat ships security-sensitive code. An independent layer lets the team get full coverage on every repo without that per-seat multiplier.
- One control plane across finding types. Native code scanning, dependency review, and secret scanning are related but separate surfaces inside the platform. Cloudanix presents SAST, SCA, secrets, IaC, image, and repo-posture findings in one ranked view, which is what the platform team actually needs to manage risk across many project teams.
- The cloud half of the story. This is the capability GitHub simply does not have: connecting a code finding to the AWS workload, role, and data it becomes. For a team whose whole reason to care about a finding is “does this put production at risk,” that connection is the point.
None of this requires leaving GitHub or changing how developers work. The integration is additive — developers keep opening pull requests in GitHub, and the security signal meets them there.
Key Outcomes
- ✅ Direct GitHub Integration: SAST, SCA, and secrets without Actions reconfiguration.
- ✅ PR-Level Feedback: Inline annotations at the code line during review.
- ✅ Full-History Secret Scanning: Thousands of patterns plus custom support, across all history.
- ✅ Repo Misconfiguration Checks: GitHub repository posture, not just file findings.
- ✅ Container Image Scanning: Vulnerabilities caught in Actions before images reach EKS/ECS.
- ✅ IaC Scanning: Cloud misconfigurations caught in Terraform/manifests pre-deployment.
- ✅ Unified Findings View: All repos, all finding types, one prioritized dashboard.
- ✅ No SCM Tier Upgrade: Full code security without changing your GitHub plan.
- ✅ Code-to-Cloud Correlation: Findings tied to the workloads and roles they become.
Running GitHub Actions and Deploying to AWS?
If your code lives in GitHub, your pipeline builds images in Actions, and those images run on EKS or ECS, Cloudanix integrates at every layer — SAST, SCA, and secrets at the repository level, image scanning at the pipeline level, IaC scanning for your infrastructure definitions, and repository misconfiguration checks on GitHub — all connected to your cloud posture through a single asset graph.
Book a Free Assessment to see your repositories through Cloudanix — findings in minutes, no workflow changes required — or explore the interactive demo on the Code Security page.
Related Resources
- What is Code Security?
- What is Shift-Left Security?
- How to Catch Security Issues in Pull Requests
- Inside Static Source Code Analysis (SAST)
- What is Software Composition Analysis (SCA)?
- How to Stop Secrets Leaking in Git
- Understanding Infrastructure as Code (IaC) Security
- Shift-Left Code Security for GitLab CI/CD Pipelines
- Cloudanix Code Security
