Notifications
Clear all
Topic starter
18/08/2026 2:24 pm
TL;DR: Sigma Computing says most DAST tools missed GraphQL-specific vulnerabilities and internal endpoints until it moved to schema-first, in-cluster scanning with Escape, which produced verifiable findings and faster triage. The underlying lesson is that API security fails when crawling, not exploitation evidence, defines coverage.
NHIMG editorial — based on content published by Escape: Sigma Computing's GraphQL-native DAST case study
Questions worth separating out
Q: How should security teams test GraphQL APIs in CI/CD?
A: They should trigger targeted scans from schema changes, not from a fixed weekly cadence.
Q: Why do REST-based crawlers miss risk in GraphQL applications?
A: REST-based crawlers infer coverage from paths, but GraphQL risk lives in schema structure, nested fields, and mutation logic.
Q: What breaks when internal endpoints are only tested from outside the cluster?
A: Private services, staging workloads, and internal-only interfaces can remain invisible, which means the security team gets a false sense of coverage.
Practitioner guidance
- Map DAST coverage to GraphQL schema changes Trigger focused scans whenever new queries or mutations are introduced, and verify that the scanner can reason over recursive schema paths rather than only discovered URLs.
- Place scanners inside the workload boundary Deploy testing in-cluster for private services and staging environments so internal endpoints, service-to-service paths, and non-public interfaces are exercised directly.
- Require exploit evidence before triage Only open high-priority tickets when the finding includes a reproducible payload, request trace, and response evidence that prove reachability and impact.
What's in the full article
Escape's full case study covers the operational detail this post intentionally leaves for the source:
- Per-scan logs, payload traces, and rule outputs that show how findings were validated in practice
- Configuration details for in-cluster deployment across Kubernetes regions and the operational trade-offs involved
- Examples of GraphQL-specific issues such as alias batching and denial-of-service behaviour
- The team's internal workflow for ranking findings and reducing false positives before tickets are created
👉 Read Escape's case study on GraphQL-native DAST coverage at Sigma Computing →
Graphql-native DAST: what it means for API security teams?
Explore further
18/08/2026 3:15 pm
GraphQL-native testing is now a coverage requirement, not a niche preference. REST-first crawlers fail when the real object of testing is the schema, nested query behaviour, and mutation logic. That shifts the security question from "did we scan the application" to "did we exercise the application in the way attackers can." For API-heavy programmes, schema awareness is becoming a baseline control expectation.
A question worth separating out:
Q: Which governance controls matter most when DAST produces lots of findings?
A: The key controls are evidence quality, prioritisation logic, and identity hygiene around the systems being tested. Findings should include reproducible payloads and request traces, and teams should correlate them with default credentials, stale test environments, and over-permissioned service access. That combination turns noisy scanning into decision-ready security work.
👉 Read our full editorial: Graphql-native DAST exposes gaps in api coverage and triage
