Create Vulnerability Events
Track vulnerability lifecycle with events. Record assessments, decisions, and actions taken on vulnerabilities to maintain a complete audit trail for compliance and remediation tracking.
Prerequisites
Before you begin, ensure you have:
- Access to a DevGuard organization, project, and asset
- Read access to vulnerabilities in your asset
- Write access to create events (typically Owner or Admin role)
- Identified which vulnerability you want to document
Event Types
DevGuard supports these vulnerability events:
| Event | Purpose | When to Use |
|---|---|---|
| Accepted | Document a deliberate risk acceptance | You’ve assessed and accepted the risk |
| False Positive | Mark the vulnerability as not applicable | The vulnerability doesn’t affect your code or environment |
| Fixed | Record vulnerability remediation | You’ve fixed the vulnerability in code |
| Reopened | Reopen a closed vulnerability | An accepted/false positive requires re-evaluation |
| Mitigate | Create a ticket for remediation | You’re creating a tracking issue for the team |
| Comment | Add notes without changing status | You need to provide context or updates |
Create an Event
Via Web UI
-
Navigate to Organization → Project → Repository → Vulnerabilities
-
Click on a vulnerability to open its details
-
In the Events section at the bottom, you’ll see the event history
-
Select an action from the available options:
- Accept Risk: Mark as intentionally accepted
- False Positive: Mark as not applicable
- Create Ticket: Open a mitigate event
- Reopen: Reopen if previously marked as false positive or accepted
- Add Comment: Document additional context
-
Provide required information:
- Justification: Explain your decision
- Mechanical Justification (for false positives): Select the reason
-
Click Save
The event is recorded immediately with your user ID and timestamp.
Event Timeline
The Events section shows a complete audit trail:
- Detected: When DevGuard first discovered the vulnerability
- User Actions: All manual events (accepted, reopened, fixed, etc.) with user ID and timestamp
- Automatic Updates: Risk score recalculations and system events
This timeline is included in compliance reports (CSAF) and supports regulatory audits.
Best Practices
Document Decisions
Every event should explain the decision made:
- Acceptance: Explain business impact and mitigations
- False Positive: Specify which reason applies
- Reopened: Explain what changed
- Fixed: Mention the patch or update version
Regular Review
- Review accepted vulnerabilities monthly
- Reopen if circumstances change
- Follow up on open tickets
- Close events only when truly fixed