Beyond Web Apps: How AWS Continuum Secures Analytics, AI/ML, and Data Pipeline Workloads

Introduction

When most people hear "penetration testing" or "code scanning," they picture a traditional web application — a login page, a REST API, a shopping cart. But modern cloud architectures look nothing like that. Your analytics dashboards are embedded in customer-facing portals. Your data pipelines are complex chains of code transforming sensitive data. Your ML inference endpoints serve predictions over APIs that accept user input.

All of these are attack surfaces. All of them have code, endpoints, or architecture documents. And all of them can be secured with AWS Continuum.

In this article, I'll show how Continuum applies beyond traditional web applications, covering analytics, AI/ML, and data pipeline workloads. Then I'll walk through a complete implementation: pen testing an embedded Amazon QuickSight application from start to finish.

Prerequisite reading: If you're new to AWS Continuum, start with the overview at AWS Continuum Product Page or the launch blog Introducing AWS Continuum: Security at machine speed.

---

The Pattern: When Does Continuum Apply?

Continuum isn't limited to one type of workload. The question is simple:

• Do you have code in a repository? → Code Scanning applies
• Do you expose an endpoint (web, API, or embedded)? → Penetration Testing applies
• Do you have architecture or design documents? → Threat Modeling applies
• Do you have a backlog of security findings from any tool? → Code Vulnerabilities applies

If your workload satisfies any of these conditions, Continuum can secure it. The workload type — analytics, AI/ML, streaming, or data pipeline — doesn't matter. What matters is the presence of code, endpoints, or architecture.

---

Continuum Across Workload Types

Analytics Workloads

Component	Continuum Capability	What Gets Secured
Embedded QuickSight dashboards	Penetration Testing	Authentication flows, embedding URLs, API endpoints exposed to end users
Custom analytics APIs (serving Athena/Redshift results)	Penetration Testing	REST/GraphQL endpoints, authorization logic, data filtering
ETL scripts (Glue jobs, Lambda transforms)	Code Scanning	SQL injection in dynamic queries, hardcoded credentials, insecure data handling
Data pipeline architecture (Step Functions, Glue workflows)	Threat Modeling	Trust boundaries between ingestion/transform/serve layers, IAM role chains

AI/ML Workloads

Component	Continuum Capability	What Gets Secured
SageMaker inference endpoints	Penetration Testing	Input validation, authentication, model extraction attacks
Bedrock agent applications	Threat Modeling + Pen Testing	Prompt injection, trust boundaries between agent and tools, API exposure
ML training pipeline code	Code Scanning	Data poisoning vectors, credential handling, dependency vulnerabilities
Custom model serving APIs	Penetration Testing	Authorization bypass, input manipulation, rate limiting

Streaming & Event-Driven Workloads

Component	Continuum Capability	What Gets Secured
Kinesis/MSK consumer applications	Code Scanning	Deserialization vulnerabilities, message handling, error paths
Real-time processing APIs	Penetration Testing	WebSocket endpoints, streaming connections, back-pressure handling
Event-driven architecture (EventBridge, SNS/SQS)	Threat Modeling	Trust boundaries between producers and consumers, event schema validation

The Common Thread

Continuum doesn't need to "know" that your workload is analytics, ML, or streaming. It operates on the fundamental building blocks:

• Code → Can it be exploited?
• Endpoints → Can they be attacked?
• Architecture → Are there design-level risks?

This is why it works across all workload types without requiring service-specific integrations.

---

Implementation Walkthrough: Pen Testing an Embedded QuickSight Application

Let's get practical. Embedded QuickSight is a common analytics pattern — you embed dashboards into your customer-facing application, protected by your own authentication layer. This creates a web application with real attack surfaces: login flows, embedding tokens, API calls, and custom domains.

This makes it a perfect candidate for Continuum penetration testing.

The Scenario

Imagine you have:

• A customer-facing portal at analytics.yourcompany.com
• Embedded QuickSight dashboards behind authentication
• A backend API at api.yourcompany.com that generates embedding URLs
• User authentication via your identity provider

You want to validate that this application is secure before your next release.

Prerequisites

Before you begin, ensure you have:

