Fewer arguments over noise
A static finding confirmed at runtime will move from probable to proven, so developers can spend time fixing rather than disputing. Read reducing SAST false positives without hiding real bugs.
Coming soon
Connect application requests
to code-level evidence.
Add runtime context to application testing. Follow exercised code paths, investigate observed data flows and give developers evidence they can use to reproduce and resolve issues.
Instrumented request
Incoming request
Executed code path
Runtime observation
Investigation context
01 / Define coverage
Agree where instrumentation belongs.
- Runtime scope
- Instrumentation requirements
Discuss supported runtimes and the application paths your evaluation needs.
02 / Trace execution
Connect a request to its code path.
- Request context
- Executed path
Evaluate the intended relationship between runtime observation and source evidence.
03 / Review evidence
Make the observation useful to a developer.
- Source reference
- Evaluation evidence
Define the runtime evidence required for a meaningful investigation.
Taint
Runtime data flow
Parameter to sink, frame by frame.
Routes
Live route discovery
The endpoints your application really serves.
SAST
Static confirmation
Runtime evidence will raise static confidence.
RASP
Runtime protection
Same agent, blocking mode.
The category
What is IAST?
Static analysis can over-report, because it cannot always tell whether a flow is reachable. Dynamic testing can under-explain, because it sees the response but not the code. IAST resolves both by instrumenting the application itself. When a test request carries input into a SQL statement, a file path or an HTML response without the right sanitisation, the agent records the source parameter, the taint path and the sink method. The result is a finding that is both proven at runtime and located in code, so a developer knows exactly where the fix belongs.
Instrumented application
Define the application and test environment.
Executed path
Observe the code reached during a test.
Runtime evidence
Associate the observed execution with the finding.
Designed workflow: coverage depends on the paths exercised during testing.
Testing methods
How does IAST compare with SAST and DAST?
Each method sees the application from a different vantage point. Used together, they cover each other's blind spots.
| Area | SAST | DAST | IAST |
|---|---|---|---|
| Vantage point | Source code, at rest | Outside the running application | Inside the running application |
| Needs a running app | No | Yes | Yes, with tests exercising it |
| Shows the code location | Yes | No | Yes |
| Proves reachability | Not on its own | Yes | Yes |
| Typical stage | Pull request and pipeline | Staging and production | Functional and automated testing |
| In SecurityVault | Available today | Available today | Discuss rollout |
The design
What will the IAST agent record and do?
Agents
Agents for Java, Python and Node.js, with .NET to follow, will register with your organisation, report their health and receive their configuration centrally.
Runtime taint
Each runtime taint trace will become a normalised finding with the HTTP method, URL, source parameter, taint path, and sink class and method.
Route discovery
The routes the application actually serves will be recorded at runtime, along with the code paths your tests exercise, so untested critical paths become visible.
Correlation
RASP
In protection mode, the agent will block attacks with rules that normalise encoded payloads before matching and recognise safe contexts such as a parameterised query.
Outcomes
How will runtime proof change triage?
01
02
Priority from exposure
Linked to the image and workload it ran in, a confirmed injection will be ranked by whether that workload is reachable from the internet and which cloud permissions it holds.
03
Gates with confidence
Runtime confidence is designed to flow into the fail-closed deployment gates that already decide releases, with an owner and a deadline on every finding.
FAQ
IAST questions.
- What is the difference between IAST, SAST and DAST?
- SAST reads source code without running it. DAST probes the running application from outside. IAST sits inside the running application and sees both the request and the code path it took. SecurityVault ships SAST and DAST today; IAST is designed to confirm and connect the two.
- Which languages is SecurityVault's IAST designed for?
- Java and other JVM languages, Python and Node.js first, with .NET to follow. Configuration will be delivered centrally to each agent when it registers.
- What is the difference between IAST and RASP?
- IAST observes and reports a vulnerable flow, usually in test environments. Runtime application self-protection (RASP) uses the same in-process vantage point to block an attack as it happens. SecurityVault's agent is designed to run both modes, with the mode set per deployment.
- Will IAST create duplicate findings next to SAST and DAST?
- No. A runtime finding is designed to be matched to the static finding for the same weakness and code location, raising its confidence and linking the two, rather than opening a second record.
- When will IAST be available?
- IAST is in development. Check your runtime and instrumentation requirements with our team before planning an IAST trial.
Available today: static analysis (SAST) · dynamic testing (DAST) · API security. Further reading: SAST taint analysis explained. Built for AppSec teams and developers.
Discuss your requirements
Tell us which applications you test.
Discuss the application runtime, test environment and instrumentation constraints for your IAST requirements.