Interactive Application Security Testing (IAST) and Runtime Protection

The Day a Zero-Day Exploit Hit Production (And How We Survived)

It was 2:47 PM on a Tuesday when our Slack security channel exploded with alerts. A zero-day vulnerability in a third-party library we'd been using for months was being actively exploited in the wild. Our static analysis tools hadn't caught it—how could they? The vulnerability was in the runtime behavior, a subtle deserialization flaw that only manifested under specific conditions with malicious input.

Within minutes, we confirmed: our production API was vulnerable. But here's the twist—we weren't actually breached. Our runtime application self-protection (RASP) layer had already blocked 47 exploit attempts in the past hour. We didn't even know we were under attack until the CVE was published.

That day transformed how I thought about application security. SAST and DAST are essential, but they're not enough. You need eyes inside your running application, watching every request, every database query, every external call. You need defense-in-depth that works when your code is under fire.

This article covers how I implemented Interactive Application Security Testing (IAST) and runtime protection layers that caught vulnerabilities static analysis missed and stopped attacks DAST never saw coming.

What You'll Learn

How IAST works and why it complements SAST/DAST
Implementing Runtime Application Self-Protection (RASP)
Deploying and configuring Web Application Firewalls (WAF)
API Gateway security patterns
Runtime monitoring for security observability
Building a defense-in-depth security architecture

Understanding the Testing Spectrum

Before diving into IAST and runtime protection, let's understand where they fit in your security testing arsenal.

The Security Testing Pyramid:

SAST (Static): Analyzes source code without execution
IAST (Interactive): Instruments code and monitors during testing
DAST (Dynamic): Tests running application as a black box
RASP (Runtime): Protects application from within at runtime
WAF (Web Application Firewall): Network-level application protection

What is IAST?

Interactive Application Security Testing instruments your application code with sensors that monitor execution during functional testing. Unlike SAST (which analyzes code) or DAST (which tests from outside), IAST watches your code run from the inside.

How IAST Works

Key advantages of IAST:

Low false positives: Sees actual runtime behavior
Full code coverage: Monitors all executed paths
Context-aware: Understands data flow and trust boundaries
Developer-friendly: Reports include stack traces and reproduction steps

Real-World IAST Implementation

Setting Up Contrast Security IAST

I've used several IAST tools, but Contrast Security has been the most effective for our Node.js microservices.

Installation

# package.json
{
  "name": "payment-service",
  "scripts": {
    "start": "node -r @contrast/agent server.js",
    "test": "node -r @contrast/agent node_modules/.bin/jest"
  },
  "dependencies": {
    "@contrast/agent": "^6.11.0"
  }
}

Configuration

# contrast_security.yaml
api:
  url: https://app.contrastsecurity.com/Contrast
  api_key: ${CONTRAST_API_KEY}
  service_key: ${CONTRAST_SERVICE_KEY}
  user_name: ${CONTRAST_USER_NAME}

agent:
  logger:
    level: INFO
    path: ./contrast.log
  
  service:
    name: payment-service
    environment: staging
    tags:
      - microservice
      - payments
      - pci-dss
  
  security:
    # Report all vulnerabilities
    level: all
    
  application:
    # Application metadata
    name: payment-processing-platform
    version: ${CI_COMMIT_SHA}
    group: financial-services

GitLab CI Integration

# .gitlab-ci.yml
stages:
  - build
  - test
  - iast-analysis
  - deploy

variables:
  CONTRAST_API_KEY: ${CONTRAST_API_KEY}
  CONTRAST_SERVICE_KEY: ${CONTRAST_SERVICE_KEY}
  CONTRAST_USER_NAME: ${CONTRAST_USER_NAME}

test-with-iast:
  stage: test
  image: node:18-alpine
  services:
    - postgres:14
    - redis:7
  before_script:
    - npm ci
    - npm run db:migrate
  script:
    # Run tests with IAST instrumentation
    - npm run test:integration
    - npm run test:e2e
  artifacts:
    reports:
      junit: test-results/junit.xml
    paths:
      - contrast.log