• Access to the AWS Continuum web application (sign in at the console)
• Your application domain verified in AWS Continuum (admin verifies domain ownership once)
• An IAM role configured with appropriate permissions for Continuum
• Understanding of your application's authentication flow

Step 1: Create the Penetration Test

1. Sign in to the AWS Continuum web application
2. Navigate to Penetration tests
3. Choose Create a penetration test
4. Enter a descriptive name:

Embedded Analytics Portal - Pre-Release Security Validation

Step 2: Configure the Test Scope

Add target domains — these are the domains Continuum will actively test:

Target URLs:
  - https://analytics.yourcompany.com      (the embedded dashboard portal)
  - https://api.yourcompany.com            (the backend API serving embedding URLs)

Add accessible domains (not attacked, but needed for navigation):

If your authentication flows through a third-party identity provider (like Okta, Auth0, or Cognito hosted UI), add those as accessible domains. Continuum needs to reach them to complete login, but won't pen test them:

Accessible URLs:
  - https://auth.yourcompany.com           (your IdP login page)

Important: Accessible domains do NOT require ownership verification. Only target domains do.

Exclude risk types (optional):

If certain OWASP categories don't apply to your embedded analytics use case, you can exclude them to focus the test. For most embedded QuickSight apps, you'd leave the defaults.

Add out-of-scope URL paths:

Protect any destructive operations or admin functions you don't want tested:

Out-of-scope URLs:
  - https://analytics.yourcompany.com/admin/delete-workspace
  - https://api.yourcompany.com/admin/purge-cache

Add custom HTTP headers (optional):

If your application sits behind a WAF, add a custom header to allowlist Continuum traffic so it doesn't trigger security alerts:

Custom HTTP Headers:
  Header: X-Security-Test
  Value: continuum-authorized-2026

Then add an allowlist rule in your WAF for this header. This prevents your SOC from receiving false alarms during the test.

Note: By default, Continuum sends a User-Agent header set to securityagent. You can customize this.

Step 3: Configure Authentication

Your embedded QuickSight app requires login. Provide credentials so Continuum can test authenticated areas:

1. Select Input credentials
2. Enter test account credentials:
   • Username: security-test-user@yourcompany.com
   • Password: (your test account password)
3. Select the Access domain: https://analytics.yourcompany.com
4. Add an Agent login prompt describing your auth flow:

Navigate to https://analytics.yourcompany.com/login. Enter the username in the 
"Email" field. Enter the password in the "Password" field. Choose "Sign In". 
After login, you will be redirected to the dashboard page.

Tip: Use a dedicated test account with the same permissions as a typical user — not an admin account. You want to test what a normal user could exploit.

Step 4: Attach Additional Context (Recommended)

This is where Continuum's application-aware testing shines. The more context you provide, the more targeted the attack scenarios become.

Choose Upload or Select from existing resources to attach:

• Architecture diagram — How your embedding flow works (portal → API → QuickSight)
• API documentation — OpenAPI/Swagger spec for your embedding API
• Source code repository — Connect your GitHub/GitLab repo so Continuum understands your application logic

Connected resources:
  - GitHub: yourorg/analytics-portal (main branch)
  - Uploaded: embedding-architecture.pdf
  - Uploaded: api-spec.yaml

Why this matters: Without context, Continuum runs generic OWASP tests. With context, it crafts attack scenarios specific to your embedding token generation, session management, and data access patterns.

Step 5: Set Task-Hours Limit

Set a maximum to control scope and cost:

Max task hours: 30

For a typical embedded analytics application with 2 target domains and authentication, 20-30 task hours is reasonable. Continuum bills only for actual hours used — the limit is a cap, not a commitment.

Note: Task hours measure cumulative agent work time, not wall-clock time. Multiple agents working in parallel means task hours accumulate faster than real time.

Step 6: Create and Execute

Review your configuration, then choose Create and execute to start the test immediately.

The test will:

1. Build context from your code, docs, and architecture
2. Log in using your provided credentials
3. Craft targeted attack scenarios specific to your embedding application
4. Test for OWASP Top 10 vulnerabilities plus business logic flaws
5. Adapt in real-time based on application responses
6. Document findings with reproducible exploit paths

Step 7: Review Findings

