Web Application Vulnerability Tracker
A record of vulnerabilities found through DAST scans and penetration tests against running web applications, and their remediation status.
I. Overview
%%{init: { 'theme': 'base', 'themeVariables': { 'edgeLabelBackground': '#fff' }}}%%
flowchart LR
A["Pentest and scan findings\ndelivered as a report, then forgotten"] -- "Need for tracked, verifiable\nremediation of runtime findings" --> B["Formal Web Application\nVulnerability Tracker"]
style A fill:#f9f9f9,stroke:#333,stroke-width:3px
style B fill:#e1f5fe,stroke:#01579b,stroke-width:3px
Definition: A Web Application Vulnerability Tracker records findings from dynamic testing against a running application — DAST (Dynamic Application Security Testing) scans, penetration tests, and bug bounty reports — covering classes like SQL injection, XSS, CSRF, and broken access control.
Features:
( Ownership ) Maintained by the AppSec team, who coordinate remediation with the engineering team that owns the affected service.
( Black-Box Coverage ) Exists because black-box testing surfaces exploitable conditions that source-level review can miss — authentication bypasses and business-logic flaws.
( Runtime Focus ) Captures issues that only manifest once the application is deployed and reachable.
( Prevents Forgotten Findings ) Without a tracker, findings from a pentest engagement risk becoming a one-time PDF that no one revisits.
II. Structure & Process
sequenceDiagram
participant Test as "DAST Scan / Pentester"
participant AppSec as "AppSec Team"
participant Dev as "Owning Engineering Team"
participant Lead as "AppSec Lead"
Test->>AppSec: "Report vulnerability with proof of concept"
AppSec->>AppSec: "Validate finding and assign severity"
AppSec->>Dev: "Log entry and assign remediation deadline"
Dev->>Dev: "Implement fix (e.g. parameterized query, output encoding)"
Dev->>AppSec: "Request retest"
AppSec->>Test: "Re-run scan or manual verification"
AppSec->>Lead: "Escalate any SLA breaches"
| Field | Description |
|---|---|
| Application / URL | Target application or endpoint where the finding occurred |
| Vulnerability Class | e.g. SQL Injection, XSS (Stored, Reflected, or DOM-based), CSRF, Broken Access Control |
| Discovery Source | DAST scan, manual penetration test, or bug bounty submission |
| Severity | CVSS score or equivalent risk rating |
| Proof of Concept | Steps or payload demonstrating the exploit, stored securely |
| Status | Open, In Remediation, Retested, or Closed |
| Remediation Deadline | SLA-driven date based on severity |
| Owner | Engineering team responsible for the affected application |
Findings are logged as scans and engagements complete; the tracker is reviewed weekly by AppSec and formally audited after each scheduled penetration test.
III. Best Practices & Comparison
| Document | Primary Purpose | Update Cadence | Owner |
|---|---|---|---|
| Web Application Vulnerability Tracker | Track exploitable runtime findings from DAST and pentesting | Per scan / pentest cycle | AppSec |
| Static Code Analysis Log | Source-level findings from SAST, complementary white-box view | Per build / commit | AppSec + Engineering |
| Secure Coding Checklist | Preventive standard that reduces recurrence of the same finding classes | Per pull request | AppSec + Engineering |
| OWASP Top 10 | Reference taxonomy most findings are classified against | On standard revision | AppSec |
- Store every proof of concept and payload in a restricted-access location, never in a general ticket visible to all staff.
- Map each finding to its OWASP Top 10 category to spot which vulnerability classes recur most often.
- Retest every fix against the original proof of concept before marking a finding closed, not just against the ticket description.
- Run DAST scans continuously against staging, not only during scheduled pentest windows.
- Feed recurring finding classes back into the Secure Coding Checklist and SAST ruleset to prevent reintroduction.
Last updated 18 Aug 2026, 00:00 UTC.