Skip to main content

​
Overview

Vulnerability tracking is central to Faction’s workflow. This guide covers adding vulnerabilities to assessments, using templates, creating custom findings, and managing vulnerability lifecycle from discovery to remediation.

​
Understanding Vulnerability Components

Each vulnerability in Faction consists of several key components:
  • Name: Short title identifying the vulnerability
  • Description: Detailed explanation of the security issue
  • Recommendation: Remediation guidance for developers
  • Details: Specific exploit information, steps to reproduce
  • Category: OWASP Top 10, CWE, or custom categorization
  • Risk Rating: Likelihood, Impact, and Overall risk scores
  • CVSS Scoring: CVSS 3.1 or CVSS 4.0 vectors and scores (if enabled)
  • Tracking ID: Unique identifier for remediation (format: VID-XXXX)
  • Custom Fields: Additional metadata specific to your workflow

​
Adding Vulnerabilities to an Assessment

1

Navigate to Assessment

Open the assessment from your queue or dashboard where you want to add findings.
2

Click Add Vulnerability

From the assessment view, select Add Vulnerability to create a new finding.
3

Choose a Template or Create Custom

You have two options:

​
Use a Vulnerability Template

Faction includes 75+ pre-populated vulnerability templates covering:
  • OWASP Top 10 vulnerabilities
  • Common web application flaws
  • API security issues
  • Mobile application vulnerabilities
  • Infrastructure weaknesses
Templates provide:
  • Pre-written descriptions
  • Standard remediation advice
  • Default risk ratings
  • Category assignments
  • Reference links (CWE, OWASP)
Start with a template and customize the details to your specific finding. This saves time while maintaining consistency.

​
Create a Custom Vulnerability

For unique findings not covered by templates:
  1. Select Create Custom
  2. Enter vulnerability details manually
  3. Set risk ratings and category
  4. Add custom exploit details
4

Configure Risk Ratings

​
Traditional Risk Scoring

If using custom risk levels (not CVSS):
  • Likelihood: How probable is exploitation?
  • Impact: What’s the potential business damage?
  • Overall: Combined risk severity (auto-calculated or manual)
Risk levels are customizable per organization (Critical, High, Medium, Low, Informational).

​
CVSS Scoring

If the assessment type uses CVSS 3.1 or CVSS 4.0:
  1. Enter the CVSS Vector String (e.g., CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
  2. Enter the CVSS Score (0.0 - 10.0)
  3. Overall risk is automatically mapped from score:
    • 9.0-10.0 = Critical
    • 7.0-8.9 = High
    • 4.0-6.9 = Medium
    • 0.1-3.9 = Low
5

Add Exploit Details

Document the technical details in the Details section:
  • Steps to reproduce
  • HTTP requests/responses
  • Proof-of-concept code
  • Affected parameters or endpoints
  • Screenshots or video evidence
The details section supports HTML formatting and can include embedded images uploaded to the assessment.
6

Customize for This Finding

Even when using templates, customize:
  • Description Notes: Add assessment-specific context
  • Recommendation Notes: Tailor fix guidance to the application
  • Detail Notes: Include specific evidence
Notes are merged with template content in the final report.
7

Set Category and Section

  • Category: Assign OWASP, CWE, or custom category for report grouping
  • Section: Organize vulnerabilities into custom report sections (if enabled)
Sections allow grouping findings by:
  • Application component (Web, API, Mobile)
  • Testing phase (External, Internal, Post-Auth)
  • Custom organization
8

Review Tracking ID

Each vulnerability is automatically assigned a unique tracking ID:
VID-1234
This ID:
  • Persists across remediation and retests
  • Links to verification workflows
  • Appears in remediation queue
  • Tracks closure in dev and production
Development teams can reference tracking IDs in their issue trackers (Jira, GitHub Issues) for cross-system correlation.
9

Save the Vulnerability

Click Save to add the vulnerability to the assessment. It will appear in:
  • Assessment vulnerability list
  • Risk analysis dashboard
  • Report preview

​
Vulnerability Status Tracking

Faction tracks two closure states for each vulnerability:

Development Environment

Dev Closed DateSet when the fix is implemented in development/staging. Indicates readiness for verification testing.

Production Environment

Production Closed DateSet when the fix is deployed to production and verified. This is the official closure date for SLA tracking.

​
Status Workflow

  1. Opened: Vulnerability discovered and added to assessment
  2. In Remediation: Assessment finalized, vulnerability assigned to remediation team
  3. Dev Closed: Fix implemented in development environment
  4. Verification Scheduled: Retest scheduled for the fix
  5. Production Closed: Fix verified and deployed to production
Only the Production Closed date stops SLA alerts. A vulnerability closed in dev but not production will continue triggering warnings.

​
Collaborative Editing with Section Locks

To prevent editing conflicts, Faction implements section-level locking:
  • Description Lock: Prevents simultaneous edits to description field
  • Recommendation Lock: Locks recommendation section
  • Details Lock: Locks exploit details section
When a user begins editing a section:
  1. Lock is automatically acquired
  2. Other users see who has the lock and timestamp
  3. Lock releases when editing completes or times out

​
Tracking ID for Remediation

The auto-generated tracking ID (VID-XXXX) serves multiple purposes:
  • Unique Identification: Distinguishes vulnerabilities across assessments
  • Retest Correlation: Links original finding to verification results
  • Historical Tracking: Tracks vulnerability recurrence across assessments
  • External Integration: Reference in external ticketing systems

​
Vulnerability History

Faction maintains complete history for each vulnerability:
  • When it was opened (discovered)
  • When it was closed in dev
  • When it was closed in production
  • All verification/retest results
  • Historical presence in previous assessments
The assessment view shows vulnerability history across all assessments for the same App ID, helping identify recurring issues.

​
Screenshots and Evidence

Add visual evidence to vulnerabilities:
  1. Upload images to the assessment’s file repository
  2. Reference images in vulnerability details using HTML
  3. Images are embedded in generated reports
  4. Supports PNG, JPG, GIF formats

​
Using the Burp Suite Extension

The Faction Burp Extension enables real-time vulnerability creation:
  1. Install extension in Burp Suite
  2. Configure Faction server connection
  3. Right-click HTTP request/response in Burp
  4. Select Send to Faction
  5. Vulnerability is created with request/response details pre-populated

​
Custom Vulnerability Fields

Add custom metadata to vulnerabilities:
  • Affected endpoints or parameters
  • Business impact ratings
  • Compliance framework mappings
  • Testing methodology used
  • Custom severity modifiers

​
Best Practices

Use Consistent Naming

Start with vulnerability type, then location: “SQL Injection in Login Form”

Leverage Templates

Use templates for common findings to ensure consistency and save time.

Include Reproduction Steps

Always provide clear steps in Details so developers can reproduce the issue.

Add Proof of Concept

Include screenshots, requests, or exploit code to demonstrate impact.

Set Accurate Risk Ratings

Consider both likelihood and impact when rating vulnerabilities.

Track Recurrence

Check vulnerability history to identify recurring security issues.

Creating Assessments

Set up new security assessments

Remediation Workflow

Schedule retests and verify fixes

Custom Templates

Customize report output format

API Reference

Automate vulnerability management

Build docs developers (and LLMs) love

Get started for freeTalk to us