iast-analysis:
  stage: iast-analysis
  image: curlimages/curl:latest
  script:
    # Wait for Contrast to process findings
    - sleep 30
    
    # Fetch vulnerabilities from Contrast API
    - |
      curl -X GET \
        -H "Authorization: ${CONTRAST_AUTH_HEADER}" \
        -H "API-Key: ${CONTRAST_API_KEY}" \
        "https://app.contrastsecurity.com/Contrast/api/ng/${CONTRAST_ORG_ID}/traces/${CONTRAST_APP_ID}/filter?severities=CRITICAL,HIGH" \
        -o iast-results.json
    
    # Check for critical vulnerabilities
    - |
      CRITICAL_COUNT=$(cat iast-results.json | jq '.traces | length')
      echo "Found $CRITICAL_COUNT critical/high vulnerabilities"
      
      if [ "$CRITICAL_COUNT" -gt 0 ]; then
        echo "❌ IAST found critical vulnerabilities!"
        cat iast-results.json | jq '.traces[] | {rule: .rule.name, severity: .severity, url: .url}'
        exit 1
      fi
  artifacts:
    reports:
      junit: iast-results.json
  dependencies:
    - test-with-iast

What IAST Caught That SAST Missed

1. SQL Injection via Dynamic Query Builder

// src/services/UserService.js
class UserService {
  async searchUsers(filters) {
    // SAST didn't flag this as vulnerable
    // Because it's using a query builder
    let query = this.db.table('users');
    
    // But this is still vulnerable!
    if (filters.sortBy) {
      // IAST caught this: user input in ORDER BY
      query = query.orderByRaw(filters.sortBy);
    }
    
    return await query;
  }
}

// ❌ Attack: filters.sortBy = "1; DROP TABLE users--"

IAST Detection:

[CRITICAL] SQL Injection
Path: /api/users/search
Parameter: sortBy
Stack Trace:
  at UserService.searchUsers (UserService.js:15)
  at UserController.search (UserController.js:42)
  at Router.handle (express/lib/router/index.js:284)

Evidence: Untrusted data flows from HTTP parameter 'sortBy' 
          to SQL query without sanitization

Remediation: Use parameterized queries or whitelist allowed sort columns

2. XSS via Template Rendering

// src/utils/emailTemplates.js
function renderWelcomeEmail(user) {
  // SAST might miss this depending on template engine
  return `
    <html>
      <body>
        <h1>Welcome, ${user.displayName}!</h1>
        <p>Your email: ${user.email}</p>
      </body>
    </html>
  `;
}

// ❌ Attack: displayName = "<script>alert('XSS')</script>"

IAST Detection:

[HIGH] Cross-Site Scripting (XSS)
Function: renderWelcomeEmail
File: src/utils/emailTemplates.js:12

Evidence: Untrusted data from user.displayName rendered in HTML 
          without encoding

Impact: Stored XSS - malicious script stored in database

Runtime Application Self-Protection (RASP)

RASP takes IAST a step further—instead of just reporting vulnerabilities, it actively blocks attacks at runtime.

How RASP Works

RASP Implementation Example

// server.js with RASP
const contrast = require('@contrast/agent');
const express = require('express');
const app = express();

// Contrast RASP automatically instruments the app
app.use(express.json());

// This endpoint is now protected by RASP
app.post('/api/users/:id/profile', async (req, res) => {
  const { id } = req.params;
  const { bio } = req.body;
  
  // RASP monitors this query
  // Blocks if it detects SQL injection attempt
  await db.query(
    'UPDATE users SET bio = $1 WHERE id = $2',
    [bio, id]
  );
  
  res.json({ success: true });
});

Real Attack Blocked by RASP

# Attack attempt
curl -X POST https://api.example.com/api/users/1/profile \
  -H "Content-Type: application/json" \
  -d '{
    "bio": "'; DROP TABLE users--"
  }'

