11.2 Application Security Testing: SAST, DAST, SCA & SBOM

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:

1. Abstract Syntax Tree (AST): The scanner converts source code into a hierarchical tree representation representing grammatical structure.
2. Control Flow Graph (CFG): Analyzes the logical execution paths that code can traverse during runtime, mapping loops, conditional branches, and subroutine calls.
3. 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):

1. Crawling / Spidering: Discovers application endpoints, forms, API definitions, and URL structures.
2. 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.
3. 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

---

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.    │
└────────────────────────────────────────────────────────────────────────┘

1. 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).
2. 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.