Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | SaaS Platform |
| Cloud Environment | AWS (9 accounts) |
| Workloads | ECS (90%), EC2 (9%), EKS (1%) |
| Code & CI/CD | GitLab (SaaS) for SCM, GitLab Pipelines for CI/CD |
| Existing Code Security | Open-source scanning tools, periodic VAPT audits |
| Container Registry | Images built in CI, deployed to ECS |
| Team Size | 4 people and AppSec handled by a separate in-house team |
| Compliance | CIS, NIST with custom framework built on top |
| Focus Area | Code Security + CSPM |
The Situation: Strong AppSec Culture, But a Gap in the Pipeline
This is a SaaS company that takes application security seriously. They invested in it early, built a dedicated in-house AppSec team three years ago, ran regular VAPT audits, and found that their team was doing a decent job catching vulnerabilities through periodic assessments. The application layer was well-covered.
But there is a structural difference between periodic security assessments and continuous security in the development pipeline. VAPT audits catch what exists at the point of assessment. They do not catch what is introduced between assessments for e.g. the new dependency with a known CVE added in a merge request on Tuesday, the AWS secret accidentally committed on Thursday, the overly permissive IAM policy in a Terraform file merged on Friday.
The team’s code lived in GitLab SaaS, and their CI/CD ran on GitLab Pipelines. They had some open-source scanning tools in place (likely running as standalone checks or manual triggers) but nothing was integrated into the merge request workflow as a continuous, automated gate. Developers were not seeing security findings at the point of code review. Instead, findings surfaced later, during the next VAPT cycle or after the code had already reached production.
For a team deploying containerized workloads to ECS across 9 AWS accounts, this gap between code and cloud meant that insecure configurations, vulnerable dependencies, and leaked secrets could flow from a merge request directly into a running container without any security checkpoint in between.
The Core Tension
A mature AppSec culture built around periodic audits, but no continuous security feedback loop in the development pipeline itself. Developers write code, merge it, build container images, and deploy to ECS, with security assessments happening on a separate cadence, disconnected from the flow of code.
Where the Gaps Were?
Periodic Audits Cannot Keep Pace With Continuous Delivery
VAPT audits are valuable. They provide a thorough, point-in-time assessment of application security by skilled testers who think like attackers. For many organizations, they are a compliance requirement and a genuine source of findings that automated tools might miss.
But they operate on a fundamentally different cadence than modern software delivery. A SaaS team deploying multiple times per week/per day, introduces new code between audits that never gets assessed until the next cycle. The attack surface changes continuously; the assessment happens periodically.
This is not a criticism of VAPT. It is a recognition that VAPT and continuous pipeline scanning solve different problems:
- VAPT: Deep, contextual assessment of the running application (business logic flaws, authentication bypasses, complex attack chains).
- Continuous pipeline scanning: Automated detection of known vulnerability patterns, dependency risks, secret exposure, and misconfigurations at the point of code change.
The two are complementary, not substitutes. A team that has only VAPT is missing the continuous layer. A team that has only automated scanning is missing the depth of manual assessment. This team had strong VAPT coverage but no automated, continuous scanning integrated into their GitLab workflow.
Open-Source Code Scanning Tools Hit a Ceiling
The team had experimented with open-source scanning tools, the same pattern we see with cloud security tooling. Open-source SAST, SCA, and secrets scanners exist and can be useful for initial adoption. But they share common limitations:
- Fragmented coverage: You need one tool for SAST, another for SCA, another for secrets, and yet another for IaC scanning. Each has its own configuration, its own output format, its own false-positive profile, and its own maintenance burden.
- No unified findings view: Results from each scanner live in separate reports or CI job artifacts. There is no single place where the security team can see all code-level risk across all repositories, prioritized and deduplicated.
- Limited pattern depth: Open-source secrets scanners typically cover a few hundred patterns. For a team with AWS credentials, database connection strings, API keys across multiple services, and custom secret formats, the gap between 200 patterns and 2,000+ patterns is meaningful.
- No merge request integration: Most open-source tools can be wired into CI to produce reports, but they do not annotate merge requests directly with inline findings at the relevant code line. Developers have to leave their review workflow to check a separate report.
- No remediation guidance: A finding that says “CVE-2024-XXXX found in package X” without context on severity in your environment, fix path, or upgrade compatibility is a research task, not an actionable alert.
Container Images Built Without Security Gates
With 90% of workloads running on ECS, this team’s deployment pipeline builds container images in GitLab CI and pushes them to a registry before deploying to ECS. If no image scanning happens during that build process, vulnerable base images, outdated packages, and known CVEs flow directly into production containers.
The gap is between code-level scanning (checking the source) and image-level scanning (checking what was actually built). A Dockerfile might reference a base image that was secure six months ago but has accumulated critical vulnerabilities since. Dependencies resolved at build time might pull versions with known exploits. Without scanning the built image as part of the pipeline, these issues are invisible until they are discovered in production, or in the next VAPT audit.
No Connection Between Code Risk and Cloud Posture
This is the subtler gap that most code security tools do not address at all. A Terraform file that defines an overly permissive IAM role is a code finding. The misconfigured IAM role that results from deploying that Terraform is a cloud posture finding. In most environments, these two findings live in completely separate tools with no connection between them.
For a team managing 9 AWS accounts with infrastructure-as-code, the ability to trace a cloud misconfiguration back to the code that created it, and to catch that misconfiguration before it is deployed; is the bridge between shift-left security and runtime security. Without it, the code security team and the cloud security team are working from separate views of the same underlying problem.
How Cloudanix Addresses This?
Direct GitLab Integration for SAST, SCA, and Secrets
Cloudanix integrates directly with GitLab SaaS at the repository level. No pipeline modification required for the core scanning capabilities. Once connected, every merge request is automatically analysed for:
- SAST (Static Application Security Testing): Pattern-based and semantic analysis of source code for vulnerability patterns — injection flaws, authentication weaknesses, insecure data handling, and language-specific security anti-patterns.
- SCA (Software Composition Analysis): Dependency scanning across all package manifests
package.json,requirements.txt,go.mod,Gemfile,pom.xml, and others. Identifies dependencies with known CVEs, assesses severity in context, and provides upgrade path recommendations. - Secrets Detection: Scanning for 2,000+ secret patterns such as AWS keys, database connection strings, API tokens, OAuth secrets, private keys, and custom patterns. Catches secrets at the point of commit, before they reach the default branch.
Findings surface as merge request annotations, inline comments at the relevant code line, visible during code review. Developers do not need to leave their review workflow or check a separate dashboard. The security signal meets them where they already work.
Get Enterprise-Grade Features of Popular SCMs With Cloudanix
Many SCM platforms gate advanced security features (SAST, SCA, secrets detection, dependency scanning) behind their highest-priced tiers. For teams on standard or mid-tier plans, this creates a gap: you have the repository, the pipeline, and the deployment infrastructure, but the security scanning that should sit between them is either missing or requires a significant upgrade in licensing cost across all seats.
Cloudanix operates as an independent security layer on top of your existing SCM, regardless of which tier you are on. You get the full suite of code security capabilities without changing your SCM plan, without migrating repositories, and without restructuring your pipeline. The integration is additive: it layers security onto your existing workflow rather than requiring you to change it.
2,000+ Secret Patterns With BYO-Pattern Support
Secret detection is only as good as the patterns it knows. Open-source scanners typically cover a few hundred common patterns: AWS access keys, GitHub tokens, standard API key formats. But real-world codebases contain custom secrets: internal service tokens, partner API keys with non-standard formats, database URLs with embedded credentials in custom formats, and platform-specific keys that do not match generic regex patterns.
Cloudanix ships with 2,000+ secret patterns covering cloud providers (AWS, Azure, GCP), SaaS platforms, database credentials, private keys, and common service tokens. Beyond the built-in patterns, BYO-pattern support allows teams to define custom regex patterns for their own internal secret formats, ensuring that the secrets unique to their environment are caught with the same confidence as standard ones.
For a team with AWS credentials, database connection strings for RDS and EC2-hosted databases, and GitLab tokens flowing through their pipeline, this breadth of coverage is the difference between catching the obvious leaks and catching all of them.
Container Image Scanning in the Pipeline
For teams deploying to ECS, code scanning alone is not sufficient. The container image that gets built during CI (pulling a base image, installing dependencies, copying application code) is the actual artifact that runs in production. If that image contains vulnerabilities, it does not matter that the source code was clean.
Cloudanix integrates at the pipeline level for container image scanning. During the docker build stage of GitLab CI, built images are scanned for:
- OS-level vulnerabilities: CVEs in the base image and system packages.
- Application dependency vulnerabilities: Issues in packages installed during the build that may differ from what is declared in source-level manifests.
- Configuration issues: Running as root, unnecessary capabilities, missing health checks.
- Image provenance: Verification of base image source and digest.
This is the last gate before an image reaches your container registry and is deployed to ECS. If a critical vulnerability is found at this stage, the pipeline can be configured to fail; preventing the vulnerable image from reaching production.
IaC Scanning: Catching Cloud Misconfigurations Before Deployment
If your infrastructure is defined in Terraform, CloudFormation, or other IaC formats and lives in your GitLab repositories, those files are scanned alongside your application code. Cloudanix identifies misconfigurations in infrastructure definitions before they are applied: overly permissive IAM policies, unencrypted storage resources, public network exposure, and missing logging configuration.
For a team managing 9 AWS accounts with infrastructure-as-code, this means the ECS task definitions, IAM roles, security groups, and VPC configurations in their Terraform files are assessed for security risk at merge request time. The misconfiguration is caught in code review, not discovered later in a CSPM scan after it has already been deployed.
This is where code security and cloud posture management connect: a finding in a Terraform file today is a misconfiguration in your AWS account tomorrow. Catching it in the pipeline is cheaper, faster, and less risky than remediating it after deployment.
Unified Findings Across Repositories
When security scanning is fragmented across multiple open-source tools, each producing its own report format, the security team spends time aggregating and deduplicating rather than prioritising and fixing. Cloudanix provides a single view across all connected repositories every SAST, SCA, secrets, IaC, and image scanning finding in one place, ranked by severity, deduplicated, and traceable to the specific merge request and code line where it was introduced.
For a team with multiple repositories across multiple services (common in microservices architectures deployed on ECS), this unified view is the difference between “we have findings scattered across repos” and “we have a prioritised list of what to fix first, across everything.”
GenAI-Powered Remediation Guidance
Every finding includes actionable remediation context, and not just the CVE number or the rule that was triggered, but what to do about it:
- For SCA findings: which version to upgrade to, whether the upgrade is breaking, and what the fix addresses
- For SAST findings: the specific code pattern that triggered the finding and the secure alternative
- For secrets: where the secret was found, when it was introduced, and the steps to rotate it
- For IaC findings: the specific configuration change needed, with corrected code snippets
GenAI-powered remediation playbooks take this further for complex findings, providing step-by-step fix instructions that account for the context of the finding within the repository. For a team where DevOps is handling remediation alongside their other responsibilities, actionable guidance eliminates the research step between “finding received” and “fix shipped.”
The Connection: Code Security Meets Cloud Posture
For teams evaluating both CSPM and code security ‘as this team was’ there is a significant advantage to running both on the same platform. Cloudanix’s unified asset graph connects code-level findings to the cloud resources they affect:
- A Terraform file with an overly permissive IAM role → the actual IAM role in AWS → the ECS task that uses it → the data stores it can access
- A dependency with a critical CVE in the source → the container image built from that source → the ECS service running that image → the network exposure of that service
This correlation is what separate code scanning and CSPM tools cannot provide. When code risk and cloud risk live on the same graph, the security team sees attack paths that cross the boundary between code and runtime, not just individual findings in isolation.
Platform Impact
Direct integration with GitLab and no pipeline changes for SAST/SCA/secrets | 2,000+ patterns for secrets detection + BYO-pattern support | Pipeline-level container image scanning before ECS deployment | MR annotations: findings at the code line during review | Unified view across all repos and all finding types.
The Bigger Picture: Continuous Security as a Complement to VAPT
The shift from periodic assessment to continuous pipeline security is not about replacing VAPT. It is about closing the gap between assessments. A team that deploys multiple times per week has a continuously changing attack surface. VAPT assessments, however thorough, are snapshots. The code that was merged and deployed between the last assessment and the next one is unassessed code in production.
Continuous pipeline scanning changes the economics of this gap. Instead of discovering issues in the next audit cycle when they have already been running in production for weeks or months, issues are caught at the point of introduction. The merge request is the checkpoint. The developer who wrote the code is still in context. The fix is a one-line change in the same MR, not a remediation project scheduled three sprints from now.
For teams that have already built a strong AppSec culture through VAPT, continuous pipeline scanning is the natural next step: it extends the same security mindset into the daily flow of code, without replacing the depth that periodic manual assessment provides. The two approaches cover different angles of the same surface — and together, they leave fewer gaps than either one alone.
Key Outcomes
✅ Direct GitLab Integration: SAST, SCA, and secrets scanning without pipeline reconfiguration. ✅ MR-Level Feedback: Inline annotations at the code line during developer review. ✅ 2,000+ Secret Patterns: Comprehensive coverage plus custom pattern support. ✅ Container Image Scanning: Vulnerabilities caught before images reach ECS. ✅ IaC Scanning: Cloud misconfigurations caught in Terraform/CloudFormation before deployment. ✅ Unified Findings View: All repositories, all finding types, one prioritised dashboard. ✅ GenAI Remediation: Actionable fix guidance, not just CVE numbers. ✅ VAPT Complement: Continuous scanning fills the gap between periodic assessments. ✅ No SCM Tier Upgrade: Enterprise-grade code security without changing your GitLab plan.
Running GitLab Pipelines and Deploying to ECS?
If your code lives in GitLab, your pipeline builds container images, and those images run on 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 all of it connected to your cloud posture through a single asset graph.
Book a Free Assessment to see what your code repositories look like through Cloudanix — findings in minutes, no pipeline changes required.
Related Resources
- What is Code Security?
- What is Shift-Left Security?
- What is Software Composition Analysis (SCA)?
- Inside Static Source Code Analysis (SAST)
- Secret Scanning: Guide to Prevent Data Breaches and Leaks
- Understanding Infrastructure as Code (IaC) Security
- Code Security Best Practices for DevSecOps Teams in 2026
- Announcing Cloudanix Code Security
- CSPM for ECS-Heavy AWS Workloads
- Container Security and Real-Time Visibility for Modern Cloud
- Securing a Scalable SaaS Platform
- From Tool Sprawl to a Single Dashboard: E-Commerce Cloud Security
