Overview
Faction’s remediation workflow helps security and development teams coordinate vulnerability fixes, schedule verification testing, and track closure status. This guide covers the complete remediation lifecycle from assessment finalization through verified production fixes.Remediation Lifecycle
The vulnerability remediation process follows these stages:Assessment Finalization
When an assessor finalizes an assessment:
- Assessment status changes to “Complete”
- All vulnerabilities are marked with an Opened date
- Vulnerabilities enter the remediation queue
- SLA tracking begins automatically
- Remediation contacts receive notification
The opened date triggers SLA countdown timers based on risk severity.
Remediation Queue
Vulnerabilities appear in the remediation queue, prioritized by:
- Risk severity (Critical, High, Medium, Low)
- SLA due dates and warnings
- Days open
- Application priority
- View all open vulnerabilities
- Filter by severity, application, or team
- Track fix progress
- Schedule verification testing
Development Closure
When a fix is deployed to development/staging:
- Development team marks vulnerability as Closed in Dev
- Dev Closed date is recorded
- Vulnerability becomes eligible for verification
- SLA warnings continue (dev closure doesn’t stop SLA)
Verification Scheduling
Remediation contact schedules a retest:
- Select vulnerabilities for verification
- Assign an assessor for retesting
- Set start and end dates for verification window
- Add notes or special instructions
- Notification sent to assigned assessor
Verification Testing
Assigned assessor performs retest:
- Reviews original vulnerability details
- Tests the fix in the target environment
- Documents verification results
- Marks as Pass or Fail
If Verification Passes
- Vulnerability is marked closed in production
- Production Closed date recorded
- SLA tracking stops
- Success notification sent
If Verification Fails
- Vulnerability remains open
- Assessor documents why fix was insufficient
- Development team notified
- New fix cycle begins
Understanding the Remediation Queue
The remediation queue displays all open vulnerabilities with actionable information:Queue Columns
- Application ID: Target application identifier
- Application Name: Full application name
- Vulnerability: Finding name
- Severity: Risk rating (Critical/High/Medium/Low)
- Opened: Date vulnerability was discovered
- Due Date: SLA deadline for remediation
- Status Badges: Visual indicators for urgency
Status Badges
Vulnerability Past Due (Red)
Vulnerability Past Due (Red)
SLA deadline has passed. Immediate attention required.
Vulnerability Approaching Due Date (Yellow)
Vulnerability Approaching Due Date (Yellow)
Within warning window of SLA deadline. Fix should be prioritized.
Verification Past Due (Red)
Verification Past Due (Red)
Scheduled verification window has closed but retest not completed.
Verification Almost Due (Yellow)
Verification Almost Due (Yellow)
Verification deadline approaching (within 2 days).
In Retest (Green)
In Retest (Green)
Verification is currently in progress by assigned assessor.
Verification Passed (Green)
Verification Passed (Green)
Fix verified successfully. Ready for production closure.
Verification Failed (Red)
Verification Failed (Red)
Fix was insufficient. Requires additional development work.
Verification Cancelled (Yellow)
Verification Cancelled (Yellow)
Verification was cancelled. May need rescheduling.
SLA Warnings and Alerts
Faction automatically calculates SLA deadlines based on:- Vulnerability Severity: Higher severity = shorter SLA
- Opened Date: SLA countdown starts when assessment is finalized
- Organization Settings: Customizable SLA periods per severity
Default SLA Periods (Customizable)
| Severity | Due Date | Warning Window |
|---|---|---|
| Critical | 7 days | 2 days before due |
| High | 30 days | 5 days before due |
| Medium | 90 days | 14 days before due |
| Low | 180 days | 30 days before due |
SLA Configuration
Admins can customize SLA periods in Settings > System Settings:- Set due date periods for each severity level
- Configure warning windows (when yellow badges appear)
- Enable/disable email notifications for SLA events
- Set notification recipients
Scheduling Verifications
Access Remediation Module
Navigate to Remediation > Schedule Verification with remediation permissions.
Search for Assessment
Enter the Application ID to find the assessment containing vulnerabilities to verify.
You can also navigate directly from a vulnerability in the remediation queue.
Select Vulnerabilities
Choose which vulnerabilities to include in this verification:
- Single vulnerability per verification (recommended)
- Multiple related vulnerabilities (if fixed together)
Assign Assessor
Select the assessor who will perform the retest:
- Original assessor (knows the finding)
- Available team member
- Specialist for specific vulnerability types
Assign Remediation Contact
Designate who coordinates the remediation:
- Development team lead
- DevOps engineer
- Product owner
- Security liaison
Set Verification Window
Define when verification should occur:
- Start Date: When the assessor can begin testing
- End Date: Deadline for verification completion
- Assessor to review original findings
- Perform thorough retesting
- Document results
Update Distribution List
Add or modify email addresses for notifications:
- Development team members
- Product stakeholders
- Management for high-severity issues
Add Verification Notes
Include any special instructions:
- Testing credentials or access
- Specific environments to test
- Areas of concern
- Context about the fix
Assessor Verification Process
When an assessor receives a verification assignment:Accessing Verifications
- Navigate to Remediation Queue or My Verifications
- View assigned verifications with status badges
- Click verification to see details
Reviewing Verification Details
- Original Vulnerability: Full details of initial finding
- Tracking ID: Unique identifier linking to original
- Assessment Info: Application ID, name, assessment date
- Fix Context: Notes from remediation contact
- Verification Window: Start and end dates
Performing the Retest
Review Original Finding
Study the original vulnerability:
- Description and exploit details
- Steps to reproduce
- Affected components
- Risk context
Test the Fix
Attempt to reproduce the original vulnerability:
- Follow original reproduction steps
- Test edge cases and variations
- Verify fix doesn’t introduce new issues
- Confirm fix is in the correct environment
Document Results
Record detailed findings:
- What was tested
- Results of each test
- Screenshots or evidence
- Conclusion (Pass/Fail)
Dev vs. Production Closure Tracking
Faction tracks two distinct closure states:Development Closure
Purpose: Indicates fix is ready for verification- Set when fix deployed to dev/staging
- Enables verification scheduling
- Does NOT stop SLA tracking
- Tracked via
devClosedfield in Vulnerability.java (line 57)
Production Closure
Purpose: Indicates verified fix is in production- Set when verification passes
- Stops SLA tracking
- Removes from remediation queue
- Official vulnerability closure
- Tracked via
closedfield in Vulnerability.java (line 54)
This two-stage tracking ensures fixes are verified before being considered truly remediated, preventing premature closure of vulnerabilities.
Remediation Queue Filters
Filter the queue to focus on specific vulnerabilities:- By Severity: Show only Critical/High issues
- By Application: Filter to specific app or business unit
- By Status: Open, In Verification, Past Due
- By Assigned Contact: Your assigned vulnerabilities only
- By Team: Team-specific remediation items
View All vs. Assigned Only
Remediation users can toggle:- Assigned to Me: Only verifications where you’re the remediation contact
- All: Every open vulnerability (if permissions allow)
Verification Workflow States
Verifications progress through workflow states:| State | Description |
|---|---|
In Assessor Queue | Scheduled but not started |
Assessor Completed | Testing finished, results recorded |
Assessor Cancelled | Verification was cancelled |
Updating Vulnerability Open Dates
In some cases, you may need to adjust when a vulnerability’s SLA tracking begins:- Access the verification or vulnerability details
- Select Update Open Date
- Set new opened date
- SLA calculations adjust automatically
Email Notifications
Faction sends automated emails for remediation events:- Assessment Finalized: Vulnerabilities opened
- Verification Scheduled: Assigned assessor and contacts notified
- Verification Updated: Schedule or details changed
- Verification Completed: Results available
- SLA Warnings: Approaching due dates
- SLA Breaches: Past due vulnerabilities
Best Practices
Regular Queue Reviews
Check the remediation queue daily to identify new past-due or approaching items.
Prompt Verification Scheduling
Schedule verifications as soon as dev closure is confirmed to maintain momentum.
Clear Communication
Use verification notes to provide context and expectations to assessors.
Track Recurrence
Monitor vulnerabilities that fail verification multiple times - may indicate deeper issues.
Prioritize by Risk
Focus on Critical and High severity vulnerabilities first to reduce risk exposure.
Document Failures
When verification fails, provide detailed feedback to help developers fix properly.
Integration with External Systems
Use Faction’s Extension system to:- Jira Integration: Auto-create Jira tickets for open vulnerabilities
- Slack/Teams Notifications: Real-time alerts for SLA events
- Ticketing Systems: Sync status with external tracking
- Metrics Dashboards: Export remediation data to BI tools
The Jira Integration extension is available in the Faction App Store (introduced in version 1.2).
Related Resources
Vulnerability Tracking
Understanding vulnerability lifecycle
Team Management
Assign remediation contacts and permissions
Creating Assessments
Set up assessments that feed remediation
API Reference
Automate remediation workflows via API