Vulnerability states
Every finding in Musha has a state that reflects where it is in your remediation workflow.
States
| State | Meaning |
|---|---|
open | Newly detected, not yet triaged |
in_backlog | Acknowledged, will be fixed eventually |
in_progress | Someone is actively working on the fix |
resolved | Fixed: Musha confirmed the vulnerability is gone in a subsequent scan |
accepted | Risk accepted for a defined period (requires a reason + expiry date) |
false_positive | Confirmed not a real vulnerability in this context |
State transitions
| From | To | How |
|---|---|---|
open | in_backlog | Someone acknowledges the finding |
open, in_backlog | in_progress | Someone starts working on the fix |
open, in_backlog, in_progress | resolved | Automatic, on the next scan where the vulnerability is gone |
resolved | open | The vulnerability reappears in a later scan, or someone reopens it |
accepted and false_positive can be set from any active state. Both can be reopened if needed.
Who can change states
| Action | Roles |
|---|---|
Mark as in_progress | Member, Admin, Owner |
Mark as in_backlog, accepted, false_positive | Admin, Owner |
| Reopen | Admin, Owner |
| Auto-resolve (scan confirms vuln gone) | System |
Accept risk
When you accept a risk, you must provide:
- A reason (minimum length configurable in Settings > Scan Policy)
- An expiry date (required, maximum 1 year from today)
When the expiry date passes, the finding returns to open automatically. This prevents accepted risks from being forgotten indefinitely.
Assignment
Findings can be assigned to any team member. Assignees receive an in-app notification when:
- They are assigned a finding
- A finding assigned to them is resolved automatically by a scan
Members can only see and modify findings assigned to them. Admins and Owners see all findings.
History
Every state change is recorded in the finding's history with:
- Who made the change
- When it happened
- The reason (for
acceptedandfalse_positive) - A link to the scan that triggered the change (for automatic resolutions)
Automatic resolution
When a scan runs and a previously-detected vulnerability is no longer present (the dependency was updated, the misconfiguration was fixed, or the secret was removed), Musha automatically transitions it to resolved.
The resolution includes a link to the scan that confirmed the fix, so your team has an audit trail of when the vulnerability was remediated.