Exception Approval

scd-server provides a structured workflow for managing security exceptions — findings that a developer considers acceptable risk or a false positive. Exceptions require team lead or admin approval before they take effect.

Navigate here via Dashboard → Exceptions in the navbar.

---

The workflow

1. Developer runs scd accept <finding-id> --reason "..." or scd ignore <finding-id> --reason "..."
2. Exception is pushed to scd-server with status pending
3. Team lead or admin reviews in the exceptions page — approves or rejects with a reason
4. Developer runs scd sync to pull the decision
5. Next scan reflects the approved exception

---

Tabs

Tab	Shows
Pending	Exceptions awaiting a decision
Approved	Accepted risks and false positives
Rejected	Exceptions that were rejected — developer must fix
Resolved	Fixed findings where the exception is no longer active

---

Code hash binding

Every exception includes a hash of the relevant code line. If the code changes, the exception automatically reverts to pending and requires re-approval. This prevents exceptions from silently covering new or modified code.

---

Developer view

Developers see exception status in scd scan output and via scd exceptions --list all. Rejected exceptions show inline with the rejection reason:

⚠  1 rejected exception(s) — fix required:
   PHP-INJ-002  WS_addUser.php:10  [exc-mn7k96ml]
   Reason: This is a real injection risk — parameterize the query