# RASP blocks and logs:
{
  "timestamp": "2024-01-06T14:32:17Z",
  "event": "ATTACK_BLOCKED",
  "type": "SQL_INJECTION",
  "severity": "CRITICAL",
  "source_ip": "203.0.113.42",
  "user_agent": "curl/7.84.0",
  "path": "/api/users/1/profile",
  "parameter": "bio",
  "attack_payload": "'; DROP TABLE users--",
  "action": "BLOCKED",
  "response_code": 403
}

Web Application Firewall (WAF)

WAF provides the first line of defense at the network edge, before requests even reach your application.

AWS WAF Configuration

# terraform/waf.tf
resource "aws_wafv2_web_acl" "main" {
  name  = "production-api-waf"
  scope = "REGIONAL"

  default_action {
    allow {}
  }

  # Rule 1: Rate limiting
  rule {
    name     = "rate-limiting"
    priority = 1

    action {
      block {
        custom_response {
          response_code = 429
        }
      }
    }

    statement {
      rate_based_statement {
        limit              = 2000
        aggregate_key_type = "IP"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name               = "RateLimitRule"
      sampled_requests_enabled  = true
    }
  }

  # Rule 2: AWS Managed Rules - Core Rule Set
  rule {
    name     = "aws-managed-core-rules"
    priority = 2

    override_action {
      none {}
    }

    statement {
      managed_rule_group_statement {
        vendor_name = "AWS"
        name        = "AWSManagedRulesCommonRuleSet"
        
        # Exclude rules that cause false positives
        excluded_rule {
          name = "GenericRFI_BODY"
        }
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name               = "AWSManagedCoreRules"
      sampled_requests_enabled  = true
    }
  }

  # Rule 3: SQL Injection Protection
  rule {
    name     = "sql-injection-protection"
    priority = 3

    action {
      block {}
    }

    statement {
      or_statement {
        statement {
          sqli_match_statement {
            field_to_match {
              body {}
            }
            text_transformation {
              priority = 1
              type     = "URL_DECODE"
            }
          }
        }

        statement {
          sqli_match_statement {
            field_to_match {
              query_string {}
            }
            text_transformation {
              priority = 1
              type     = "URL_DECODE"
            }
          }
        }
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name               = "SQLInjectionRule"
      sampled_requests_enabled  = true
    }
  }

  # Rule 4: XSS Protection
  rule {
    name     = "xss-protection"
    priority = 4

    action {
      block {}
    }

    statement {
      xss_match_statement {
        field_to_match {
          body {}
        }
        text_transformation {
          priority = 1
          type     = "URL_DECODE"
        }
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name               = "XSSProtectionRule"
      sampled_requests_enabled  = true
    }
  }

  # Rule 5: Geographic restrictions
  rule {
    name     = "geo-blocking"
    priority = 5

    action {
      block {}
    }

    statement {
      geo_match_statement {
        # Block requests from high-risk countries
        country_codes = ["KP", "IR", "SY"]
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name               = "GeoBlockingRule"
      sampled_requests_enabled  = true
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name               = "ProductionAPIWAF"
    sampled_requests_enabled  = true
  }

  tags = {
    Environment = "production"
    ManagedBy   = "terraform"
  }
}

# Attach WAF to ALB
resource "aws_wafv2_web_acl_association" "main" {
  resource_arn = aws_lb.api.arn
  web_acl_arn  = aws_wafv2_web_acl.main.arn
}

Custom WAF Rules for API Protection

# Custom rule for API abuse
resource "aws_wafv2_rule_group" "api_protection" {
  name     = "api-protection-rules"
  scope    = "REGIONAL"
  capacity = 100

  rule {
    name     = "block-invalid-json"
    priority = 1

    action {
      block {}
    }

    statement {
      and_statement {
        statement {
          byte_match_statement {
            field_to_match {
              single_header {
                name = "content-type"
              }
            }
            positional_constraint = "CONTAINS"
            search_string        = "application/json"
            text_transformation {
              priority = 1
              type     = "LOWERCASE"
            }
          }
        }

        statement {
          not_statement {
            statement {
              regex_match_statement {
                field_to_match {
                  body {}
                }
                regex_string = "^\\{.*\\}$"
                text_transformation {
                  priority = 1
                  type     = "NONE"
                }
              }
            }
          }
        }
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name               = "InvalidJSONRule"
      sampled_requests_enabled  = true
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name               = "APIProtectionRuleGroup"
    sampled_requests_enabled  = true
  }
}

API Gateway Security Patterns

API Gateways provide another layer of security before requests reach your services.

Kong API Gateway Security Configuration

# kong.yml
_format_version: "3.0"

services:
  - name: payment-service
    url: http://payment-service:3000
    routes:
      - name: payment-routes
        paths:
          - /api/payments
        methods:
          - POST
          - GET
        strip_path: false
    
    plugins:
      # Rate limiting
      - name: rate-limiting
        config:
          minute: 100
          hour: 1000
          policy: redis
          redis_host: redis
          redis_port: 6379
      
      # IP restriction
      - name: ip-restriction
        config:
          allow:
            - 10.0.0.0/8
            - 172.16.0.0/12
          deny:
            - 203.0.113.0/24
      
      # Request size limiting
      - name: request-size-limiting
        config:
          allowed_payload_size: 1
          size_unit: megabytes
      
      # Request validation
      - name: request-validator
        config:
          body_schema: |
            {
              "type": "object",
              "required": ["amount", "currency"],
              "properties": {
                "amount": {
                  "type": "number",
                  "minimum": 0.01,
                  "maximum": 1000000
                },
                "currency": {
                  "type": "string",
                  "enum": ["USD", "EUR", "GBP"]
                }
              }
            }
      
      # Bot detection
      - name: bot-detection
        config:
          allow:
            - GoogleBot
            - Pingdom
          deny:
            - curl
            - python-requests
      
      # CORS
      - name: cors
        config:
          origins:
            - https://app.example.com
          methods:
            - GET
            - POST
          headers:
            - Authorization
            - Content-Type
          exposed_headers:
            - X-Request-Id
          credentials: true
          max_age: 3600

Runtime Security Monitoring

Observability is crucial for runtime security. You need to see attacks as they happen.

Datadog Security Monitoring

# datadog-agent.yml
apiVersion: v1
kind: ConfigMap
metadata:
  name: datadog-agent
  namespace: monitoring
data:
  security-agent.yaml: |
    runtime_security_config:
      enabled: true
      
      policies:
        # Monitor suspicious file access
        - name: sensitive-file-access
          expression: >
            open.file.path in [
              "/etc/passwd",
              "/etc/shadow",
              "/root/.ssh/id_rsa"
            ]
          actions:
            - alert
            - block
        
        # Monitor unusual network connections
        - name: suspicious-outbound-connection
          expression: >
            network.destination.ip not in [
              "10.0.0.0/8",
              "172.16.0.0/12"
            ] and 
            network.destination.port not in [80, 443]
          actions:
            - alert
        
        # Monitor process execution
        - name: unauthorized-process-execution
          expression: >
            exec.file.name in [
              "nc",
              "ncat",
              "netcat",
              "wget",
              "curl"
            ] and 
            process.name != "npm"
          actions:
            - alert
            - block
    
    compliance_config:
      enabled: true
      check_interval: 20m

Security Event Correlation

// src/middleware/securityMonitoring.js
const { Logger } = require('@datadog/datadog-lambda-js');
const logger = new Logger();

class SecurityMonitor {
  static async logSecurityEvent(req, eventType, details) {
    const event = {
      timestamp: new Date().toISOString(),
      type: eventType,
      severity: this.calculateSeverity(eventType, details),
      source_ip: req.ip,
      user_agent: req.get('user-agent'),
      path: req.path,
      method: req.method,
      user_id: req.user?.id,
      session_id: req.session?.id,
      ...details
    };

    // Send to Datadog
    logger.log('security.event', event, {
      tags: [
        `event_type:${eventType}`,
        `severity:${event.severity}`,
        `environment:${process.env.NODE_ENV}`
      ]
    });

    // Also send to SIEM
    await this.sendToSIEM(event);

    // Check for attack patterns
    await this.checkAttackPattern(req.ip, eventType);
  }

  static calculateSeverity(eventType, details) {
    const severityMap = {
      'sql_injection_attempt': 'CRITICAL',
      'xss_attempt': 'HIGH',
      'authentication_failure': 'MEDIUM',
      'rate_limit_exceeded': 'LOW'
    };
    return severityMap[eventType] || 'INFO';
  }

  static async checkAttackPattern(ip, eventType) {
    // Check Redis for recent events from this IP
    const key = `security:${ip}:${eventType}`;
    const count = await redis.incr(key);
    await redis.expire(key, 300); // 5 minutes

    if (count > 5) {
      // Potential attack pattern detected
      await this.blockIP(ip);
      await this.alertSecurityTeam(ip, eventType, count);
    }
  }

  static async blockIP(ip) {
    // Update WAF to block this IP
    await wafClient.updateIPSet({
      Name: 'BlockedIPs',
      Id: process.env.WAF_IP_SET_ID,
      Scope: 'REGIONAL',
      Addresses: [ip]
    });

    logger.log('security.ip_blocked', {
      ip,
      reason: 'attack_pattern_detected'
    });
  }
}

module.exports = SecurityMonitor;

Using the Security Monitor

// src/middleware/sqlInjectionDetection.js
const SecurityMonitor = require('./securityMonitoring');

function detectSQLInjection(req, res, next) {
  const sqlPatterns = [
    /(\%27)|(\')|(\-\-)|(\%23)|(#)/i,
    /((\%3D)|(=))[^\n]*((\%27)|(\')|(\-\-)|(\%3B)|(;))/i,
    /\w*((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/i,
    /union.*select/i,
    /select.*from/i,
    /insert.*into/i,
    /delete.*from/i,
    /drop.*table/i
  ];

  const checkValue = (value) => {
    return sqlPatterns.some(pattern => pattern.test(value));
  };

  // Check query parameters
  for (const [key, value] of Object.entries(req.query)) {
    if (checkValue(value)) {
      SecurityMonitor.logSecurityEvent(req, 'sql_injection_attempt', {
        parameter: key,
        value: value,
        location: 'query'
      });
      
      return res.status(403).json({
        error: 'Security violation detected'
      });
    }
  }

  // Check body parameters
  if (req.body) {
    for (const [key, value] of Object.entries(req.body)) {
      if (typeof value === 'string' && checkValue(value)) {
        SecurityMonitor.logSecurityEvent(req, 'sql_injection_attempt', {
          parameter: key,
          value: value,
          location: 'body'
        });
        
        return res.status(403).json({
          error: 'Security violation detected'
        });
      }
    }
  }

  next();
}

module.exports = detectSQLInjection;

Defense-in-Depth Architecture

Combining all these layers creates a robust security posture:

Each layer handles specific threats:

CloudFlare: DDoS, bot attacks
AWS WAF: OWASP Top 10, rate limiting
API Gateway: Authentication, request validation
Service Mesh: mTLS, traffic policies
RASP: Runtime vulnerability protection
Monitoring: Detection, alerting, response

Best Practices

1. Start with Monitoring, Not Blocking

# Start in detection mode
rasp:
  mode: monitor  # Not 'block'
  alert_threshold: medium
  
waf:
  default_action: count  # Count, don't block initially

Why: Understand your traffic patterns before blocking. What looks like an attack might be legitimate traffic.

2. Tune False Positives Aggressively

// Keep track of false positives
const falsePositivePatterns = [
  {
    rule: 'XSS_BODY',
    pattern: /react-dom/,
    reason: 'React DevTools legitimate traffic'
  },
  {
    rule: 'SQL_INJECTION',
    pattern: /ORDER BY \d+/,
    reason: 'Sorting by column index is safe in our ORM'
  }
];

3. Layer Your Defenses

Don't rely on a single tool. If RASP fails, WAF should catch it. If WAF fails, monitoring should alert.

4. Monitor Performance Impact

// Track RASP overhead
const performanceMonitor = {
  async measureRASPImpact() {
    const without = await this.benchmarkWithoutRASP();
    const with = await this.benchmarkWithRASP();
    
    const overhead = ((with - without) / without) * 100;
    
    if (overhead > 5) {
      logger.warn('RASP overhead exceeds 5%', { overhead });
    }
    
    return overhead;
  }
};

Common Pitfalls

❌ Pitfall 1: Alert Fatigue

Problem: Too many low-severity alerts drown out critical ones.

Solution: Implement intelligent alerting with severity-based routing.

const alertRouting = {
  CRITICAL: ['pagerduty', 'slack', 'email'],
  HIGH: ['slack', 'email'],
  MEDIUM: ['email'],
  LOW: ['log_only']
};

❌ Pitfall 2: Blocking Legitimate Traffic

Problem: Overly aggressive rules block real users.

Solution: Implement progressive enforcement.

// Progressive blocking strategy
if (threatScore > 90) {
  block();
} else if (threatScore > 70) {
  challenge(); // CAPTCHA
} else if (threatScore > 50) {
  monitor();
}

❌ Pitfall 3: Ignoring Performance

Problem: Security tools add latency.

Solution: Measure and optimize continuously.

# Monitor security tool performance
metrics:
  - name: waf_latency
    threshold: 50ms
  - name: rasp_overhead
    threshold: 5%
  - name: iast_memory_usage
    threshold: 100MB

Key Takeaways

✅ IAST complements SAST/DAST by monitoring actual runtime behavior ✅ RASP provides last-line defense when other tools miss vulnerabilities ✅ WAF protects at the edge before attacks reach your application ✅ Layer security defenses for defense-in-depth ✅ Monitor everything but alert intelligently ✅ Tune aggressively to reduce false positives ✅ Measure performance impact and optimize continuously

What's Next

Now that you have runtime protection in place, it's time to tackle the supply chain—the dependencies your application relies on. In the next article, we'll cover dependency scanning and Software Composition Analysis (SCA), including how to handle incidents like Log4Shell.

Next Article: Dependency Scanning and Software Composition Analysis →

Part of the DevSecOps 101 Series

PreviousDynamic Application Security Testing (DAST)NextDependency Scanning and Software Composition Analysis

Last updated 1 month ago

hashtagThe Day a Zero-Day Exploit Hit Production (And How We Survived)

hashtagWhat You'll Learn

hashtagUnderstanding the Testing Spectrum

hashtagWhat is IAST?

hashtagHow IAST Works

hashtagReal-World IAST Implementation

hashtagSetting Up Contrast Security IAST

hashtagInstallation

hashtagConfiguration

hashtagGitLab CI Integration

hashtagWhat IAST Caught That SAST Missed

hashtag1. SQL Injection via Dynamic Query Builder

hashtag2. XSS via Template Rendering

hashtagRuntime Application Self-Protection (RASP)

hashtagHow RASP Works

hashtagRASP Implementation Example

hashtagReal Attack Blocked by RASP

hashtagWeb Application Firewall (WAF)

hashtagAWS WAF Configuration

hashtagCustom WAF Rules for API Protection

hashtagAPI Gateway Security Patterns

hashtagKong API Gateway Security Configuration

hashtagRuntime Security Monitoring

hashtagDatadog Security Monitoring

hashtagSecurity Event Correlation

hashtagUsing the Security Monitor

hashtagDefense-in-Depth Architecture

hashtagBest Practices

hashtag1. Start with Monitoring, Not Blocking

hashtag2. Tune False Positives Aggressively

hashtag3. Layer Your Defenses

hashtag4. Monitor Performance Impact

hashtagCommon Pitfalls

hashtag❌ Pitfall 1: Alert Fatigue

hashtag❌ Pitfall 2: Blocking Legitimate Traffic

hashtag❌ Pitfall 3: Ignoring Performance

hashtagKey Takeaways

hashtagWhat's Next