1. SAST, DAST, and IAST

Modern software development is defined by speed, automation, and continuous delivery. While these characteristics enable rapid innovation, they also introduce unprecedented security risk if security controls fail to evolve at the same pace. Traditional security testing models—performed late in development or after deployment—are no longer sufficient in environments where code may be pushed to production dozens of times per day.

Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Interactive Application Security Testing (IAST) represent three complementary approaches to embedding security directly into the software delivery pipeline. Together, they form the technical backbone of automated application security assurance in DevSecOps-driven organizations.

This chapter explores these testing paradigms not as isolated tools, but as integrated security feedback mechanisms that support secure software engineering, risk-informed decision-making, and continuous improvement.

DevSecOps Context: Why Application Security Must Be Automated

DevSecOps is not simply the addition of security tools into a CI/CD pipeline. It is a cultural and architectural shift that treats security as a shared responsibility across development, operations, and security teams. Within this model, security testing must be automated, repeatable, and aligned with developer workflows.

Manual testing remains valuable for depth and creativity, but it cannot scale to the velocity of modern pipelines. Automated testing techniques such as SAST, DAST, and IAST enable early detection of vulnerabilities, reduce remediation costs, and prevent insecure code from progressing downstream.

NIST SP 800-218 (Secure Software Development Framework) explicitly emphasizes the integration of automated security testing throughout the SDLC, reinforcing the importance of these techniques as foundational controls rather than optional enhancements.

Overview of SAST, DAST, and IAST

Although SAST, DAST, and IAST all aim to identify application security weaknesses, they differ fundamentally in where, when, and how they analyze software.

• SAST examines source code or compiled artifacts without executing the application

• DAST tests a running application from the outside, simulating real-world interaction

• IAST analyzes application behavior internally during execution

Understanding these distinctions is critical for designing effective CI/CD security pipelines and interpreting results accurately.

Static Application Security Testing (SAST)

- Conceptual Foundations

Static Application Security Testing analyzes application code in a non-executing state. It inspects source code, bytecode, or binaries to identify patterns associated with security weaknesses such as unsafe input handling, insecure cryptographic usage, or flawed access control logic.

SAST tools operate on the assumption that many vulnerabilities are deterministic outcomes of insecure coding patterns, which can be identified before the application ever runs. This makes SAST particularly well-suited for early SDLC phases.

- Role of SAST in the CI/CD Pipeline

SAST is most effective when integrated early, often during:

• Developer commit or pull request stages

• Build pipeline execution

• Pre-merge code reviews

Early placement ensures that developers receive feedback while the code context is still fresh, reinforcing secure coding practices rather than retroactive fixes.

- Strengths and Limitations of SAST

SAST provides several strategic advantages:

• Early detection of vulnerabilities

• No requirement for a running application

• Broad coverage of code paths

• Alignment with secure coding standards

However, SAST also presents challenges:

• High false-positive rates if poorly tuned

• Limited visibility into runtime behavior

• Difficulty analyzing dynamically generated code

Effective SAST programs focus heavily on rule tuning, developer education, and triage workflows, rather than raw tool output.

Dynamic Application Security Testing (DAST)

- Conceptual Foundations

Dynamic Application Security Testing evaluates an application in its running state, interacting with it through exposed interfaces such as HTTP APIs or web frontends. DAST simulates external user behavior, making it particularly valuable for identifying issues that emerge only at runtime.

Unlike SAST, DAST does not require access to source code. It observes application responses to crafted inputs and analyzes behavior for signs of security weaknesses.

- Placement in CI/CD Pipelines

DAST is typically executed against:

• Deployed test or staging environments

• Ephemeral environments created during pipeline execution

Because DAST requires a functioning application, it is naturally positioned later in the pipeline than SAST.

- Strengths and Limitations of DAST

DAST excels in identifying:

• Runtime configuration issues

• Authentication and session management flaws

• Input validation failures observable from the outside

