Study guide
11.2 Application Security Testing: SAST, DAST, SCA & SBOM
Certificate of Cloud Security Knowledge CCSK v5
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CCSK Exam Overview & CSA Security Frameworks
1.1 CCSK v5 Exam Structure, Logistics & Open-Book Strategy 1.2 CCSK v5 Source Hierarchy & CSA Cloud Architecture 1.3 CSA Assurance Tools: CCM v4.1, CAIQ v4.1 & the STAR Registry
2 Chapter 2: Cloud Computing Concepts & Architectures
2.1 Cloud Definition, Essential Characteristics & ISO/IEC Standards 2.2 Cloud Service Models (IaaS, PaaS, SaaS) & Abstraction Layers 2.3 Cloud Deployment Models & Shared Responsibility in Practice
3 Chapter 3: Cloud Governance
3.1 Enterprise Governance, Cloud Strategy & Policy Frameworks 3.2 Contracts, Service Level Agreements (SLAs) & Vendor Due Diligence 3.3 Cloud Governance Operating Models & CCM Control Implementation
4 Chapter 4: Risk, Audit, & Compliance
4.1 Cloud Risk Management, Risk Tolerance & Shared Risk Profiles 4.2 Audit Principles, Assurance Inheritance & Third-Party Reports (SOC & ISO) 4.3 Compliance Assessment, Continuous Auditing & Regulatory Mandates
5 Chapter 5: Organization Management
5.1 Cloud Center of Excellence (CCoE) & Organizational Design 5.2 Cloud Vendor Management, Supply Chain Risk & Multi-Cloud Operations 5.3 Cloud Financial Governance (FinOps), Business Continuity & People 5.4 Provider Organization Hierarchies, Identity Mapping & Shared Services
6 Chapter 6: Identity & Access Management
6.1 Cloud IAM Architecture: Authentication, Authorization & RBAC vs. ABAC 6.2 Identity Federation: SAML 2.0, OpenID Connect, OAuth 2.0 & SCIM 6.3 Privileged Access Management (PAM), CIEM & Cloud Secrets Lifecycle
7 Chapter 7: Security Monitoring
7.1 Cloud Telemetry Architecture, Audit Logging & Control Plane Trails 7.2 Cloud Security Posture Management (CSPM) & Configuration Baselining 7.3 Centralized SIEM/SOAR Integration, Cloud Detection and Response (CDR) 7.4 Cloud Telemetry Sources, Collection Architecture & Retention 7.5 AI for Security Monitoring: Use Cases, Risks & Governance
8 Chapter 8: Infrastructure & Networking
8.1 Virtualization Foundations, Hypervisors & Multi-Tenant Isolation 8.2 Cloud Virtual Networks, Subnetting, Security Groups & Microsegmentation 8.3 Hybrid Connectivity, Software-Defined Perimeters (SDP) & DDoS/WAF Defense 8.4 Infrastructure as Code Security, Policy Gates & Drift Control
9 Chapter 9: Cloud Workload Security
9.1 Virtual Machine (VM) Hardening, Golden Images & Immutable Infrastructure 9.2 Container Security: Image Scanning, Registries & Runtime Defense 9.3 Kubernetes Orchestration Security, Serverless (FaaS) & CWPP/CNAPP 9.4 Cloud Workload Types, Security Boundaries & Control Substitution
10 Chapter 10: Data Security
10.1 Cloud Data Lifecycle (CSU-SAD) & Data Discovery/Classification 10.2 Cloud Cryptography: Data at Rest, In Transit (TLS 1.3) & In Use (Confidential Computing) 10.3 Key Management Systems (KMS), HSMs, BYOK/HYOK & Cloud DLP 10.4 Cloud Storage Models & Object Storage Security 10.5 Data Security Posture Management & AI Data Protection
11 Chapter 11: Application Security
11.1 Secure Software Development Lifecycle (SSDLC) & DevSecOps Pipelines 11.2 Application Security Testing: SAST, DAST, SCA & SBOM 11.3 Cloud API Security: OWASP API Top 10 & API Gateway Protections
12 Chapter 12: Incident Response & Resilience
12.1 Cloud Incident Response Lifecycle, Cloud Challenges & Playbooks 12.2 Cloud Digital Forensics: Ephemeral Workloads, Snapshots & Chain of Custody 12.3 Cloud Resilience, Business Continuity & Disaster Recovery Patterns
13 Chapter 13: Related Technologies & Strategies
13.1 Zero Trust Architecture in Cloud (NIST SP 800-207 Principles & Execution) 13.2 Secure Access Service Edge (SASE) & Cloud Access Security Brokers (CASB) 13.3 Artificial Intelligence & Machine Learning Security (CSA AI Safety & LLM Risks) 13.4 CCSK v5 Synthesis, Cross-Domain Scenarios & Exam-Day Strategy
11.2 Application Security Testing: SAST, DAST, SCA & SBOM
Key Takeaways Explain This Topic AI
Static Application Security Testing (SAST) evaluates source code and Abstract Syntax Trees (AST) early in development to pinpoint structural vulnerabilities, but lacks runtime execution context and requires calibration to manage high false-positive rates.
Dynamic Application Security Testing (DAST) analyzes running application endpoints via black-box HTTP/API interactions, effectively uncovering runtime flaws and environment misconfigurations without requiring access to underlying source code.
Interactive Application Security Testing (IAST) bridges the gap between SAST and DAST by executing inside the application runtime via instrumentation agents, delivering real-time vulnerability detection with precise line-of-code attribution and lower false-positive rates.
Software Composition Analysis (SCA) systematically scans direct and transitive third-party dependencies against vulnerability databases (CVE/NVD) and identifies legal intellectual property risks from copyleft open-source licenses.
A Software Bill of Materials (SBOM), standardized in formats such as CycloneDX and SPDX, provides an authoritative, machine-readable inventory of software components, empowering organizations to assess zero-day supply chain disclosures (such as Log4j) in minutes rather than weeks.
Last updated: September 2026
11.2 Application Security Testing: SAST, DAST, SCA & SBOM
Quick Answer: Modern cloud application security requires an integrated, multi-layered testing paradigm. Static Application Security Testing (SAST) inspects source code and Abstract Syntax Trees (AST) pre-build to identify syntactic and structural flaws (such as SQL injection and unvalidated inputs) with high line-of-code accuracy, though it suffers from false positives and lacks runtime awareness. Dynamic Application Security Testing (DAST) executes automated black-box attacks against running application endpoints, detecting runtime misconfigurations, authentication bypasses, and API authorization flaws. Interactive Application Security Testing (IAST) combines these techniques using runtime instrumentation agents. Because modern cloud applications consist of 70–90% third-party open-source code, Software Composition Analysis (SCA) is vital for scanning dependencies for Common Vulnerabilities and Exposures (CVEs) and licensing liabilities. Finally, a machine-readable Software Bill of Materials (SBOM) —commonly represented in CycloneDX or SPDX —provides a component inventory that can accelerate response to supply-chain disclosures such as Log4Shell. An SBOM supports discovery; it does not prove exploitability or guarantee instant response.
Under Domain 10 of the CSA Security Guidance v5, software testing is not a single checkpoint but an automated, continuous verification matrix embedded across the software development lifecycle. Cloud-native architectures introduce distributed microservices, containerized runtimes, and third-party API dependencies, rendering single-dimensional security testing obsolete. Engineering teams must understand the distinct coverage profiles, execution environments, and operational trade-offs of each testing discipline.
The Application Security Testing Spectrum
To construct an effective application security program, organizations deploy complementary testing methodologies that evaluate software from different perspectives: white-box (internals visible), black-box (external behavior observed), and grey-box/interactive (runtime instrumentation). ┌────────────────────────────────────────────────────────────────────────┐
- │ APPLICATION SECURITY TESTING (AST) TAXONOMY │
- ├────────────────────────────────────────────────────────────────────────┤
- │ METHODOLOGY PERSPECTIVE EXECUTION STAGE PRIMARY TARGET │
- ├────────────────────────────────────────────────────────────────────────┤
- │ SAST White-Box Pre-Build / IDE Proprietary Source │
- │ DAST Black-Box Post-Deploy (Run) Exposed Endpoints │
- │ IAST Grey-Box QA / Staging (Run) Bytecode / Runtimes │
- │ SCA White/Metadata Commit / Build Open-Source Libs │
- │ SBOM Inventory Artifact Release Full Supply Chain │
- └────────────────────────────────────────────────────────────────────────┘
- Static Application Security Testing (SAST)
SAST is a white-box testing technique that parses uncompiled source code, bytecode, or binary files without executing the application.
Technical Mechanics
SAST engines do not simply perform naive regex pattern matching. Enterprise SAST tools construct structural models of the application:
Abstract Syntax Tree (AST): The scanner converts source code into a hierarchical tree representation representing grammatical structure.
Control Flow Graph (CFG): Analyzes the logical execution paths that code can traverse during runtime, mapping loops, conditional branches, and subroutine calls.
Taint Analysis (Data Flow Analysis): Identifies untrusted user inputs ( Sources , e.g., request.getParameter() ), tracks how that data propagates through intermediate variables, and determines whether it reaches sensitive execution functions ( Sinks , e.g., db.execute() or eval() ) without passing through an authorized sanitization or validation routine ( Sanitizers ). ┌────────────────────────────────────────────────────────────────────────┐
- │ SAST TAINT ANALYSIS MODEL │
- ├────────────────────────────────────────────────────────────────────────┤
- │ [SOURCE] [PROPAGATION] [SINK] │
- │ Untrusted Input ───► Variable Assignment / String ───► Database │
- │ (e.g., req.body) Concatenation Execution │
- │ │ │
- │ ▼ │
- │ [SANITIZER APPLIED?] │
- │ ├───────────────┤ │
- │ YES NO │
- │ │ │ │
- │ ▼ ▼ │
- │ [Safe / Pass] [FLAGGED: SQL INJECTION FLAW] │
- └────────────────────────────────────────────────────────────────────────┘
- Strengths & High-Value Use Cases
Broad Static Coverage: Can inspect code paths that dynamic tests may not execute, subject to supported languages, build context, generated code, configuration, and analysis limitations.
Pinpoint Remediation: Identifies the exact file path and line number responsible for the vulnerability, accompanied by contextual guidance for developers.
Early Phase Execution: Runs within developer IDEs and initial pull request CI checks, preventing flawed code from ever merging into main branches.
Weaknesses & Operational Challenges
False-Positive Fatigue: Because SAST lacks runtime context, it cannot determine whether an external Web Application Firewall, API gateway, or higher-level business constraint neutralizes the theoretical flaw, often generating high volumes of false alerts.
Language & Framework Dependent: Scanners must possess specialized parsers for each programming language and web framework in use.
Blind to Infrastructure & Runtime Configs: Cannot detect runtime authentication timing flaws, environment variable misconfigurations, weak TLS cipher suites, or container orchestration vulnerabilities.
Dynamic Application Security Testing (DAST)
DAST is a black-box testing methodology that analyzes an application from the outside while it is running in an active staging or ephemeral preview environment.
Technical Mechanics
DAST scanners operate as automated vulnerability testing agents (or automated web penetration testing tools):
Crawling / Spidering: Discovers application endpoints, forms, API definitions, and URL structures.
Fuzzing & Payload Injection: Submits crafted malicious inputs (e.g., SQL payloads, cross-site scripting strings, oversized buffers, directory traversal sequences) into HTTP headers, query parameters, cookies, and body payloads.
Response Evaluation: Inspects HTTP status codes, server headers, response times, and DOM changes to infer whether an exploit succeeded.
Strengths & High-Value Use Cases
Technology Agnostic: DAST interacts purely over network protocols (HTTP/1.1, HTTP/2, REST, GraphQL). It does not matter whether the backend is written in Rust, Go, Python, or legacy COBOL.
Runtime Evidence: A reproducible exploit can provide strong evidence of a vulnerability in the tested environment, but scanner findings still require validation and scoping.
Detects Environmental & Configuration Flaws: Identifies missing HTTP security headers ( Content-Security-Policy , Strict-Transport-Security ), misconfigured Cross-Origin Resource Sharing (CORS) policies, TLS negotiation weaknesses, and cookie security flags ( Secure , HttpOnly , SameSite ).
Weaknesses & Operational Challenges
Late Lifecycle Execution: Requires a fully compiled, running application deployed in a reachable staging or test environment, making remediation slower and more complex.
Lack of Code-Level Line Attribution: DAST alerts report that POST /api/checkout returned an error indicative of SQL injection, but cannot specify which database query or microservice source file contains the defect.
Incomplete Path Coverage: Complex multi-step user workflows (e.g., a checkout flow requiring multi-factor authentication and CAPTCHA) frequently block automated crawlers, leaving deeply nested application logic untested.
Interactive Application Security Testing (IAST)
IAST (Interactive Application Security Testing) is a hybrid grey-box methodology designed to unite the precision of SAST with the real-world contextual accuracy of DAST. ┌────────────────────────────────────────────────────────────────────────┐
- │ IAST RUNTIME EXECUTION MODEL │
- ├────────────────────────────────────────────────────────────────────────┤
- │ │
- │ [Automated Functional / Integration Tests] │
- │ │ │
- │ ▼ HTTP Requests │
- │ ┌────────────────────────────────────────────────────────────────┐ │
- │ │ Application Runtime Container (JVM / CLR / Node.js) │ │
- │ │ │ │
- │ │ ┌────────────────────────────────────────────────────────┐ │ │
- │ │ │ Application Business Logic Code │ │ │
- │ │ └───────────────────────────┬────────────────────────────┘ │ │
- │ │ │ Function Invocations │ │
- │ │ ▼ │ │
- │ │ ┌────────────────────────────────────────────────────────┐ │ │
- │ │ │ IAST In-Process Instrumentation Agent │ │ │
- │ │ │ • Monitors internal memory, variables, and API calls │ │ │
- │ │ │ • Correlates HTTP request with backend SQL query │ │ │
- │ │ │ • Verifies whether sanitizer sanitized payload │ │ │
- │ │ └───────────────────────────┬────────────────────────────┘ │ │
- │ │ │ Confirmed Flaw Detected │ │
- │ └───────────────────────────────┼────────────────────────────────┘ │
- │ ▼ │
- │ [Instant Alert with Exact Line of Code] │
- │ │
- └────────────────────────────────────────────────────────────────────────┘
- How IAST Works
IAST deploys a specialized sensor agent directly inside the application execution runtime (e.g., as a Java JVM -javaagent , .NET CLR profiler, or Node.js module). Unlike SAST (which scans static text) and DAST (which only inspects network boundaries):
When normal functional tests, QA testers, or automated integration scripts exercise the application, the IAST agent observes execution inside the running process .
The agent monitors memory buffers, internal variable transformations, database calls, and filesystem I/O.
If an HTTP request containing an attack payload reaches a database call without traversing a sanitizer, the IAST agent intercepts it at runtime, confirms vulnerability exploitability, and reports the exact line of source code responsible.
Comparison: SAST vs. DAST vs. IAST
- Dimension SAST DAST IAST
- Perspective White-box (Static Code) Black-box (External Network) Grey-box (In-Process Runtime)
- Phase Coding / Commit / Build Staging / Pre-Production QA / Functional Testing
- Execution Required? No Yes (Running application) Yes (Running with agent)
- False Positive Rate Moderate to High Low Very Low
- Coverage 100% of theoretical paths Limited to crawled paths Driven by functional test suites
- Line-of-Code Precision Yes No Yes
- Runtime Config Visibility None High High
- Performance Overhead Scans take minutes to hours Scans take hours to days Minimal overhead (~2–5% in QA)
- Software Composition Analysis (SCA)
Modern cloud-native software is rarely written entirely from scratch. Upwards of 70% to 90% of an enterprise application codebase consists of third-party open-source libraries, packages, and frameworks ingested from public package registries (such as npm, PyPI, Maven Central, NuGet, and RubyGems).
Software Composition Analysis (SCA) is the dedicated discipline of inspecting an application's dependency graph to identify open-source components, detect known security vulnerabilities, and enforce legal licensing compliance.
The Direct vs. Transitive Dependency Challenge
Direct Dependencies: Libraries explicitly declared by the developer in project package manifests (e.g., package.json , pom.xml , requirements.txt ).
Transitive (Indirect) Dependencies: The dependencies of your dependencies. A project declaring only 10 direct dependencies may inadvertently pull in over 800 transitive libraries during compilation.
Attack Surface: Vulnerabilities in deeply nested transitive dependencies are just as exploitable as flaws in top-level code, but are far harder to detect without automated dependency resolution tooling. ┌────────────────────────────────────────────────────────────────────────┐
- │ TRANSITIVE DEPENDENCY EXPANSION │
- ├────────────────────────────────────────────────────────────────────────┤
- │ │
- │ [Direct Dependency] │
- │ express (v4.18.2) │
- │ │ │
- │ ├──► accepts ──► negotiator │
- │ ├──► body-parser ──► raw-body ──► bytes │
- │ ├──► send ──► mime ──► [CVE-202X-XXXX High Severity Flaw!] │
- │ └──► qs │
- │ │
- │ * Developer sees 1 dependency; security boundary absorbs 40+ packages│
- └────────────────────────────────────────────────────────────────────────┘
- Vulnerability Detection & Common Weakness Enumeration
SCA tools parse lockfiles (e.g., package-lock.json , yarn.lock , Pipfile.lock , go.sum ) to establish a deterministic dependency graph. The tool queries authoritative vulnerability databases:
National Vulnerability Database (NVD): Maintained by NIST, providing standardized Common Vulnerabilities and Exposures (CVE) scores using the Common Vulnerability Scoring System (CVSS) .
Open Source Vulnerabilities (OSV): Distributed open-source database aggregating disclosures across ecosystems.
Vendor Threat Intelligence: Proprietary research tracking zero-day exploits and malicious package insertions before public NVD indexing.
Open-Source License Risk Management
In addition to security vulnerabilities, SCA tools enforce legal compliance by auditing open-source software licenses:
Permissive Licenses (MIT, Apache 2.0, BSD): Allow royalty-free commercial distribution, modification, and proprietary integration with minimal attribution requirements.
Weak Copyleft Licenses (LGPL, MPL): Permit integration if the library itself remains unmodified or dynamically linked, but modifications to the library must be open-sourced.
Strong Copyleft Licenses (GPL v2/v3, AGPL): Enforce the "viral" clause—incorporating or linking GPL code into proprietary software may legally obligate the enterprise to open-source the entire proprietary codebase. SCA engines automatically flag GPL/AGPL licenses to prevent intellectual property loss.
Software Bill of Materials (SBOM): Architecture, Standards & Governance
A Software Bill of Materials (SBOM) is a comprehensive, machine-readable, formal record containing the details, supply chain relationships, and hierarchical metadata of components used in building software. Just as an ingredients list on food packaging discloses all allergens and components, an SBOM details every library, module, author, hash, and license embedded in an application.
SBOM Policy and Standards Context
US Executive Order 14028 historically accelerated federal SBOM work and directed publication of NTIA's minimum elements. Current implementations should verify the contract and policy in force rather than treating that 2021 order as a timeless universal mandate. NTIA's minimum-elements work, NIST SP 800-218 (SSDF), CISA resources, CycloneDX, and SPDX remain useful references for building and consuming SBOMs.
Authoritative SBOM Standards: CycloneDX vs. SPDX
The cloud security industry has converged on two primary open standards for machine-readable SBOM generation: ┌────────────────────────────────────────────────────────────────────────┐
- │ CYCLONEDX VS. SPDX COMPARISON │
- ├────────────────────────────────────────────────────────────────────────┤
- │ STANDARD ORIGIN / BODY PRIMARY STRENGTH / FOCUS │
- ├────────────────────────────────────────────────────────────────────────┤
- │ OWASP OWASP Foundation Engineered specifically for │
- │ CycloneDX application security, DevOps, │
- │ vulnerability analysis, and VEX.│
- ├────────────────────────────────────────────────────────────────────────┤
- │ SPDX Linux Foundation Comprehensive software packaging│
- │ (ISO/IEC 5962) IP tracking, licensing analysis,│
- │ and formal legal compliance. │
- └────────────────────────────────────────────────────────────────────────┘
OWASP CycloneDX:
A modern, lightweight standard optimized for security analysis, continuous DevSecOps integration, and automated pipeline tooling.
Supports JSON, XML, and Protocol Buffers (protobuf).
Natively supports specialized security extensions: Hardware Bill of Materials (HBOM) , Operations Bill of Materials (OBOM) , and Software-as-a-Service Bill of Materials (SaaSBOM) to track cloud service endpoints and data privacy classifications.
Fully integrates with VEX (Vulnerability Exploitability eXchange) .
SPDX (Software Package Data Exchange - ISO/IEC 5962:2021):
Developed by the Linux Foundation and recognized as an international standard (ISO).
Heavily focused on intellectual property provenance, component licensing, and legal distribution obligations.
Supports tag/value, JSON, YAML, and RDF formats.
Vulnerability Exploitability eXchange (VEX)
A critical operational barrier to SBOM adoption is vulnerability noise. An SCA scanner inspecting an SBOM may flag that an application contains an open-source library affected by a Critical CVE. However, in modern compiled applications, the vulnerable function within that library may never be invoked, imported, or reachable by user inputs ( Reachability Analysis ).
VEX (Vulnerability Exploitability eXchange) is a machine-readable companion assertion format (supported in CycloneDX and OpenVEX) that allows software authors to publish authoritative status updates regarding specific CVEs within their SBOM:
not_affected : The component contains the CVE, but the vulnerability is not exploitable (e.g., vulnerable code is not invoked or is protected by inline compiler flags).
affected : The vulnerability is present and actively exploitable.
fixed : The vulnerability has been remediated in the specified release.
under_investigation : The author is analyzing the vulnerability impact.
Coupling SBOMs with reviewed VEX assertions can reduce irrelevant alerts and help prioritize affected or reachable components; VEX quality and trust still require validation.
The Log4j (Log4Shell - CVE-2021-44228) Case Study
In December 2021, the disclosure of Log4Shell —a remote code execution flaw in the ubiquitous Apache Log4j logging framework—exposed the fragility of enterprise software supply chains. Organizations without standardized SBOM repositories faced catastrophic operational hurdles:
Engineers spent hundreds of hours manually logging into servers, extracting jar archives, and executing grep searches to determine if Log4j was present.
Because Log4j was frequently embedded as a deep transitive dependency inside commercial off-the-shelf software and vendor SaaS platforms, discovery took weeks.
Conversely, enterprises possessing centralized, machine-readable SBOM repositories (e.g., Dependency-Track) queried their enterprise inventory using simple API calls, instantly identifying every workload, service, and container image containing vulnerable versions of Log4j across multi-cloud environments in seconds.