For the complete documentation index, see llms.txt. This page is also available as Markdown.

Dynamic Testing & API Security

Dynamic Testing & API Security validates the security of running applications — testing how they actually behave under real-world conditions, not how their code looks at rest. It adds a critical "shift-right validation layer" that complements shift-left practices like SAST and SCA — catching vulnerabilities that only emerge when systems interact with real inputs, users, APIs, and external integrations.

Modern applications are heavily API-driven and operate in highly interconnected environments — making them particularly vulnerable to runtime exploits such as injection attacks, authentication bypasses, misconfigured endpoints, and sensitive data exposure that no amount of static analysis can predict.

Dynamic Testing & API Security ensures that what was built securely also behaves securely — validating application defense under real attack conditions before customer exposure.

DAST — Dynamic Application Security Testing

DAST tests running applications from the outside — simulating how an attacker would interact with the system. It sends crafted inputs, monitors responses, and identifies exploitable vulnerabilities including SQL injection, XSS, authentication flaws, and runtime misconfigurations.

OpsMx Delivery Shield integrates OWASP ZAP — enhanced with automated scanning, intercepting proxy, spidering, active/passive scanning, and fuzz testing — to provide continuous dynamic security validation against live application endpoints.

Why DAST Is Used in OpsMx

SAST and SCA catch code-level and dependency risks — but many vulnerabilities only appear at runtime. DAST completes the coverage picture by:

  • Testing what attackers actually see — live endpoints, session handling, authentication flows, and API responses

  • Triggering automatically on every deployment — every new image deployment via Argo CD, Spinnaker, or Jenkins initiates a DAST scan through the ZAP integrator

  • Validating OWASP Top 10 coverage — SQL injection, XSS, CSRF, broken authentication, sensitive data exposure, and more

  • Supporting API security testing — REST, SOAP, and GraphQL endpoints scanned via imported API definitions

Scan Types Supported

Scan Type
Description

Passive Scan

Monitors traffic for security issues — safe for production, no attack payloads sent

Active Scan

Simulates SQL injection, XSS, command injection — for staging/pre-production

Authenticated Scan

Tests internal functionality, RBAC, and user-specific vulnerabilities with valid credentials

Non-Authenticated Scan

Tests public-facing components — login pages, public APIs

Ad Hoc Scan

On-demand scan of any service URL directly from the dashboard

Fuzz Testing

Tests API endpoints and form fields with varied payloads to find input validation flaws

Key Capabilities

  • Intercepting Proxy — analyzes and modifies requests/responses to uncover hidden vulnerabilities

  • Spidering & Crawling — maps entire application architecture, entry points, URLs, parameters, and forms

  • Custom Scan Policies — configure scan depth and scope per application risk profile

  • Custom Scripts — write rules in JavaScript, Python, or Groovy for organization-specific test scenarios

  • Session Management Testing — tracks session states, cookies, and tokens to uncover privilege escalation and logic bugs

  • Multi-URL DAST — scan multiple service endpoints in a single scan run when authentication is shared

Results Location in Delivery Shield

  • Post Deploy section of the DBOM page — results tied to each deployment record

  • Vulnerability Management page — findings by severity with remediation guidance

  • Top 5 Vulnerabilities tab — immediate visibility into highest-risk runtime issues

API Security

API Security protects the APIs that serve as the backbone of modern application communication — ensuring that service-to-service interactions, external integrations, and user-facing endpoints are secured against unauthorized access, data leakage, injection attacks, and abuse.

APIs are a major attack surface in microservices architectures. A single misconfigured or unprotected API endpoint can expose sensitive business logic, user data, or internal services.

Why API Security Is Used in OpsMx

OpsMx uses API Security in Delivery Shield to:

  • Discover shadow and unmanaged APIs — identifying endpoints that were never formally documented or secured

  • Enforce authentication and authorization — validating OAuth, JWT, and API key controls on every endpoint

  • Detect input validation failures — preventing injection attacks via malformed or malicious API inputs

  • Protect against data exposure — identifying APIs that return more data than the caller is entitled to

  • Test GraphQL, REST, and SOAP APIs — imported via OpenAPI/Swagger, WSDL, or GraphQL introspection

Key Aspects

Control
Description

Authentication & Authorization

OAuth 2.0, JWT validation, API key enforcement

Schema Validation

Prevents malformed or malicious inputs at the API boundary

Rate Limiting & Abuse Protection

Detects and blocks API abuse patterns

Sensitive Data Exposure Detection

Flags APIs returning PII, credentials, or sensitive business data

API Inventory & Discovery

Tracks all known and shadow API endpoints across the environment

Penetration Testing

Penetration Testing goes beyond automated scanning by simulating targeted, real-world attack scenarios to identify exploitable weaknesses in applications and systems that automated tools alone cannot surface — including business logic flaws, chained exploits, and advanced attack paths.

Why Penetration Testing Is Used in OpsMx

Automated scanning answers "are there vulnerabilities?" Penetration Testing answers:

  • Can an attacker actually exploit this vulnerability?

  • What is the potential impact of a successful attack?

  • How far can an attacker move within the system once inside?

OpsMx integrates penetration testing into its continuous security practices — combining automated dynamic testing with targeted deep assessments that validate whether security controls are effective in practice, not just in theory.

Key Capabilities

  • Business logic flaw detection — exploiting application workflows that automated scanners miss

  • Chained exploit identification — finding multi-step attack paths that combine low-severity findings into critical risks

  • Credential and session abuse testing — validating authentication strength under real attack conditions

  • Post-exploitation assessment — determining lateral movement potential once initial access is achieved

  • Compliance validation — meeting PCI DSS, SOC 2, and other regulatory penetration testing mandates

Benefits for the User

  • Validates that security controls work in practice — not just in design

  • Identifies exploitable vulnerabilities missed by DAST and SAST

  • Provides board-level and auditor-ready evidence of real-world security posture

Last updated