HW Security Sign-Off
Purpose
Define the handoff contract between Foundry (builder) and Forge (security auditor) for hardware security sign-off. Ensure all security-critical design artifacts are delivered, reviewed, and approved before tape-out commitment.
Scope Constraints
Coordinates the handoff process between builder and auditor roles. Does not perform the security review itself (delegates to rtl-security-review, microarch-analysis, physical-design-security). Does not modify design files.
Inputs
- Design name and tape-out target date
- Security-critical modules identified by Foundry
- Trust boundary definitions
- Threat model (if available) or threat categories in scope
- Any prior security review findings
Input Sanitization
No user-provided values are used in commands or file paths. All inputs are treated as read-only analysis targets.
Procedure
Progress Checklist
Step 1: Verify Builder Artifact Delivery
Foundry must deliver the following before security review begins:
Reject handoff if any artifact is missing. Document gaps and return to Foundry.
Step 2: Validate Security Scope Agreement
- Confirm threat categories in scope (side-channel, fault injection, logical bypass, debug access).
- Agree on security-critical module boundaries (which modules are in-scope for full review).
- Define review depth per module: full RTL review, interface-only, or documentation review.
- Set severity classification: critical (blocks tape-out), high (requires mitigation plan), medium (accept with justification), low (track).
- Confirm timeline and review capacity.
Step 3: Coordinate Security Reviews
Dispatch to Forge specialist skills based on scope:
- rtl-security-review: Access control gates, FSM transitions, information leakage for all in-scope modules.
- microarch-analysis: Speculative execution, cache timing, branch predictor attacks if CPU/core is in scope.
- physical-design-security: Power domain isolation, clock domain security, layout-level leakage if physical design is available.
Track review progress per module and per skill.
Step 4: Track Finding Resolution
- Maintain finding tracker with: ID, module, category, severity, status, owner, target date.
- For each critical finding: Foundry implements fix, Forge re-reviews.
- For each high finding: Foundry provides mitigation plan, Forge approves plan.
- For each medium finding: Foundry documents accepted risk with justification.
- Verify all critical findings are resolved before sign-off.
Step 5: Issue Sign-Off Decision
- Approved: All critical/high findings resolved, no open blockers.
- Conditional approval: All critical resolved, high findings have approved mitigation plans with committed timelines.
- Blocked: Open critical findings or unresolved high findings without mitigation plans.
Document decision with: reviewer, date, scope covered, open items (if conditional), and next review trigger.
Compaction resilience: If context was lost, re-read the Inputs section for the design under review, check the Progress Checklist, then resume from the earliest incomplete step.
Output Format
Sign-Off Summary
| Field |
Value |
| Design |
... |
| Reviewer |
Forge |
| Date |
... |
| Decision |
Approved / Conditional / Blocked |
| Scope |
Modules A, B, C |
| Open items |
... |
Finding Tracker
| ID |
Module |
Category |
Severity |
Status |
Owner |
| F1 |
access_ctrl |
Bypass |
Critical |
Fixed |
Foundry |
| F2 |
debug_if |
Leakage |
High |
Mitigated |
Foundry |
Handoff
- Hand off to forge/rtl-security-review for detailed RTL security analysis.
- Hand off to forge/microarch-analysis for microarchitectural attack surface review.
- Hand off to foundry/chip-design-flow for design fixes required by findings.
Quality Checks
Evolution Notes
1---2name: hw-security-signoff3description: Use when a hardware design needs security sign-off before tape-out. Defines the builder-to-auditor handoff contract between Foundry (constructive design) and Forge (security review). Covers security review prerequisites, artifact checklist, sign-off criteria, and conditional approval workflow. Do not use for RTL security review itself (use rtl-security-review) or design flow guidance (use foundry/chip-design-flow).4---56# HW Security Sign-Off78## Purpose910Define the handoff contract between Foundry (builder) and Forge (security auditor) for hardware security sign-off. Ensure all security-critical design artifacts are delivered, reviewed, and approved before tape-out commitment.1112## Scope Constraints1314Coordinates the handoff process between builder and auditor roles. Does not perform the security review itself (delegates to rtl-security-review, microarch-analysis, physical-design-security). Does not modify design files.1516## Inputs1718- Design name and tape-out target date19- Security-critical modules identified by Foundry20- Trust boundary definitions21- Threat model (if available) or threat categories in scope22- Any prior security review findings2324## Input Sanitization2526No user-provided values are used in commands or file paths. All inputs are treated as read-only analysis targets.2728## Procedure2930### Progress Checklist31- [ ] Step 1: Verify builder artifact delivery32- [ ] Step 2: Validate security scope agreement33- [ ] Step 3: Coordinate security reviews34- [ ] Step 4: Track finding resolution35- [ ] Step 5: Issue sign-off decision3637### Step 1: Verify Builder Artifact Delivery3839Foundry must deliver the following before security review begins:4041- [ ] RTL source for all security-critical modules (final, synthesis-ready)42- [ ] Security-critical module list with trust boundary annotations43- [ ] Register map with access control policy per register44- [ ] FSM state diagrams for security-relevant state machines45- [ ] Clock domain crossing report46- [ ] DFT/scan chain documentation (which chains touch security logic)47- [ ] Debug interface specification (JTAG, trace ports)48- [ ] Known limitations or accepted risks documented4950Reject handoff if any artifact is missing. Document gaps and return to Foundry.5152### Step 2: Validate Security Scope Agreement5354- Confirm threat categories in scope (side-channel, fault injection, logical bypass, debug access).55- Agree on security-critical module boundaries (which modules are in-scope for full review).56- Define review depth per module: full RTL review, interface-only, or documentation review.57- Set severity classification: critical (blocks tape-out), high (requires mitigation plan), medium (accept with justification), low (track).58- Confirm timeline and review capacity.5960### Step 3: Coordinate Security Reviews6162Dispatch to Forge specialist skills based on scope:6364- **rtl-security-review**: Access control gates, FSM transitions, information leakage for all in-scope modules.65- **microarch-analysis**: Speculative execution, cache timing, branch predictor attacks if CPU/core is in scope.66- **physical-design-security**: Power domain isolation, clock domain security, layout-level leakage if physical design is available.6768Track review progress per module and per skill.6970### Step 4: Track Finding Resolution7172- Maintain finding tracker with: ID, module, category, severity, status, owner, target date.73- For each critical finding: Foundry implements fix, Forge re-reviews.74- For each high finding: Foundry provides mitigation plan, Forge approves plan.75- For each medium finding: Foundry documents accepted risk with justification.76- Verify all critical findings are resolved before sign-off.7778### Step 5: Issue Sign-Off Decision7980- **Approved**: All critical/high findings resolved, no open blockers.81- **Conditional approval**: All critical resolved, high findings have approved mitigation plans with committed timelines.82- **Blocked**: Open critical findings or unresolved high findings without mitigation plans.8384Document decision with: reviewer, date, scope covered, open items (if conditional), and next review trigger.8586> **Compaction resilience**: If context was lost, re-read the Inputs section for the design under review, check the Progress Checklist, then resume from the earliest incomplete step.8788## Output Format8990### Sign-Off Summary9192| Field | Value |93|-------|-------|94| Design | ... |95| Reviewer | Forge |96| Date | ... |97| Decision | Approved / Conditional / Blocked |98| Scope | Modules A, B, C |99| Open items | ... |100101### Finding Tracker102103| ID | Module | Category | Severity | Status | Owner |104|----|--------|----------|----------|--------|-------|105| F1 | access_ctrl | Bypass | Critical | Fixed | Foundry |106| F2 | debug_if | Leakage | High | Mitigated | Foundry |107108## Handoff109110- Hand off to forge/rtl-security-review for detailed RTL security analysis.111- Hand off to forge/microarch-analysis for microarchitectural attack surface review.112- Hand off to foundry/chip-design-flow for design fixes required by findings.113114## Quality Checks115116- [ ] All builder artifacts delivered and complete117- [ ] Security scope and threat categories agreed118- [ ] All security-critical modules reviewed by appropriate Forge skill119- [ ] All critical findings resolved120- [ ] All high findings resolved or have approved mitigation plans121- [ ] Sign-off decision documented with scope and conditions122123## Evolution Notes124<!-- Observations appended after each use -->