After the test completes (typically hours, not days), review the results:

Each finding includes:

• Severity — Critical, High, Medium, Low (based on actual exploitability, not generic CVSS)
• Reproducible exploit path — Step-by-step proof showing exactly how the vulnerability was exploited
• Impact analysis — What an attacker could achieve
• Ready-to-implement fix — Code-level remediation guidance in developer-friendly language

Common findings for embedded analytics applications:

Finding Category	Example	Why It Matters
Authentication bypass	Embedding URL generated without proper session validation	Unauthorized users could access dashboards
Authorization flaws	User A can access User B's dashboard by manipulating parameters	Data leakage between tenants
Token exposure	Embedding tokens visible in client-side code or browser history	Tokens could be harvested and replayed
API vulnerabilities	Backend embedding API doesn't validate input parameters	Could be exploited to access unauthorized datasets
Session management	Sessions don't expire after logout or token refresh is flawed	Stale sessions remain exploitable

Step 8: Remediate

For each finding, Continuum provides specific code fixes. If you connected your GitHub repository and enabled automatic remediation, Continuum can submit pull requests with the fixes directly to your repo.

The human-in-the-loop model means:

• You review each proposed fix
• You accept, modify, or reject
• Nothing changes without your approval

---

Other Workloads: What to Expect

While pen testing is GA and ready for production use, here's how the other capabilities apply to analytics and AI/ML workloads (currently in preview):

Code Scanning for Data Pipeline Code

Scenario: Your team writes Glue jobs in Python that process customer PII, build dynamic SQL queries, and call external APIs.

What Code Scanning catches:

• SQL injection in dynamically constructed queries
• Hardcoded credentials or API keys in transformation scripts
• Insecure deserialization of incoming data formats
• Missing input validation on data sources
• Overly permissive exception handling that leaks information

How to use it: Connect your data pipeline repository (GitHub, GitLab, or Bitbucket) and enable PR evaluation. Every pull request to your ETL code gets scanned against your organizational security requirements before merge.

Threat Modeling for Data Architecture

Scenario: You're designing a new real-time analytics pipeline with Kinesis ingestion, Lambda transformation, and QuickSight serving.

What Threat Modeling produces:

• STRIDE-categorized threats across your architecture
• Trust boundary identification between ingestion, processing, and serving layers
• Data flow analysis showing where sensitive data could be exposed
• Prioritized mitigations specific to your design

How to use it: Upload your architecture diagram or design document to the Continuum console. The output is a complete STRIDE threat model you can use for your security review — before writing a single line of code.

---

Getting Started: Recommended Path by Workload

Your Workload	Start With	Why
Embedded analytics (QuickSight, Grafana)	Pen Testing (GA)	It's a web app — test it like one
Data pipelines (Glue, EMR, Lambda)	Code Scanning (Preview)	Your pipeline code is in a repo — scan it
Custom analytics APIs	Pen Testing (GA)	API endpoints are pen-testable today
New architecture design	Threat Modeling (Preview)	Catch risks before writing code
AI/ML inference endpoints	Pen Testing (GA)	ML endpoints are APIs — test them
Large existing findings backlog	Code Vulnerabilities (Gated Preview)	Prioritize and validate what you already have

---

Conclusion

AWS Continuum isn't just for traditional web applications. Any workload with code, endpoints, or architecture can benefit from continuous security validation. The embedded analytics, data pipeline, and AI/ML workloads that dominate modern cloud architectures all present attack surfaces that Continuum is designed to secure.

The key insight: you don't need to wait for a "data analytics security scanner" to exist. The security capabilities are workload-agnostic — what makes them effective for your analytics workload is the context you provide (your architecture docs, your code, your organizational requirements).

Start with what's GA today — run a pen test on your embedded analytics application or ML endpoint — and expand to code scanning and threat modeling as those capabilities become generally available.

---

References

• AWS Continuum — Product Page
• AWS Continuum — Features
• AWS Continuum — Pricing
• AWS Continuum — Getting Started
• Create a Penetration Test — User Guide
• Code Scanning — User Guide
• Threat Modeling — User Guide
• Introducing AWS Continuum: Security at machine speed (AWS Security Blog)