However, DAST also has limitations:

• Limited insight into internal code logic

• Potentially longer execution times

• Dependence on application reachability and test data

DAST findings are often more actionable from a risk perspective, but less precise in pinpointing root causes without developer context.

Interactive Application Security Testing (IAST)

- Conceptual Foundations

IAST combines elements of both SAST and DAST by instrumenting the application during runtime. It monitors internal execution paths while the application is being exercised, correlating code-level context with runtime behavior.

This hybrid approach allows IAST to provide highly accurate findings with lower false-positive rates than traditional SAST or DAST alone.

- Integration into Development and Testing

IAST is commonly integrated into:

• Automated functional testing environments

• Quality assurance (QA) pipelines

• Continuous testing stages

Because IAST operates alongside normal application usage, it aligns naturally with modern test automation frameworks.

- Strengths and Trade-offs of IAST

Key advantages of IAST include:

• Precise vulnerability identification

• Strong correlation between cause and effect

• Reduced noise compared to standalone tools

Trade-offs include:

• Dependency on test coverage quality

• Instrumentation overhead

• More complex deployment requirements

IAST is most effective in organizations with mature test automation practices.

Comparative View: When to Use SAST, DAST, and IAST

Rather than viewing these approaches as competitors, mature DevSecOps programs treat them as complementary controls.

In practice:

• SAST enforces secure coding discipline early

• DAST validates runtime exposure and configuration

• IAST bridges development and execution insight

Together, they provide layered assurance across the SDLC.

Managing Findings and Reducing Noise

One of the greatest risks in automated security testing is alert fatigue. Without proper governance, pipelines can overwhelm teams with low-quality findings, eroding trust in security tooling.

Effective programs implement:

• Severity thresholds aligned with risk tolerance

• Automated suppression of known acceptable risks

• Clear ownership for triage and remediation

Security tools must support developers, not hinder delivery.

Aligning Findings with Secure Coding Standards

SAST, DAST, and IAST findings should map directly to secure coding standards such as OWASP Top Ten and organizational secure development policies. This alignment transforms findings from isolated issues into learning opportunities.

Developers benefit most when findings include:

• Clear explanations of root causes

• Secure alternatives and coding patterns

• References to internal guidelines

This educational feedback loop is essential for long-term security maturity.

Security Gates and Pipeline Enforcement

Automated security testing enables the implementation of security gates, which prevent insecure artifacts from progressing through the pipeline. These gates must be designed carefully to balance risk reduction with delivery velocity.

Well-designed gates focus on:

• Blocking critical and high-risk issues

• Allowing conditional progression with documented risk acceptance

• Supporting gradual improvement rather than perfection

Rigid, poorly calibrated gates often lead to bypasses and shadow processes.

Continuous Improvement and Metrics

Beyond individual findings, security testing data provides valuable insights into organizational security posture over time. Metrics such as vulnerability density, recurrence rates, and time-to-remediation help guide strategic improvements.

These metrics support:

• Secure SDLC refinement

• Training prioritization

• Tool tuning decisions

Security testing becomes a driver of systemic improvement rather than reactive firefighting.

Ethical and Professional Considerations

Automated testing must be conducted responsibly, respecting system stability, data privacy, and organizational policy. Even in internal pipelines, safeguards are necessary to prevent unintended disruption.

Professional DevSecOps practices emphasize transparency, consent, and accountability in security testing operations.

SAST, DAST, and IAST as Pillars of Secure Delivery

SAST, DAST, and IAST are not merely tools; they are mechanisms for embedding security into the DNA of software development. When implemented thoughtfully, they enable rapid innovation without sacrificing trust, resilience, or compliance.

At the Master’s level, practitioners must understand not only how these techniques work, but how to orchestrate them strategically within CI/CD pipelines, organizational culture, and risk governance frameworks.

The ultimate goal is not to eliminate all vulnerabilities, but to create systems that fail safely, improve continuously, and resist exploitation by design.