The one-sentence version
Security is not about "how many features were added," but "whether an attacker can be stopped when they arrive." Threat modeling first answers: who will come, what do they want, and how will they get in; Red teaming then actually executes attacks like a real adversary to verify if every line of defense is effective. The most practical principle is: Every security rule must have a corresponding attack use case; a rule that has never been tested is as good as non-existent.
This article has three layers:
- Layer 1: The Intuition: First think about how a thief would enter, then try it out.
- Layer 2: Real-World Use: STRIDE, MITRE ATT&CK, Red Team / Blue Team / Purple Team, Bug Bounty.
- Layer 3: Principles and Engineering details.
Layer 1: The Intuition
1.1 First, think about how a thief would enter
Before installing security measures for a house, stand in the shoes of a thief and think:
- What does the thief want? (Cash, jewelry, identity documents)
- Where can they enter? (Front door, windows, balcony, impersonating a delivery person to trick you into opening the door)
- What will they do once inside? (Rummage through drawers, pry open the safe, delete surveillance footage)
Each answer corresponds to a line of defense. This is threat modeling.
1.2 Then, find someone to actually try it
Once installed, ask an expert friend to actually try to break in: Does the window lock really hold? Does the alarm actually sound? Does the camera actually record?
Many defenses are installed but ineffective: configurations are wrong, certain conditions are not covered, or alerts are sent to an unmonitored email. You only find out by actually fighting. This is red teaming.
Layer 2: Real-World Use
2.1 Common Frameworks
| Framework | Purpose |
|---|---|
| STRIDE (Microsoft, 1999) | Check the system against six threat categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege |
| Attack Trees (Schneier, 1999) | Uses the "attacker's goal" as the root and breaks it down layer by layer into various paths to achieve it, making it easy to find the cheapest attack path |
| MITRE ATT&CK | A knowledge base of adversary tactics and techniques based on real-world attack events, used to check "can we detect this specific move" |
2.2 Red Team, Blue Team, Purple Team
| Role | Responsibility |
|---|---|
| Red Team | Acts as the attacker, attempting to breach the system |
| Blue Team | Responsible for defense, monitoring, and response |
| Purple Team | Red and Blue collaboration: As the Red Team executes a move, the Blue Team immediately confirms "did we see it, did we stop it"; if not, they fix it immediately |
For small teams or individual projects, one person often wears all three hats. The Purple Team approach is the most practical: For every line of defense designed, write an attack use case to target it simultaneously.
2.3 Bug Bounty
Inviting external security researchers to find vulnerabilities in exchange for rewards. This is an extension of red teaming: internal testing is limited by one's own imagination, while external researchers will attack from unexpected angles. Even without a budget, you should at least publish a security contact email (e.g., security@) and a security.txt.
Layer 3: Principles and Engineering
3.1 Deriving defense from real-world methods
Do not imagine attacks out of thin air; instead, start from events that have already occurred:
| Real-world Method | Corresponding Defense | Corresponding Test Use Case |
|---|---|---|
| Address Poisoning | Similar address detection | Perform a poisoning transfer, then try to copy the address from history to see if it is flagged as high risk |
| Permit Signature Phishing | Parse EIP-712, prohibit blind signing | Simulate a phishing website requesting a Permit signature |
| Frontend Tampering | Integrity checks, broadcast comparison | Tamper with the recipient address on the page in a test environment |
| Account Takeover | Cooling-off periods, strong authentication | Simulate an immediate transfer after a "forgot password" takeover |
| Lying Data Sources | Multi-source cross-verification | Force one data source to return a forged result |
| Replay Attack | One-time nonce | Submit a previously used signature again |
| CSRF | SameSite, Origin validation | Initiate a modification request from a different domain |
3.2 How to write a test checklist
Each item should contain at least:
| Field | Content |
|---|---|
| ID | For cross-referencing with design docs and rule configurations |
| Scenario | What the attacker does |
| Prerequisites | The environment and data required for the test |
| Expected Result | Should be blocked, alerted, or degraded |
| Actual Result | Pass / Fail, with evidence (logs, screenshots) |
| Conclusion & Follow-up | Was it fixed if it failed? Was it retested after the fix? |
Additionally, maintain an overview table to see at a glance which tests passed, which were not tested, and which failed and are awaiting fixes.
3.3 Tests must be "able to fail"
A test that always passes has no value. A few common techniques:
- Inject Faults: Use fake data sources (fake RPC, fake API) to return forged or incorrect data to verify if the system detects and rejects it;
- Inject Malicious Clients: Test a wallet that intentionally tampers with transaction parameters to see if the signature verification catches it;
- Make it fail first: For a newly written detection, run it once without the defense enabled to confirm the test actually fails; then enable it and confirm it passes.
3.4 Both automation and manual testing are required
| Automated Testing | Manual Drills |
|---|---|
| Run on every code change to prevent regressions | Conduct periodically to simulate complete attack chains |
| Covers individual rules | Covers combinatorial attacks where "multiple small issues are linked together" |
| Uses fake dependencies for speed and stability | Run in a real environment (testnet) to discover configuration issues |
Many problems only appear in real environments: a third-party platform silently injecting a script into a page, sensitive parameters accidentally recorded in logs, or a certificate configuration allowing an obsolete protocol. These can only be discovered by "actually fighting."
3.5 Regarding disclosure
The methodology and categories of testing can be shared publicly, but specific test checklists, failed items, and pending issues are sensitive information—equivalent to a roadmap for attackers—and should be kept confidential.
Summary
| Layer | Key points |
|---|---|
| Threat Modeling | Who comes, what they want, how they enter; STRIDE, Attack Trees, ATT&CK |
| Red Teaming | Actually fighting like an attacker; Purple Team approach is most practical |
| Principle | One attack use case per rule; tests must be able to fail |
| Practice | Derive from real events; Automation + Manual drills; Keep failed items confidential |