Lightning
A focused look at the application’s front door.
- Headers, cookies, and transport
- Reads the entry page
- No active payloads
DAST / Active Testing
Test your apps.
Prove the fix.
Turn application security findings into evidence you can act on.
Verify your domain. Test your running application. See what was found, make the fix, and retest it—all in RiskAssure.
Built for verified domains and authorized testing.
FROM FINDING TO FOLLOW-THROUGH01 — 03
WORK FROM THE EVIDENCE
Every finding. A next step.
Content-Security-Policy needs attention
https://portal.example.com/
CAPTURED EVIDENCE
The response policy permits inline scripts. The captured header is attached to this finding.
RECOMMENDED ACTION
Review script requirements and tighten the policy. Use nonces or hashes for trusted inline scripts.
Confirmed
Interactive example · Synthetic findings · No scan is started
Evidence. Remediation. Retest.
Verify domain ownership Review captured evidence Retest individual findings Share with access control
01 / A clear path to resolution
A finding is the start.
Follow it through.
Bring testing, remediation, and security evidence into the same workflow. Give each result a next step and the context your team needs to review it.
- 01
Verify & scope
Prove domain control with DNS or a web-root file. Choose your target and testing mode.
Ownership comes first - 02
Test & review
Inspect the affected URL, captured evidence, severity, and remediation for each finding.
Evidence with every finding - 03
Fix & retest
Make the change, then retest the individual finding to see whether it still appears.
Close the loop on the issue - 04
Report & share
Export a report, save it to Documents, or share the assessment through your Trust Center.
You control access
02 / Choose your testing depth
The right test.
For the right scope.
Start with entry-page posture or choose an active pass. Each mode makes its approach clear before you run it.
Safe
A bounded active test of the application.
- Active test inputs
- Constrained scan budgets
- Evidence and coverage reporting
Normal
A deeper crawl and a wider active pass.
- Broader application exploration
- Active checks across reached surfaces
- Evidence and coverage reporting
Run within your authorized scope. Plan active tests with the application owner; the selected mode does not guarantee zero disruption.
03 / Context you can trust
Know what the
test actually reached.
A useful security result includes its limits.
See reached pages, forms, parameters, requests, and skipped links. Review which checks ran and which surfaces remain untested.
01
Confirmed findings carry evidence.Review the affected URL, captured behavior, and the recommended fix. CWE, OWASP, and CVSS context appears where available.
02
Unconfirmed observations stay separate.Items labeled “Detected, not demonstrated” give reviewers a lead without presenting it as a proven issue.
03
Limited reach means limited conclusions.Blocked or insufficient-coverage scans are inconclusive and unscored.
COVERAGE REPORTIllustrative
portal.example.comNormal · Authorized scope
- Pages reached
- 24
- Forms found
- 3
- Parameters
- 18
Entry-page headersTested
Discovered formsTested
External linksSkipped
Unreached routesNot tested
Coverage is part of the result.Conclusions apply to the surface this test reached.
04 / From technical proof to buyer trust
Keep the evidence.
Control the audience.
Put your testing work to use in a security review. Keep a report in Documents, send a PDF or HTML export, or make the assessment discoverable in your Trust Center.
Explore the RiskAssure Trust CenterASSESSMENT SHARING
Active Testing report
Illustrative Trust Center entry
Request required
Visitors ask for access.
You decide who can view the findings.
PDFHTMLDocuments
A few useful details
Before you test.
Scope, evidence, and access.
Here’s how the pieces fit.
What is dynamic application security testing (DAST)?
DAST examines a running web application from the outside to identify security weaknesses in its responses and behavior. RiskAssure Active Testing brings the resulting evidence, remediation guidance, coverage, and retests into one workflow. It complements code review and manual security testing; it does not replace a penetration test.
Which domains can I test?
Test only applications you own or are explicitly authorized to assess. Before scanning, verify domain control through a DNS TXT record, a DNS CNAME record, or a verification file at the web root. Domain verification is a prerequisite to the testing workflow.
How do Lightning, Safe, and Normal differ?
Lightning reads the entry page’s headers, cookies, and transport without sending active payloads. Safe and Normal perform active testing, with Normal using a deeper crawl and a wider active pass. Choose a mode appropriate to your authorized scope and environment. Active testing can affect an application, so plan the test with its owner.
What happens if the scanner cannot reach enough of the application?
Blocked scans or scans with insufficient coverage are reported as inconclusive and unscored. The report shows what was reached and what was skipped or not tested, so a limited scan is not mistaken for evidence that the application is secure.
Can I check that a finding has been fixed?
Yes. Per-finding retests let you revisit a reported issue after remediation. Review the new evidence and result alongside the original finding. A successful retest describes that issue within the tested scope; it does not establish the security of the entire application.
How can I share the results?
Export a PDF or HTML report, or save it to Documents. You can optionally show the assessment in your Trust Center. Sharing defaults to Request required: visitors can see that an assessment exists and ask for access, while the findings remain behind that access decision.
Make your next fix a verified one
From “we fixed it”
to evidence you can show.
See the Active Testing workflow in RiskAssure.