SAST-directed DAST. Test the finding at runtime.
Farion connects static analysis directly to dynamic testing. A SAST finding supplies the route, parameter, vulnerable operation, and data flow for a targeted test against the running application. The result returns to the same finding with runtime evidence.
Active Verification is enabled only after target ownership or explicit authorization has been verified.
Test the path identified in your code.
Endpoint discovery tells a scanner where it can send requests. Farion also knows what the static analysis found: the input involved, the operation it reaches, and the path between them. That context directs DAST toward a specific vulnerability hypothesis and makes the result relevant to an existing finding.
1. Start with the SAST finding
Use the finding’s route, affected parameter, vulnerable operation, and data flow to define what the dynamic test needs to check.
2. Configure the authorized target
Select the running application and environment to test. Confirm ownership or testing authorization and configure authentication for protected paths.
3. Generate and run a targeted test
Farion uses the static-analysis context to generate a test for that finding and execute it against the configured application. The code context guides the request and payload.
4. Review the runtime evidence
Inspect the payload, requests, responses, and observations alongside the original SAST finding. Review what the execution demonstrated and use the result in the same assessment and remediation workflow.
| Route Path | Exploitability | SCA | SAST | DAST | |
|---|---|---|---|---|---|
APIPOST/api/auth/login | 5/5 | 7 | 2 | 2 | |
A07:2021 – No rate limiting on authentication endpointCWE-307: Improper Restriction of Excessive Authentication Attempts DAST medium The /api/auth/login endpoint does not implement rate limiting or account lockout. An attacker can perform unlimited login attempts for credential brute-forcing. Target EndpointPOST https://shop.example.com/api/auth/login Attack DetailsPayloadEvidenceAll 100 requests returned HTTP 401 in ~0.8s avg response time with no rate limiting headers (X-RateLimit-*). No CAPTCHA or account lockout triggered. | |||||
APIGET/api/users | 4/5 | 7 | 2 | 1 | |
APIPUT/api/users/:id | 4/5 | 5 | 1 | 0 | |
APIDELETE/api/users/:id | 4/5 | 4 | 1 | 0 | |
APIGET/api/restaurants/…/menu | 3/5 | 5 | 1 | 0 | |
APIGET/api/restaurants/feed | 3/5 | 5 | 0 | 1 | |
APIPOST/api/payments/checkout | 3/5 | 3 | 1 | 0 | |
APIPOST/api/auth/reset-password | 3/5 | 3 | 1 | 0 | |
APIGET/api/users/…/profile | 2/5 | 2 | 1 | 0 | |
APIGET/api/admin/dashboard | 2/5 | 2 | 0 | 0 | |
APIPOST/api/orders | 1/5 | 1 | 1 | 0 | |
APIPUT/api/orders/…/status | 1/5 | 1 | 0 | 0 | |
APIGET/api/restaurants/:id | 1 | 0 | 0 | ||
APIGET/api/orders/…/track | 1 | 0 | 0 | ||
APIGET/api/search/export | 1 | 0 | 0 | ||
APIGET/api/orders | 1 | 0 | 0 | ||
APIGET/api/health | 0 | 0 | 0 | ||
APIGET/api/config/features | 1 | 0 | 0 | ||
Include protected application paths.
Configure authentication and application secrets for the authorized target. Farion can then test findings on protected routes in the context of the configured access.
Keep the result with the finding.
Static analysis identifies the suspected weakness. Dynamic testing adds observations from the running application. Both remain attached to the finding, so your team can review the code evidence and test result together.
Frequently asked questions
No. The test checks the hypothesis against the configured target. Its outcome must be read with the execution evidence, authentication, and environment. A test that does not reproduce a vulnerability is not by itself proof that the application is safe.
Yes. Configure authentication and secrets for an authorized target so the test can exercise protected application paths.
Active Verification runs against configured targets after ownership or explicit testing authorization has been verified.
Take a SAST finding into a dynamic test.
Walk through the code context, targeted execution, and resulting evidence with our team.