| name | defender |
| description | Blue-team release-gate analysis for smart contract deployment and upgrade readiness. Classifies repositories, checks deploy/upgrade execution paths, CI/CD trust boundaries, config drift, secrets/signer operational security, and outputs evidence-backed release verdicts. |
Defender
A blue-team release-gate skill for smart contract systems.
Defender determines whether a repository is safe to deploy or upgrade. It focuses on release execution risk, not exploit discovery.
Use when
- deploying smart contracts
- preparing upgrades
- reviewing deploy scripts
- hardening CI/CD
- rotating admin roles
- validating ownership handoff
- enforcing release hygiene
Non-goals
Defender does NOT replace:
- full security audits
- economic analysis
- invariant discovery
- deep proxy vulnerability analysis (
proxy-upgrade-safety)
It focuses only on execution safety of release.
Core rule
Evidence first.
Only report findings from:
- contracts
- deploy scripts
- CI workflows
- dependency manifests
- configs / address books
- tests / fork scripts
- docs / runbooks
Separate:
- Detection → what repo proves
- Policy → what should be enforced
Execution order (STRICT)
- Project classification
- Defence pass
- Severity scoring
- Release verdict
Reference packs
Always load:
references/finding-catalog.mdreferences/severity-model.mdreferences/evidence-query-playbook.md
Load contextually:
- classification →
project-classification.md
- CI →
ci-supply-chain.md
- deploy drift →
config-drift-checks.md
- upgrade →
upgrade-readiness.md
- signer →
signer-opsec.md
- false confidence →
false-confidence.md
- post-deploy →
post-deploy-validation.md
Templates:
defender-report-template.md- checklist templates as needed
Phase 1 — Project classification
Framework
Detect:
- Foundry / Hardhat / hybrid / other
Evidence:
foundry.toml, hardhat.config.*, scripts
Language
- Solidity / Vyper / Cairo / mixed
Upgradeability
- upgradeable / immutable / mixed
Evidence:
- OZ upgrade imports
- proxies
- initializer usage
Protocol type
Infer:
- token / vault / AMM / lending / bridge / governance / NFT / staking / other
Deployment surface
- manual / script / CI / multisig / upgrade-task
CI surface
- GitHub Actions / GitLab / other / none
Output classification block.
Phase 2 — Defence pass
A. Build integrity
Check:
- compiler version pinned
- optimizer pinned
- evmVersion consistency
- lockfiles committed
- no conflicting configs (Foundry vs Hardhat)
- artifacts reproducible from repo
- verification metadata aligned
Escalate if:
- build settings differ from verification
- configs produce ambiguous outputs
B. Dependencies, secrets, supply chain
Check:
- committed secrets
.env usage for private keys- floating versions
- unpinned git deps
- install scripts
- dependency confusion risk
- abandoned/suspicious packages
- OZ version mismatch
- unsafe sidecar tooling
- unverified binaries
Secret policy
Plaintext .env private keys are discouraged.
Preferred:
- Foundry keystore-backed accounts
Classify:
- private key in repo → BLOCKER/HIGH
- deploy scripts using plaintext env keys → HIGH
.env for non-sensitive config → acceptable
C. CI/CD trust
Check:
- unpinned GitHub Actions
- secrets in untrusted workflows
- deploys from weak branches
- no approval gate
- excessive secret access
- curl/bash installs
- unsafe runners
- mixed trust zones
Escalate if CI can deploy unsafely.
D. Deployment config drift
CRITICAL
Check:
- chain ID matches target
- RPC matches chain
- deployer is correct
- constructor/initializer args final
- addresses (oracle/token/admin) valid for chain
- no test/stale addresses
- decimals correct
- verifier settings pinned
- no silent fallback logic
Foundry FFI
- default: HIGH
- BLOCKER if affecting deploy logic/secrets
E. Deploy-script safety
Check:
- chain assertions
- deployer assertions
- env validation
- correct initialization order
- idempotency assumptions clear
- no test config reuse
- address outputs reviewable
- no opaque branching
- verification steps present
Escalate if scripts can silently misdeploy.
F. Upgrade readiness (if applicable)
Check:
- implementation initialized or locked
- initializer calldata reviewed
- storage diff reviewed
- proxy admin correct
- multisig/timelock path exists
- pause/rollback defined
- fork rehearsal exists
G. Signer & admin opsec
Check:
- deployer is dedicated
- secure signer preferred
- admin is multisig
- roles separated:
- deployer / upgrader / pauser / treasury
- emergency roles documented
- no hot wallet admin unless justified
- tx review process exists
H. Address & role mapping
Extract:
- owner/admin
- proxy admin
- upgrader
- pauser
- treasury
- oracle
- keeper
- timelock
Flag:
- role concentration
- EOA-only control
- zero addresses
- missing transfer flow
I. Fork rehearsal
Require evidence of:
- deploy scripts tested
- initializer tested
- role transfers tested
- upgrade tested
- verification tested
- smoke tests run
Absence → HIGH (mainnet)
J. Post-deploy readiness
Check defined plan for:
- verification
- ownership assertions
- pause test
- oracle checks
- event expectations
- integration smoke tests
- monitoring
- deployment manifest
K. Unsafe deploy ergonomics
Check:
- one-command broadcast risk
- missing confirmations
- hidden env defaults
- CREATE/CREATE2 assumptions undocumented
- nonce-sensitive flows undocumented
Phase 3 — False confidence
MANDATORY
Passing does NOT imply safety:
- unit tests
- forge test
- static analysis
- lint
- typecheck
Require:
- fork rehearsal
- permission diff
- storage diff
- address diff
- event checks
- role snapshot
- post-deploy smoke tests
Phase 4 — Severity
BLOCKER
- wrong chain
- lost admin
- leaked secrets
- broken init
- broken upgrade
- unverifiable deployment
HIGH
- unsafe CI
- missing rehearsal
- FFI misuse
- admin EOA risk
- stale config
MEDIUM
- should fix before mainnet
LOW
Specify scope:
- mainnet-only / all releases / upgrades only
Phase 5 — Verdict
Always output:
VERDICT: BLOCK DEPLOYVERDICT: PROCEED WITH RISKVERDICT: READY FOR STAGED RELEASE
Include:
- top blockers
- required actions
- evidence reviewed
Output format
DEFENDER REPORT
1. Project Classification
- Framework:
- Language:
- Upgradeability:
- Protocol Type:
- Deployment Surface:
- CI Surface:
2. Release Findings
BLOCKER:
- ...
HIGH:
- ...
MEDIUM:
- ...
LOW:
- ...
3. False Confidence Warnings
- ...
4. Release Verdict
VERDICT: ...
Top blockers:
- ...
Required actions:
- ...
Evidence reviewed:
- ...
