Introduction to Frameworks

Welcome to the Security Frameworks by Security Alliance (SEAL), a curated resource for those seeking knowledge in the realm of blockchain security. Our organization, a collective of dedicated security specialists, is on a mission to spread awareness and educate the community about best practices and potential pitfalls in Web3 security.

Why We Created This Resource

We have noticed a growing need to address the various challenges and issues facing our field, some of which include security threats not specifically aimed at Web3 infrastructure. Recognizing that information is abundant but not always easily accessible, we've compiled and organized existing resources from around the internet and generated new content specifically with this purpose in mind.

Who Can Benefit

Regardless of your background—whether in Web2, Web3, or beyond—these guidelines are open to all who seek to learn and contribute. We aim to establish a comprehensive, high-level security framework for Web3 projects, providing best practices to development teams throughout the lifecycle of their projects. Consider this a one-stop shop for everything related to Web3 security.

How to Contribute

Read our Contribution Guide to learn how you can contribute to this project.

Who We Are

SEAL is a not-for-profit organization committed to enhancing security awareness, education, and specialized work as a public good for the Web3 ecosystem, its supporting technologies, and communities. Our efforts are driven by a shared desire to foster a safer, more informed digital landscape. We do this by designing innovative projects, engaging elite technologists, and coordinating on the social layer to ensure meaningful adoption.

How to Navigate the Website

Navigating the Security Frameworks by SEAL will be designed, in time, to be intuitive and user-friendly. We currently allow users to filter contents by role, but we're not quite there yet. Any feedback on how to improve the usage of frameworks in the future is appreciated.

Categories

The content is organized into different categories, each focusing on a specific aspect of security. Currently, we are under the introduction section, but you can explore the broader category of "Frameworks" below. Each framework is categorized to help you find relevant information quickly.

Filtering by Profile

This is currently being implemented, and we're currently looking for volunteers and collaborators for this specific task. The main objective is to allow users to filter the content by profile to focus on information relevant to their role within the organization. This feature allows them to bypass unnecessary reading and concentrate on what matters most.

Example roles:

• Developer
• Executive
• Security
• Finance
• Crypto
• Management
• Community
• Non-Technical

This targeted approach will ensure you get the most relevant information efficiently.

Overview of Each Framework

Important Disclaimer: The frameworks presented in this documentation are living documents that evolve with the Web3 security landscape. They may undergo restructuring, updates, or modifications in the future to reflect emerging threats, new best practices, and community feedback. We recommend regularly checking for updates to ensure you're working with the most current security guidelines.

This document provides an overview of the various frameworks covered in the Security Frameworks by SEAL. Each framework addresses a specific aspect of Web3 security, providing best practices and guidelines to help secure your projects.

Community Management

This framework explores best practices for securing and managing online communities associated with Web3 projects, covering platforms like Discord, Twitter, Telegram, and Google. It focuses on establishing secure communication channels and community guidelines.

Awareness

This section covers strategies for fostering security awareness among team members and users of Web3 projects, including understanding threat vectors, cultivating a security-aware mindset, and staying informed about security developments.

Operational Security (OpSec)

This comprehensive framework addresses day-to-day security practices for Web3 teams, covering fundamentals, governance, risk management, control domains, lifecycle management, monitoring, incident response, and continuous improvement.

Wallet Security

This section delves into the crucial aspect of managing cryptographic keys in Web3 projects, discussing various wallet types (cold vs hot, custodial vs non-custodial), hardware wallets, signing schemes, and software wallets.

External Security Reviews

This framework provides guidance on conducting and preparing for external security audits and reviews, including setting expectations, preparation, security policies, and vendor selection.

Vulnerability Disclosure

This section discusses best practices for handling and disclosing vulnerabilities in Web3 projects, including establishing security contacts and managing bug bounty programs.

Infrastructure

This section covers the fundamental aspects of securing the underlying infrastructure of Web3 projects, including asset inventory, cloud infrastructure, DDoS protection, DNS security, IAM, network security, and zero-trust principles.

Monitoring

This framework discusses the importance of continuous monitoring in Web3 projects, focusing on setting up effective monitoring systems and defining appropriate thresholds for alerts.

Front-End/Web Application

This section addresses security considerations specific to the user-facing components of Web3 projects, including both web and mobile application security, common vulnerabilities, and security tools.

Incident Management

This section outlines protocols for handling security incidents, including communication strategies, detection and response procedures, lessons learned, and playbooks, including specific guidelines for SEAL 911 War Room.

Threat Modeling

This framework provides guidance on creating and maintaining threat models, as well as identifying and mitigating potential threats to Web3 projects.

Infrastructure

This section covers the fundamental aspects of securing the underlying infrastructure of Web3 projects, including asset inventory, cloud infrastructure, DDoS protection, DNS security, IAM, network security, and zero-trust principles.

This section addresses risk management, regulatory compliance, and security metrics for Web3 projects, ensuring proper oversight and control.

DevSecOps

This framework focuses on integrating security practices into the development and operations processes, covering code signing, CI/CD, IDE security, repository hardening, and security testing.

Privacy

This section explores tools and practices for maintaining privacy in the Web3 ecosystem, including secure browsing, data removal, digital footprint management, encrypted communication, and privacy-focused operating systems.

Supply Chain

This framework addresses the security implications of dependencies and third-party components in Web3 projects, including dependency awareness and supply chain levels for software artifacts.

Front-End/Web Application

This section addresses security considerations specific to the user-facing components of Web3 projects, including both web and mobile application security, common vulnerabilities, and security tools.

This section explores ways to automate security processes in Web3 projects, including threat detection and response, compliance checks, and infrastructure as code.

Identity and Access Management (IAM)

This framework covers best practices for managing user identities and access control in Web3 projects, including role-based access control and secure authentication.

Secure Software Development

This section focuses on integrating security practices throughout the software development lifecycle, including secure coding standards, code reviews, and secure design principles.

Security Testing

This framework explores various methods of testing Web3 projects for security vulnerabilities, including dynamic and static application security testing, fuzz testing, and security regression testing.

ENS

This section covers Ethereum Name Service security considerations, including data integrity, cross-chain compatibility, smart contract integration, interface compliance, and name handling.

Safe Harbor

This framework provides guidance on establishing safe harbor protocols for security researchers, including key terms, protocols, technical outlines, and whitehat guidelines.

Encryption

This comprehensive section covers various encryption methods and their applications in protecting data, including cloud data encryption, communication encryption, database encryption, and various types of storage encryption.

Community Management

Communities might be the key of many Web3 projects, but they also represent a significant security challenge. From casual users to top-level executives, everyone within an organization can be targeted by social engineering tactics across platforms like Telegram, Discord, X (formerly Twitter), Google, and more. When a community channel is compromised—whether by phishing, fraudulent links, or account takeovers—it can quickly become a vehicle for wider attacks, putting both users and organizational reputations at risk.

Here, we present essential best practices to safeguard your community. In the following sections, we will explore platform-specific recommendations in more depth.

---

Best Practices for Community Security

Strong Passwords and Two-Factor Authentication (2FA)

• Use unique, complex passwords for each service and store them securely in a reputable password manager. Refer to the Operational Security Framework and Wallet Security Framework for more information on this.
• Secure the email account linked to your community platforms with a unique password and 2FA.
• Always enable 2FA. Prefer hardware-based tokens (e.g., Yubikey) or mobile authenticator apps over SMS-based methods, which are vulnerable to SIM-swapping.
• If you use an authenticator app like Authy, 1Password, or Aegis to generate time-based one-time passwords (TOTP). Ensure that the secret keys are stored encrypted and protected with robust security measures.
• Configure your app to require a password, PIN, or biometric authentication (e.g., fingerprint or face recognition) to unlock access to the tokens. This prevents unauthorized access and ensures the tokens remain secure even if someone gains physical or remote access to your device.
• Keep password generation and 2FA codes separate; do not use your password manager to generate 2FA codes. Otherwise, if the password manager is compromised, it could render the 2FA ineffective, allowing unauthorized access to your accounts.
• Encourage community members to adopt these practices as well.

Phishing Awareness

• Educate members on recognizing and reporting phishing attempts.
• Clearly communicate to community members that your team will never send the first direct message to them. This is important because attackers often impersonate team members and initiate direct messages to trick users into believing they are legitimate, thereby gaining their trust and potentially compromising their security.
• Publicly define all official communication channels used by your organization.

Refer to the Security Awareness framework to learn more about social engineering techniques and security training best practices.

Operational Security (OpSec)

• Be mindful of the devices you use to manage community channels. Malware or compromised hardware can give attackers an entry point.
• Regularly update software, run antivirus checks, and avoid installing untrusted applications that may compromise your security.

For a comprehensive understanding of Operational Security, including additional strategies and guidelines, please refer to the dedicated Operational Security framework.

Emergency Response Plan

• Prepare a clear protocol for handling security incidents, including how to quickly remove compromised accounts and warn community members.
• Adopt a proactive mindset: it's not a matter of if but when a breach will occur. Having a plan in place helps you act decisively and contain damage.

As part of the communication team, it is crucial to know when and how to communicate effectively during an incident. This involves understanding the appropriate timing and messaging to ensure clarity and prevent misinformation. For more insights on where this role fits within an incident, refer to the Incident Management framework.

Discord Security

🔑 Key Takeaway for Discord: To secure your Discord server, focus on implementing robust access controls and enforcing two-factor authentication for all administrators. Regularly audit roles and permissions, and maintain vigilant moderation. Educate your community about security best practices to prevent unauthorized access and protect against potential threats.

Discord offers a variety of security features that are essential to use. Despite these, users should stay alert to threats like phishing, which can target server moderators. Such threats may appear as QR code scams, fake login screens, or misleading direct messages pretending to be from Discord support.

To enhance the security of your Discord server, take into account these suggestions. They cover important aspects like server settings, roles and permissions, moderation, bots, channels, invites, member screening, logging, and other security measures.

---

Essential Security Measures

Server Settings

a) Enable 2FA Requirement for Moderation

• Go to Server Settings > Safety Setup > Moderation
• Toggle on "Require 2FA for moderation"
• This ensures all moderators have an extra layer of security

b) Set Appropriate Verification Level

• Go to Server Settings > Safety Setup > Verification Level
• Choose from: None, Low, Medium, High, Highest
• Recommended: "Moderate" for public servers (requires users are registered on discord for longer then 5 min.)
• Higher levels protect against spammers and raids

c) Enable Explicit Content Filter

• Go to Server Settings > Safety Setup > Content Filter
• Set to "Scan messages from all members"
• This automatically blocks messages containing explicit images in non-age-restricted channels
• Age-restricted channels are exempt from this filter

d) Enable Raid Protection and CAPTCHA

• Go to Server Settings > Safety Setup > Raid Protection and Captcha
• Activate all relevant settings to require CAPTCHA for new user actions
• This protection uses machine learning to detect and block bot-driven join-raids
• When activated:
  • Sends alerts to a specified channel
  • Requires CAPTCHA verification for new users for one hour after detection

Roles and Permissions

a) Implement Role Hierarchy

• Go to Server Settings > Roles

• Create roles like: Cold Admin, Team, Moderator, & Verified.

• Drag to reorder; higher roles override lower roles

• Restructure the role hierarchy by dragging roles higher or lower in the roles list:

  • Cold Admin
  • Team
  • Moderator
  • Verified

b) Restrict Administrative Permissions

• For each role, carefully review the 32 available permissions
• Key permissions to restrict: Administrator, Manage Webhooks, Manage Server, Manage Roles, & Manage Channels
• Never give Admin or Kick permissions to anyone you don't fully trust
• Good permissions for moderators: Manage Channels, Manage Roles, Manage Messages, Ban Members, Delete Messages
• Good permissions for members: View Channels, View audit logs, Create Invite, Manage Messages, Read Message History, Connect, Speak & Use Voice Activity, & Ban/Kick/Timeout

c) Use Channel-Specific Permissions

• Right-click on a channel > Edit Channel > Permissions
• Set custom permissions for roles or members in specific channels

d) Use the "View Server as Role" Feature

• Go to Server Settings > Roles > Select a role > View Server as Role
• This allows you to see what members with a certain role can see and access

Advanced Security Measures

Moderation

a) Set Up Auto-Moderation Rules

• Go to Server Settings > AutoMod
• Set up rules for: Spam, Harmful Links, Mention Spam, Inappropriate Words
• Configure custom keyword filters and exempted roles
• Customize the response to spam, like blocking the message, sending an alert, or timing out the member
• Add to the existing automod rule to block keywords in a users name, and put Support, Bot, Admin, Tech, Helpdesk, etc.

b) Configure Timeout Duration

• Go to Server Settings > Safety Setup > Timeout
• Set default duration (e.g., 60 minutes)
• Educate moderators on using timeouts effectively

c) Establish Clear Server Rules

• Create a #rules channel
• Use Discord's built-in rules screening feature
• Include sections on: Behavior, Content, Moderation Actions, Appeals Process

Extra Moderation Best Practices

a) Leverage "Default Notifications to Mentions Only"

• Go to Server Settings > Overview and set Default Notifications to Mentions Only.
• Reduces potential spam notifications for members, making them more vigilant about suspicious or phishing content.

b) Stay Alert to New Features & Potential Exploits

• Keep track of newly introduced features such as Threads, Scheduled Events, or Stage Channels.
• Configure their permissions carefully (e.g., who can start or join a Thread) to prevent abuse by spammers or scammers.

c) Regularly Check Third-Party Bot Security

• Ensure bots are from reputable sources and receive frequent updates.
• Review bot permissions after each significant update to avoid newly introduced vulnerabilities.

Bots

a) Audit Bot Permissions

• Go to Server Settings > Integrations
• Review each bot's permissions
• Remove unnecessary permissions
• Remove permissions for bots that ask for Admin or other permissions that aren't needed, use least privilege with permissions at the role level and channel level.

b) Remove Unnecessary Bots

• Uninstall any bots that aren't actively used or needed

c) Implement Security/Moderation Bots

• Consider bots like:
  • Dyno for advanced moderation and logging
  • Carl-bot for reaction roles and custom commands
  • Set up security Bots

Security-Specific Bots

Various third-party Discord bots offer valuable security and protection features, facilitating automated moderation for your server. In the sections below, we'll explore different categories of security bots and highlight popular options for each category.

Anti-Impersonation Bots

Set up custom rules to prevent other users from joining using the same username and PFP (profile picture) to impersonate you or other important members of the server. A popular bot in this category is Wick Bot.

Anti-Raid Bots

to prevent spam bots from joining your server all at once, an attack known as raiding, you can also set up bots with particular rules. Beemo is a good example of a bot in this category.

Anti-Nuke Bots

This is a monitoring system to observe and note any changes (spontaneous or planned) that take place in your discord server. Some key observation markers are channel and role creation/deletions, banning or kicking members, and webhook creation/deletion.

Moderation & Link Whitelisting Bots

Only allows approved links to be used in the discord server. A popular bot in this category is Goodknight Bot.

The bots above are not all-inclusive but rather a recommended list of bots to help protect your Discord server in these categories.

Enhanced Server Configuration

Channels

a) Organize Channels Logically

• Use categories to group related channels
• Suggested categories: Information, General, Voice Channels, Topic-Specific

b) Set Slow Mode Where Needed

• Channel Settings > Overview > Slow Mode
• Set appropriate cooldown (e.g., 5-30 seconds) for busy channels

c) Use Age-Restricted Channels Appropriately

• Channel Settings > Overview > Age-Restricted Channel
• Enable for channels with mature content

Invites

a) Disable Permanent Invites

• Server Settings > Invites
• Un-check "Allow anyone with administrative permissions to create invites"

b) Set Invite Expiration and Usage Limits

• When creating an invite: Set "Expire After" and "Max Number of Uses"
• Recommended: 24 hours expiration, 50-100 uses

c) Regularly Audit Active Invites

• Server Settings > Invites
• Review and delete unnecessary or old invites

Member Screening

a) Enable Membership Screening

• Server Settings > Safety Setup > Membership Screening
• Toggle on "Enable Membership Screening"

b) Set Up Screening Questionnaire

• Add questions about server rules, age verification, etc.
• Require members to agree to rules before joining

c) Set Up Membership Requirements

• Require users to react to a message or post an introduction
• This helps filter out bots and spam accounts from joining

Logging

a) Enable Audit Logs

• Ensure admin/mod roles have "View Audit Log" permission

b) Set Up a Private Logging Channel

• Create a private channel visible only to admins/mods
• Use a logging bot like Logger or Dyno to send detailed logs

Best Practices & Administrative Security

Regular Reviews

a) Conduct Periodic Permission Audits

• Monthly: Review all role permissions
• Use a spreadsheet to track changes and justifications

b) Review and Update Server Rules

• Quarterly: Assess if rules need updating
• Announce any changes in a dedicated announcements channel

c) Check for Unused Channels/Roles

• Bi-annually: Delete or archive inactive channels
• Remove roles that are no longer needed

Cold Admin Accounts

a) Set Up a "Cold" Admin Account

• Create a new account on a separate device never used for chatting or clicking links
• This account is highly resistant to phishing and provides an extra layer of security for the server owner

b) Secure the Cold Account

• Create a new email account for the cold account
• Factory reset the device used for this account

c) Use the Cold Account for Critical Actions

• Manage bots, modify server settings, and respond to compromises
• Never use this account for regular server activities

d) Disable QR Code Login on Cold Device

• In User Settings > Privacy & Safety, deselect any quick login or QR scan options.
• Prevents attackers from using QR phishing tactics to hijack this high-privilege account.

Additional Community Features

a) Enable the Community Feature (Newer Discord Update)

• Go to Server Settings > Community to activate the Community Feature.
• Unlocks tools like membership screening, server insights, welcome screen, and discovery settings.
• Helps maintain a structured, secure environment by surfacing official rules and critical info to newcomers.

b) Review Updated Discord Moderation Resources

• Consult the official Discord Moderator Academy for ongoing best practices and new features.
• Implement recommended strategies (e.g., improved spam filters, updated role recommendations).

Platform-Specific Security Considerations

Additional Security Measures

a) Verification Systems

• Implement a verification bot like Wick
• Require users to complete an in-channel captcha before accessing the server
• Advance Settings: Have verification bot filter based on account age, PFP set, and timeout for incomplete captcha

b) Raid Protection

• Use anti-raid bots like Wick or Dyno
• Configure automatic lock-down settings for suspicious activity

c) Privacy Settings

• Server Settings > Privacy Settings
• Disable "Allow direct messages from server members"

d) Integration Whitelisting

• Server Settings > Integrations > Allow new integrations to be added by:
• Set to "Only Administrators" to prevent unauthorized bot additions

e) Server Insights

• Enable Server Insights for detailed analytics
• Use this data to inform moderation strategies and server improvements

f) Backup Systems

• Use a bot like ServerBackup to regularly backup your server configuration
• Store backups securely off-platform

g) Audit New Integration/Link Safety Settings

• Regularly review Server Settings > Integrations for newly added apps or link shorteners.
• Disable suspicious integrations or automate link scanning with a bot that checks URLs against known phishing databases.

h) Enable Safe Direct Messaging for All Users

• In User Settings > Privacy & Safety, select Keep Me Safe for direct messages.
• Encourages moderators and community members to adopt the same setting to minimize phishing DMs.

Additional Resources

• Securing Your Server - Discord
• Four Steps for a Super Safe Server - Discord
• How to setup a Discord server securely

X (Twitter) Security

🔑 Key Takeaway for Twitter (X): To secure your Twitter account, prioritize using an authenticator app or security key over SMS-based 2FA, remove your phone number, and regularly review third-party app permissions. Ensure your recovery settings are robust and frequently monitor account activity to safeguard your online presence and maintain community trust.

A compromised X account can harm not only you but also your community. Attackers often use phishing tactics—like SIM swaps or fake login screens—to seize control of your profile. A few simple steps can significantly reduce these risks.

Securing your Twitter account is not particularly hard or time consuming, so consider following the best practices below.

---

Essential Security Measures

Remove your phone number

There are no good reasons to keep a phone number attached to your account, and it's the easiest way for a hacker to get into your account after SIM swapping you. Getting verified requires you to add a phone number, but you can remove it afterward.

1. Go to: Phone Settings
2. Remove: Click Delete phone number if one is listed.

After removing your phone number, it's crucial to navigate to Settings > Security and Account Access > Security > Two-Factor Authentication > Backup Codes. Store these codes offline, just like your seed phrase. Anyone with these codes can bypass your 2FA, so it's extremely important to write them down and keep them secure. Remember, when you change your password, new backup codes are generated.

Configure 2FA

Two-factor authentication is a great way to keep hackers at bay, but it's not foolproof if you're relying on SMS 2FA and someone gets hold of your phone number. It's generally better to use an authenticator app or a security key. Also, ensure your backup codes are stored safely, ideally printed on paper rather than saved on your device.

1. Go to: Login Verification
2. Disable: Un-check Text message
3. Enable: Choose Authentication app and/or Security key
   1. If using an authentication app, store your secret (TOTP) in a reliable app (Authy, Google Authenticator), but disable syncing for added security.
   2. If using security keys, keep at least two (e.g., from Yubico) in case one fails.
4. Under Additional methods, below, select Backup codes and create a new backup code. Store this code securely, offline, ideally in a physical format like a printout, to ensure that if one device is compromised, the code remains safe.

Enable password reset protect

Twitter provides a feature that requires users to input their email or phone number linked to the account before they can initiate a password reset. This adds an extra layer of security by ensuring that hackers must know your email, rather than receiving a hint.

1. Go to: Security Settings
2. Toggle On: Check Password reset protect.

Advanced Security Measures

Revoke access from delegated accounts

It's possible to allow other accounts to access your Twitter account. If your account was previously compromised, attackers could exploit this feature to maintain access even after you've regained control.

1. Go to: Delegate Members
2. Review: Remove any unfamiliar accounts.

Revoke access from unnecessary apps

It's possible that you've linked your Twitter account to several apps, and some might have more permissions than necessary. To check and manage these permissions, follow these steps:

1. Go to: Connected Apps
2. Review: Check each app's permissions and Revoke if it's no longer needed or trusted.

Log Out of Unnecessary Sessions

It's possible you've accessed Twitter from devices you don't regularly use, like a friend's phone. Review your active sessions and log out of any that are unfamiliar or unnecessary.

Old sessions on unfamiliar devices can be risky.

1. Go to: Sessions
2. Log Out: For any device or session you don't recognize.

Verify Your Email is Current

If you've changed your email since creating your Twitter account, ensure your current email is linked to receive security alerts and updates.

1. Go to: Email Settings
2. Confirm: Update to your current email if needed.

Refresh Your Password

Using a unique password for Twitter is crucial. If you haven't set one, now is the time to do so.

1. Go to: Password Settings
2. Change: Select a long, complex password.

Best Practices & Additional Tips

• Disable Email and Phone Discoverability

  • Go to: Discoverability and Contacts
  • It is recommended to turn both email and phone discoverability off.

• Privacy & Safety Settings:

  • In Privacy & Safety, consider disabling "Allow message requests from everyone" to limit spam DMs and phishing attempts and enabling "Filter low-quality messages".

• Monitor for Suspicious Alerts:

  • X (Twitter) may notify you about unusual activity. If you suspect a breach, log out of all sessions, revoke suspicious apps, and change your password immediately.

• Use Unique Recovery Methods:

  • If you choose to use a recovery phone number, which we generally strongly advise against, make sure it isn't your main mobile number. Instead, use a separate VoIP or alternative line to minimize the risk of SIM swapping.

• If you received an email about any content moderation, login, or any email from "X"; ensure the email is from "@x.com"

Telegram Security

🔑 Key Takeaway: Stay vigilant with group chats on Telegram. Implement verification steps and secure communication practices to protect against sophisticated interception attacks.

While Telegram is widely used in the crypto community, it's crucial to understand its security limitations. Telegram does not offer end-to-end encryption (E2EE) by default, which means your messages could potentially be accessed by third parties. Additionally, Telegram's reliance on phone numbers for account creation can expose users to SIM swapping attacks, and its peer-to-peer call feature can reveal your IP address to other users. If E2EE is a priority, consider using Signal.

However, if you choose to use Telegram, the following best practices can help enhance your security.

---

Essential Security Measures

Configure 2FA

Telegram sign-ups require a phone number, but you can also enable two-factor authentication via a password—your main protection if you're ever SIM-swapped. Don't reuse this password anywhere else.

1. Go to: Settings > Privacy and Security > Two-Step Verification
2. Set: A strong password and recovery email (store both in a password manager)

Hide Your Phone Number

Making your phone number visible can expose you to unwanted contact or social engineering attacks. Restricting visibility helps safeguard your personal info.

1. Go to: Settings > Privacy and Security > Phone Number
2. Who can see my phone number?: Select Nobody
3. Who can find me by my number?: Select My contacts

Disable P2P Calling

By default, Telegram calls can connect you directly to the other user, potentially revealing your IP address.

1. Go to: Settings > Privacy and Security > Calls
2. Use peer-to-peer with: Select Nobody

Manage Inactive Sessions

Telegram supports auto-terminating inactive sessions. You can also manually review and end any suspicious active sessions.

1. Go to: Settings > Privacy and Security > Active sessions
2. Review: Delete any sessions you don't recognize
3. Auto-terminate: Set inactive sessions to end after 1 month

Implement Device-Level Security

Securing the device you use for Telegram is crucial for preventing unauthorized access to your account and messages.

1. Enable Full Device Encryption:

   • Ensure your device has full disk encryption enabled
   • For iOS: This is enabled by default with a passcode
   • For Android: Go to Settings > Security > Encryption and follow instructions

2. Set Strong Device Passcodes:

   • Use alphanumeric passwords rather than simple PINs
   • Enable biometric authentication as a secondary measure

3. Keep Your Device Updated:

   • Install OS updates promptly to patch security vulnerabilities
   • Update Telegram to the latest version regularly

4. Install Security Software:

   • Use reputable anti-malware software on your device
   • Consider privacy-focused apps that detect network anomalies

5. Secure Your Backups:

   • Ensure any device backups containing Telegram data are encrypted
   • Be cautious about cloud backups that might store Telegram messages

Advanced Security Measures

Consider Using a Different Phone Number

Even if you implement all the recommended security measures, there are still valid reasons to use a separate phone number. For instance, it can help prevent your contacts from discovering your Telegram account or reduce the risk of accidental number exposure. This is particularly important because the "Share My Phone Number" option is enabled by default whenever you add a new contact.

Using a VoIP Number

Telegram restricts many VoIP providers, but services like Google Voice or Burner might work. Purchase a burner number solely for Telegram if you prefer additional anonymity.

Using an Anonymous Number

In December 2022, Telegram introduced support for anonymous numbers purchased through its TON blockchain infrastructure. You can also check out Fragment for such options.

Turn On Auto-delete Messages

Consider the photo you shared with a friend several months ago. While it might have slipped your mind, an attacker who gains access to your account could find such information quite valuable.

1. Go to: Settings > Privacy and Security > Auto-Delete Messages
2. Set: Choose a time frame (e.g., 1 week) based on your risk tolerance

Use Secret Chats for Enhanced Privacy

For conversations that require an extra layer of security, use Telegram's Secret Chats, which offer end-to-end encryption.

1. Start a Secret Chat: Open the chat with the desired contact, tap on their name, and select Start Secret Chat
2. Benefits:
   • Messages are encrypted and can only be read by you and the recipient
   • Offers self-destruct timers for messages
   • Prevents forwarding of messages to other chats

Regularly Update the Telegram App

Ensure you are always using the latest version of Telegram to benefit from the newest security patches and features.

1. Check for Updates: Visit your device's app store regularly
2. Enable Automatic Updates: If possible, turn on automatic updates to stay current

Be Cautious with Third-Party Bots and Integrations

Third-party bots can enhance functionality but may also introduce vulnerabilities.

1. Use Trusted Bots: Only add bots from reputable sources
2. Review Permissions: Limit the permissions you grant to bots
3. Regular Audits: Periodically review and remove unnecessary bots

Manage Group and Channel Admin Permissions

If you manage Telegram groups or channels, properly configuring admin permissions is crucial for maintaining security.

1. Limit Admin Privileges:

   • Go to your group/channel, tap the group name, select Administrators
   • Only grant necessary permissions to each admin
   • Avoid giving "Add Users" permission to untrusted admins

2. Implement Admin Verification:

   • Establish a verification process before promoting members to admin
   • Use separate channels (like voice calls) to confirm admin identities
   • Document when admin changes occur and why

3. Configure Group Settings:

   • Restrict member actions such as sending media or links
   • Enable "Slow Mode" for large groups to prevent spam
   • Use discussion groups for channels to control information flow

4. Audit Admin Activities:

   • Regularly review admin actions in the group
   • Remove inactive or suspicious admins
   • Consider using admin action logs if available

5. Handle Admin Transitions Securely:

   • Have protocols for transferring ownership if needed
   • Revoke admin rights immediately when team members leave

Enhanced Privacy Settings

Passcode Lock

• Settings > Privacy and Security > Passcode Lock: This feature adds a passcode to access your Telegram app after a period of inactivity. The default setting is "away for 1 hour."
  • Recommendations:
    • Store Passcode Securely: Do not lose this passcode—store it offline if needed.
    • Unique Passcode: Ensure it is different from your phone's unlock passcode.

Privacy and Security Settings

Go to: Settings > Privacy and Security

Security

Two-Step Verification

• Overview: Telegram does not require a login by default. However, you can set up a password that acts as a "second" 2FA method when logging in from a new device.
• Security Measures:
  • SMS Codes: Telegram sends a code via SMS, which is not secure.
  • Email Recovery: Offers email recovery, which is more secure but lacks options for authenticator apps or hardware keys.
• Important:
  • Backup Password: If you lose this password, access to your account may be compromised.
  • Secure Storage: Write it down offline and ensure it is not lost.

Additional Privacy Settings

Consider adjusting the following settings based on your country, usage, and purpose for using Telegram:

• Phone Number: Set to Nobody to prevent exposure.
• Last Seen & Online: Set to Nobody to enhance privacy.
• Profile Picture: Set to Everybody to stop scammers from impersonating your profile picture.
• Bio: Set to Nobody (depending on use of Telegram).
• Date of Birth: Set to Nobody.
• Forwarded Messages: Set to Nobody.
• Calls: Set to Nobody or Contacts Only (depending on use of Telegram).
• Voice Messages: Set to Contacts Only (depending on use of Telegram).
• Messages: Set to Everybody or Contacts Only (depending on use of Telegram).
• Invites: Set to Contacts Only or Nobody to prevent being added to random groups that may impersonate legitimate groups and lead to scams.

Data Settings

Go to: Settings > Privacy and Security > Data Settings

• Sync Contacts: Disable (depending on use of Telegram) to prevent syncing your contacts.
• Suggest Frequent Contacts: Disable (depending on use of Telegram) to avoid unsolicited contact suggestions.

Best Practices & Tips for Safe Use

• Use Secret Chats: When messaging someone, create a 'secret' chat to ensure encrypted 1:1 communication, providing end-to-end encryption for sensitive transactions.
• Verify Group Invites and Authenticity: Always triple-check group invitations and confirm the legitimacy of group chats through separate channels to avoid joining impostor groups that share malicious links.
• Beware of Unsolicited DMs: Never trust direct messages from anyone sending links or posing as "support," "exchanges," or "team" members.
• Double-Check Payment Details: Verify payment information through multiple methods before transferring funds to prevent fund redirection.
• Block and Report Scammers: Use the block function to prevent further contact, and report spammers/scammers instead of just deleting chats.
• Limit Group Permissions: Restrict who can add members to groups to prevent unauthorized cloning and protect against raids.

Educate Community Members on Security Practices

If you're managing a community on Telegram, educating your members about security is vital for collective protection.

1. Regular Security Announcements:

   • Schedule periodic reminders about security best practices
   • Pin important security announcements in your group/channel
   • Create dedicated security FAQ channels or posts

2. Clear Verification Procedures:

   • Establish and communicate how official communications will occur
   • Create verification steps for new members to follow
   • Document how to verify the authenticity of admins and official messages

3. Threat Awareness Training:

   • Share examples of common scams targeting your community
   • Post screenshots of phishing attempts (with sensitive info redacted)
   • Explain the "Man-in-the-Group Attack" and how to avoid it

4. Incident Reporting Protocol:

   • Create clear guidelines for reporting suspicious activity
   • Designate security-focused admins to handle reports
   • Acknowledge reports publicly (without specifics) to encourage vigilance

5. Security Resources:

   • Develop simple, accessible security guides for members
   • Share platform-specific security updates when Telegram releases them
   • Create a security checklist for new community members

• Exercise Caution with Mini Apps: Avoid logging in or providing information to mini apps that redirect outside of Telegram. Triple-check the username of the mini app to ensure its legitimacy, as Telegram lacks a bot verification system. Never download or run any commands from Telegram on your device.
• Enhance Privacy with a VPN: Advanced tip: Set up a proxy or VPN to hide your IP address while using the Telegram app.
• Stay Vigilant Against Scam Ads: Be aware that anyone can post ads in channels, with 99% being scam ads. Exercise caution when interacting with advertisements.

Platform-Specific Risks: Man-in-the-Group Attack

Attackers can exploit Telegram's group chat features to intercept and manipulate communications between two parties. Here's a concise example of how such an attack might occur:

Scenario: Intercepting a Payment Deal

Step 1: Initial Communication

• Alice and Bob decide to finalize a cryptocurrency deal using a Telegram group chat named "Crypto Deals".

Step 2: Attackers Create Cloned Groups

• Attacker 1 creates Group A impersonating Alice.
• Attacker 2 creates Group B impersonating Bob.

Step 3: Replicating Conversations

• In Group A (Impersonating Alice):

  • The attacker, posing as Alice, relays Alice's messages from Group B to maintain the conversation.

• In Group B (Impersonating Bob):

  • The attacker, posing as Bob, mirrors Bob's messages from Group A, acting as a middleman without altering the content.

Step 4: Swapping Payment Details

• In Group A:

  • Fake Alice and Bob agree to the terms of the deal.
  • Bob shares his payment address.

• In Group B:

  • Fake Bob shares his swapped payment address.
  • The conversation continues normally, with neither Alice nor Bob aware of the swap.

Step 5: Execution of the Scam

• Alice sends the payment to what she believes are Bob's details but are actually those of Fake Bob.
• The attacker now controls both ends of the conversation, having successfully redirected the funds.

Google Security

🔑 Key Takeaway: Enhance your Google account security by implementing robust 2FA, eliminating redundant recovery options, and diligently overseeing third-party access.

Google provides a wide range of services—from email to file storage. Safeguarding your Google account is among the most critical steps you can take to protect your personal and professional data. Below are simple yet effective measures to improve your Google account security.

---

Essential Security Measures

This section does not include Google Suite or more advanced security configurations. For that, refer to the Operational Security Framework, under Google Suite Security.

Configure 2FA

Properly setting up two-factor authentication (2FA) is one of the most crucial steps you can take. Disable SMS 2FA to avoid SIM swaps, and instead use an authenticator app or a hardware security key (preferred).

1. Go to Google 2-Step Verification
2. Disable: "Voice or text message" if it's enabled
3. Enable: "Authenticator app" and/or "Passkeys and security keys". You can also can continue using Google prompts.
4. Store Backup Codes: Keep them offline in a secure place

Remove Recovery Methods

By default, Google allows account recovery using phone numbers and emails. Attackers can exploit these if they compromise your phone or email.

1. Go to: Google Recovery Phone
2. Remove: Any phone number listed
3. Optional: If you're confident you won't need standard recovery processes:
   1. Go to: Google Recovery Email
   2. Remove: Any recovery email present

Manage Active Sessions

Keeping track of active sessions helps you detect unauthorized access.

1. Go to: Google Device Activity
2. Terminate: Any session you don't recognize

Manage OAuth Applications

Some apps request extensive permissions (e.g., full inbox or file access). Regularly review these to minimize risks.

1. Go to: Google Connections
2. Review: Each connected app's permissions; remove if unnecessary or excessive

Hide Personal Information

Publicly visible personal info can aid attackers in impersonating you.

1. Go to: Google Profile
2. Check Visibility: If any info is set to "Anyone," switch it to private if unnecessary
   • Birthday: Consider making it private

Advanced Security Measures

Extended Security Settings

1. Start from: Google Security.
2. Go to:"Your connect to third-party apps & Services".
3. Revoke: all applications that should not be connected.
4. Go to: "Log out of all unknown devices"
5. Turn off: "skip password when possible" (below previous step)
6. Go to: "How you sign in with Google"
7. Setup: your 2FA or Security Key in this section
8. Ensure you do not have a recovery phone setup. No SMS 2FA or phone number on your account at all.

Once these steps are completed, please change your password. Remember to note down your backup codes.

If using Google Authenticator as a 2FA app on your phone, disconnect it from the cloud, as backup codes are then stored in the google cloud associated to email. Use it without an account and ensure backup codes are written down offline.

Advanced Protection Program

For those who are public figures or need heightened security, Google's Advanced Protection Program is worth considering. It requires the use of security keys, limits access to unverified apps, and makes the process of account recovery more challenging.

1. Go to Google Advanced Protection Program
2. Enroll: Follow the on-screen steps

Best Practices & Additional Tips

• Review Security Alerts: Pay attention to any email or phone notifications from Google regarding unusual sign-ins or account changes.
• Perform a Security Checkup: Regularly visit Google's Security Checkup to identify potential issues and resolve them.
• Consider using identity monitoring apps like Push Security.

Security Awareness

Key Takeaway Stay vigilant, your awareness is your strongest defense against cyber threats. Recognizing red flags and questioning unexpected requests can prevent costly breaches.

This framework is all about understanding the threat landscape, recognizing risk signals, and cultivating a security-aware mindset. It serves as a high-level guide to help individuals and organizations identify potential vulnerabilities and remain vigilant—without overlapping with the detailed, technical scenarios covered in other sections.

Introduction & Objectives

The modern digital landscape is filled with sophisticated attacks, including web3-specific threats like crypto drainers and rug pulls. This section lays the foundation for why a high level of security awareness is essential. It's about empowering you to notice, question, and respond appropriately when something feels off. Trust, but verify!

Objectives

• Recognize Threats: Understand common tactics used by cybercriminals, including both traditional and web3-specific attack vectors.
• Adopt a Proactive Stance: Learn how early recognition can stop an attack in its tracks.
• Foster a Security Culture: Build an organizational environment where security is everyone's responsibility.
• Implement Effective Training: Develop structured approaches to security education for all team members.
• Separate Awareness from Implementation: Focus here on "being aware" rather than the step-by-step controls, which are covered in other sections.

Contents

1. Core Awareness Principles - Foundational security concepts and mindsets that form the basis of security awareness
2. Understanding Threat Vectors - Comprehensive overview of attack methods, indicators, and preventive measures
3. Cultivating a Security-Aware Mindset - Behavioral practices and organizational strategies for building a security culture
4. Staying Informed & Continuous Learning - Training frameworks, educational approaches, and information sources
5. Resources & Further Reading - External tools, references, and resources for ongoing security education

1. Core Awareness Principles

🔑 Key Takeaway: Security awareness is built on fundamental principles like threat recognition, risk assessment, and zero trust verification. These principles form the foundation of a security-conscious culture where every individual plays a vital role in protecting organizational assets.

Key concepts

• Threat Recognition: Understand that threats come in various forms—phishing, social engineering, malware, and insider risks. For instance, a social media message urging immediate action might be a scam designed to exploit urgency.

• Risk Perception: Assessing risk means evaluating both the likelihood of an attack and the potential impact. For example, if you frequently receive messages from unknown sources on a platform like Twitter, you should view these interactions with increased skepticism.

• Zero Trust Mindset: Always verify before trusting. Even messages from familiar contacts should be confirmed if they involve unexpected requests or sensitive information.

• Filtering Credible Information: In an era of information overload, it's critical to identify and rely on reputable sources. This means following established security blogs, official alerts from cybersecurity agencies, or verified community channels.

• Organizational Responsibility: Security is a shared responsibility that requires commitment at all levels of the organization. Leadership must demonstrate strong commitment by prioritizing and investing in security initiatives, while every team member should understand their role in maintaining security.

Real-World Example: A company might receive a seemingly routine email from a "vendor" requesting updated banking details. An employee with a strong zero trust mindset will independently verify the request through known contact numbers or an established internal process, thereby avoiding a potential fraud.

2. Understanding Threat Vectors

🔑 Key Takeaway: Understanding the various ways attackers can target you and your organization is essential for effective defense. By recognizing common attack patterns like phishing, social engineering, and emerging threats in digital spaces, you can better protect yourself and your team from potential security breaches.

2.1. Traditional Attack Vectors

2.1.1. Social Engineering & Phishing

• Phishing Emails: Look for red flags like misspellings, odd URLs, and urgent language. Scenario Example: An email that claims "Your account will be locked in 24 hours" but uses a suspicious domain.

• SMS & Messaging Scams: Attackers may use text messages or direct social media messages to bypass email filters. Scenario Example: A text message that claims to be from a delivery service asking for a confirmation code.

• Voice Phishing (Vishing): Phone calls that pretend to be from a trusted organization, often using spoofed caller IDs. Scenario Example: A staff member receives a voicemail warning about a potential security breach and instructing them to call a specific number immediately.

• Pretexting: Attackers create a fabricated scenario to steal personal information or gain access. Scenario Example: Someone pretending to be a new contractor who needs urgent access to systems or information.

• Baiting: Offering something enticing to entrap the victim. Scenario Example: Leaving infected USB drives in public places or offering free downloads that contain malware.

• Tailgating: Physically following authorized personnel into restricted areas without proper credentials. Scenario Example: An unknown person following an employee through a secure door by claiming they forgot their access card.

• Shoulder Surfing: Observing someone's screen, keyboard, or device to gather information. Scenario Example: A threat actor monitoring your screen in a shared co-working space to capture sensitive information or credentials.

2.1.2. Malware & Technical Attacks

• Ransomware: Malicious software that encrypts files and demands payment for decryption. Scenario Example: An organization finds their critical files encrypted with a ransom note demanding cryptocurrency payment.

• Man-in-the-Middle Attacks: Intercepting communications between two parties. Scenario Example: An attacker on a public Wi-Fi network intercepts unencrypted traffic to steal credentials.

• Credential Stuffing: Using stolen username/password combinations to attempt access to multiple services. Scenario Example: After a data breach at one service, attackers try the same credentials on financial or email accounts.

2.2. Web3-Specific Threats

2.2.1. Crypto-Focused Attacks

• Crypto Drainers: A common attack where a threat actor suggests users can participate in an airdrop by visiting a provided link. Unsuspecting users who click the link are directed to a counterfeit website, where they are asked to authenticate their wallet and sign a transaction. Once signed, the threat actor gains access to steal funds from the wallet.

• Rug Pulls: In the context of web3 and cryptocurrencies, these scams typically involve fraudulent schemes designed to swindle individuals out of their digital assets. For example, an enticing new project may promise revolutionary technology and unprecedented returns. However, the project developers quickly vanish, leaving investors with worthless tokens and empty promises.

• Token Approval Exploits: Attackers may trick users into approving smart contracts that give unlimited access to tokens in their wallet. These "allowances" permit the approved contract to transfer any amount of a specific token without further permission. Always verify what permissions you're granting when signing transactions and set specific approval limits when possible.

2.2.2. Smart Contract Vulnerabilities

• Reentrancy Attacks: Exploiting a contract's execution flow to repeatedly withdraw funds. Scenario Example: A malicious contract calls back into the victim contract before the first execution is complete, draining funds with each call.

• Flash Loan Attacks: Using uncollateralized loans to manipulate market prices and exploit vulnerabilities. Scenario Example: An attacker borrows a large amount of cryptocurrency, manipulates a price oracle, exploits a vulnerability, and repays the loan in a single transaction.

2.3. Common Indicators & Red Flags

2.3.1. Behavioral Cues

• Inconsistencies: Look for changes in tone or style in communications from known contacts. Scenario Example: A normally formal manager sends a casual message with unexpected requests.

• Unusual Requests: Requests for urgent transfers of money, sensitive information, or changes in process should always trigger caution.

• Environmental Anomalies: Spotting unexpected logins or unfamiliar devices in account activity reports can indicate compromised accounts.

2.3.2. Technical Indicators

• Unexpected Authentication Prompts: Sudden requests to re-authenticate without clear reason. Scenario Example: Being asked to provide credentials on a site you're already logged into.

• Browser Certificate Warnings: Alerts about invalid or expired security certificates. Scenario Example: Your browser displays a warning that a connection is not secure when visiting a familiar website.

• Unusual System Behavior: Slowdowns, crashes, or unexpected pop-ups. Scenario Example: Your computer suddenly runs significantly slower or displays unfamiliar advertisements.

2.3.3. Checklist for Suspicious Communications

• Does the message contain spelling errors or unusual formatting?
• Is the sender's email or username slightly different from the norm?
• Are there requests for urgent action without proper verification channels?
• Does the message create a sense of fear, urgency, or excitement?
• Is there an unexpected attachment or link?
• Does the request bypass normal security procedures?

2.4. Preventive Measures

2.4.1. General Security Practices

• Double-Check Requests: Always verify the identity of individuals requesting sensitive information, especially if the request is unusual or urgent. Scenario Example: If you receive an email from your CEO asking for an urgent wire transfer, call them directly using a known phone number to confirm.

• Use Secure Channels: Communicate through official channels and avoid sharing sensitive information over unsecured methods. Scenario Example: Use your organization's established communication platforms rather than responding to external email links.

2.4.2. Web3-Specific Protections

• Check & Remove Token Approvals: Regularly check which smart contracts have approvals to handle funds in your wallet and revoke unnecessary approvals to improve your security posture. Useful Tools:

  • Unrekt
  • Etherscan Token Approval Checker

• Scrutinize Transaction Requests: Never sign a transaction unless you are completely sure exactly what you are signing. Be especially skeptical of offers that seem too good to be true.

• Hardware Wallets for Critical Assets: Use hardware wallets for storing significant cryptocurrency holdings. Scenario Example: Keeping your long-term investments on a hardware wallet while only maintaining small amounts in hot wallets for daily transactions.

3. Cultivating a Security-Aware Mindset

🔑 Key Takeaway: Developing a security-aware mindset is about building habits that prioritize caution and verification. By questioning unusual requests, pausing before acting, and leveraging peer support, you transform security from a set of rules into an intuitive approach to daily interactions.

3.1. Behavioral Best Practices

Practical Tips

• Question Unusual Requests: Always verify any request for sensitive information or financial transactions through a separate communication channel.

• Pause Before Reacting: Take a moment to think before clicking a link or downloading an attachment. Example: If you get an unexpected file from a colleague, call them directly to confirm they sent it.

• Peer Verification: Leverage your team by asking a colleague's opinion if something seems off.

Scenario Example A community manager receives a direct message on Discord that looks like it comes from a well-known project partner, asking for private credentials. Instead of immediately responding, they cross-check the message in a team meeting or via a known contact method.

3.2 Awareness in Community Settings

Unique Challenges on Social Platforms

• Platform-Specific Red Flags: Each community platform—Discord, Twitter, Telegram—has its own quirks. Example: On Telegram, unsolicited group invites with suspicious usernames could be phishing attempts.

• Community Role Awareness: Moderators and administrators should be extra cautious since they have higher privileges. Example: A moderator on a crypto project Discord might notice a sudden spike in login attempts from an unfamiliar IP range.

• Culture of Reporting: Foster an environment where suspicious behavior is immediately reported and discussed, not brushed aside.

Scenario Example During a routine community chat, several members report receiving odd messages that urge them to click on a link. The community manager organizes a quick session to remind members of red flags and the correct reporting channels, reinforcing collective vigilance.

3.3 Organizational Strategies for Security Culture

• Leadership Commitment: Ensure that leadership demonstrates a strong commitment to security by prioritizing and investing in security initiatives. Leaders should model security-conscious behavior and allocate appropriate resources to security efforts.

• Regular Communication: Communicate the importance of security regularly through team meetings, newsletters, and other channels. Keep security topics visible and relevant to all team members.

• Security Policies and Procedures: Develop and enforce clear security policies and procedures that outline expectations and responsibilities for all team members.

• Encourage Reporting: Create an environment where team members feel comfortable reporting security incidents, suspicious activities, and potential vulnerabilities without fear of retribution.

• Recognition and Rewards: Recognize and reward team members who demonstrate exemplary security practices and contribute to the organization's security efforts.

• Continuous Improvement: Continuously assess and improve the project's security culture through feedback, assessments, and audits.

• Shared Responsibility: Instill a sense of responsibility for security at all levels of the project, emphasizing that security is everyone's job.

• Collaboration: Promote collaboration and information sharing among team members to enhance overall security awareness and response capabilities.

Scenario Example A project implements a monthly "Security Spotlight" where different aspects of security are highlighted, and team members can share their experiences or ask questions. This regular touchpoint keeps security top-of-mind and encourages ongoing dialogue about best practices.

3.4 Essential Security Practices

3.4.1. Password Management

• Strong, Unique Passwords: Use complex, unique passwords for each account to prevent credential stuffing attacks. Example: A passphrase like "correct-horse-battery-staple" (with four random words) is both strong and memorable, while being more secure than shorter passwords with special characters like "P@ssw0rd!".

• Password Managers: Utilize a reputable password manager to securely store and generate complex passwords. Example: Tools like Bitwarden, 1Password, or KeePassXC can generate and store unique passwords for all your accounts.

3.4.2. Multi-Factor Authentication (MFA)

• Enable MFA Everywhere Possible: Add an extra layer of security beyond just passwords. Example: Even if someone obtains your password, they still can't access your account without the second factor.

• Choose Secure MFA Methods: Hardware tokens and authenticator apps are more secure than SMS-based verification. Example: Use YubiKeys or authenticator apps like Authy instead of SMS, which can be vulnerable to SIM swapping attacks.

3.4.3. Secure Communication

• End-to-End Encryption: Use messaging platforms with end-to-end encryption for sensitive communications. Example: Signal provides strong encryption for messages, ensuring only the intended recipient can read them.

• Verify Communication Channels: Be cautious of unexpected platform changes for important communications. Example: If a colleague suddenly asks to switch from your company's official channel to a personal messaging app for work discussions, verify this request directly.

3.4.4. Device Security

• Keep Systems Updated: Regularly update your operating system and applications to patch security vulnerabilities. Example: Schedule automatic updates or set a weekly reminder to check for and install updates.

• Secure Your Workspace: Be mindful of physical security in shared or public spaces. Example: Use privacy screens when working in public and lock your device when stepping away.

3.5. Incident Response Awareness

3.5.1. Recognizing Security Incidents

• Know the Warning Signs: Understand what constitutes a potential security incident. Example: Unexpected account lockouts, strange system behavior, or unusual access requests could indicate a breach.

• Immediate Actions: Know what steps to take when you suspect a security incident. Example: Disconnect from networks, document what happened, and report to your security team immediately.

3.5.2. Reporting Procedures

• Clear Reporting Channels: Ensure everyone knows how and where to report security concerns. Example: Have a dedicated email address or communication channel specifically for security reports.

• No-Blame Culture: Encourage prompt reporting by focusing on solutions rather than blame. Example: Acknowledge and thank team members who report potential issues, even if they turn out to be false alarms.

Scenario Example A team member notices unusual login attempts to their account. Instead of ignoring it or feeling embarrassed, they immediately report it to the security team, who can then investigate whether this is part of a larger attack pattern affecting other users.

4. Staying Informed & Continuous Learning

🔑 Key Takeaway: Security is not a one-time achievement but an ongoing journey of learning and adaptation. By establishing regular training routines, staying current with emerging threats, and fostering a culture of continuous improvement, you ensure your security awareness remains effective against evolving challenges.

4.1. Comprehensive Security Training Framework

4.1.1. Training Approaches

• Bite-Sized Learning: Security training doesn't need to be lengthy or overwhelming. Short, focused sessions of relevant information can be more effective than infrequent, lengthy presentations. Example: Weekly 5-minute security tips delivered via team chat or email.

• Role-Based Training: Tailor security training to specific roles and access levels within your organization. Example: Developers might need more in-depth training on secure coding practices, while community managers might focus more on social engineering awareness.

• Recurring Schedule: Make security training a regular, ongoing activity rather than a one-time event. Example: Monthly security topics with quarterly refreshers on critical subjects.

• Practical Application: Include hands-on exercises that allow people to apply what they've learned. Example: Conduct simulated phishing tests followed by immediate feedback and learning opportunities.

• Interactive Training Methods: Use interactive training methods, such as SEAL Wargames or workshops to engage team members and enhance learning.

• Real-World Scenarios: Incorporate real-world scenarios and case studies to illustrate the impact of security breaches and the importance of preventive measures.

• Assessments and Quizzes: Use assessments and quizzes to evaluate the effectiveness of training and identify areas where additional training may be needed.

4.1.2. Training Delivery

• Regular Awareness Sessions: Schedule quarterly webinars or short training refreshers focusing on the latest trends and emerging threats.

• Interactive Simulations: Participate in phishing simulations or scenario-based exercises that allow you to practice identifying and responding to threats in a risk-free environment.

• Security Awareness Campaigns: Implement periodic campaigns that focus on specific security themes to reinforce key messages. Example: A "Phishing Awareness Month" with targeted activities and resources.

4.1.3. Measuring Training Effectiveness

• Baseline Assessments: Conduct assessments before and after training to measure improvement.

• Behavioral Metrics: Track security-related behaviors such as reporting rates for suspicious emails or incidents.

• Feedback Collection: Gather participant feedback to continuously improve training content and delivery methods.

4.2. Essential Training Topics

• Phishing and Social Engineering: Educate team members on recognizing and responding to phishing attacks and social engineering tactics, with special focus on web3-specific threats.

• Password Management: Provide best practices for creating and managing strong passwords and using password managers.

• Data Protection: Teach methods for protecting sensitive data, including encryption, access controls, and secure data handling practices.

• Incident Reporting: Instruct team members on how to report security incidents and suspicious activities promptly.

• Secure Coding Practices: For developers, provide training on secure coding practices and common vulnerabilities in web3 environments.

• Device and Account Security: Cover best practices for securing devices and accounts, including updates, encryption, and access controls.

• Emerging Threats: Keep team members informed about new and evolving security threats relevant to your organization.

4.3. Trusted Information Sources

4.3.1. Security Newsletters

• Industry News: Subscribe to newsletters from sources such as FIRST.org for broader cybersecurity trends. Example: The SANS NewsBites provides twice-weekly summaries of the most important security news.

• Vendor Updates: Follow security updates from the software and hardware vendors in your project stack. Example: Subscribe to security bulletins from cloud providers, operating system vendors, and key software dependencies.

4.3.2. Security Communities

• Online Forums and Groups: Join online communities dedicated to security topics. Example: The SEAL Discord provides a space to discuss security challenges specific to web3 projects.

• Local and Virtual Meetups: Attend security-focused events to network and learn. Example: Conferences like DeFi Security Summit offer insights into emerging threats and defenses.

4.3.3. Security Blogs and Podcasts

• Technical Blogs: Follow security researchers and organizations that regularly publish detailed analyses. Example: Trail of Bits blog provides in-depth technical security content.

• Security Podcasts: Listen to podcasts that cover current security topics. Example: The Daily Stormcast from FIRST.org offers brief daily updates, while Darknet Diaries provides longer-form stories about notable security incidents.

4.4. Implementing a Learning Culture

• Share Knowledge: Create channels for team members to share security articles, news, and insights. Example: A dedicated Slack channel for security-related content.

• Recognize Vigilance: Acknowledge and reward security-conscious behavior. Example: Highlight team members who identify and report potential security issues.

• Learn from Incidents: Use security incidents (both internal and external) as learning opportunities. Example: After major industry breaches, conduct brief sessions to discuss what happened and how similar issues could be prevented in your organization.

5. Resources & Further Reading

🔑 Key Takeaway: Expanding your security knowledge requires reliable resources and continuous engagement with the security community. By leveraging curated learning materials, self-assessment tools, and professional networks, you can deepen your expertise and stay ahead of emerging threats.

5.1. Additional Learning Materials

• Security Awareness Blogs: Subscribe to blogs like "Security Week" or "Dark Reading" for the latest on cyber threat trends.

• Self-Assessment Tools: Use downloadable checklists and online quizzes to periodically test your awareness.

• Community Forums & Discussion Groups: Engage with professional security communities on platforms such as Reddit's r/cybersecurity or specialized Discord groups.

• Case Studies and Whitepapers: Read detailed incident reports and analysis (available from sources like Verizon's Data Breach Investigations Report) to learn from past events.

Example Resources:

• Personal security checklist: Digital Defense (we are currently developing a version of this based on frameworks, will be available at https://check.frameworks.securityalliance.dev).
• Interactive phishing simulation: Phishing Dojo.
• SEAL's blog on frameworks.

5.2. Recommended Security Newsletters

• SANS NewsBites - Twice-weekly summaries of the most important security news
• FIRST.org - Forum of Incident Response and Security Teams newsletters and resources
• The Hacker News - Cybersecurity news and analysis
• Krebs on Security - In-depth security news and investigation

5.3. Security Podcasts and Media

• Daily Stormcast - Daily 5-10 minute updates from SANS Internet Storm Center
• Darknet Diaries - Stories from the dark side of the internet
• Security Now - Weekly deep dives into security topics
• Risky Business - Weekly information security podcast

5.4. Security Training Resources

• OWASP - Open Web Application Security Project resources and guides
• Cybrary - Free and premium cybersecurity training
• SANS - Professional information security training
• Phishing.org - Anti-phishing training and awareness resources

5.5. Web3-Specific Security Resources

• DeFi Security Summit - Conference focused on DeFi security
• SEAL news & SEAL Discord - Security Alliance's initiatives related to news and events
• Immunefi - Educational resources about web3 security
• Consensys Diligence - Smart contract security blog
• Blockthreat - Web3 security news and analysis
• The Red Guild - Web3 security awareness and education

5.6. Web3 Security Tools

• Token Approval Management:

  • Unrekt - Check and revoke token approvals
  • Etherscan Token Approval Checker - Monitor smart contract approvals

• Wallet Security:

  • wise-signer - Game to learn how to verify transaction information on your wallets
  • Qualified Signer Certification - Certification for verifying transaction information
  • Software and Hardware Wallets comparison - Compare security features of different crypto wallets
  • Hardware Wallets comparison - Compare security features of different hardware wallets
  • Wallet Scrutiny - Analyze wallet security and features
  • Hardware Wallet Resources - Educational content about hardware wallet security

5.7. Security Tools and Services

• Password Managers:

  • Bitwarden - Open-source password management
  • 1Password - Premium password management solution
  • KeePassXC - Free, open-source, cross-platform password manager

• Two-Factor Authentication:

  • Authy - Multi-device 2FA application
  • YubiKey - Hardware authentication device

• Secure Communication:

  • Signal - End-to-end encrypted messaging
  • ProtonMail - Encrypted email service

Operational Security

Operational Security (OpSec) is a systematic approach to identifying critical information, determining threats to that information, analyzing vulnerabilities, assessing risks, and implementing countermeasures to protect sensitive data and operations. This framework provides comprehensive guidance for implementing effective operational security practices in Web2 and Web3 environments.

Core Components

This framework is organized into several interconnected components:

1. Overview: Core principles and concepts of operational security
2. Threat Modeling Overview: Identifying and analyzing potential security threats
3. Risk Management Overview: Identifying, assessing, and mitigating security risks
4. Monitoring & Detection Overview: Continuous monitoring of security events and anomalies
5. Incident Response & Recovery Overview: Handling security incidents when they occur
6. Governance & Program Management Overview: Establishing security leadership and organizational structures
7. Control Domains Overview: Key areas requiring specific security controls and practices
8. Lifecycle Overview: The continuous process of implementing and maintaining security measures
9. Continuous Improvement Overview: Learning from incidents and evolving security practices

Additional contents

• While Traveling
  • TL;DR
  • Guide

Using This Framework

Organizations should adapt this framework to their specific needs, considering their size, resources, and risk profile. Start with the fundamentals and gradually implement more advanced controls as your security program matures.

The guidance provided here is designed to be practical and actionable, with specific recommendations that can be implemented by Web3 teams of all sizes.

Overview

Operational Security (OpSec) is a practical approach that helps organizations protect sensitive information and critical assets through both foundational security concepts and actionable implementation processes. In simple terms, it means identifying what information is valuable, understanding who might try to steal or misuse it, figuring out how it could be accessed, and then putting the right protections in place to prevent that from happening. This section covers the essential frameworks that form the basis of an effective operational security program.

What is Operational Security?

Operational Security is a systematic process that:

1. Maps and secures critical information and assets
2. Identifies and analyzes relevant threats
3. Discovers and addresses exploitable vulnerabilities
4. Evaluates risks in a business context
5. Deploys targeted controls to mitigate identified risks

The goal is to prevent unauthorized access to systems and information that, if compromised, could lead to operational, financial, or reputational harm. To achieve this, modern Operational Security frameworks should adopt zero trust security model, which assumes no user, or device is inherently trustworthy. Instead, every access request must be explicitly verified, regardless of origin or credentials.

Security Fundamentals

The following fundamentals form the foundation of effective operational security:

• Layered Protection: Implementing multiple overlapping security controls so that if one mechanism fails, others will continue to protect your assets.
• Minimal Access Scopes: Granting users, systems, and processes only the specific permissions they need to perform their required functions and nothing more.
• Information Flow Control: Ensuring sensitive information is only accessible to those with a legitimate need to know, with restrictions on how that information can be shared and used.
• System Isolation: Segmenting systems and networks into isolated zones to contain security breaches and limit lateral movement.
• Continuous Visibility: Maintaining ongoing awareness of your security posture through active monitoring, testing, and continuous improvement.

Check the Security Fundamentals for practical application guidance.

Operational Implementation Process

1. Critical Asset Identification: Map and document the assets that would cause significant harm to your organization if compromised.
2. Practical Threat Analysis: Identify specific, relevant threat actors and their tactics based on your organization's profile.
3. Actionable Vulnerability Assessment: Systematically identify and validate weaknesses in your environment through practical testing.
4. Contextual Risk Evaluation: Analyze identified risks in the context of your business to drive informed decision-making.
5. Targeted Control Deployment: Implement security controls that address prioritized risks while minimizing operational friction.

Check out the Operational Implementation Process for detailed implementation actions.

Web3-Specific Considerations

In Web3 environments, operational security must address unique challenges:

• Transparency vs. Privacy: Balancing blockchain transparency with the need for operational secrecy
• Decentralized Operations: Securing operations across distributed teams and systems
• Cryptocurrency Security: Protecting digital assets and private keys
• Smart Contract Vulnerabilities: Addressing the immutable nature of deployed code
• Community Dynamics: Managing security in open, community-driven projects

Check out Web3 considerations for more details on these topics.

Security Fundamentals

🔑 Key Takeaway: Effective security operations are built on five practical fundamentals: layered protective measures, minimized access scopes, controlled information flows, system isolation, and continuous visibility — working together to secure critical assets in dynamic environments.

Relationship to Implementation Process

This document outlines the foundational security approaches that should be embedded throughout your organization's operations. They complement the practical Operational Implementation Process, which defines specific action steps:

• These fundamentals establish enduring approaches that shape your security architecture
• The implementation process provides a sequential workflow for security teams to follow

While these fundamentals provide the security principles that should be consistently applied across your environment, the implementation process offers a structured methodology for putting security into practice. Both elements must work in concert - these fundamentals guide your overall approach, while the implementation process provides the tactical roadmap.

For organizations just beginning their security journey, start with the Operational Implementation Process for concrete steps.

The ultimate goal is to prevent unauthorized access to systems and information that could cause operational, financial, or reputational harm if compromised.

Practical Example: Web3 Organization

Consider a Web3 project managing a DeFi protocol with a treasury of $10M in assets. Practical security fundamentals in action include:

• Layered protection: Hardware security modules for key storage, multi-signature requirements (3-of-5) for transactions, automated monitoring for unusual patterns, and regular third-party security audits
• Minimal access scopes: Deployment keys accessible only to specific DevOps team members, with different permission levels strictly enforced between development, staging, and production environments
• Information flow control: Private keys for multi-signature wallets distributed among trusted team members based on role, with sensitive incident response procedures restricted to the security team
• System isolation: Clear separation between development environments and production systems, with treasury management isolated from day-to-day operations
• Continuous visibility: Real-time monitoring systems tracking transaction patterns, weekly security reviews, and quarterly penetration tests with findings addressed in prioritized sprints

1. Layered Protection

Implement multiple overlapping security controls so that if one mechanism fails, others will continue to protect your assets.

🔗 Related Framework: This approach is reinforced in frameworks like Infrastructure with Zero-Trust Principles and Network Security.

Practical Application

1. Implement multiple defensive mechanisms that protect against the same risks using different methods
   • Example: Protect admin interfaces using network ACLs, MFA, time-limited access windows, and anomaly detection
2. Deploy protection at each layer of your technology stack
   • Network layer: Firewalls, network segmentation, DDoS protection
   • Host layer: Endpoint protection, host-based IDS, secure configuration
   • Application layer: Input validation, output encoding, API security
   • Data layer: Encryption, access controls, data loss prevention
3. Identify and eliminate single points of failure in your security architecture
   • Map defense coverage to ensure overlapping protections
   • Document security dependencies and create contingency plans
4. Test defensive layers regularly through realistic scenarios
   • Conduct tabletop exercises focused on specific defensive failures
   • Use red team exercises to validate defense-in-depth effectiveness
5. Maintain a continuous improvement cycle for each defensive layer
   • Review and update security controls after incidents or near-misses
   • Track industry developments to identify emerging defensive tactics

2. Minimal Access Scopes

Grant users, systems, and processes only the specific permissions they need to perform their required functions and nothing more.

🔗 Related Framework: For detailed implementation, see Identity and Access Management and Role-Based Access Control.

Practical Application

1. Implement a structured permission model that starts with zero access
   • Default deny: Require explicit permission grants for all access
   • Document justification for each permission granted
   • Create standardized role templates for common job functions
2. Establish automated processes for access lifecycle management
   • Onboarding: Provision minimal initial access based on role
   • Role changes: Adjust permissions when responsibilities change
   • Offboarding: Remove all access immediately upon departure
3. Apply time-based restrictions to elevated privileges
   • Use just-in-time access for administrative functions
   • Implement automatic session termination after periods of inactivity
   • Require re-authentication for sensitive operations
4. Conduct regular access reviews with verification
   • Quarterly: Review all privileged accounts and service accounts
   • Semi-annually: Audit all standard user accounts and group memberships
   • Use automated tools to identify inactive or excessive permissions
5. Implement technical controls to enforce minimal access
   • Application permissions: API scopes, feature flags, entitlement checks
   • Infrastructure permissions: IAM policies, network ACLs, resource policies
   • Database permissions: Row-level security, column-level controls

3. Information Flow Control

Ensure sensitive information is only accessible to those with a legitimate need to know, with restrictions on how that information can be shared and used.

🔗 Related Framework: This approach is supported by practices in Data Protection and aspects of Privacy.

Practical Application

1. Implement a practical data classification system with clear handling requirements
   • Public: Information approved for general distribution
   • Internal: Business information for employee use only
   • Confidential: Sensitive information requiring specific protections
   • Restricted: Critical information with strictly controlled access
2. Define and enforce data handling procedures for each classification level
   • Storage requirements: Where information can be stored
   • Transmission rules: How information can be sent/shared
   • Processing restrictions: How information can be used
   • Retention limits: How long information should be kept
3. Deploy technical controls to enforce information flow policies
   • Data loss prevention tools to monitor and block unauthorized sharing
   • Encryption for data at rest and in transit based on sensitivity
   • Information rights management for persistent protection
4. Establish secure channels for different types of communication
   • High-sensitivity: End-to-end encrypted messaging with disappearing messages
   • Medium-sensitivity: Encrypted collaboration platforms with access controls
   • Low-sensitivity: Standard business communication tools
5. Train users on practical information handling procedures
   • Provide clear guidelines with concrete examples
   • Use realistic scenarios in training materials
   • Conduct periodic verification checks

4. System Isolation

Segment systems and networks into isolated zones to contain security breaches and limit lateral movement.

Practical Application

1. Implement network segmentation based on security requirements
   • Create security zones with consistent trust levels
   • Implement strict traffic control between zones
   • Document and regularly review allowed communication paths
2. Establish environment separation with controlled boundaries
   • Maintain distinct development, testing, staging, and production environments
   • Implement one-way data flows from higher to lower environments
   • Control code promotion processes between environments
3. Isolate high-value systems with enhanced protection
   • Place critical infrastructure on dedicated hardware
   • Example: Run blockchain nodes on dedicated hardware isolated from general workstations
   • Implement jump servers or privileged access workstations for administrative access
4. Apply micro-segmentation where appropriate
   • Container isolation: Enforce pod security policies and network policies
   • Application segmentation: Implement service meshes with mutual TLS
   • Process isolation: Use containerization, virtualization, or sandboxing
5. Monitor and enforce boundary controls
   • Implement egress filtering to control outbound connections
   • Deploy internal firewalls between segments
   • Use network monitoring to detect unauthorized communication attempts

5. Continuous Visibility

Maintain ongoing awareness of your security posture through active monitoring, testing, and continuous improvement.

🔗 Related Framework: For implementation details, see the Monitoring framework, including Guidelines and Thresholds. Also relevant is Incident Management for response to detected issues.

Practical Application

1. Implement a multi-layered monitoring strategy
   • System monitoring: Performance, availability, and system integrity
   • Security monitoring: Threat detection, anomaly identification, and correlation
   • Compliance monitoring: Policy enforcement and regulatory requirements
   • Establish clear ownership for each monitoring domain
2. Define actionable metrics tied to security objectives
   • Leading indicators: Metrics that help predict future issues
   • Example: Percentage of systems with current patches
   • Lagging indicators: Metrics that measure past performance
   • Example: Mean time to detect and respond to incidents
3. Establish a regular testing cadence to validate security controls
   • Vulnerability scanning: Weekly automated scans
   • Penetration testing: Quarterly focused tests on critical systems
   • Red team exercises: Annual comprehensive assessments
4. Implement a structured incident management process
   • Define clear incident response procedures with specific roles
   • Conduct regular tabletop exercises to practice response
   • Perform thorough post-incident reviews focused on improvement
   • Create feedback loops to security controls based on incidents
5. Maintain an active threat intelligence program
   • Collect intelligence relevant to your specific environment
   • Analyze and contextualize threats for your organization
   • Disseminate actionable intelligence to appropriate teams
   • Use threat intelligence to drive security improvements

Operational Implementation Process

🔑 Key Takeaway: Operational security is implemented through a practical five-phase process: critical asset identification, practical threat analysis, actionable vulnerability assessment, contextual risk evaluation, and targeted control deployment.

Relationship to Security Fundamentals

This document outlines a practical implementation process for operational security that organizations can follow in sequence. This process complements the Security Fundamentals document, which defines the guiding principles:

• This process provides a sequential workflow for security teams to follow
• The fundamentals establish enduring principles that shape security architecture

While this process offers a concrete methodology for implementation, the fundamentals establish the ongoing security approaches that must be maintained throughout your systems. Both elements must work together: the fundamentals guide your overall approach, while this process provides the tactical roadmap.

For organizations just beginning their security journey, start here with these concrete implementation steps.

1. Critical Asset Identification

Map and document the assets that would cause significant harm to your organization if compromised.

🔗 Related Framework: This phase integrates with Asset Inventory practices and drives Data Protection strategies.

Implementation Actions

1. Conduct asset discovery across your environment using both automated tools and manual inventorying
   • Digital assets: Use network scanning, CMDB tools, and cloud resource inventories
   • Physical assets: Document hardware, systems and access points
2. Apply a practical classification system with clear, actionable categories
   • High-value assets: Direct financial impact if compromised (e.g., private keys, treasury wallets)
   • Operational assets: Required for continued business operations
   • Sensitive data: Includes Customer information, intellectual property, strategic plans
3. Map information flows to understand how data moves between systems
4. Assign specific owners responsible for each asset category
5. Establish a sustainable review cadence based on your environment
   • High-volatility environments: Monthly reviews
   • Stable environments: Quarterly reviews
   • Document trigger events that require immediate reassessment (e.g., acquisitions, new product, etc.)

2. Practical Threat Analysis

Identify specific, relevant threat actors and their tactics based on your organization's profile.

🔗 Related Framework: For hands-on approaches, see Understanding Threat Vectors and Threat Modeling frameworks.

Implementation Actions

1. Create a focused threat profile based on:
   • Your industry's recent attack history (consult threat intelligence reports)
   • Your organization's specific attack surface
   • The value of your assets to different adversaries
2. Document concrete adversary personas with specific capabilities:
   • External attackers: Targeted vs. opportunistic
   • Insider risks: Privileged users, contractors, disgruntled employees
   • Supply chain actors: Vendors with access to your systems
3. Map threat actors to their likely tactics using MITRE ATT&CK or similar frameworks
4. Establish threat intelligence feeds relevant to your environment
5. Create a lightweight process for updating threat models when new intelligence emerges

3. Actionable Vulnerability Assessment

Systematically identify and validate weaknesses in your environment through practical testing.

🔗 Related Framework: This aligns with the Security Testing framework and includes practices like Static Application Security Testing and Dynamic Application Security Testing.

Implementation Actions

1. Implement a layered vulnerability discovery program:
   • Automated scanning: Deploy tools appropriate for your environment (infrastructure, applications, cloud)
   • Manual testing: Conduct regular penetration tests focusing on critical systems
   • Red team exercises: Simulate real-world attacks against your defenses
2. Examine security processes for operational gaps:
   • Incident response procedures: Test through tabletop exercises
   • Access management: Audit privilege escalation paths
   • Change management: Review for security bypass opportunities
3. Evaluate security awareness through:
   • Targeted phishing simulations
   • Knowledge assessments
   • Procedural compliance checks
4. Document findings in a centralized vulnerability management system with clear ownership
5. Implement a consistent vulnerability scoring system to enable prioritization

4. Contextual Risk Evaluation

Analyze identified risks in the context of your business to drive informed decision-making.

🔗 Related Framework: For practical approaches, see Governance and Risk Management frameworks.

Implementation Actions

1. Establish a practical risk calculation methodology that considers:
   • Business impact (financial, operational, reputational)
   • Exploitation likelihood based on real-world attack patterns
   • Existing control effectiveness
2. Create a prioritized risk register with clear owners and timelines
3. Define risk acceptance criteria based on your organization's risk tolerance
4. Develop risk narratives that translate technical findings into business impacts
5. Implement a streamlined risk review process that:
   • Enables timely decisions
   • Involves appropriate stakeholders
   • Documents rationale for future reference
   • Triggers reassessment when conditions change

5. Targeted Control Deployment

Implement security controls that address prioritized risks while minimizing operational friction.

🔗 Related Framework: Implementation integrates with Security Automation and control frameworks like Infrastructure and Identity and Access Management.

Implementation Actions

1. Design a defense-in-depth strategy with layered controls:
   • Preventive: Stop attacks before they succeed
   • Detective: Identify attacks in progress
   • Responsive: Limit damage from successful attacks
   • Recovery: Restore normal operations
2. Select controls using a balanced approach:
   • Technical feasibility in your environment
   • Implementation and maintenance costs
   • Potential operational impact
   • Coverage of multiple risks where possible
3. Implement controls using a phased approach:
   • Quick wins: Deploy high-impact, low-effort controls first
   • Foundational controls: Build core security capabilities
   • Advanced measures: Address sophisticated threats
4. Validate control effectiveness through:
   • Technical testing
   • Process verification
   • Metrics collection
5. Document clear procedures for:
   • Control operation
   • Maintenance requirements
   • Monitoring and alerting
   • Incident response when controls fail

Web3-Specific OpSec Considerations

🔑 Key Takeaway: Web3 environments require specialized security approaches that balance blockchain transparency with privacy, address immutability risks, manage self-custody responsibilities, secure decentralized operations, mitigate smart contract vulnerabilities, and navigate community-driven security challenges.

In addition to traditional OpSec principles, Web3 environments require consideration of unique challenges. Many organizations claim to be backed only by decentralized technologies, but they later realize that part of their process is dependant on technologies that are not.

Transparency vs. Privacy

Balancing the transparent nature of blockchain with the need for operational privacy.

Suggested steps

1. Understand what information is publicly visible on-chain
   • Transaction amounts, addresses, contract interactions, and timestamps
   • Use block explorers and analysis tools to understand your on-chain footprint
2. Develop strategies to maintain operational privacy while utilizing public blockchains
   • Use different addresses for different transaction types or business functions
   • Consider privacy-focused layer 2 solutions for sensitive operations
3. Use privacy-enhancing technologies where appropriate
   • ZK (Zero-Knowledge) protocols for privacy-preserving computations
   • Privacy pools or similar technologies (when legally permissible)
   • Privacy-focused blockchains for specific operations (e.g., Monero, Zcash)

Immutability and Finality

Recognizing that blockchain transactions are generally irreversible, requiring heightened security before execution.

Suggested steps

1. Implement robust verification procedures before executing transactions
   • Mandatory multi-person review for transactions above defined thresholds
   • Automated checks for anomalous transaction patterns
   • Hash verification of destination addresses
2. Use multi-signature requirements for high-value transactions
   • 3-of-5 or 2-of-3 signature schemes for treasury operations
   • Hardware wallets for each signer with physical separation
   • Time-locks for large transfers (24-48 hour delay before execution)
3. Deploy transaction simulation tools to verify outcomes before execution
   • Use Tenderly or similar platforms to simulate transactions in a fork of the chain
   • Verify gas estimates and test with small amounts first when using new contracts\
   • Use auxiliary tools such as Safe Multi-sig Transaction Hashes
4. Establish secure deployment practices for smart contracts
   • Use formal verification tools before mainnet deployment
   • Implement deployment scripts with dry-run functionality
   • Require multiple approvals in your deployment pipeline
   • Consider gradual deployments with circuit breakers for critical contracts

Self-Custody Responsibility

Managing private keys and digital assets with appropriate security controls.

🔗 Related Framework: For detailed guidance on wallet security practices, see the Wallet Security framework.

Suggested steps

1. Develop clear procedures for wallet security
   • Air-gapped hardware wallet setups for cold storage
   • Specific seed phrase backup procedures (e.g., metal backups, split storage)
   • Clear rules for when hot vs. cold wallets should be used
2. Implement separation of duties for transaction approval
   • Different roles for transaction initiation, verification, and execution
   • Rotation of responsibilities to prevent single points of compromise
   • Hardware security modules (HSMs) for institutional-grade key management
3. Balance security with operational efficiency
   • Define thresholds for different security requirements (e.g., <$10K, $10K-$100K, >$100K)
   • Implement tiered wallet architecture (hot wallets for operations, cold storage for reserves)
   • Establish secure methods for replenishing hot wallets from cold storage
4. Stay up-to-date with best practices in wallet security and custody solutions
   • Subscribe to security advisory services for cryptocurrencies
   • Follow developments in MPC (Multi-Party Computation) wallet technologies
   • Regularly review and test recovery procedures

Decentralized Operations

Securing operations across distributed teams and systems.

Suggested steps

1. Establish clear security protocols for remote team members
   • Device security requirements (disk encryption, endpoint protection, auto-updates)
   • Secure home network guidelines (dedicated VLANs, strong WPA3 passwords)
   • Clear policies for public WiFi usage (always-on VPN requirement)
2. Use secure communication channels for sensitive discussions
   • End-to-end encrypted messaging (Signal, Matrix/Element with verified devices)
   • Ephemeral messaging for highly sensitive topics (disappearing messages)
   • Encrypted video conferencing with waiting rooms and passwords (Jitsi, Signal)
   • PGP-encrypted emails for sensitive communications that need to be preserved
3. Implement strong authentication for all team members
   • Hardware security keys (Yubikeys, Passkeys) as primary 2FA method
   • TOTP apps as backup authentication method (not SMS)
   • Passwordless authentication where possible (WebAuthn/FIDO2)
   • Regular access review and prompt offboarding procedures
4. Create guidelines for secure collaboration in a distributed environment
   • Encrypted file storage and sharing (Cryptomator, end-to-end encrypted cloud storage)
   • Private repositories with signed commits for code collaboration
   • Secure DevOps practices for CI/CD pipelines
   • Role-based access to administrative systems with just-in-time privilege elevation

Smart Contract Vulnerabilities

Addressing the immutable nature of deployed code.

Suggested steps

1. Conduct thorough code reviews and security audits before deployment
   • Multiple independent security audits for critical contracts
   • Comprehensive test coverage (>95%) for all contract functions
   • Symbolic execution and static analysis tools (Slither, Mythril)
2. Implement upgradability patterns where appropriate
   • Proxy patterns with clear governance mechanisms
   • Immutable core logic with upgradeable periphery
   • Emergency pause functionality with decentralized controls
3. Use formal verification where possible
   • Mathematical proofs of contract correctness for critical functions
   • Verification of business logic and security properties
   • Property-based testing frameworks (Echidna, Scribble)
4. Maintain comprehensive testing environments
   • Local development environments with mainnet forking
   • Testnet deployments with real-world simulation
   • Adversarial testing and red team exercises
5. Consider timelocks and circuit breakers for critical functions
   • Time-delayed administration actions (48-72 hours)
   • Value-limit circuit breakers for suspicious transaction volumes
   • Decentralized monitoring and alerting systems

Community Dynamics

Managing security in open, community-driven projects.

Suggested steps

1. Develop clear security guidelines for community contributors
   • Documented security policies in repositories
   • Security templates for pull requests
   • Required security reviews for changes to sensitive components
2. Establish review processes for community-submitted code
   • Multi-level review requirements based on code criticality
   • Automated security scanning integrated into CI/CD pipelines
   • Bounty programs for vulnerability identification
3. Create security awareness programs for the community
   • Educational resources on common vulnerabilities
   • Regular security-focused community calls or workshops
   • Recognition for security-conscious contributions
4. Balance transparency with operational security needs
   • Clear guidelines on what information should remain private
   • Secure channels for reporting vulnerabilities
   • Responsible disclosure policies and timelines
   • Public security incident post-mortems (with appropriate redactions)

Threat Modeling Overview

🔑 Key takeaway: Think of threat modeling as your security roadmap. It's how you understand what you need to protect, who might try to steal it, and how they might do it. From random hackers to state actors, knowing your potential attackers helps you build defenses that actually matter. It's about being smart with your security resources and focusing on what really needs protection.

Effective security requires understanding what you're protecting and who you're protecting it from. Without a structured threat model, security efforts become unfocused and inefficient. Different entities face different threats based on their assets, visibility, and technological footprint.

Why is it important

Failure to implement threat modeling has led to catastrophic security breaches:

• How Threat Modeling Could Have Prevented the 1.5B ByBit Hack
• North Korea's Lazarus Group stole $620 million from Axie Infinity's Ronin bridge (2022) through a sophisticated attack targeting blockchain infrastructure
• The Nomad bridge lost $190 million (2022) through a critical vulnerability that allowed attackers to bypass transaction validation
• The 2020 Twitter compromise resulted in hijacked high-profile accounts being used for cryptocurrency scams

Common pitfalls & examples

• Tunnel vision: The Colonial Pipeline attack (2021) succeeded through a legacy VPN account without MFA, while the company focused security resources on operational technology
• Unrealistic scenarios: Many organizations over-invested in zero-day defense while leaving basic phishing vulnerabilities open
• Static models: Equifax's 2017 breach occurred partly because threat models weren't updated to reflect new attack patterns
• Insider blindness: The 2020 Twitter compromise of high-profile accounts happened when internal admin tools weren't included in threat modeling

Organizations that implement threat modeling can focus limited security resources on their most significant risks, avoiding both over-protection of low-value assets and under-protection of critical systems. A DeFi protocol that fails to properly identify potential attack vectors, might focus extensively on their website and marketing infrastructure while overlooking smart contract security.

Effective threat modeling ensures security teams can identify and document all potential attack paths - enabling risk management teams to later assess and prioritize these threats effectively. Without threat modeling, organizations often distribute security resources evenly across all assets regardless of risk levels.

Practical guidance

🔗 Related Framework: For detailed approaches, see Understanding Threat Vectors and Threat Modeling frameworks.

Asset inventory

1. Digital value stores: Document cryptocurrencies, tokens, NFTs, and any assets directly convertible to monetary value
2. Credentials & access information: Catalog passwords, API keys, recovery seeds/phrases, private keys, and other non-physical authentication data
3. Identify all Hardware & physical devices:
   • Computing devices: Computers, phones, tablets, servers
   • Security hardware: Hardware wallets, YubiKeys, MFA devices, HSMs
   • Physical security: Office equipment, security systems, physical access controls
4. Infrastructure & systems: Map cloud resources, development environments, network equipment, and third-party services
5. Sensitive information & intellectual property: Track code repositories, proprietary algorithms, customer data, business documents, email archives, and backup files
6. Legal & compliance assets: Identify digital certificates, identity documents, contracts, and regulatory compliance documentation

For these, you can use technologies such as:

• Configuration Management Databases (CMDBs)
• Specialized asset tracking software
• GRC (Governance, Risk, and Compliance) platforms with asset inventory modules

⬇️ Collapsible Example: Pinnipeds Inc. asset inventory

Pinnipeds Inc. Asset Inventory

Pinnipeds Inc. is a small company with 15 employees. Here's how they categorized their assets:

Asset Category	Items
Digital value stores	• Company treasury holding 5 BTC and 50 ETH for operations • Client tokens held in custody during project development • Test tokens on various testnets for development purposes
Credentials & access information	• Multi-signature wallet configuration (3-of-5 signers) • Password manager company accounts for all employees • Recovery seed phrases (stored separately from devices) • SSH keys for server access • API keys for third-party services
Hardware & physical devices	Computing devices: • 15 developer laptops with encrypted drives • 5 company mobile phones for executives • 2 physical servers for internal development Security hardware: • Hardware wallets for each founding member (3) • YubiKeys for all developers for GitHub access • Biometric access readers Physical security: • Office security system with cameras • Card readers for building access • Secure storage for sensitive documents
Infrastructure & systems	• AWS cloud infrastructure for production environments • GitHub organization with private repositories • CI/CD pipeline tools (Jenkins, GitHub Actions) • Company VPN for remote work • Slack and Discord for internal and client communications
Sensitive information & IP	• Custom smart contract code for clients • Internal research on blockchain optimization • Client database with contact and project information • Financial records and business strategy documents • Employee personal information
Legal & compliance assets	• Company incorporation documents • Client contracts and NDAs • Regulatory compliance documentation for different jurisdictions • SSL certificates for company websites • Code audit reports and security assessments

Adversary analysis

1. Classify potential attackers by tiers:
   • Tier 1 (Opportunistic): Random cybercriminals, script kiddies, automated scanners
   • Tier 2 (Targeted): Organized crime groups, corporate competitors, angry ex-employees
   • Tier 3 (Advanced): Nation-state actors, APT groups, sophisticated criminal syndicates
2. Document adversary capabilities and motivations:
   • Technical capabilities and resources
   • Financial motivations or strategic goals
   • Persistence level (hit-and-run vs. long-term compromise)

⬇️ Collapsible Example: Analysis of adversaries targeting Pinnipeds Inc.

Pinnipeds Inc. Adversary Analysis

Adversary Tier	Characteristics	Examples & Techniques
Tier 1 (Opportunistic)	Who: Individual hackers, script kiddies, automated scanners/bots Motivations: Quick financial gain, building reputation, opportunistic theft Capabilities: Using public exploits, basic phishing, automated scanning tools Targets: Public-facing infrastructure, employee email accounts, known vulnerabilities	• Crypto wallet draining scams • Generic phishing campaigns • Website defacement • Automated vulnerability scanning
Tier 2 (Targeted)	Who: Organized criminal groups, competitors, disgruntled former employees Motivations: Financial theft, competitive advantage, sabotage, revenge Capabilities: Custom malware, spear phishing, social engineering, persistent attacks Targets: Company treasury wallets, intellectual property, client data, employee credentials	• Targeted social engineering of specific developers • Custom exploits for Pinnipeds' systems • Extended reconnaissance operations • Sophisticated phishing campaigns
Tier 3 (Advanced)	Who: Nation-state actors, sophisticated criminal syndicates, APT groups Motivations: Strategic intelligence, large-scale financial theft, disruption Capabilities: Zero-day exploits, supply chain attacks, long-term persistence, stealth techniques Targets: Crypto treasury, proprietary algorithms, strategic business information, infrastructure access	• Lazarus Group's systematic targeting of cryptocurrency organizations • Supply chain compromises • Advanced persistent threats with long dwell times • Multi-stage attack campaigns

Attack vector mapping

1. Map potential attack vectors:
   • Technical: Zero-day exploits, vulnerability exploitation, network attacks
   • Social: Phishing, social engineering, insider threats
   • Physical: Device theft, office intrusion, hardware tampering
   • Operational: SIM swapping, supply chain compromise, third-party breaches
2. Document potential attack scenarios for each critical asset
3. Link attack vectors to adversary capabilities identified in your adversary analysis

⬇️ Collapsible Example: Attack Vector Mapping for Pinnipeds Inc.

Pinnipeds Inc. Attack Vector Analysis

Critical Asset: Treasury Wallet (Financial)

Attack Vector	Description	Relevant Adversary
Phishing	Targeted emails to obtain wallet credentials	Tier 1-2 attackers
Social engineering	Manipulating employees to gain access	Tier 2 attackers
Supply chain compromise	Compromised wallet software	Tier 3 attackers
Insider threat	Disgruntled employee with access	Tier 2 attackers

Critical Asset: Source Code (Intellectual Property)

Attack Vector	Description	Relevant Adversary
GitHub account compromise	Targeting developer credentials	Tier 1-3 attackers
CI/CD pipeline injection	Injecting malicious code during build	Tier 3 attackers
Code repository breach	Direct attack on GitHub infrastructure	Tier 3 attackers
Developer machine compromise	Targeting local development environment	Tier 2-3 attackers

Critical Asset: Client Data (Customer Information)

Attack Vector	Description	Relevant Adversary
Database exploitation	SQL injection or other DB vulnerabilities	Tier 1-2 attackers
AWS credential theft	Stolen cloud access credentials	Tier 2 attackers
API vulnerabilities	Insecure API endpoints	Tier 1-2 attackers
Data in transit interception	Man-in-the-middle attacks	Tier 2-3 attackers

Implementation details

Role-specific considerations:

• Security specialists: Lead the threat modeling process, provide intelligence on current threats
• Operations: Contribute infrastructure knowledge and implement technical controls
• Developers: Identify code-level vulnerabilities and secure development practices
• HR/Management: Address insider threat risks and security awareness training
• Community/Marketing: Consider reputation risks and public-facing attack surfaces

Practical Frameworks and Tools

After completing the asset inventory, adversary analysis, and attack vector mapping, organizations can leverage established frameworks and visualization techniques to systematize their threat modeling approach. These tools help translate the theoretical understanding of threats into practical, actionable security measures.

STRIDE Threat Categorization Framework

The STRIDE framework, developed by Microsoft in the late 1990s, offers a systematic approach to identifying and categorizing threats. It maps directly to key security properties that must be protected in any system:

Organizations can apply STRIDE systematically to each component identified in their asset inventory to ensure comprehensive threat coverage.

Attack Trees: Visualizing Attack Paths

Attack trees provide a structured method to visualize potential attack scenarios against critical assets. They help security teams understand the relationship between different attack vectors and identify the most critical paths requiring mitigation:

Goal: Steal crypto assets
├── Compromise user wallet
│   ├── Phishing attack
│   │   └── Mitigate: Security awareness training
│   └── Malware infection
│       └── Mitigate: Endpoint protection
├── Attack exchange
│   ├── API key theft
│   │   └── Mitigate: IP restrictions, 2FA
│   └── Credential stuffing
│       └── Mitigate: Unique passwords, MFA
└── SIM swapping
    └── Mitigate: Hardware keys, non-SMS 2FA

Further Reading & Tools

Frameworks & References

• NIST SP 800-154: Guide to Data-Centric System Threat Modeling
• OWASP Threat Modeling Cheat Sheet
• Microsoft STRIDE Model
• MITRE ATT&CK Framework

Visualization & Modeling Tools

• Microsoft Threat Modeling Tool,
• OWASP Threat Dragon

Risk Management

🔑 Key takeaway: Risk management transforms threat information into actionable priorities. It helps you determine which threats matter most, where to allocate resources, and how to make security trade-offs that align with business goals.

Effective risk management builds upon threat modeling to assess, prioritize, and mitigate identified security risks. While threat modeling identifies what needs protection and potential attack vectors, risk management determines which threats warrant immediate attention and resources.

Risk Assessment Process

🔗 Related Framework: This process builds directly on outputs from Threat Modeling.

Key Components

1. Impact Analysis: Estimating the potential consequences of a security incident
2. Likelihood Determination: Assessing the probability of a threat exploiting a vulnerability
3. Risk Calculation: Combining impact and likelihood to determine risk levels
4. Risk Prioritization: Determining which risks to address first

Implementation Steps

1. For each threat scenario identified in threat modeling, assign impact ratings based on financial, operational, and reputational factors
2. Determine likelihood based on threat intelligence and historical data
3. Calculate risk scores (typically Risk = Impact × Likelihood)
4. Prioritize risks based on scores and organizational context

Prioritization Methodology

Not all risks require the same level of attention. Prioritize based on:

Trade-off Analysis

Security decisions often involve trade-offs between security, usability, cost, and other factors. Trade-off analysis helps make informed decisions.

Key Considerations

Decision-Making Framework

1. Define: Clearly articulate the security challenge and objectives
2. Identify: Enumerate all viable options
3. Analyze: Evaluate each option against established criteria
4. Select: Choose the option that best balances competing priorities
5. Implement: Execute the chosen option
6. Review: Assess the effectiveness of the decision and adjust as needed

Web3-Specific Considerations

In Web3 environments, risk management must address unique challenges:

Unique Risk Factors

Best Practices for Web3 Organizations

⬇️ Collapsable Example: Risk Assessment for Pinnipeds Inc.

Pinnipeds Inc. Risk Assessment

Building on the threat vectors identified during threat modeling, Pinnipeds Inc. conducted a risk assessment:

Risk Calculation Methodology

Rating	Impact	Likelihood
1	Minimal	Rare
2	Minor	Unlikely
3	Moderate	Possible
4	Major	Likely
5	Severe	Almost Certain

Formula: Risk Score = Impact × Likelihood

High Risk Threats (Score 15-25)

Threat Scenario	Likelihood	Impact	Risk Score	Reasoning
Treasury wallet compromise	4	5	20	High impact due to direct financial loss; relatively high likelihood given frequency of attacks on crypto companies
Source code theft	3	5	15	High impact due to IP loss and potential backdoor insertion; medium likelihood based on industry intelligence
Phishing of employees	5	3	15	Medium impact as most employees have limited access; very high likelihood based on attack trends

Medium Risk Threats (Score 8-14)

Threat Scenario	Likelihood	Impact	Risk Score	Reasoning
Client data breach	3	4	12	Major impact to reputation; moderate likelihood based on API exposure
DDoS on infrastructure	4	3	12	Moderate impact on operations; likely to occur given industry trends
AWS credentials leaked	2	5	10	Severe impact if exploited; unlikely due to current controls

Mitigation Decision Process

Factor	Approach
Resource allocation	60% of security budget allocated to high-risk threats
Implementation timeline	High-risk mitigations scheduled for completion within 30 days
Control selection criteria	Controls evaluated based on cost, operational impact, effectiveness, and implementation time

This risk-based approach allowed Pinnipeds Inc. to make informed decisions about which security controls to implement first, focusing resources where they would have the greatest risk-reduction impact.

Further Reading & Tools

• NIST Risk Management Framework
• ISO 31000:2018 Risk Management Guidelines
• FAIR (Factor Analysis of Information Risk) Framework
• OWASP Risk Rating Methodology
• Tools: Eramba (open source GRC)

Operational Security while traveling

🔑 Key Takeaway: Travel introduces unique security risks to your digital assets and sensitive information. Proper preparation before, vigilance during, and careful review after travel creates a comprehensive defense strategy that balances security with practical usability.

When we travel, our normal security routines are disrupted, and we face elevated risks from physical theft, digital surveillance, border inspections, and social engineering. Web3 professionals face additional challenges when traveling with crypto assets or access to treasury funds.

The resources in this section provide practical guidance for maintaining operational security while traveling:

• OpSec Travel Guide - A comprehensive resource covering all aspects of travel security with in-depth explanations and implementation details
• Too Long; Did not Read version - A condensed checklist format for quick security planning before and during travel

Three-phase Security Approach

Our travel security framework is organized into three critical phases:

1. Pre-travel preparation: Risk assessment, device hardening, backup creation, and contingency planning
2. On-trip vigilance: Network security, physical device protection, social engineering awareness, and maintaining operational security
3. Post-travel review: Device inspection, account security verification, and lessons learned documentation

Additional considerations are provided for high-risk travelers who may face targeted threats due to their role or access to valuable assets.

Personal security travel guide — full

🔑 Key Takeaway: Minimize data exposure by carrying only essential devices with full-disk encryption and updated software. Secure accounts with backup 2FA methods, avoid biometrics at borders, use trusted networks with VPNs, and never leave devices unattended. Guard against USB attacks, shoulder surfing, and hidden cameras. For crypto, use strong passphrases and never travel with seed phrases. Upon returning, scan devices for malware and consider resetting high-risk devices.

❗ This is not, by any means, an extensive guide on this subject or expected to be followed at its core. Its intention is to guide and provide hints as to where to apply security. This will vary depending on case to case, or, in other words, the risks you expose yourself to, by specifically traveling.

This guide is categorized into four sections:

1. Before traveling: All the things you could do before you depart, such as hardening some devices or making sure you have a backup of the data you’ll be traveling with, even letting know someone you’ll be calling in case of an emergency and how to identify you. This does not necessarily mean that if you’re reading this while traveling you cannot do anything from that list, only that it might be more challenging to execute depending on your context.
2. While traveling: All the things you have to pay attention to or take care of while on the move. Is it necessary to connect to that conference’s WiFi? Have you checked if there is a camera that might be recording your keystrokes? Leaving your computer unattended or just running whatever software your hackathon teammate asks you to download in order for your promising project to win.
3. Returning home: Not in the literal sense of it, but directed toward all the things you have to do after your travels. From updating your processes based on experience to wiping exposed devices before rejoining them to your networks.
4. Additional information for high-profile targets: If you are a high-profile target, you’ll evidently realize that some of these initial suggestions fall short within your threat model. This section provides a hint toward profiles like yours.

Before traveling

💡Remove or securely store any data, devices, printed files, and documents you don’t absolutely need on the trip. The less sensitive information and fewer critical assets you carry, the lower the risk and impact if loss, theft, or inspection occurs. Minimize your digital and physical footprint by leaving backups and originals securely at home or in trusted locations, and encrypt what must travel with you. This principle applies to laptops, phones, hardware wallets, paper backups, and any portable storage media.

Perform a quick threat model

Even if you are already traveling, take 5 minutes to map out your risks. Identify what assets you're carrying (laptops, phones, hardware wallets, seed phrases, account access), who might target them (thieves, cybercriminals, border agents, etc.), and how attacks might happen (device theft, tampering, malware, coercion). For each threat, plan a mitigation. For example, if you're carrying a hardware wallet, a threat is pickpocketing – mitigation could be keeping it attached to yourself (just don't use ledger's necklace) and securing it with a secure PIN/passphrase (no patterns, not repeated across devices).

This exercise keeps security measures proportionate to your situation.

Secure devices with encryption & updates

Enable full-disk encryption on all devices (laptops, phones, tablets) to protect data if lost or stolen. Most modern OSes have this by default (e.g. BitLocker for Windows, FileVault for MacOS, LUKS for Linux,or Android/iOS encryption – just ensure a strong password/PIN is set).

Use popular devices like iPhones and Pixels. Install the latest OS and app updates since these patch security vulnerabilities, you can install any of the mobile security applications there are, which adds a layer of security and also reminds you of important security updates.

If you must bring high-risk confidential data, consider encrypting those files individually using tools like VeraCrypt.

Back up and prepare for loss

Back up your devices before travel (and ensure cloud backups like iCloud/Google are up to date). This way, if a device is lost or confiscated, you won’t lose important information. Record device details (make, model, serial numbers, IMEI for phones) and keep that list separate – it will help in filing reports or remote-wipe commands.

If your company uses Mobile Device Management (MDM) on phones or laptops, verify the device is enrolled and you know how to trigger a remote wipe or “lost mode.” Test “Find My” or equivalent device-finding services so you can use them if needed. Pack chargers and cables so you won’t need to borrow unknown ones (which could be malicious).

Protect Accounts with 2FA redundancy

Plan for how you’ll access accounts that use two-factor authentication if your main device is unavailable. For authenticator apps (TOTP codes), print out backup codes for your important accounts and keep them securely in services like 1Password or NordPass. Alternatively, consider storing them elsewhere physically (not on your phone). If your 2FA is tied to a phone number (SMS or voice), disable SMS for 2FA. For technologies that are unfortunately dependent on phone numbers, use a separate line (not your personal one) from services like Google Voice, Burner App or SLYFONE. Transfer your number to an eSIM since they are harder to physically steal or swap than a physical SIM.

Ensure your password manager is accessible – many like 1Password have a Travel Mode that removes sensitive vaults from your device while you travel (you can restore them later). This limits exposure if your device is searched or seized.

You can also register a backup or alternative 2FA method, like a secondary phone (the device) or a PIN-protected hardware key to be used as a passkey. We discourage the use of software passkeys, particularly if you are using a password manager to store both your passwords and passkeys, as this creates a single point of failure.

Secure your wallets and keys

Hardware wallets (e.g. Ledger, Trezor): Update the firmware and test the device before you leave, don’t do this while traveling. Do NOT bring any written seed phrases under any circumstance – seed backups are unencrypted keys that are far easier to steal or copy than a hardware device. Leave seed backups in a secure place and travel only with your hardware wallet. Enable all security features on the device (set a strong PIN, and use a BIP39 passphrase for example, if supported) so that even if the device is stolen, the amount of required information to access your crypto, is high. Carry hardware wallets and security keys in your carry-on or under your sight, not in checked luggage, to avoid loss or tampering.

Yubikeys and 2FA tokens: Bring them to protect logins (they’re the best MFA) and make sure they’re enabled on your critical accounts. Keep them on your person or in a separate bag from your laptop/phone so that a thief or snoop can’t easily steal both at once. If you have a spare hardware wallet or Yubikey, you might leave one at home as a backup in case the one you carry is lost. Add, when possible, an extra layer of security to the token, such as a PIN code.

Lock down phones

On your smartphone, take advantage of security settings before you travel. Set a strong passcode (not just a 4-digit PIN or pattern). Consider disabling Touch ID/Face ID if you might face situations where someone could force-unlock your device using your biometrics – in many jurisdictions, authorities can compel a fingerprint or face scan more easily than a memorized password. At a minimum, know how to quickly and temporarily disable biometrics; for example, on an iPhone, holding the side button and a volume button will trigger an emergency mode that requires the passcode to unlock. On Android, use Lockdown mode if available (which only temporarily disables biometrics and is different from iOS Lockdown Mode).

If you have an iPhone, enable Lockdown Mode (extreme protection on iOS) even if you are not at high risk or traveling to a high-threat region – but be aware it restricts many features, though totally worth it.

Disabling or restricting USB debugging on Android and using iOS USB restricted mode helps prevent unauthorized physical USB access and reduces risks from malicious cables or compromised charging stations.

If your phone is managed by work (MDM), inform your IT team of your travel so they can assist with any location-based security policies and ensure you have the latest security profile. Finally, consider using a dedicated eSIM/local SIM for travel data. This can protect your primary phone number (you can keep your main line on eSIM and turn it off, while using a local data eSIM for mobile internet) and avoids physical SIM issues.

Configure additional phone protections: On iOS devices, disable Control Center and Notification Center access from the lock screen (Settings > Face ID & Passcode) to prevent thieves from seeing notifications or enabling Airplane Mode without unlocking. Disable USB accessory connections when locked to prevent unauthorized connections. For device recovery, ensure Find My iPhone is enabled with "Send Last Location" and "Find Network" options activated so tracking continues even if the device is powered off.

On Android, similar protections can be configured: disable notifications on lock screen (Settings > Notifications > On lock screen > Don't show notifications), and enable "Find My Device" with all location services.

Pay special attention apps security: many financial apps default to PIN verification instead of biometrics, which means a thief who has your phone and knows your PIN could potentially access your financial accounts even if they can't bypass Face ID/Touch ID. Use unique PINs for banking apps that differ from your device PIN, or where possible, configure these apps to require biometric verification for every login.

Minimize digital footprint & social visibility

It's not just cyber threats – operational security matters. Avoid announcing your travel plans publicly on social media and be careful with real-time updates. Posts about being away from home can signal to criminals that you (and possibly valuable devices or even your house) are vulnerable. Consider sharing trip photos and crypto conference highlights after you return or only with trusted contacts. Ensure your social media privacy settings are tightened so strangers can't see your travel posts.

When registering for events, use privacy-focused tools like iOS's Hide My Email or create burner emails through providers like ProtonMail. Avoid giving out personal details unnecessarily during registration—use minimal, generic info to reduce your digital footprint.

Discretion is key: if possible, don't advertise that you work in crypto or carry cryptocurrency. For example, remove or cover any crypto stickers on laptops or bags, and avoid wearing company swag or Bitcoin/Ethereum logos while in transit. These can be neon signs attracting thieves or unwanted attention ("I have valuable data or wallets!"). If asked about your work or luggage by curious strangers, have a cover story (e.g. "I work in finance/IT") rather than "I manage a crypto fund". High-profile team members might travel under pseudonyms or at least not list their company on luggage tags to stay low-profile. Also, be wary that you might be traveling with someone with these characteristics, so don't give them away.

Plan emergency and incident responses

Before departure, know what you'll do if something goes wrong. Have a fallback plan in case of device loss: who will you notify & how (have safe words and beware of deepfakes or impersonations); how will you revoke access to sensitive accounts; and how will you continue working (e.g., a backup laptop or a colleague who can step in).

If traveling to countries with strict tech or encryption laws (e.g., China, Russia, UAE), devices like VPNs, encrypted messaging apps (Signal, or Telegram with Secret Chats only), hardware wallets (Ledger, Trezor), Yubikeys, or encryption software (VeraCrypt, BitLocker) may be flagged by border authorities. Research local laws beforehand. Consider carrying a travel letter from your organization explaining the professional need for these tools, or use sanitized loaner devices to avoid issues at border controls.

Share your itinerary and contact information with a trusted peer so they can assist or monitor for any issues.

Finally, schedule critical work (especially high-value transactions) for before or after your trip if possible, so you’re not forced to do ultra-sensitive actions on the road. Criminals usually play with the “time-sensitive factor,” trying to trick you into doing something quick and urgent, by committing something reckless.

---

While traveling

Network safety – avoid untrusted Wi-Fi & Bluetooth

Treat every network as potentially hostile. Whenever possible, use a cellular connection or a personal hotspot instead of public Wi-Fi – your mobile data is encrypted and safer than an open café or hotel network. If you must use public Wi-Fi (hotel, airport, conference), verify the network name with staff and disable auto-connect features so your devices don't join networks without prompting you.

Turn off Wi-Fi and Bluetooth on your phone and laptop when you're not using them; this reduces the risk of unsolicited connections or Bluetooth-based attacks. Also, disable any device-to-device sharing like AirDrop or Nearby Share to prevent strangers from sending you files.

Use a trustworthy VPN for an extra layer of encryption for your internet traffic, although in most cases by using an updated device, safe hardcoded DNS records, and ensuring SSL while browsing (enforce HTTPS-only-modes or adding “http://*” to your uBlock list, might be enough. A reputable, non-logging VPN (or your company’s VPN) helps protect against snooping on public networks, especially if you’re handling highly sensitive work and using several communication channels.

Using a personal portable router combined with a trusted VPN adds a strong layer of security when connecting to public Wi-Fi networks. This setup creates a private, encrypted tunnel between your devices and the internet, minimizing exposure to malicious actors on shared networks. Whenever possible, prefer mobile data over Wi-Fi, as cellular networks provide better encryption and isolation by default. If you must use Wi-Fi, disable automatic connections and ensure you connect only to verified, trusted networks to reduce risk.

Device handling – keep them close and protected

Never leave your devices (laptops, phones, hardware wallets) unattended or unsecured in public. Keep them on your person or within sight whenever possible. In a conference or cafe, use a cable lock for your laptop if you must step away briefly, take it with you or get someone you trust to watch it over for you.

In hotels/Airbnbs, use the room safe for small devices when you're out, or consider a portable travel safe/bag you can lock to a fixed object. A portable door lock or door jammer for your room can add an extra barrier against intruders (useful in rentals without chain locks). This simple gadget prevents anyone (even with a key) from opening your door while you're inside, giving you peace of mind at night. When out and about, be mindful of pickpockets – use bags that zip and consider a subtle anti-theft backpack for expensive gadgets or important assets.

For hardware wallets or Yubikeys, a good practice is to separate them from the device they authenticate: e.g. don't carry your Yubikey on the same keychain as your laptop bag key; keep it hidden on you. And, of course, keep devices powered off or locked when not in use – enable short auto-lock timeouts on your phone/laptop so they aren't unlocked if snatched.

Beware of public USB charging

Avoid plug-and-play charging stations at airports or malls. The risk of “juice jacking” is that a malicious charging kiosk or cable can inject malware or siphon data when you connect via USB. Stick to using your own charger plugged into a power outlet, or use a USB data blocker (a little adapter that only passes power, not data). Similarly, do not plug unknown USB drives into your laptop – if someone hands you a free USB stick at an event, assume it could be a trap. USBGuard software (for Linux) or equivalent can be used to restrict USB device access on your computer, allowing only whitelisted devices. This tool can prevent an unknown USB from automatically tampering with your system by requiring authorization for new devices. At a minimum, disable any “USB autorun” features and consider locking down ports if your OS allows.

Note: The chances that you're a victim of a juice jacking attack, at common shared areas like an airport are really, really low, and probably mostly unseen or unheard of. Regardless of that, depending on your profile risk, you might encounter technologies that mimick different kind of cables and accessories with the same purpose. These exist out of the box, and have been widely used by red-teamers and pentesters.

Screen privacy and social engineering

Practice situational awareness when working in public spaces. Shoulder surfing is a real threat – someone nearby could be watching you enter passwords or PIN codes. Use a privacy screen filter on your laptop or phone to narrow the viewing angle. This makes it much harder for anyone not directly in front of your screen to read it. Sit with your back to a wall when possible, and shield the keypad with your body or hand when typing sensitive info.

In crowded conferences or airports, be cautious if someone you don't know strikes up conversation — might be trying to distract you or talk about crypto; scammers might engage you to glean info or even attempt to get you to unlock your device. Don't log in to critical accounts in front of others – you never know who's looking.

Also be mindful of phishing attempts: traveling users are prime targets for fake "urgent" emails or messages. Double-check any unusual prompts before entering credentials, especially if you're on untrusted Wi-Fi (use your VPN and look for HTTPS).

Maintain OpSec in public

While traveling, blend in and stay discreet. Refrain from discussing sensitive matters in public areas where eavesdropping is possible, or directly sharing things like where you are staying to people you don't know. Even hotel lobbies or rideshares might not be secure for private discussions.

When meeting people, don't give your phone to others to type down their socials, and remember to disable default options like Telegram's sharing phone number when adding a contact.

Remember that hidden cameras or microphones could exist in unfamiliar environments. It's rare but not unheard of, especially in Airbnbs or rented spaces – malicious hosts have hidden cameras in items like smoke detectors, clock radios, or USB chargers. Give your accommodations a scan: look for odd or extra devices plugged in (especially facing beds or desks) and cover or unplug them if suspicious. You can also play ambient noise (or use a noise generator app) during confidential conversations to thwart any listening devices.

Keep a low profile: as mentioned, don't flaunt crypto wealth or gear. For example, if attending a blockchain conference, consider using an alias on your name badge that doesn't explicitly say your company or title, and don't display that badge outside the venue. When moving around, secure your laptop in a nondescript sleeve or bag (instead of one with a well-known conference brand). The goal is to avoid drawing the attention of both petty thieves and more organized attackers by limiting the signals that you're a high-value crypto target.

Don't fall into security by obscurity. Don't assume that by going "stealth", you cannot be the victim of an attack. These section's suggestions don't replace the rest.

Traveling with high-value crypto or duties

If you must make crypto transactions or access sensitive systems while on the road, do so with caution. Use trusted hardware and networks: e.g. if you need to send a transaction, use your hardware wallet on your own laptop (never a shared computer), on a secured connection.

Be aware of surveillance at events – attackers have been known to watch for people handling sensitive info. If you need to access a seed or enter a recovery phrase, do it in a private, secure setting (never over public Wi-Fi or in view of anyone, including cameras). Consider that everyone knows you own crypto at a crypto event, so your threat profile is elevated. Adjust your security: for instance, enable a passphrase or a pin on any single-signature wallet you carry so that even if someone obtains your hardware wallet, they can’t access funds without that passphrase. For large amounts, rely on multi-sig – you might carry one key on you and leave another key(s) with trusted parties so no single person has all signing power while traveling. In short, treat any on-trip crypto operations with more care than you would in the office.

While presenting or doing public appearances

One often overlooked risk is the exposure caused by presenting or hosting technical workshops in public. Without properly hardening or isolating your computer before setting up, you may unintentionally expose network services to hostile environments or reveal sensitive information on-screen. Always prepare a clean, minimal environment and verify no confidential data or open ports are accessible before connecting to unfamiliar networks or projecting your screen.

Physical safety and common sense

Operational security also has a physical aspect. Trust your instincts and normal travel safety rules: stick to well-lit and populated areas if carrying devices at night, don’t let strangers “shoulder surf” your ATM or credit card PIN (check for skimmers, fake interfaces), and keep your travel documents secure since identity theft can be as damaging as device theft.

Use hotel lockers at conferences if provided (for example, some events offer secure charging lockers – use them rather than leaving devices out only).

Beware of the classic “evil maid” scenario in hotels (where someone might tamper with your laptop in your room): using tamper-evident tape or seals on your laptop case can help detect this, though it’s mostly a concern for high-risk targets. If you have tamper-evident stickers or tamper-evident bags, you can seal your device in them overnight – any attempt to open or remove the device will leave a visible trace. While not foolproof against a determined adversary, it raises the bar and can deter casual snooping.

Petty thieves may look beyond obvious valuables. Simply locking items in a dorm safe or hiding them at home might deter casual theft, but savvy criminals often search inside books, behind electrical outlets, or within patterns on walls or furniture to find hidden stashes. Consider unconventional hiding spots and avoid predictable storage methods. Layer your physical security measures with tamper-evident seals or discreet decoy containers to raise the effort required for unauthorized access.

Above all, maintain an alert posture: be aware of who’s around when you’re working, and if something feels off (like someone persistently hovering or a device acting strangely), don’t ignore it. You can always relocate, power down your device, or otherwise cut off exposure at the first sign of trouble.

---

Returning home

Secure your accounts and passwords

Once you're back, if you suspect that any account credentials you used while abroad might have been exposed (especially if you had to log in over a hotel or conference Wi-Fi), address the issue. Change the passwords for any accounts you accessed unsafely during the trip – but if you don't feel is necessary, sometimes you pose a greater risk at doing so.

Do this from a trusted device/network (ideally wait till you're on your home or office network, not the airport Wi-Fi). Use this opportunity to upgrade weak passwords and ensure 2FA is still working on those accounts. Check your email filters and crypto account settings for any unauthorized changes (attackers sometimes add forwarding rules or new withdrawal addresses if they did get access).

Essentially, rotate secrets that may have been used under less-secure conditions.

Inspect and clean your devices

After traveling, give your devices a thorough once-over. Run a reputable anti-malware scan on laptops and phones. Look for any unusual apps, processes, or device behavior (for example, unusual battery drain could indicate malware).

If you were in a high-risk environment or your device was out of your control at any point, consider wiping the device and restoring it from your pre-trip backup (or factory-resetting a phone) to ensure it's clean. This is especially recommended for "burner" devices used on the trip – you can safely restore your data onto your main device and decommission the travel device.

For hardware wallets, verify they weren't tampered with: check the device seals if any, and when you connect, confirm the firmware is still legitimate (if the manufacturer provides verification software). If you have any suspicion that a device (or hardware wallet) was compromised, do not continue using it for sensitive transactions. Transfer crypto assets to new wallets (using your seed backups in a new device if necessary) once you're on a secure network and device. It's also a good idea to disable or remove any travel-specific eSIMs or accounts you used on the trip – for example, remove that foreign cellular plan from your phone if you no longer need it, and uninstall any travel or conference apps that are no longer required.

Post-travel review

Now that you're home, reflect on the trip and note any security incidents or close calls. If any device was lost, stolen, or even taken out of your sight and potentially tampered (like held by airport security for a long inspection), inform your organization's IT or security team immediately. They may assist with forensic checks or account monitoring. Also inform colleagues if any work data might have been exposed so they can be vigilant. This is not about blame – it's about mitigating any damage early.

Re-enable any data or accounts you put in "travel mode." For instance, if you used 1Password Travel Mode to hide vaults, log in and turn those vaults back on. If you created throwaway emails or burner chat accounts for the trip, decide if you'll deactivate them now.

Update your threat model based on your experience: did any new threats emerge, or did some precautions prove unnecessary? Use that to improve future travel prep. Finally, share key lessons with your team. Sharing what you've learned from each trip and tweaking your security practices contributes to a stronger security culture for everyone!

---

Additional precautions for high-risk travelers

This section is for Web3 professionals who have elevated privileges or profiles – for example, access to multisig treasury keys, leadership roles, or possession of sensitive organizational secrets. These users may be targeted more deliberately by criminals or even nation-states. In addition to all the precautions above, high-risk travelers should take further steps:

For high-profile or recognizable individuals, keeping a low profile is essential. Beyond avoiding branded merchandise, a simple yet effective tactic is wearing a COVID N95 mask or similar face covering. It's socially accepted, draws no attention, and helps protect your identity — making it harder for adversaries to target or track you during public events.

Use loaner or "burner" devices

If feasible, travel with clean devices that don't contain sensitive data. Leave your primary laptop/phone at a protected location (assuming you also have security in place as well), and bring a wiped, minimal laptop or a cheap travel phone with only the basics. Log into what you absolutely need (through secure channels) and nothing more. Treat these devices as expendable – assume they will be compromised and plan to wipe them afterward. For example, a senior developer might bring a laptop with no source code on it and use a VPN or VDI (virtual desktop) to access company systems when necessary, leaving no data on the local disk. A hardware wallet keyholder might carry a secondary hardware wallet with lower privileges (or a single key to a multisig instead of full access). Keep your primary keys secured in a location that is not accompanying you. Remember, a nearly empty device can raise suspicion at some borders, so don't make it obvious – load some innocuous data (music, generic files) so it looks used, but nothing that would be harmful if inspected.

Plan for customs and border checks

High-risk individuals may face increased scrutiny or device searches at borders due to the sensitive nature of their data or their roles (e.g., journalists). Before crossing borders, purge or secure sensitive information. Turn off devices before landing (some experts even recommend encrypting and then powering down devices – a powered-off device with strong encryption is extremely hard to access).

Disable cloud auto-sync of sensitive data; you don’t want customs inadvertently accessing company cloud drives if they inspect your laptop. If asked to unlock devices, having them powered off gives you an opportunity to state that it’s encrypted and requires a passphrase (which you should have memorized, not written down). It’s wise for high-risk travelers to disable biometrics entirely before travel – use PIN/password only, as mentioned – so you cannot be compelled or tricked via fingerprint/face. Know your legal rights in the countries you transit; in some places you can refuse to unlock (though it may mean the device is held or you are denied entry), while in others you might face penalties. This is a personal risk decision – but the best case is to carry nothing truly incriminating or irreplaceable across a checkpoint. For ultra-sensitive data, use secure communication channels to retrieve it at destination rather than carrying it. For instance, an executive could store confidential files in a secure cloud drive they access over VPN once abroad, rather than carrying them on a laptop.

Border checks/immigration checks often require you to share your travel plans, including hotel information and airline details. Having a physical copy of them (printouts, ingress-egress) means you do not need to access your devices in front of agents or potential cameras while being scrutinized. This will also prevent the need to let them peek at them to provide information, thereby risking the disclosure of sensitive personal information.

Since COVID, many nations have moved to digital immigration paperwork. This often requires the use of an email address. You should consider a dedicated email address for interaction with government agencies, instead of an email address that might have a public/open-source affiliation with cryptocurrency (or other sensitive topics).

Enhanced device protections

High-risk users should layer additional defenses. Lockdown Mode (on iOS) or Android’s equivalent secure modes should be enabled if there’s any chance of targeted spyware (these modes disable exploit-prone services and attachments). Use messaging apps with end-to-end encryption and disappearing messages (NOT Telegram, Signal is a good example) for any sensitive communications – assume that standard SMS or emails could be monitored.

Consider using a Faraday bag for phones when not in use, if you suspect active tracking or exploitation (this prevents any signals in or out, though use sparingly as it also blocks your calls). If you leave a device in your hotel, you can put it in a tamper-evident bag and seal it, or at least take measures like noting the exact placement or taking a photo, so you can detect if it was disturbed. Some high-risk individuals even weigh their devices before and after travel to detect the addition of hardware implants (a change in weight could indicate something like a chip added) – this is an extreme step, but shows the level of caution possible. At the very least, physically inspect your devices for new scratches, screws that look tampered with, or unexpected behavior.

Protect crypto keys with multi-party controls

If you have access to significant crypto funds (exchanges, DAO treasury, etc.), implement policies that prevent a single point of failure while you’re traveling. For example, if you’re one of N-of-M multisig signers, consider temporarily requiring an extra signer for transactions while you’re away (so if normally 2-of-3 can move funds, bump it to 3-of-3 or add a 4th backup signer) so that a compromised key or coerced action cannot alone execute a transfer.

If you hold hardware keys, keep them geographically split – e.g. bring one key device with you, leave the backup key in a safe place at home, and perhaps give a third key to a colleague, so that even a forced disclosure cannot result in an immediate loss of funds without collaboration. Use duress codes if your hardware supports it (some wallets allow a secondary PIN that opens a decoy account with minimal funds, the same can also be made with encryption volumes).

In general, assume a determined adversary could target you specifically for your role: use confidential communication to stay in touch with your team (so they know you’re safe daily), and establish a code word or protocol for emergencies. High-risk travelers might also arrange a “check-in” schedule with their security team or colleagues – if you don’t check in by a certain time, they can take pre-agreed actions (like disabling your accounts or alerting authorities). This kind of planning is an extra safety net when the stakes are especially high.

Post-trip device rebuilding

For highly targeted individuals, the safest course after returning is to treat every device as compromised and rebuild it, especially before reaching your safe zone (home, work office). This involves wiping devices to factory settings, flashing firmware if necessary, and restoring data from known-good backups made before the trip.

Consider using read-only operating systems or booting from trusted live media during travel to reduce risk exposure. Before your trip, you can create a cloned disk image of a clean system state, so after traveling you can restore your device to that exact low-level copy — starting fresh with a known secure baseline. This approach helps eliminate stealthy malware or spyware that may have been implanted.

Additionally, review system logs if available (security apps or MDM solutions often report unusual access or configuration changes during your absence). As always, report any suspicious incidents promptly. High-risk roles may require a debrief with your security officer — be transparent about any odd encounters or possible security lapses to mitigate threats that could have followed you home.

--

Part of the contents were inspired and based on some of the following articles.

• CISA Cybersecurity While Traveling – official tips on device updates, Wi-Fi safety, and physical device security | cisa.govcisa.gov.
• Cornell University IT Security – international travel security checklist (device encryption, using loaner devices, minimizing data) | it.cornell.edu | it.cornell.edu.
• Cypherock Blog – "Safe Vacation Tips while Traveling with Crypto" (advice on MFA keys, avoiding public Wi-Fi and chargers, not carrying seed phrases) | cypherock.com | cypherock.com.
• Schneier on Security (comments) – community OPSEC suggestions for border crossings (burner phones, no biometrics, 1Password Travel Mode) | schneier.com.
• The MacGuys – Apple device travel tips (Lockdown Mode, separate eSIM for travel, disabling Face ID in emergencies) | themacguys.com | themacguys.com.
• Unchained Capital – "7 Tips for Traveling with Bitcoin Keys" (don't advertise crypto holdings, leave seed backups at home, use passphrases/multisig for travel) | unchained.com | unchained.com.
• BlackCloak – Dangers of oversharing travel on social media (real-time posts can invite burglaries or attacks) | blackcloak.io.
• Trio Security Blog – Shoulder surfing and visual hacking (use privacy screens and be mindful of surroundings) | trio.so.
• Washington Post – Portable door locks for travelers (added security in accommodations) | travelandleisure.com and finding hidden cameras in rentals | washingtonpost.com.
• GitHub USBGuard – tool to enforce USB device policies on laptops (helps block malicious USB devices) | github.com.

Wallet Security

In cryptocurrency, the security of digital assets is directly tied to how control over the funds is protected. This section provides a technical deep-dive into wallet security, covering the range from fundamental concepts to advanced practices for safeguarding assets against theft, loss, and unauthorized access.

The goal is to move beyond introductory concepts and provide actionable, technical knowledge for securely managing crypto assets.

Table of Contents

• Custodial vs Non-Custodial - Comparing custodial and non-custodial wallet solutions.
• Cold vs Hot Wallet - Understanding the security trade-offs of online and offline wallets.
• Wallets For Beginners & Small Balances - Recommended setups for users with non-critical funds.
• Wallets For Intermediates & Medium Funds - Security upgrades for users with significant assets.
• Multisig Wallets For Advanced Users & High Funds - Best practices for setting up and managing multisig wallets.
• Account Abstraction Wallets - Exploring the security features of smart contract wallets.
• Signing & Verification - An overview of secure transaction signing and verification.
  • Verifying Standard Transactions (EOA) - How to safely verify transactions from standard wallets.
  • Multisig Signing Process - Detailed guide for secure multisig transaction signing.
  • Using EIP-7702 - Enabling smart contract features for EOAs and mitigating new risks.
• Private Key & Seed Phrase Management - Best practices for securing your seed phrase.
• Tools & Resources - A curated list of security tools and resources.

In this section you can learn:

• Explore wallet fundamentals, analyzing the security trade-offs of hot vs. cold wallets and the ownership implications of custodial vs. non-custodial models.
• Receive guidance on choosing the right wallet for your threat model, from basic setups to advanced configurations like Multisignature (Multisig) and Account Abstraction wallets.
• Master transaction verification techniques, from basic smart contract interactions to the advanced verification.
• Implement security best practices for private key and seed phrase management.

Mastering wallet security is a critical skill for any developer, user, or organization operating in the web3 ecosystem.

xkcd

Custodial vs. Non-Custodial Wallets

The distinction between custodial and non-custodial wallets centers on who controls the private keys. This control directly impacts ownership, security responsibility, and the ability to interact with the web3 ecosystem.

Custodial Wallets

What Are They?

Custodial wallets are managed by a third party, such as a centralized exchange (CEX) or a dedicated wallet service provider. In this model, the third party holds and manages the private keys on behalf of the user.

Characteristics

• Managed Private Keys: The third party has full control over the private keys. You do not possess them.
• Recovery Options: It is often easier to recover account access if login credentials are lost, as the custodian can assist.
• Security Dependence: The security of your assets is entirely dependent on the custodian's security practices, infrastructure, and operational integrity.
• Ease of Use: Provides a simpler user experience, abstracting away the complexities of private key management.

Use Cases

• New Users/Beginners: Suitable for users who are new to cryptocurrency and prefer a simpler, managed solution.
• Convenience Over Control: Ideal for users who prioritize convenience and ease of use over full control.

Non-Custodial Wallets

What Are They?

Non-custodial (or self-custody) wallets are managed directly by the user, who has sole and complete control over their private keys. The user is entirely responsible for the security, backup, and management of these keys.

Characteristics

• User-Controlled Private Keys: The user has exclusive control and possession of their private keys.
• Eliminates Counterparty Risk: Assets are not exposed to the risk of a third-party custodian being hacked, becoming insolvent, or freezing funds. Security becomes dependent on the user's own practices.
• Full Responsibility: The user is solely responsible for backing up their seed phrase and securing their private keys. Loss of these keys means irreversible loss of funds.
• Web3 Interaction: Enable seamless interaction with dApps.

Use Cases

• Experienced Users & Developers: Preferred by users who understand blockchain and wallet security best practices.
• Security & Control Prioritization: Ideal for users who prioritize full control over their assets and are willing to undertake the responsibility of self-custody.

Comparison

Cold vs. Hot Wallets

The primary distinction between wallet types is their connectivity to the internet. This factor dictates their security threat model, risk profile, and ideal use cases.

Cold Wallets

What Are They?

Cold wallets are cryptocurrency wallets that store private keys in an offline environment. By being disconnected from the internet, or "air-gapped," by default, they provide the highest level of security against online attacks like malware and phishing.

Transactions are signed offline and then broadcast to the network using a connected device, ensuring the private keys are stored on device with minimal connectivity.

❓ Did you know?

Most cold wallets come with some way to connect to the internet, such as via a USB connection. This technically makes them "hot" when connected. However, the key distinction is that they are not continuously online and are designed to minimize exposure to online threats.

Types of Cold Wallets

• Hardware Wallets: Dedicated physical devices that store private keys offline and sign transactions without exposing the keys to a connected internet device.
• Paper Wallets: Physical printouts or handwritten notes of private keys and QR codes.
• Software Wallets on Air-Gapped Devices: Standard wallet software installed on a device that is permanently disconnected from the internet, used for offline transaction signing.
• Brain Wallets: Private keys that are memorized.
• Account Abstraction Wallets: Using smart contracts to manage keys and transactions without exposing private keys.
• Multisig Wallets: Require multiple signatures to authorize a transaction, enhancing security.

Use Cases

• Long-Term Storage: Ideal for storing large amounts of cryptocurrency for extended periods.
• High-Security Needs: Essential for individuals securing significant value and operating with a low risk tolerance.

Hot Wallets

What Are They?

Hot wallets are actively and consistently connected to the internet. This connectivity makes them highly convenient for daily use but also inherently more vulnerable to online attacks.

Types of Hot Wallets

• Browser Wallets (Extensions): Software that integrates directly into a web browser, allowing seamless interaction with dApps.
• Mobile Wallets: Apps installed on smartphones.

Use Cases

• Daily Transactions & dApp Interaction: Perfect for users who need quick and frequent access to their funds for interacting with applications.
• Small Balances: Suitable for storing smaller, non-critical amounts of cryptocurrency that are used regularly.

Comparison

Key Security Considerations

Regardless of the type, non-custodial wallets place the full burden of security on the user:

• Online Vulnerabilities: If the device they are on (computer or phone) is compromised, your assets can be stolen.
• Supply Chain Attacks: Be cautious of both software and hardware integrity. Always download wallet software from official sources and purchase hardware wallets directly from the manufacturer to avoid receiving a tampered device.

For Beginners & Small Balances

User Profile

A user with foundational web3 knowledge who is actively learning and interacting with dApps. The asset value is typically non-critical, where a potential loss would not be financially significant. This profile prioritizes ease of use and learning over protections against online threats.

Primary Goal

The primary objective is a low-friction setup for convenience and dApp interaction. This includes frequent transactions, exploring DeFi protocols, and engaging with NFTs.

Recommended Setup

The standard setup for this profile is a hot wallet, which provides the necessary internet connectivity for active use. The most common types are:

• Browser Extension Wallets: Integrate directly into a web browser for seamless dApp interaction.
• Mobile Wallets: Applications installed on a smartphone, offering convenience and on-the-go access.
• Desktop Wallets: Software applications installed on a computer, which can sometimes offer more advanced features than mobile or browser counterparts.

Key Considerations & Trade-offs

While convenient, this setup carries inherent risks that the user must understand and accept.

• Online Threat Vector: As hot wallets are internet-connected, they are inherently vulnerable to malware and exploits targeting the browser or operating system.
• Supply Chain Risk: It is critical to download wallet software only from official, verified sources.

How to Select a Wallet

When selecting a wallet, prioritize those whose code is open-source, as this allows for public scrutiny and independent verification by the security community. For users who are not developers, several platforms provide independent analysis to help evaluate a wallet's security.

For example, Wallet Scrutiny focuses on verifying if a wallet's code is verifiably open-source. Others, like Wallet Security Ranking, provide a security score based on specific criteria such as transaction clarity, protection against known threats, and how it handles dApp permissions.

Using these tools can provide valuable data points to help you assess a wallet's security posture and make an informed decision.

For Intermediates & Medium Balances

User Profile

An intermediate user who is comfortable with web3 interactions and is now managing a significant, but not life-altering, amount of assets. This user understands the inherent risks of hot wallets and is actively seeking to upgrade their security posture to protect their capital.

Primary Goal

The main objective is to secure balances against online threats while still retaining the ability to interact with dApps when necessary. This involves separating the bulk of assets from daily operational balances.

Recommended Setup

A hardware wallet is the core of this setup. This dedicated physical device stores private keys offline in a secure, tamper-resistant environment, acting as a vault for the majority of the user's balances.

Key Considerations & Trade-offs

Adopting a hardware wallet introduces a new set of security considerations focused on physical and supply chain vectors.

• Physical Security: A hardware wallet is a physical asset that must be protected from theft, damage, or coercion.
• Supply Chain Integrity: Hardware wallets must only be purchased directly from the manufacturer or an authorized reseller to avoid receiving a tampered device.
• Convenience vs. Security: Using a hardware wallet introduces friction into the transaction process, as it requires physical access and approval on the device for every signature.

How to Select a Hardware Wallet

• Open Source: Evaluate if the wallet's firmware and software are open-source, which allows for public auditing and verification by the security community.
• Secure Element (SE) Look for devices with a SE certified, tamper-resistant chip that protects against physical attacks. Check for high assurance ratings like EAL6+ and features like attestation, which verifies the device is genuine.
• Reputation & Incident: Investigate the manufacturer's security track record, including their response to past vulnerabilities, data breaches, and overall transparency.
• Verify Device Integrity: A legitimate hardware wallet will arrive uninitialized, requiring you to perform the initial setup. Reject any device that comes with a pre-set PIN, a pre-generated recovery phrase, or appears to be already configured, as it is likely compromised.

Multisig Wallets For Advanced Users & High Funds

User Profile

Advanced technical users, developers, Decentralized Autonomous Organizations (DAOs), and organizations responsible for managing protocol treasuries, smart contract ownership, or significant personal/collective assets.

Primary Goal

The primary objective is to eliminate single points of failure and establish robust, distributed control over high-value assets and critical smart contract functions.

Core Concept: M-of-N Scheme

A multisignature (multisig) wallet is a smart contract that requires a predefined minimum number of approvals M from a total set of authorized signers N to execute a transaction. This is known as an M-of-N scheme (e.g., 2-of-3, 3-of-5).

By distributing signing authority, a multisig ensures that the compromise of a single private key is insufficient to authorize the movement of funds or execute a privileged action.

Setup Best Practices

• Threshold Selection: The M-of-N threshold should be chosen to balance security and operational resilience. Avoid N-of-N schemes, as the loss of a single key would result in a permanent loss of access to all funds.

• Strategic Signer Distribution: The security of a multisig depends entirely on the operational security (OpSec) of its individual signer keys. Storing multiple signer keys on the same device or in the same physical location negates the security benefits. Effective distribution strategies include:

  • Using different hardware wallet models and manufacturers.
  • Maintaining geographical separation for devices holding signer keys.
  • Assigning signer keys to different trusted individuals within an organization.
  • Using diverse client software to interact with the multisig to mitigate single-point-of-failure risks from a software vulnerability.

• Practice on Testnet: Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and owner management on a test network.

• Timelocks: Enforce a mandatory delay between the approval of a transaction and its execution. This provides a critical window for the community or team to detect and react to malicious proposals.

• Role-Based Access Control (RBAC): Implement modules that grant specific, limited permissions to certain addresses (e.g., a "pauser" or "executor" role) without making them full owners, adhering to the principle of least privilege.

• Disaster Recovery Plan: Establish a clear, documented process for what to do when a signer is compromised, the multi-signature UI is down, or other emergencies arise. These should be done at regular intervals.

Operational Best Practices

• Signer Key Revocation and Replacement: A feature of multisigs is the ability to add, remove, or replace signer keys. If a signer's key is compromised or lost, it can be revoked and replaced with a new, secure key through a transaction approved by the remaining owners, preserving the integrity of the wallet's assets without needing to migrate funds.

• Secure Signing Environment: For maximum security, all signing activities should be performed on a dedicated, air-gapped, or hardened device running a secure OS. Using a primary work laptop significantly increases the risk of malware interference.

• Independent Transaction Verification: Before signing, always verify the raw transaction data (target address, function call, parameters) to ensure it matches the intended operation.

• Out-of-Band Verification for Admin Changes: Any critical administrative action, such as adding or replacing a signer, must be verified through multiple, independent communication channels (e.g., a video call and a signed message) to prevent social engineering attacks.

• Active Monitoring: Implement monitoring and alerting systems to be immediately notified of any on-chain activity related to the multisig, including proposed transactions, new signatures, and owner changes (e.g., using tools like Safe Watcher ).

• Documented Procedures: Maintain clear, secure, and accessible documentation for all multisig procedures, including transaction creation, signing, and emergency recovery plans.

Acknowledgements

Some ideas were borrowed from the EF's multisig SOP notes and Manifold Finance multisig best practices.

Account Abstraction Wallets

User Profile

Advanced users, developers, and organizations interested in programmable security, customizable transaction rules, and moving beyond the limitations of standard Externally Owned Accounts (EOAs) to eliminate single points of failure like seed phrase loss.

Primary Goal

To leverage the power of smart contracts at the account level, enabling features like social recovery, gas sponsorship, batch transactions, and flexible security policies that are not possible with an EOA.

Core Concept: ERC-4337

Account Abstraction (AA) turns a user's account into a smart contract, making it programmable. Instead of being controlled directly by a single private key, the account's logic is defined by its code. This is achieved through ERC-4337, a standard that enables AA without requiring changes to the core Ethereum protocol. It introduces a higher-level pseudo-transaction system with several key components:

• Smart Contract Account: The user's wallet itself is a smart contract, containing custom logic for validating transactions.
• UserOperation: A data structure that bundles the user's intent, calldata, and signature. This object is sent to a dedicated, alternative mempool.
• Bundlers: Specialized nodes that package multiple UserOperation objects from the mempool into a single transaction and submit it to the EntryPoint contract.
• EntryPoint: A singleton smart contract that acts as the central orchestrator. It verifies and executes the bundled UserOperations, ensuring that accounts and paymasters have sufficient funds to pay for gas.
• Paymasters: Optional smart contracts that can sponsor gas fees on behalf of the user, enabling gasless transactions for the end-user or allowing fees to be paid in ERC-20 tokens.

Key Benefits & Features

• Enhanced Security:

  • Social Recovery: Mitigate the risk of losing a primary key by designating trusted "guardians" (other accounts or devices) who can collectively approve an account recovery.
  • Customizable Policies: Implement robust security rules directly into the wallet, such as daily spending limits, whitelisting trusted contracts, or requiring multisig confirmation for transactions over a certain value.

• Improved User Experience:

  • Gasless Transactions: Enjoy a smoother experience where dApps can sponsor gas fees, or pay for transactions using ERC-20 tokens instead of needing the chain's native asset (e.g., ETH).
  • Simplified Interactions: Perform complex, multi-step actions (like approve and swap) in a single, atomic transaction, reducing clicks and potential points of failure.

Security Considerations & Best Practices

• Smart Contract Risk: The security of an AA wallet is entirely dependent on the quality and security of its underlying smart contract code. Bugs or vulnerabilities in the account's implementation can lead to a total loss of funds. Thorough audits of the account logic are non-negotiable.
• Guardian Selection and Security: The strength of the social recovery model depends on the security and independence of the guardians. They should be diverse and not susceptible to a single common threat.
• EntryPoint Centralization: The EntryPoint contract is a central trust point for the entire ERC-4337 ecosystem. A vulnerability in the official EntryPoint could have widespread consequences. Use only the canonical, heavily audited EntryPoint contract.
• Paymaster and Factory Security: Malicious or poorly coded Paymasters and Factories can introduce DoS vectors or other risks. The ERC-4337 standard includes a reputation system and staking mechanisms to throttle or ban misbehaving entities, but users should only interact with trusted and audited Paymasters.
• Gas Overhead: The added logic in a smart contract account means that transactions can be more expensive than those from a standard EOA. This trade-off between features and cost should be considered, though it can be offset by gas sponsorship.
• Key Revocation: If the primary signing key is compromised, the recovery process allows you to swap it out for a new one without having to move all assets to a new wallet address.
• Advanced Guardian Setups: For enhanced security, guardian roles can be implemented using Multi-Party Computation (MPC). In an MPC-based recovery, guardians hold cryptographic shares that are used collectively to authorize a recovery action. This method allows guardians to produce a valid signature through a distributed computation using their individual shares, without ever reconstructing a single master key on any device.

Signing & Verification

This section provides a guide to transaction verification, from basic EOA interactions to advanced multisig operations.

The rule is to never sign blindly. Always take the time to verify what your wallet is asking you to approve. A compromised dApp front-end or a misunderstanding of a transaction's parameters can lead to a complete loss of funds, even with a wallet that is not compromised.

Core Principles of Secure Signing

Before diving into specific use cases, it's critical to adopt a security-first mindset built on these foundational principles:

• Verify, Don't Trust: Never trust a user interface blindly. The raw transaction data is the ground truth of what you are authorizing. Always use independent tools to confirm that what you see is what you sign.
• Simulate Before Signing: Before approving any non-trivial transaction, use a simulation tool. These tools act as a "sandbox," showing you the human-readable outcome before you commit, protecting you from unexpected results and malicious contracts.
• The Hardware Wallet is the Source of Truth: Your hardware wallet's trusted display is your last line of defense against UI spoofing. If the information on your computer screen does not perfectly match what is on your hardware device, reject the transaction immediately.
• Demand Clear Signing: Prioritize hardware and software that can decode and display a transaction's intent in a human-readable format. If a wallet requires "blind signing" (approving a raw, unreadable hash), you are accepting a significant level of risk.

In This Section

This chapter breaks down transaction verification into key areas:

• Standard Transaction Verification: An overview of the foundational security principles that apply to all types of transactions.
• Verifying Multisig Transactions: A detailed guide to the two-phase process of securely signing and executing multisig transactions, including how to verify EIP-712 hashes and execTransaction calldata.
• Verifying EIP-7702 Transactions: An analysis of the new security considerations introduced by EIP-7702, which allows EOAs to temporarily act as smart contracts, with specific guidance for both users and developers.

To apply these principles, this framework provides a curated list of verification and simulation tools in the Tools & Resources.

Verifying Standard Transactions (EOA)

When interacting with a dApp using a standard Externally Owned Account (EOA) via a wallet, you must verify several key components of the transaction request before signing.

1. Verify the Origin

• What to check: The URL of the website initiating the transaction request.
• Why it's critical: A malicious site can perfectly clone a legitimate dApp's interface to trick you into signing a malicious transaction. Always ensure you are on the correct, official domain.

2. Verify the Smart Contract Address

• What to check: The contract address listed under a field like "Interacting With" in your wallet's transaction prompt.
• Why it's critical: This is the actual on-chain address your transaction is being sent to. A malicious dApp will substitute a fraudulent contract address here.
• Verification Methods:
  • Official Documentation: The most reliable source. Find the "Contract Addresses" or "Deployments" section in the protocol's official documentation and confirm the address matches.
  • Block Explorer (Etherscan, Blockscout, etc.): Paste the address into a block explorer. Look for verification checkmarks, official labels, and a healthy transaction history.

3. Verify the Function and Parameters

• What to check: The function name (e.g., depositETH) and the parameters in the "Data" tab of your wallet.
• Why it's critical: This is the exact action you are authorizing the smart contract to perform. A malicious transaction might look legitimate on the surface but contain a harmful function call.
• Verification Methods:
  • Cross-reference with Documentation: The protocol's developer documentation will define the function and what each parameter represents.
  • Scrutinize Recipient Addresses: For any function that directs assets (e.g., onBehalfOf, recipient, to), ensure the address is your own or the intended recipient.
  • Understand Amounts: Verify token amounts, paying attention to the number of decimals.

4. Sanity-Check the Network Fee (Gas)

• What to check: The estimated gas fee for the transaction.
• Why it's critical: An unusually high gas fee for a simple operation can be a red flag, potentially indicating an inefficient or malicious contract designed to waste user funds.

Verifying Multisig Transactions

The security of a multisig wallet relies on each signer independently verifying what they are signing. A compromised web interface could present a legitimate-looking transaction while tricking a hardware wallet into signing a malicious one.

The verification process is divided into two distinct phases: signing the off-chain message and executing the on-chain transaction.

Phase 1: Signing the Off-Chain Message

When you are the first signer or are adding your signature to a transaction that has not yet met its threshold, you are not sending an on-chain transaction. Instead, you are signing a structured, off-chain message that conforms to the EIP-712 standard.

Goal: To confirm that the cryptographic hash displayed on your hardware wallet exactly matches the hash of the transaction you intend to approve.

Process

1. Initiate Signing: Start the signing process in the multisig wallet's web interface.
2. Verify on Hardware Wallet: Your hardware wallet will display an EIP-712 hash for you to sign.
3. Compute Hash: Use an independent, local tool to re-calculate the expected hash from the transaction's parameters (nonce, to, value, data, etc.). For a list of recommended options, see the Transaction Verification Tools section.
4. Compare Hashes: Compare the SafeTxHash generated by the local tool with the hash displayed on your hardware wallet's screen. They must match perfectly.
5. Sign: If the hashes match, you can confidently sign the message on your hardware wallet. This confirms you are approving the correct transaction, even if the web UI has been compromised.

Phase 2: Executing the On-Chain Transaction

Once a transaction has the required M-of-N signatures, it can be executed. This involves submitting a final on-chain transaction that calls the execTransaction function on the multisig contract, passing in all the previously signed data.

Goal: To confirm that the on-chain transaction being sent correctly encapsulates the multisig transaction you and other signers approved.

Process

1. Initiate Execution: In the multisig interface, start the execution of the fully signed transaction.
2. Verify Calldata: Your hardware wallet will prompt you to sign a new on-chain transaction. It will display the raw transaction data (calldata), which should show a call to the execTransaction function.
3. Decode and Compare: Use a calldata decoder (e.g.,calldata.swiss-knife.xyz) to parse the data shown on your hardware wallet.
4. Confirm Parameters: Carefully check the decoded parameters within the execTransaction call, especially the internal destination address (to), value, and data payload. Ensure they match the original, intended transaction.
5. Sign and Broadcast: If the calldata is correct, sign the transaction on your hardware wallet to broadcast it to the network.

Operational Best Practices

⚠️ Beware of DELEGATECALL: In a smart contract multisig transaction, an operation: 1 (DELEGATECALL) is dangerous if the target contract is not explicitly known and trusted. This opcode gives another contract full control over your wallet's context and storage.

• Transaction Simulation: Before signing, use a simulator like Tenderly or Alchemy to preview the transaction's outcome. This helps confirm that it will not revert and will result in the expected state changes.
• Hardware Wallet Standard: All multisig signers should use hardware wallets to protect their keys from online threats. Data shown in a browser extension wallet should be treated with the same skepticism as data in the web UI.
• Alternative Frontends: To further reduce reliance on a single public UI, consider using an alternative or self-hosted multisig interface.

Using EIP-7702

The Pectra network upgrade introduces EIP-7702, which allows a standard Externally Owned Account (EOA) to temporarily function like a smart contract wallet. This is achieved via a new transaction type (0x04) that lets an EOA delegate its authority to a smart contract's code for the duration of a transaction or until it's changed.

Benefits of EIP-7702

This EIP unlocks several key user experience improvements:

• Transaction Batching: Users can combine multiple operations (e.g., an ERC-20 approve and a swap) into a single, atomic transaction, saving on gas fees and reducing confirmation fatigue.
• Gas Sponsorship: It enables third parties to pay for a user's transaction fees, which can simplify onboarding and abstract away gas management for the user.
• Privilege De-escalation: Users can delegate to contracts that enforce specific permissions, such as daily spending limits or interactions with only certain dApps.

Risks of EIP-7702

While powerful, this feature introduces a new attack vector. If an attacker tricks a user into signing a message that sets the wallet's code to a malicious contract, the attacker can gain full control and drain all assets.

• Phishing Attacks: The primary threat is phishing sites or scams that trick users into signing a SetCode delegation to a malicious contract under the guise of a wallet "upgrade."
• Multi-Chain Replay Attacks: A signature authorizing a delegation with chain ID 0 can be replayed on other EVM chains. An attacker could deploy a malicious contract at the same address on a different chain and use the replayed signature to take control there.

Guidance for Users

• Trust Your Wallet's Implementation: Major wallets mitigate phishing risks by hardcoding the only valid delegation contract. This prevents malicious websites from tricking you into delegating to an unsafe contract. Only approve delegations to contracts vetted and integrated by your wallet provider.
• Verify Delegation Targets: Only delegate your account to contracts that are well-known and audited.
• Understand Revocation: You can revoke a delegation and return your account to a standard EOA by authorizing a new transaction that sets the delegation address to the zero address (0x0000000000000000000000000000000000000000).
• Protect Your Private Key: Delegation does not eliminate the fundamental risk of a private key compromise. If your key is stolen, an attacker can still authorize delegations.
• Beware of Phishing: Be skeptical of any request to "upgrade" or "enable" smart account features, especially if it comes from an external link or pop-up.

⚠️ Wallets will only prompt you to switch to a smart account within the wallet's native. Any request to do so via email, a website, or a direct message is a phishing scam.

Private Key & Seed Phrase Management

The seed phrase (or mnemonic phrase) is the master key to a non-custodial wallet, granting complete control over all its derived private keys and assets. The management of this phrase is the single most important aspect of self-custody security.

⚠️ If you suspect for even a moment that your private key or seed phrase has been lost, viewed by another person, or exposed digitally (e.g., shown on-screen, copied to a clipboard on a connected device), you must consider it compromised. Immediately create a new, secure wallet and transfer all assets to it.

Secure Storage Practices

The goal is to protect the seed phrase from both physical threats (theft, fire, water damage) and digital threats (hacking, malware). The foundational principle is to keep your seed phrase offline at all times.

As soon as a new wallet is created, back it up using one of the following offline methods. Wallet providers do not have access to your seed phrase and cannot help you recover it.

• Physical Written Copies: Writing the phrase on paper or a notebook is a common starting point. To mitigate risks of loss or damage from fire or water, store multiple copies in secure, geographically separate locations (e.g., a personal safe, a trusted family member's home, a bank deposit box).

• Durable Metal Storage: For superior protection against physical damage, etch or stamp your seed phrase onto a metal plate (e.g., steel, titanium). Commercial products are available for this purpose. These should also be stored in secure, separate locations.

Prohibited Practices

Under no circumstances should you ever store your seed phrase in any of the following ways:

• Taking a digital photograph of it.
• Uploading it to cloud storage (iCloud, Google Drive, Dropbox).
• Sending it via text message or any messaging app.
• Sending it in an email, even to yourself.
• Storing it in a plain text file on a computer or phone.
• Sharing it with anyone. Wallet providers will never ask for your seed phrase.
• Never use a device obtained from an untrusted source, such as a conference, hackathon, or third-party online marketplace, as it may be tampered with.

Ongoing Security Hygiene

1. Periodic Security Audits

On a recurring basis (e.g., every 6 months), conduct a security review by asking:

• Do I know the physical location of all my seed phrase backups?
• Are my storage methods still secure and uncompromised?
• If my primary device were destroyed, do I have a clear plan to recover my assets?

2. Key Rotation

While you can use the same keys for years, it is a best practice to periodically rotate them by moving assets to new wallets.

3. Succession Planning

Establish a clear, secure protocol for a trusted next-of-kin to access your assets in case of incapacitation or death. This may involve sealed instructions stored with a lawyer or in a safe deposit box.

Tools & Resources

This section provides a curated list of tools and resources to help users select wallets, practice safe signing habits, and verify transactions. Using these tools is a critical part of a robust security strategy.

Wallet Selection

Before choosing a wallet, it is essential to consult independent, community-trusted resources.

• ethereum.org/wallets: The official, community-maintained list of wallets, filterable by features. A reliable starting point for discovering wallets.
• Wallet Scrutiny: An in-depth review site that focuses on transparency, verifiability, and reproducibility. It flags wallets that are closed-source or have other potential security concerns.
• Wallet Security Ranking: Evaluates wallets by permissions, intent clarity, device security, and threat prevention to help users choose safer, more trustworthy options.
• Wallet Beat: Aims to provide a comprehensive list of wallets, their functionality, practices, and support for certain standards.

Transaction Simulation

Transaction simulators allow you to preview the exact outcome of a transaction before signing it, preventing errors and security risks.

• Tenderly: A platform that allows you to simulate transactions and preview, helping to prevent transaction failures, security risks, and unnecessary gas costs.
• Alchemy Simulation APIs: An API suite that predicts the precise impact of a transaction before it reaches the blockchain.

Transaction Verification

These tools are designed to help you independently verify the integrity of transaction data, especially for multisig operations.

• Safe Multisig Transaction Hashes: A Bash script that locally calculates domain and message hashes using the EIP-712 standard. It allows you to generate the exact hash that your hardware wallet will display.
• Safe Utils: A user-friendly web interface for calculating and verifying Safe transaction hashes. While convenient, remember the security advantages of using a local, offline tool like safe-hash for high-value transactions.
• Foundry cast: A powerful command-line tool for local, offline decoding.
• safe-hash: A command-line tool for locally verifying Safe transaction data and EIP-712 messages before signing. It is designed to protect against phishing by allowing you to independently generate the hash your wallet will ask you to sign.
• calldata.swiss-knife.xyz: Web-based tool for quick decoding of transaction data.

Security Training

These tools allow you to practice identifying threats in a safe, simulated environment.

• The Phishing Dojo: An interactive threat simulation platform designed to train users to recognize real-world security risks. It offers realistic, in-browser scenarios covering phishing emails, fraudulent wallet signing requests, spoofed block explorer data, and malicious DApps, all without requiring any special setup or browser extensions.
• Wise Signer: An interactive platform that challenges users to identify safe and dangerous transactions before signing them. It is an excellent tool for learning to recognize common phishing attacks and deceptive transaction patterns without risking real assets.
• Web3 Wallet Security Courses: Offers a structured curriculum for hands-on security training, guiding users from foundational concepts in "Web3 Wallet Security Basics" to advanced techniques. The advanced course covers critical topics like Safe multisig configuration, EIP-712 signature verification, and real-world hack analysis.
• How to Multisig: A dedicated resource with best practices on how to implement secure standard operating procedures for multisig wallets.

External Security Reviews

An external security review is a time-boxed, security-based assessment of software systems, applications, and infrastructure to enhance security and identify vulnerabilities. External security reviews are essential for organizations to protect against threats and build trust with users and stakeholders.

Why Are External Security Reviews Important?

According to research, significant value and data have been compromised due to security vulnerabilities in software systems. Modern applications face complex threats from malicious actors, and security issues can lead to data breaches, financial losses, and reputation damage.

Beyond preventing security incidents, external security reviews provide several key benefits:

• Enhanced Security: Find and fix vulnerabilities before they can be exploited
• Team Education: Level up your engineering team's knowledge through security best practices
• Trust Building: Demonstrate maturity and safety to users and stakeholders
• Risk Mitigation: Identify business logic issues and implementation flaws
• Compliance: Meet regulatory and industry security requirements

Scope of External Security Reviews

Security reviews can encompass multiple layers of an organization's technology stack:

• Applications: Web applications, mobile apps, APIs, and microservices
• Infrastructure: Cloud configurations, network security, access controls, and deployment pipelines
• Data Systems: Databases, data processing pipelines, and storage security
• Third-party Integrations: External APIs, libraries, and vendor services
• Documentation: Technical specifications, security policies, and incident response procedures

External security reviews are not foolproof and cannot guarantee absolute security. They represent an ongoing commitment to safety rather than a one-time event.

Contents

There are many different kinds of external security reviews, and we have some context on many of them here.

1. Smart Contract Audits
2. Security Policies and Procedures

Smart Contract Security Reviews

Smart contract security reviews are specialized assessments focused on identifying vulnerabilities in blockchain-based smart contracts and protocols. These reviews are critical for web3 projects due to the immutable nature of blockchain deployments and the high-value targets that smart contracts often represent.

Why Smart Contract Security Reviews Are Critical

Smart contracts operate in a unique environment that makes security paramount:

• Immutability: Once deployed, smart contracts cannot be easily changed
• Financial Risk: Smart contracts often handle significant value in cryptocurrencies
• Public Accessibility: All code and transactions are visible on the blockchain
• Adversarial Environment: Attackers are incentivized by potential financial gains
• Complex Interactions: DeFi protocols involve intricate interactions between multiple contracts

According to industry data, billions of dollars have been lost due to smart contract vulnerabilities, making security reviews essential for protecting user funds and maintaining protocol integrity.

Smart Contract Security Review Process

A security review engagement is typically divided into four phases:

• Scoping Phase: The project team prepares the codebase and defines specific scope for security researchers
• Initial Assessment Phase: Researchers conduct preliminary analysis to identify potential security issues
• Mitigation Phase: The team works on fixing identified issues with ongoing auditor support
• Final Report Phase: Auditors review implemented fixes and provide a comprehensive final report

Audit Methodologies

• Static Analysis: Automated code scanning for known vulnerability patterns
• Dynamic Analysis: Runtime testing and fuzzing
• Manual Review: Expert analysis of business logic and complex vulnerabilities
• Formal Verification: Mathematical proofs of contract correctness (where applicable)

Types of Smart Contract Audits

Private Audits

• Dedicated security researchers assigned to your project
• Confidential and personalized attention
• Higher cost but comprehensive coverage
• Direct communication with audit team

Public/Competitive Audits

• Multiple researchers competing for prizes
• Diverse perspectives and approaches
• More cost-effective option
• Broader coverage through competition

Contents

This section contains detailed guidance on different aspects of smart contract security reviews:

1. Audit Expectations - What to expect during the audit process
2. Preparation Guide - How to prepare for a successful audit
3. Vendor Selection - Choosing the right security auditor

Manual Review

Manual review of a smart contract is the process of carefully examining the source code to identify potential vulnerabilities, logic errors, and design flaws. The approach to manual review can vary from person to person or team to team. This document outlines some of the possible things the process can comprise.

Gather resources

1. Scope:
   This can be a link to the code repository. e.g. Github, Gitlab link which consist of all the smart contracts required to be reviewed.

2. Commit hash:
   Agree on a specific commit hash from the repository and freeze the previously defined scope. Avoid continuous modifications to the codebase. Any changes should be communicated, and the commit hash should be updated for the code under review.

3. Documentation and specification:

   • Documentation describes how the code works, how to use it, and its expected functionality.
   • Specification defines the exact requirements, constraints, and behaviors the system must meet, including invariants that must always hold true.
     • Invariants are the properties of the system that should always hold. Invariants can be useful for checking the expected behavior of the system when the certain actions or a transaction flow is executed. Invariants are useful in many testing approaches, including manual reviews, where a reviewer checks whether a specific property can be violated for a function under any sequence of function calls.
     • Get simplified math formulas if the protocol has any custom/fancy formulas implemented.

4. Tests:
   Tests are important for understanding the expected behavior and ensuring that the system works as intended. The following types of tests can be useful for understanding and verifying the code:

   • unit tests: Unit tests ensure that individual functions behave correctly under expected conditions.
   • Integration Tests: Integration tests verify that your smart contracts work correctly with real external systems.

Smart contract higher overview

1. Documentation and whitepaper walkthrough:
   Go through the whitepaper and documentation to gain a better understanding of the project and to see how the proposed business logic is structured. What are the involved components.

2. High level idea:
   Get a high level idea behind the project: Through diagrams, developer walkthrough.

3. Structural overview:
   Get a structural overview of the project: Check how integration of contracts and functions is happening throughout the protocol.

4. Create a diagram:
   Based on the structural and functional understanding the high level diagram can be created if required.

   • The diagram can be modified over a time as you get more understanding.
   • The diagram can grow more complex and detailed depending on the time.
   • There are many tools that can be used like Excalidraw, Miro, Lucidchart, Mermaid etc.
   • High level structural example of staking diagram:

   classDiagram
   direction LR
   class Token {
     +mint()
     +burn()
     +transfer()
     +transferFrom()
   }
   class Staking {
     +constructor()
     +stake()
     +unstake()
     +getStakedAmount()
     +getTotalStaked()
   }
   class Rewards {
     +calculateRewards()
     +claimRewards()
     +initialize()
   }
   class Bridge {
     +transferToChain()
     +transferFromChain()
   }
   Token --> Staking: used in
   Staking --> Token
   Staking --> Rewards
   Staking --> Bridge : bridges token
   

Manual review

1. Understand the flow:
   Understand the flow from unit and Integration tests. Test cases are important. They give you an understanding of how the setup works and what state needs to be in place for users to start using the system’s entry points. They also give you time to test more offensive or edge-case scenarios (after verifying unit tests) instead of spending most of your time testing general scenarios.

   • When math formulas or complex interconnected calls are involved, debugging the values of variables helps sometime to see how the state changes are happening e.g. what is the value of variable x/totalStakedEth before the specific internal/external call. or what it becomes after that call.
   • Debugging can be done in many ways, depending on which framework you are using. Some examples are.
     • Foundry - native debugger, console logs in the contracts, Tenderly debugger, simbolik.
     • Hardhat - console logs in the contracts, debuggers like Hardhat-tracer, Tenderly debugger.

2. Choose least dependent contract to review one by one:
   This can be done by looking into a diagram and current understanding of the smart contract functionality. For example in this case it's a Token contract that is least dependent (in fact the functionality from that contract is getting used in other contracts so other smart contracts are dependent on it).

3. Checklist reviews:

   • Known smart contract vulnerabilities checklist.
   • Project specific checklists (e.g. When dealing with bridges it's also important to check bridge specific checklists).
   • Checklists may vary over time and can become outdated. Below are some examples for reference:
     • Smart Contract Security Field Guide
     • Smart Contract Security Verification Standard

4. Maintain a list of invariants:
   Maintain a list of invariants for every functions (Can be useful later for other tests/fuzzing/format verification).

5. Offensively analyze the code:
   Offensively analyze the code to identify logical issues, edge cases, and any conditions that could break invariants.

6. Visit all paths:
   Visiting all paths in a smart contract is crucial from a security perspective. For example, in the below withdraw() function, every path has its own potential security implications and behavior that needs to be verified. Sometimes these unexpected paths lead us to potential bugs. Generally frameworks provide tools to check test coverage, like the forge coverage command which can be used to generate code coverage reports for tests.

   While this section focuses more on manual approach, automated testing approaches like fuzzing and formal verification can be useful here for checking possible invariant violations across multiple paths.

   As can be seen below, everything boils down to each path. Even the ternary expression is ultimately a path.

   function withdraw(uint256 amount, bool emergency) public {
           require(amount > 0, "Withdraw amount must be greater than 0");
           uint256 balance = balances[msg.sender];
           bool success;
   
           if (emergency) {
               success = (address(this).balance >= amount) ? payable(msg.sender).send(amount) : false;
           } else {
               if (balance >= amount) {
                   balances[msg.sender] -= amount;
                   totalBalance -= amount;
                   success = payable(msg.sender).send(amount);
               } else {
                   success = false;
               }
           }
   
           if (!success) {
               // call other contract to handle failed withdrawal
           }
           emit Withdrawn(msg.sender, amount, success);
   }
   

   In next example, because every value (_amount, minRequired) can go increase or decrease, the results can vary. If the result is used for some operations like decreasing the drivingScore in burnFuelAndReduce() for example.

   E.g. depending on the amounts are same (as they were while filling the fuel) or increased or decreased, the value of fuelReduction will change and while subtracting it from the drivingScore[msg.sender] it needs to be handled accordingly. which also creates different paths.

   function fillFuelAndCalculate(uint256 _amount) public {
           require(_amount > minRequired, "ERR");
           fuelTank[msg.sender] += _amount;
           drivingScore[msg.sender] += (_amount * multiplier) / minRequired;
   }
   
   function burnFuelAndReduce(uint256 _amount) public {
           fuelTank[msg.sender] -= _amount;
           uint256 fuelReduction = (_amount * multiplier) / minRequired;
           drivingScore[msg.sender] = drivingScore[msg.sender] > fuelReduction ? drivingScore[msg.sender] - fuelReduction : 0;
   }
   

7. Write down notes, doubts and edge cases:
   One reason for writing down questions, ideas, possible issues is, when you start going through these issues as you encounter new path you can see more doubts, possible issues in your mind. So sometimes it becomes a loop where you will keep thinking about new ideas while exploring previous/current one.

   • Take notes to check your understanding.
   • Write down any questions to ask developers when you need clarification.
   • Note down edge cases for later testing. E.g: [test] Possible reentrancy in unstake() function.
   • Try to break down the business logic while going through every code block. (again note down the thing that needs to be tested)
   • Write down things to revisit after the code is fixed. E.g: In the review you noticed that if specific functionality would be added based on doubts asked or based on the suggested fixes etc, there are chances of something to go wrong for example. Note it down and check in the Fixed code review.
   • The minimal markdown file for taking notes might look like this:

   # Project Name
   ## Scope:  
   GH link:  
   Commit hash:  
   
   ## Flow:
   1. Manual review
   2. Functional testing:
       - Unit testing
       - Edge case testing
   3. Automated testing:
       - ...
   4. ...
   
   ## Resources:
   1. Specification doc:
   2. Whitepaper:
   3. Any other documentation and links.
   
   ## ToDo:
   *Things to do/ remaining things.*   
   1. High level things about audit 
   2. Developer project walk-through.
   3. ...
   
   ## Common/Doubts/Research:
   1. Relearn about specific cross chain service/protocol that's getting used.
   
   ## ContractName.sol
   *This contains doubts/points/research/potential bugs regarding the ContractName.sol*
   1. Confirmed issue 1.
   2. Confirmed issue 2.
       ### Doubts/Research:
       1. Checking specific formulas.
       2. Checking specific doubt.
       3. Check the subtraction on L453 can be a problem.
       4. [revisit] Revisit something based on the suggestion given.
       * Testcases:  
           1. [test] User should be able to stake.
           2. [test] Multiple users should be able to stake.
           3. [test] ...
   
   ## ContractName2.sol
   *This contains doubts/points/research/potential bugs regarding the ContractName2.sol*
   ...
   
   ---
   ## Questions for developers:
   1. Explanation for formulas.
   2. Questions about intended logic.
   3. ...
   

Functional testing

1. Check any missing test cases that should be covered.

2. Write and test edge cases from notes taken while manually reviewing contracts.

Automated review

While automated review can be classified as a different approach from manual review, it is useful to use techniques such as static analysis to identify low-hanging bugs by triaging warnings from tools like Slither, Wake, Aderyn etc.

There are other types of automated testing approaches, such as Fuzz Testing and formal verification, can also be helpful at different stages of the audit life-cycle, though they are less directly related to manual review.

Report writing

1. Questions and issue discussion with internal team:
   Discuss any questions and identified issues with the internal team or, if applicable, with the team of reviewers working in parallel on the project. This will help you reach a conclusion.

2. Questions and issue discussion with the developers or project team:
   Discuss and convey issues to the developers or project teams, as applicable. The goal is the technical dev. members of team should get issues so they can try to fix them. It can save time in large projects once the report is delivered.

3. Report writing:
   While the structure of a report and the issues/bugs it documents may vary, the following elements are helpful to include:

   • Public link to the code repository.
   • The commit hash pointing to the recently reviewed commit.
   • Issues can include a detailed description, recommendations, severity, status, the commit where the issue was fixed, and acknowledgments from developers.
   • References to correct functions and line numbers while writing issues.
   • Example and POC, helpful for critical bugs.
   • Checking the grammar/style for better readability.

Updated code review

For checking fixed code, it may be necessary to repeat previously performed actions, depending on what has changed. To avoid repeating work, you can:

1. Code comparison:
   This helps in identifying updates and detecting deviations from expected changes. For example, a git diff may reveal changes in functions that should not have been changed.

2. Reviewing updated code:
   Review the updated code to check expected and unexpected changes.

3. Run all the tests:
   Run all available tests on the updated code to ensure the newly updated code does not break any invariant.

4. Write new tests for the updated code:
   If the updated code creates any new control flow paths it's necessary to write tests to visit those paths and to ensure it yields the expected output.

5. Go through checklists again:
   For the updated functionality (depending on what has been changed), review the checklists to ensure that no vulnerabilities remain or have been introduced.

6. Check things/notes that needs to be revisited:
   Check items or notes that need to be revisited from the manual review. Sometimes you may have observations noted, e.g., Adding this fix to the code can create this problem.

7. Update the report:
   Update the report and issue status based on the updated code.

   • Change the status.
   • Add/update most recently reviewed commit link/hash.
   • Add comments from the audit team (when required).
     • These may include, for example, the reason why an issue remains open, any unresolved security concerns, or even new issues created by the fixes, but are not limited to these.
   • Add comments from the project team (when required).
     • These may include the reasons why an issue is acknowledged, or mitigations that will not be implemented at the smart contract level, but are not limited to these.

Final thoughts

Having multiple teams/members review each contract individually leads to better results, as it ensures more sets of eyes are examining the code.

References

Auditing mental model by Caliber

Expectations

Scoping Phase

The team looking for a security review will agree with the auditors/security researchers the exact parameters of the review. What exact contracts should they review? What should they not review? This is incredibly important so the can clearly estimate timelines on how long a review may take. This is also where compensation is discussed, usually the more aspects a team wants to review, the more expensive the audit will be.

Initial Assessment Phase

• Automated Testing: Auditors will run various automated security tools including static analysis, fuzz testing, formal verification, and unit testing to identify basic vulnerabilities
• Manual Code Review: Security researchers will manually analyze the code to understand context, complexity, and identify deeper vulnerabilities that automated tools might miss
• Documentation Review: Auditors will review project specifications and documentation to understand intended functionality

Deliverables

A comprehensive security review will generate the following:

Initial Report

• Vulnerability Identification: Security vulnerabilities classified by severity (High, Medium, Low)
• Proof of Concept: Demonstration of potential exploit scenarios where applicable
• Gas Optimizations: Recommendations for improving contract efficiency
• Informational Findings: Code quality improvements and best practice recommendations
• Mitigation Strategies: Specific recommendations for addressing each identified issue

Mitigation Phase

• Fix Review Period: Time allocated for your team to address identified vulnerabilities
• Collaborative Support: Ongoing communication with auditors during the fix implementation
• Code Re-review: Assessment of implemented fixes to ensure issues are properly resolved

Final Report

• Updated Assessment: Review of all implemented fixes and their effectiveness
• Residual Risk Analysis: Documentation of any remaining risks or limitations
• Public Publication: In web3, audit reports are commonly published publicly to build community trust

Timeline and Cost Expectations

The following are incredibly rough estimates for timelines/costs based on Solidity smart contract audits from around the industry. Actual timelines and costs will vary significantly based on the complexity of the codebase, the number of contracts, and the specific requirements of the project.

Duration

• Small Projects (< 1000 lines): 1-2 weeks
• Medium Projects (1000-4000 lines): 2-5 weeks
• Large Projects (> 4000 lines): 5+ weeks

Cost Range

• Per Week: $1,000 - $60,000 depending on complexity and auditor expertise
• Factors Affecting Cost: Codebase size, complexity, timeline requirements, auditor reputation

Important Limitations

• No Guarantee: Audits do not guarantee bug-free code or complete security. However, the engagement with the team should still provide value (teaching better security practices, improving code quality, etc.)
• Snapshot in Time: Audits assess code at a specific commit hash - any changes create unaudited code
• Ongoing Process: Security should be viewed as a continuous journey, not a one-time event
• Emergency Preparedness: Even audited protocols should have incident response plans and emergency communication channels

Preparation

A common misconception is that when doing a security review, you can just hand off the written code and let reviewers do their work. This approach is inefficient and costly, as auditors will spend time on issues you could have resolved beforehand. Proper preparation maximizes the value of your security review investment and helps auditors focus on complex vulnerabilities rather than basic issues.

How to Get the Most Out of Your Security Review

Set a Goal for the Review

This is the most important step of a security review and often the most overlooked. By setting a scope that is not too large or undefined, you are more likely to have a successful audit. If the project is very large, you may want to focus on the most critical aspects of the project.

Internal Due Diligence

Conduct internal testing before engaging an external security provider. You can do this by creating and running test vectors for your code, and leverage automated tools to identify low-hanging fruit. Here’s a list of free/open-source tools your project could use:

• Solidity: slither, mythril, semgrep-smart-contracts
• Golang: golangci-lint, go-critic, gosec
• Rust: cargo audit, cargo outdated, clippy, cargo geiger, cargo tarpaulin

Write Clear Documentation

Providing comprehensive documentation is essential for auditors to understand your protocol's intended functionality. Since 80% of all bugs are due to business logic issues, auditors need to understand what your protocol should do, not just what the code does.

Documentation should include:

• Project Overview: Describe your protocol in plain English—what it does and its components.
• Flow Diagrams: Outline all possible interaction paths within your system.
• Design Choices: Document design decisions and any known potential issues.
• Known Restrictions / Limitations: Document centralization risks and known limitations (e.g., limited TVL, token support).
• Dependencies: List all external dependencies.
• Access Control / Privileged Roles: Record all roles and their privileges.

Provide a Robust Test Suite

Maintaining a comprehensive test suite that covers significant portions of your codebase allows auditors to focus on finding vulnerabilities rather than understanding basic functionality. Before an audit, ensure you have:

• Unit Tests: Test individual functions and components
• Integration Tests: Test interactions between different parts of your system
• Fuzz Testing: Automated testing with random inputs to find edge cases
• High Code Coverage: Aim for substantial coverage of your critical code paths
• Formal Verification: If applicable, use formal methods to prove correctness of critical components

Conduct an Initial Code Walkthrough

The first step in a security audit should be a high-level video walkthrough where you:

• Explain your codebase architecture and key components
• Describe how the code is intended to function
• Highlight critical areas that need special attention
• Provide context for design decisions and trade-offs
• Guide auditors on where to find answers to common questions

This walkthrough helps auditors understand your system quickly and focus their time on security analysis rather than code comprehension.

Vendor Selection

Choosing the right security vendor is crucial for getting maximum value from your security review. There are numerous security vendors in both the web3 and web2 ecosystems, each with different specializations and approaches.

Types of Security Audits

Understanding the different types of security audits available helps you choose the right approach for your project:

Private Security Audits

Private smart contract security audits are performed by security companies or solo auditors, typically involving one or multiple security researchers specifically chosen by your team or assigned by the security firm.

Characteristics:

• Confidential engagement with limited access to code
• Dedicated focus from chosen security researchers
• Personalized attention and direct communication
• Typically higher cost but more thorough coverage

Public/Competitive Security Audits

Public or competitive audits involve tens or hundreds of security researchers competing to find the highest number of issues to win a share of a prize pool.

Characteristics:

• Open participation from multiple researchers
• Competitive environment drives thorough analysis
• Often more cost-effective than private audits, but less personalized
• Can identify a broader range of issues through diverse perspectives

Vendor Selection Criteria

1. Track Record and Reputation

• Evaluate potential vendors based on their track record, reputation, and experience in your specific technology stack
• Look for vendors with a proven history of addressing security challenges similar to your project's needs
• Check for published audit reports and client testimonials

2. Domain Expertise

• Web3 Focus: For smart contracts, DeFi protocols, or blockchain infrastructure, choose vendors with deep web3 security expertise
• Web2 Focus: For traditional infrastructure, APIs, or backend systems, consider vendors with strong web2 security backgrounds
• Specialized Knowledge: If building an L2, DEX, or other specialized system, prioritize vendors with relevant experience

3. Technical Capabilities

• Ensure the vendor has experience with your specific:
  • Programming languages (Solidity, Rust, Go, etc.)
  • Blockchain platforms (Ethereum, Polygon, Arbitrum, etc.)
  • Protocol types (DeFi, NFTs, DAOs, etc.)
  • Architecture patterns (proxy contracts, multisig, etc.)

4. Security Methodology

• Tool Usage: Verify they use appropriate automated security tools
• Manual Review: Ensure they conduct thorough manual code reviews
• Testing Approach: If applicable, look for comprehensive testing methodologies including fuzz testing or formal verification

Due Diligence Process

1. Request References: Ask for previous client references and audit examples
2. Evaluate Methodology: Understand their specific audit process and deliverables
3. Assess Communication: Ensure clear communication channels and responsive support
4. Review Pricing: Compare costs against scope and expected value
5. Timeline Alignment: Confirm availability matches your project timeline

Red Flags to Avoid

• Vendors who guarantee finding all vulnerabilities
• Extremely low pricing without clear scope limitations
• Lack of relevant experience in your technology stack
• Poor communication or unresponsive during initial discussions
• No clear methodology or standardized reporting process

Audit the Auditors

As of today, the best review of the security reviewers that we have is the historical performance of security reviewers. One of the best ways to evaluate this is to review the historical performance of the security team.

If you see codebases that they reviewed were hacked, this doesn't mean that the team is bad. There are two types of security teams out there:

• Those who have had codebases they have reviewed hacked
• Those who have not reviewed enough codebases

Additionally, comparing sequential audits of the same codebase can be misleading. If auditor A reviews codebase X, and then auditor B reviews the same codebase and finds more bugs, some insight from auditor A could have been used to find those extra bugs. However, if two auditors review the same codebase at the same time, this can be a much better comparison of the two auditors.

Security Policies and Procedures

As part of the external security review, it could be beneficial to also review the internal security policies and procedures as well. Some of the things that could be relevant to review are:

1. Ensure there is a developed and maintained plan for responding to security incidents.
2. Ensure there are defined roles and responsibilities, and enforce the principle of least privilege.
3. Ensure there are processes implemented for managing changes to the codebase and infrastructure.
4. Ensure there are regular training sessions conducted for all team members on security best practices.
5. Ensure adherence to any potentially relevant regulatory and industry standards for your project.

Security Testing

The objective of Security testing, while most likely impossible, is to ensure that applications and systems are resilient to attacks and free from vulnerabilities. This section covers various security testing methodologies, including dynamic and static application security testing, fuzz testing, and security regression testing.

There are several types of testing:

• Unit Testing: Tests individual components or functions of the codebase.
• Integration Testing: Tests the interaction between different components or systems.
• Fuzz Testing: Tests the application by providing random or unexpected inputs to identify vulnerabilities.
• Static Analysis: Analyzes the code without executing it to find potential vulnerabilities.
• Formal Verification: Uses mathematical methods to prove the correctness of algorithms and protocols.

Some types of testing overlap, for example, a unit test could also be a fuzz test. We will focus on testing and how it applies to smart contracts, and use solidity as an example.

Goal

The goal of security testing is to identify vulnerabilities and weaknesses in the codebase, while also making sure that the code behaves the same way even after changes. Different types of testing can help achieve this goal in different ways. There is no "one size fits all" solution, and the choice of testing methodology depends on the specific requirements and constraints of the project.

Smart Contracts

For smart contracts in particular, here is when to use each type of testing:

• Unit Testing: Always. And aim for high "code coverage" (i.e. unit test as many paths as possible)
• Integration Testing: Always. This can also be combined with fork testing.
• Fuzz Testing: Always. Most unit tests can be fuzz tests.
• Static Analysis: Always. Use tools like Slither and Aderyn to analyze the code for vulnerabilities.
• Formal Verification: Dependent. Anywhere functions are math heavy, stateless, or functionality matches another system, this should be used.

Evaluating your test suite

To ensure you're meeting the goals of security testing, it's essential to evaluate the quality and completeness of your test suite. This can be done through several approaches:

• Coverage Analysis: High code and branch coverage helps assess how thoroughly your test suite exercises different execution paths. Aim for comprehensive coverage to reduce blind spots.
• Mutation Testing: This technique measures the effectiveness of your test suite. It works by introducing small changes (or "mutations") to the code and checking whether the tests detect and fail on those changes. If a mutation doesn’t cause a failure, it may indicate a gap in your test logic.

Together, methods like these can give a more complete picture of how well your tests validate both expected and unexpected behaviors.

Dynamic Application Security Testing

Fuzz Testing

Fuzz testing (or fuzzing) is when you supply random data to your system in an attempt to break it. Most of the time, hacks come from scenarios you didn't think about and write a test for. What if I told you that you could write one test that would check for almost every possible scenario?

What is Fuzz Testing?

For example, if a balloon was our system/code, it would involve doing random stuff to the balloon to break it.

• Punch it
• Squeeze it
• Throw it
• etc

Why would we want to do all that? Let's look at an example.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract MyContract {
    uint256 public shouldAlwaysBeZero = 0;
    uint256 private hiddenValue = 0;

    function doStuff(uint256 data) public {
        if (data == 2) {
            shouldAlwaysBeZero = 1;
        }
        if (hiddenValue == 7) {
            shouldAlwaysBeZero = 1;
        }
        hiddenValue = data;
    }
}

Let's say we have this function named doStuff, which takes an integer as input. We additionally have a variable named shouldAlwaysBeZero that we want always to be zero.

The fact that this variable should always be zero is known as our invariant, or "property of the system that should always hold."

Invariant: The property of the system that should always hold.

Our invariant in this contract is that: Invariant: shouldAlwaysBeZero MUST always be 0

Why Normal Unit Tests Aren't Enough

Let's look at a normal unit test:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import {MyContract} from "../src/MyContract.sol";
import {Test} from "forge-std/Test.sol";

contract MyContractTest is Test {
    MyContract exampleContract;

    function setUp() public {
        exampleContract = new MyContract();
    }

    function testIsAlwaysZeroUnit() public {
        uint256 data = 0;
        exampleContract.doStuff(data);
        assert(exampleContract.shouldAlwaysBeZero() == 0);
    }
}

With this single unit test testIsAlwaysZeroUnit, we might think our code has enough coverage, but if we look at the doStuff function again, we can see that if our input is 2, our variable will not be zero.

function doStuff(uint256 data) public {
    // WHAT IS THIS IF STATEMENT???
    // 👇👇👇👇👇👇
    if (data == 2) {
        shouldAlwaysBeZero = 1;
    }
    // 👆👆👆👆👆👆

    // Ignore this one for now
    if (hiddenValue == 7) {
        shouldAlwaysBeZero = 1;
    }
    hiddenValue = data;
}

This seems obvious with our example function, but more often than not, you'll have a function that's much more complex with numerous edge cases that are impossible to manually test.

Stateless Fuzz Tests

In Foundry, you'd write a fuzz test like so:

function testIsAlwaysZeroFuzz(uint256 randomData) public {
    exampleContract.doStuff(randomData);
    assert(exampleContract.shouldAlwaysBeZero() == 0);
}

Foundry will automatically input semi-random values to randomData and over many runs, input them to the doStuff function and check that the assertion holds.

This would be equivalent to writing many tests where randomData had different values, all in one test!

Now I say "semi-random" because the way your fuzzer (in our case, Foundry) picks the random data isn't truly random, and should be somewhat intelligent with the random numbers it picks. Foundry is smart enough to see the if data == 2 conditional, and pick 2 as an input.

If we run our fuzz test, it tells us exactly what input fails our test:

$ forge test -m testIsAlwaysZeroFuzz

Failing tests:
Encountered 1 failing test in test/MyContractTest.t.sol:MyContractTest
[FAIL. Reason: Assertion violated Counterexample: calldata=0x47fb53d00000000000000000000000000000000000000000000000000000000000000002, args=[2]] testIsAlwaysZeroFuzz(uint256) (runs: 6, μ: 27070, ~: 30387)

We can see that it found out if it passed args=[2] to the test, it was able to break our assert(exampleContract.shouldAlwaysBeZero() == 0). So now, we can go back into our code, and realize we need to fix the edge case where data == 2, and now we are safe from the exploit!

Stateful vs Stateless Fuzzing

The Hidden Bug

Now you may notice that there is another scenario where our code could have an issue, and that's when hiddenValue == 7. In order for this revert to happen, you have to:

1. First call doStuff with the value 7 (which sets hiddenValue to 7)
2. Then call this function again with any other number

It takes 2 calls for our invariant to be broken:

1. Call doStuff with 7
2. Call doStuff with any other number

Our fuzz test written above will never be able to find this example because as it's currently written, our test is what's known as a "stateless fuzz test."

Stateless Fuzzing: Fuzzing where the state of a previous run is discarded for the next run.

Stateful Fuzz Tests (Invariant Tests)

So, in smart contract testing, we can do "stateful fuzzing" instead.

Stateful Fuzzing: The state of our previous fuzz run is the starting state of our next fuzz run.

To write a stateful fuzz test in Foundry, you'd use the invariant keyword, and it requires a little more setup:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import {MyContract} from "../src/MyContract.sol";
import {Test} from "forge-std/Test.sol";
import {StdInvariant} from "forge-std/StdInvariant.sol";

contract MyContractTest is StdInvariant, Test {
    MyContract exampleContract;

    function setUp() public {
        exampleContract = new MyContract();
        targetContract(address(exampleContract));
    }

    function invariant_testAlwaysReturnsZero() public {
        assert(exampleContract.shouldAlwaysBeZero() == 0);
    }
}

Instead of just passing random data to function calls, a stateful fuzz test (invariant test) will automatically call random functions with random data.

We use the targetContract function to tell Foundry that it can use any of the functions in exampleContract. There is just one function for this example, so it will just call doStuff with different values across multiple calls.

If we run this test, we can see it finds out that if you call doStuff twice (once with the value 7), it will break our invariant!

$ forge test -m invariant_testAlwaysReturnsZero

Failing tests:
Encountered 1 failing test in test/MyContractTest.t.sol:MyContractTest
[FAIL. Reason: Assertion violated]
        [Sequence]
                sender=0x000000000000000000000000000000000000018f addr=[src/MyContract.sol:MyContract]0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f calldata=doStuff(uint256), args=[7]
                sender=0x0000000008ba49893f3f5ba10c99ef3a4209b646 addr=[src/MyContract.sol:MyContract]0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f calldata=doStuff(uint256), args=[2390]

Perfect! It shows us the exact sequence of calls that broke our invariant.

Real-World Smart Contract Invariants

In an actual smart contract, your invariants won't be that a balloon shouldn't pop or some function should always be zero; they'll be something like:

• New tokens minted < inflation rate
• There should only be 1 winner of a random lottery
• Someone shouldn't be able to take more money out of the protocol than they put in
• The protocol must always be over-collateralized
• Total supply should equal sum of all balances

Fuzz Testing Tools

• Foundry
• Echidna
• Medusa

Best Practices

1. Start with Unit Tests: Build your foundation with comprehensive unit tests first
2. Identify Invariants: Clearly define what properties must always hold
3. Use Stateful Fuzzing: Most real bugs require multiple function calls to trigger
4. Bound Your Inputs: Use realistic parameter ranges in handlers
5. Document Invariants: Make your invariants clear in comments and documentation

References

Much of this document was inspired by the Cyfrin Updraft fuzzing curriculum.

Static Analysis

At a high level, static analysis examines the structure, syntax, and patterns of your code without executing it. There are many forms of static analysis, and compilers like solc rely on these techniques. From a security perspective, static analysis can help identify potential vulnerabilities and code quality issues.

Some static analysis tools are helpful for finding bugs too. Unlike dynamic testing (unit tests, fuzz tests, integration tests), these bug-finding-focused static analysis examines your code's structure, syntax, and patterns to identify potential vulnerabilities and code quality issues. You can think of these static analysis as being an automated code reviewer that never gets tired and knows common vulnerability patterns.

Static Analysis in Practice

Static analysis tools parse your source code and analyze it against known vulnerability patterns, coding standards, and best practices. They can quickly identify issues like:

• Known vulnerability patterns (reentrancy, integer overflow, etc.)
• Code quality issues (unused variables, dead code)
• Style violations (naming conventions, formatting)
• Logic errors (unreachable code, incorrect assertions)

For example, this code has a classic reentrancy vulnerability:

contract VulnerableContract {
    mapping(address => uint256) public balances;
    
    function withdraw() public {
        uint256 amount = balances[msg.sender];
        (bool success,) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
        balances[msg.sender] = 0; // ❌ State update after external call
    }
}

A static analysis tool will automatically detect this reentrancy pattern and flag it as a high-severity issue.

Static Analysis Tools

• Aderyn
• Slither
• Solhint

References

This document incorporates knowledge from:

• Cyfrin Updraft Security Testing Curriculum
• Trail of Bits secure contracts

Formal Verification

Formal verification is the act of proving or disproving a given property of a system using a mathematical model. While fuzz testing tries to break properties by throwing random data at your system, formal verification tries to break properties using mathematical proofs.

This is the highest level of assurance you can achieve in smart contract testing - mathematical certainty that your code behaves correctly under all possible conditions. The downside, is that it is often the most time-consuming to get correct.

What is Formal Verification?

Think of formal verification as translating your code into a mathematical model and using formal reasoning to prove whether certain properties hold. Unlike fuzzing, which tests the program with many random inputs, formal verification explores the program’s behavior through modeling rather than relying on specific test cases.

For example, if you want to prove that a function should never revert, formal verification will create mathematical representations of all possible code paths and determine if any input could cause a revert.

Symbolic Execution

The most popular technique for formal verification in smart contracts is symbolic execution. In a nutshell, symbolic execution explores every possible execution path mathematically.

Here's how it works:

1. Explore All Possible Paths

Consider this simple function:

function f(uint256 a) public pure returns (uint256) {
    return a + 1;
}

If our property is "this function should never revert", symbolic execution will find two possible paths:

• Path 1: a < type(uint256).max → returns a + 1
• Path 2: a == type(uint256).max → overflows and reverts

2. Convert Paths to Mathematical Expressions

These paths become boolean expressions:

Path 1: a < type(uint256).max
Path 2: a == type(uint256).max AND a + 1 < a

3. Feed to SMT/SAT Solver

These expressions are converted to SMT-LIB format and sent to solvers like Z3:

; Declare a symbolic integer variable 'a'
(declare-const a (_ BitVec 256))

; Path 2: Check if overflow is possible
(assert (= a #xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff))
(assert (bvult (bvadd a (_ bv1 256)) a))
(check-sat)

If the solver returns sat (satisfiable), it found an input that breaks your property!

Real-World Example: Complex Math Functions

Here's where formal verification really shines - catching bugs in complex mathematical code that would be nearly impossible to find manually or through testing.

Consider this intentionally confusing contract with custom operators:

It has been truncated for space here

// Custom type with confusing operator overloads
type Int is uint256;

using {add as -} for Int global;  // - actually does division!
using {div as +} for Int global;  // + actually does multiplication!
using {mul as / } for Int global; // / actually does subtraction!
using {sub as *} for Int global;  // * actually does addition!

function add(Int a, Int b) pure returns (Int) {
    return Int.wrap(Int.unwrap(a) / Int.unwrap(b)); // Division
}

contract FormalVerificationCatches {
    function hellFunc(uint128 numberr) public view returns (uint256) {
        // Extremely complex math with many nested conditions
        // and confusing operator overloads...
        // (hundreds of lines of complex mathematical operations)
    }
}

Formal Verification Test with Halmos

We can use Halmos (a symbolic execution tool) to verify this function never reverts:

import {Test} from "forge-std/Test.sol";
import {FormalVerificationCatches} from "../src/FormalVerificationCatches.sol";

contract HalmosTest is Test {
    FormalVerificationCatches fvc;

    function setUp() public {
        fvc = new FormalVerificationCatches();
    }

    // Symbolic execution test with Halmos
    // Run with: halmos --function check_hellFunc_doesnt_revert_halmos
    function check_hellFunc_doesnt_revert_halmos(uint128 num) public view {
        (bool success,) = address(fvc).staticcall(
            abi.encodeWithSelector(fvc.hellFunc.selector, num)
        );
        assert(success);
    }
}

The Power of Formal Verification

When you run this test, Halmos will output:

[FAIL] check_hellFunc_doesnt_revert_halmos(uint128) (paths: 10/18, time: 3.05s)
Counterexample:
    p_num_uint128 = 0x0000000000000000000000000000000000000063 (99)

Formal verification found that input 99 causes the function to revert!

This bug would be difficult to find through:

• Manual review (very complex to trace)
• Unit testing (would need to test that exact input)
• Fuzz testing (might miss this specific edge case)

But formal verification explored all mathematical paths and proved the bug exists.

Limitations

Formal verification is not a silver bullet:

Path Explosion Problem

Complex contracts can have too many execution paths for tools to explore in reasonable time.

Significant Effort Required

Often, to get this right, this technique requires significant effort to be used. You need to understand how they work, their limitations, and how to help them.

Specification Challenge

You must clearly define what properties you want to prove. If your specification is wrong, verification is useless.

Solver Limitations

Sometimes solvers cannot find solutions to complex mathematical problems within reasonable timeouts.

Tools and Frameworks

Symbolic Execution Tools:

• Halmos - Symbolic testing for Foundry
• HEVM - Haskell EVM with symbolic execution
• certora prover

SMT/SAT Solvers:

• Z3 - Microsoft's theorem prover
• CVC4 - Automatic theorem prover

Built-in Options:

• Solidity SMT Checker - Built into the compiler

References

This document was inspired by this article and the Cyfrin Updraft formal verification curriculum.

What is Mutation Testing?

Mutation testing is a technique used to evaluate the quality of a test suite by introducing small changes (mutations) to the code and checking if the tests catch these changes. Each change, called a "mutant," simulates a potential bug. If your tests fail when a mutant is introduced, the mutant is "killed," indicating your tests are effective. If the tests pass, the mutant "survives," revealing a potential gap in your test coverage.

How does it work?

The exact behaviour varies depending on the tool used, but the general flow looks like this:

1. Mutant Generation: The mutation testing tool automatically modifies your source code in small ways (e.g., changing a + to a -, or replacing a < with a =<).
2. Test Execution: The full test suite is run against each mutant version of the code.
3. Result Analysis: If the tests fail for a mutant, it is considered "killed." If the tests pass, the mutant "survives," indicating that the test suite did not detect the change.
4. Mutation Score: The effectiveness of your tests is measured by the mutation score, calculated as the percentage of mutants killed by the test suite.

Types of Mutants

There is a wide range of mutations that you can have, ranging from common software engineering ones to solidity-specific ones, for example:

Common Types

• Arithmetic Operator Replacement: Changes + to -.
• Relational Operator Replacement: Alters == to !=.
• Logical Operator Replacement: Modifies && to ||.
• Conditional Boundary Changes: Adjusts >= to >.
• Constant Replacement: Replaces 0 constants with 1.
• Statement Removal: Removes or skips statements to simulate missing logic.

Solidity specific

• Data Location Keyword Replacement: Changing memory to storage and vice versa.
• Call Type Replacement: Changin delegatecall() to call().
• Modifier Deletion or Insertion: Removing or inserting for example onlyOwner() modifier.
• Exception Handling Deletion: Remove require() statements.

Selecting mutations

Depending on the framework you use and the protocol you are building, you will have to pick appropriate mutators. The balance is the following:

• More mutations -> Longer execution time -> Potentially more coverage
• Less mutations -> Quicker execution time -> Potentially less coverage

Here are some examples of types of issues that mutation testing is particularly effective at spotting and types of operators you should consider using:

• Logic Errors: Off-by-one errors, incorrect comparison operators, wrong arithmetic operations, and logical operator mistakes.
• Edge Case Failures: Boundary condition bugs, empty value handling, Overflow/underflow issues.
• Validation: Missing access controls, Insufficient validation.

What it's NOT good at:

• Design-level architectural flaws
• Complex integration bugs requiring multiple components
• Performance issues not related to logic
• Documentation or specification mismatches

Modifier Mutation Example

Let's say you have this simple Token Vault that allows users to withdraw funds:

contract TokenVault {
 mapping(address => uint256) public balances;
 address public owner;
    
 modifier onlyOwner() {
 require(msg.sender == owner, "Not authorized");
 _;
 }

 // assume there is a deposit function as well here
    
 function withdraw(uint256 amount) external onlyOwner {
 require(balances[msg.sender] >= amount, "Insufficient balance");
 balances[msg.sender] -= amount;
 payable(msg.sender).transfer(amount);
 }
}

Let's now use SuMo, as they have their modifier list easily available.

We could apply the following mutation to this code:

• Remove onlyOwner modifier, using MOD operator. → Tests should fail when non-owner calls withdraw.
• Change >= to >, using the BOR operator. To be mindful, this will produce a lot of mutations with other operators as well. → Tests should fail for exact balance withdrawals.
• Change -= to +=, using AOR operator. Similarly to BOR will produce a lot of mutations. → Tests should fail (balance increases instead of decreases).
• Remove the require statement, using the EHD operator. → Tests should fail when withdrawing more than the balance.

The tool will produce a report, where survived and killed mutations will be highlighted. The next step would be to investigate whether any mutations have survived and, if so, whether testing for that case makes sense, or if there is a bug in the code.

Best Practices and things to keep in mind

1. Make sure your Line and Branch coverage is already very high, close to 100%

Mutation testing is essentially a "meta-test" of your test suite. If your tests don't even execute certain lines of code (low line coverage), then mutations in those lines will always survive because the tests never run that code path. This makes mutation testing ineffective and misleading; hence, improving line and branch coverage first is the priority before attempting mutation testing.

2. Achieving a 100% mutation score might not be feasible

A 100% mutation score indicates that no mutants have survived the test. Fundamentally, it is the end goal, but can be sometimes infesable and unnecessary, especially as the codebase grows in size. Instead 100% should be strived for, and every survived mutant carefully examined to see if that mutation makes sense and if the test should cover it.

3. Consider using only a subset of the mutators available

Not all mutation operators are equally useful for every project. Some may generate mutants that are irrelevant or impossible to kill due to language constraints or business logic. A larger subset of mutators will also take significantly longer to run, especially if there are many replacements per mutation.

4. Consider using cloud infrastructure if your codebase is reasonably large

Due to how mutation testing works, the larger the codebase size, naturally, the more mutants there will be, which increases the runtime of the test suite. Let's say you have 2k LoC, and you want to mutate > operator, you might have 100 occurrences of that operator, where each will be mutated 4 times, leaving you already with 400 variations of the codebase, where you have to run the whole test suite on. So it is not unusual for mutation testing to take multiple hours to run. Hence, having a remote cloud setup for such testing is advisable.

Limitations

• Mutation testing is a time-consuming process and is only as good as the mutations it generates. Therefore, selecting the key mutations is a crucial step.
• Mutation testing is only as good as your existing test suite. If your tests are fundamentally flawed, mutation testing won't help identify the real issues.
• Focuses primarily on unit-level testing and may miss integration-level or system-level bugs that require broader context.

In summary, mutation testing is a great tool if used correctly, but it is not a silver bullet for ensuring code quality. While it can significantly improve test quality by identifying gaps in your test suite, it requires careful configuration and interpretation of results.

Tools and Frameworks

• SuMo by MorenaBarboni
• vertigo-rs by RareSkills
• Gambit by Certora
• UniversalMutator by sambacha. However, it is a generalised mutation testing framework, which may lack the Solidity-specific mutators that the others contain.

References

This guide was heavily inspired by the following:

1. RareSkills Solidity Mutation Testing
2. Metana Solidity Mutation Testing

ENS Best Practices

🔑 Key Takeaway: To securely implement ENS in your applications, prioritize direct L1 data verification, enforce proper name normalization, and validate bidirectional resolution. Always verify interface support before interaction, respect chain-specific cointype parameters, and implement CCIP-Read functionality correctly. These practices prevent address spoofing, ensure cross-chain compatibility, and maintain data integrity throughout the ENS ecosystem.

The Ethereum Name Service (ENS) is a distributed, open, and extensible naming system based on the Ethereum blockchain.

ENS maps human-readable names like 'alice.eth' to machine-readable identifiers such as Ethereum addresses, other cryptocurrency addresses, content hashes, metadata, and more. ENS also supports 'reverse resolution', making it possible to associate metadata such as primary names or interface descriptions with Ethereum addresses.

What This Framework Covers

This best practices framework includes guidance on:

• Data Integrity & Verification - Ensuring reliable and secure name resolution
• Cross-Chain Compatibility - Supporting ENS across multiple blockchain networks
• Smart Contract Integration - Leveraging ENS in smart contract systems
• Interface Compliance - Correctly implementing and verifying ENS interfaces
• Name Handling & Normalization - Properly processing and displaying ENS names

These recommendations are designed for developers integrating ENS into applications, wallets, smart contracts, or other blockchain systems. Following these practices will help create more secure, reliable, and user-friendly ENS implementations.

Data Integrity & Verification

Use On-chain Resolution for Financial Transactions

• Always resolve fresh data directly from Ethereum mainnet whenever conducting financial transactions
• Do not rely on indexer or API data when moving or managing funds
• Preferably run an Ethereum node for high-value transactions, or if not feasible, use reputable L1 RPC providers while still verifying the integrity and audit status of all software involved in the resolution process

Rationale: Indexers and third-party APIs may have delayed updates or inconsistencies that could lead to payments being sent to outdated or incorrect addresses. By querying L1 directly, applications work with the most current and authoritative ENS data, dramatically reducing the risk of misdirected funds. This is particularly crucial for high-value transactions where the consequences of using stale data could be severe.

Verify Forward Resolution on Reverse Records

• Always perform forward resolution on reverse records to verify address matches
• Check that name → address → name completes a valid loop
• Clearly indicate to users when there's a mismatch

Rationale: ENS supports both forward resolution (name → address) and reverse resolution (address → name). However, reverse records can be set independently, creating the possibility for spoofing or impersonation if not properly verified. By performing forward resolution on the result of a reverse lookup and comparing it to the original address, applications can ensure the bidirectional integrity of the ENS data, preventing potential phishing or impersonation attacks.

Cross-Chain Compatibility

Respect Cointype for Chain-Specific Resolution

• Always use the correct cointype parameter when resolving addresses on specific chains
• For EVM-compatible chains, derive cointypes from chain IDs according to ENSIP-11

Rationale: An ENS name can resolve to a different address for each different blockchain network, which ENS supports through the cointype field in address records (following SLIP-44 standards). With the rise of smart contract wallets and account abstraction, users may have different addresses across different chains. Failing to respect the cointype when resolving addresses can lead to funds being sent to addresses that don't exist on the target chain or that belong to different entities altogether.

Implement CCIP-Read Support

• Properly support and handle CCIP-Read functionality EIP-3668
• Set reasonable timeouts and fallbacks for CCIP-Read operations

Rationale: CCIP-Read (EIP-3668) enables off-chain data retrieval for ENS resolution, allowing for more complex resolution patterns and greater flexibility for name owners. This protocol allows resolvers to redirect resolution requests to off-chain services that can implement custom logic beyond what's practical on-chain. Applications that ignore CCIP-Read requests limit the functionality available to ENS users and may provide incorrect resolution results. Supporting this standard ensures compatibility with advanced ENS use cases.

Test Multi-Chain Implementations

• Test ENS resolution across all chains your application supports
• Implement proper error handling for unsupported chains
• Document which chains are supported by your implementation

Rationale: As blockchain ecosystems expand, users expect applications to work across multiple networks. Testing ENS resolution across different chains ensures consistent behavior regardless of which network a user is connected to. Clear documentation about chain support also helps users understand the limitations of your application.

Handle Reverse Records Per Chain

• Query reverse records on the chain where the address exists, not just mainnet
• Consider user context when displaying names, prioritize the reverse record from the chain the user is currently interacting with
• Validate reverse record ownership by checking if the returned name actually resolves back to the queried address on that chain

Rationale: With ENSIP-19, reverse records (address-to-name lookups) can now be set and queried on any chain, not just Ethereum mainnet. This allows users to set different reverse records for the same address across different networks, enabling more contextual and chain-specific identity resolution. Applications that only check mainnet reverse records will miss valid reverse resolutions on other chains where users are actually active, leading to incomplete or incorrect identity displays.

Smart Contract Integration

Name Your Smart Contracts

• Register ENS names for core contracts in your project's ecosystem
• Set appropriate reverse records for your contracts
• Document contract ENS names in project documentation
• Consider naming contracts at deployment time to ensure immediate resolvability
• Use a standard pattern for contract naming to improve discoverability

Rationale: Smart contracts typically have complex hexadecimal addresses that are error-prone when shared or referenced. By assigning ENS names to smart contracts, developers can significantly improve user experience, make documentation more approachable, and reduce the risk of address errors. This practice is especially important for contracts that interact directly with users or serve as key infrastructure components. Human-readable names also aid in contract verification, as users can more easily confirm they're interacting with official protocol contracts rather than potential phishing imitations.

Leverage ENS as an Infrastructure Component

• Use ENS for service discovery between contract components
• Build upgradeability mechanisms that leverage ENS for implementation pointers
• Consider ENS as a registry for official protocol extensions and integrations
• Use ENS records to store protocol metadata in a human-readable format

Rationale: ENS can serve as more than just a human-readable address layer, it can function as critical infrastructure for contract systems. Using ENS for implementation pointers enables flexible and upgradeable architectures, as contract dependencies can be redirected without requiring contract redeployment. This pattern supports robust governance models while maintaining a consistent user interface. Additionally, using ENS to register official extensions creates a trust layer that helps users identify legitimate protocol integrations, while storing protocol metadata in ENS records improves discoverability and system documentation.

Interface Compliance

Verify Resolver Interface Support

• Always check if a resolver supports your target interface using EIP-165
• Call supportsInterface() before attempting to use specific resolver methods
• Implement graceful fallbacks when interfaces aren't supported
• Cache interface support results to minimize redundant on-chain calls

Rationale: ENS resolvers can implement various interfaces, each providing different functionality (addresses, text records, content hashes, etc.). Not all resolvers implement all interfaces, so checking interface support before calling specific methods prevents failed transactions and improves reliability. This verification step is especially important as the ENS ecosystem evolves and new resolver interfaces are introduced. Without proper interface verification, applications may fail when encountering resolvers with limited functionality or custom implementations.

Signal Supported Interfaces in Custom Resolvers

• When writing custom resolvers, properly implement EIP-165
• Signal all supported interfaces via supportsInterface()
• Document which interfaces your resolver supports
• Consider incremental implementation of interfaces based on user needs

Rationale: Implementing EIP-165 interface detection allows other contracts and applications to programmatically discover what functionality your resolver supports. This promotes interoperability and ensures your custom resolver can seamlessly integrate with the broader ENS ecosystem. Proper interface signaling is not just a technical requirement but a key element of good blockchain protocol citizenship. Without it, other contracts and applications can't reliably determine the capabilities your resolver offers, leading to poor user experiences and potential security risks.

Stay Updated with ENS Improvement Proposals (ENSIPs)

• Regularly monitor the ENS GitHub repository for new ENSIPs
• Participate in ENSIP discussions to provide implementer feedback
• Implement support for new ENSIPs after they reach "Final" status
• Plan for deprecation of older interfaces as specified by ENSIPs
• Test implementations against the reference implementations provided in ENSIPs

Rationale: The ENS protocol evolves through the ENSIP process, which introduces new interfaces, standards, and recommended practices. Staying current with these proposals ensures your implementation remains compatible with the broader ecosystem and can leverage new functionality as it becomes available. ENSIPs often address security vulnerabilities, improve user experience, or add valuable new features that users will come to expect. Implementers who track and promptly adopt new ENSIPs gain competitive advantages while contributing to the overall health and advancement of the ENS ecosystem.

Name Handling & Normalization

Normalize Names per ENSIP-15

• Always normalize ENS names before creating namehash, labelhash, or DNS-encoding
• Use established libraries that correctly implement ENSIP-15 normalization (like @adraffy/ens-normalize)
• Apply normalization at the earliest possible point in your ENS handling logic
• Include normalization checks in validation procedures for user-entered names

Rationale: ENS uses a specific normalization algorithm defined in ENSIP-15 to ensure consistent handling of Unicode characters and emoji sequences. Failing to normalize names correctly can result in different hash values for what users perceive as the same name, leading to resolution failures, security vulnerabilities, and poor user experience. Proper normalization is fundamental to the correct operation of any ENS integration and must be performed before any cryptographic operations (namehash, labelhash) or encoding. Using established libraries ensures compliance with the complex requirements of ENSIP-15.

Implement Security Measures for Homograph Attacks

• Detect and warn users about visually confusable characters in ENS names
• Display names using fonts that clearly differentiate similar-looking characters
• Consider displaying the script/language of characters in multi-script names
• Implement visual indicators for mixed-script names or potentially deceptive names
• When displaying ENS names, highlight or annotate unexpected character sets

Rationale: Homograph attacks use visually similar characters from different Unicode scripts to create deceptive names (e.g., using Cyrillic 'о' instead of Latin 'o'). While ENSIP-15 addresses some confusables, it cannot eliminate all visual ambiguities. Implementing additional security measures helps users identify potentially deceptive names before interacting with them. These protections are particularly important in financial applications or any context where users might send assets to an ENS name, as homograph attacks can lead to irreversible asset loss.

Properly Handle Emoji in ENS Names

• Ensure your UI correctly displays emoji in ENS names at appropriate sizes
• Be aware that emoji rendering varies across platforms and fonts
• Handle emoji sequences correctly, including skin tone modifiers and ZWJ sequences
• Test thoroughly with emoji-containing names on multiple platforms and browsers
• Use libraries that correctly implement UTS-51 (Unicode Emoji) for handling emoji

Rationale: Emoji are increasingly common in ENS names but introduce technical challenges. Emoji can be composed of multiple code points, including zero-width joiners (ZWJ) and variation selectors, making proper handling critical. Incorrect emoji implementation can cause names to appear differently across platforms or fail to resolve correctly. Emoji rendering also varies significantly between operating systems and browsers, requiring thorough cross-platform testing to ensure consistent user experience.

SEAL Whitehat Safe Harbor

💡 An industry-standard framework, letting your protocol pre-authorize whitehats to rescue funds during active exploits

What is Safe Harbor?

When your protocol is under attack, every second counts. Safe Harbor gives you a way to fight back.

Safe Harbor is a legal and technical framework that lets your protocol pre-authorize whitehats to step in during active exploits, rescue funds, and return them - fast, safely, and with clear legal protection for everyone involved.

By adopting Safe Harbor, protocols allow:

• Empower whitehats to act immediately during an exploit
• Remove legal ambiguity and delays
• Boost the odds of recovering user funds

Why we started Safe Harbor

💡 We started Safe Harbor after the Nomad hack, where over $190M was drained over the course of hours while whitehats stood by, willing to help, but unable to act without legal protection. With Safe Harbor, our goal is to make sure that never happens again and to empower whitehats to rescue funds.

Vetted by industry leaders and top Web3 lawyers

Safe Harbor was developed over two years with direct input and rigorous legal review from experts at a16z Crypto, Cooley, Debevoise & Plimpton, Filecoin Foundation, MetaLeX, Paradigm, Piper Alderman, Powerhouse, and more.

Who's Adopted Safe Harbor

Safe Harbor is already protecting $16B+ in assets across leading DeFi protocols. Current adopters include Uniswap, Pendle, PancakeSwap, Balancer, Silo Finance, Zksync, and more. See the full up-to-date list.

How Does Safe Harbor Work?

• Protocols pre-authorize rescues: You clearly define when and how whitehats are allowed to step in - covering what assets are protected, where to return funds, and what bounty terms apply, etc
• Whitehats act only during active exploits: Safe Harbor only applies when an exploit is already in progress or imminent - e.g., in the mempool, or after initial funds have been drained. It's not for bug bounty reports, and it does not protect blackhats. Only whitehats who rescue funds without initiating the exploit are covered.
• Funds are returned, bounty is automatic: Whitehats must send rescued funds to your official recovery addresses within 72 hours. Bounties are enforceable and pre-defined - no negotiation, no chaos.

Other key protections:

• You can choose to allow anonymous whitehats or require KYC.
• Whitehats must follow established guidelines for responsible intervention
• You define exactly which contracts, and chains are protected.
• The agreement is only valid if funds are returned and the protocol's rules are followed

How to adopt?

Adopting Safe Harbor is fast, simple, and works whether you're a DAO or a centralized team. You can complete the whole process in under an hour.

Here are a few options:

1. Get Help from SEAL

For protocols that want white-glove support, SEAL offers guided onboarding at no cost. We'll walk you through scoping, governance language, on-chain registration, etc.

→ Apply for the SEAL Onboarding Waitlist

Space is limited - we prioritize high-impact protocols and critical infrastructure

2. Self-Adopt Using Our Guide

For teams that want to do it themselves, we provide a clear step-by-step guide, including templates for scope definitions, template DAO proposals, and on-chain registration instructions.

→ View the Self-Adoption Guide

3. Adopt Through a Third-Party Provider

Safe Harbor is also supported by select ecosystem partners who offer adoption workflows as part of their existing services.

→ Adopt via Immunefi

Safe Harbor doesn't require a legal entity, legal counsel, or new infrastructure. Just define your terms, publish your scope, and your protocol is protected.

Whether you're a DAO or not, adopting Safe Harbor is a low-lift way to enable real-time defense and recover funds during live exploits.

Whitehats Work

💡 SEAL911 and the broader whitehat community have already helped protocols recover over $150M from live attacks - proving that fast, responsible intervention is possible.

FAQ

What counts as an active exploit?

An active exploit is one that’s already in progress or imminent - for example, a malicious transaction sitting in the mempool or a vulnerability that's already being exploited. Safe Harbor only applies when immediate action is required to prevent or stop fund loss. It does not apply to situations where there is no imminent threat and where responsible disclosure can prevent fund loss.

How is it different than a Bug Bounty?

Bug bounties reward whitehats for responsibly disclosing vulnerabilities before they’re exploited. Safe Harbor kicks in after an exploit is underway - when there’s no time for disclosure, and whitehats need legal cover to intervene and recover funds in real time.

What are the risks?

There is little to no risk. The status quo is the protocol is hacked and the hacker gets 100% of funds. But with Safe Harbor, we unlock the upside of whitehats stepping in and rescuing funds. So the worst case scenario is the status quo, while the best case scenario is all funds are rescued by the protocol.

Whitehats only receive protection if they follow every requirement. If no exploit happens, nothing changes. If they do not follow Safe Harbor, they’re a blackhat

Can DAOs adopt it?

Yes. Safe Harbor was built with DAOs in mind. No legal entity is required - just a governance vote and public on-chain registration. Many protocols who have adopted are DAOs (ex: Uniswap, Balancer, Zksync)

Can Non-DAOs adopt it?

Yes. Centralized teams and foundations can also adopt Safe Harbor by publishing their scope and adoption terms. No DAO is required. Many protocols who have adopted are centralized teams (Pendle, Polymarket)

Who is the agreement with?

The Safe Harbor agreement is structured as a public unilateral offer - a legally binding offer made by your protocol to any whitehat who acts under the published terms. There’s no need to know or pre-approve the individual. If a whitehat follows your rules (e.g. intervenes during an active exploit, returns funds to the recovery address, meets any KYC requirements), the agreement becomes binding. No signatures or formal negotiation required.

Do we need to sign a legal contract (like DocuSign)?

Nope. Safe Harbor uses on-chain registration and public adoption details - no signatures or lawyers required. If you’re a DAO, a governance vote is enough.

What if a blackhat initiates a hack with one account, then “whitehats” it with another account to get the bounty?

They’re not covered. Safe Harbor protections only apply to whitehats who are fully independent from the original exploit. If someone initiates a hack and then tries to “rescue” the funds with another address, they’re still considered a blackhat - no bounty, no legal protection, and fully liable.

To reduce this risk even further, we recommend protocols set their Safe Harbor bounty cap at or below their existing bug bounty. This way, there’s no financial incentive to attempt an exploit - it's easier, safer, and more profitable to report the bug through your standard disclosure process than to fake a whitehat rescue under legal risk.

Can we modify the Safe Harbor legal contract?

We strongly discourage protocols from modifying the legal language of the Safe Harbor agreement. The framework is designed as a standard across the industry, so whitehats can understand the rules quickly and act confidently during emergencies.

That said, the agreement is built with flexibility where it matters: you define your scope - such as which contracts are covered, Asset Recovery Addresses, bounty terms, and KYC requirements. These parameters are designed to give you control without breaking the shared standard that makes Safe Harbor effective.

Should our legal team review the Safe Harbor agreement?

It’s optional. The agreement has already been vetted by leading law firms (Cooley, Debevoise & Plimpton, Piper Alderman) and adopted by top-tier protocols like Uniswap, Balancer, and Pendle.

That said, if your legal team wants to review it for extra peace of mind, they absolutely can. Just keep in mind: the agreement is a community standard designed for consistency, so major edits aren’t recommended (and usually unnecessary).

Safe Harbor Eligibility Checklist

Use this checklist to evaluate whether adopting the SEAL Whitehat Safe Harbor Agreement makes sense for your protocol.

Can Safe Harbor Help Your Protocol?

• Do you hold user funds in smart contracts? Without Safe Harbor, whitehats who could save your users' funds might hesitate to act due to legal uncertainty around unauthorized access.
• Do you want whitehats to help during active attacks? Safe Harbor gives ethical hackers legal protection to intervene immediately, before attackers can drain your protocol.
• Do you already have a bug bounty or security disclosure program? Safe Harbor fills the critical gap your bug bounty can't cover - live attacks happening right now when disclosure timelines don't matter.
• Do you want to increase the odds of recovering funds? Safe Harbor encourages rescue attempts by trusted whitehats.

If you checked any of the above - you can benefit from adopting our Safe Harbor.

What Does Adoption Involve?

1. Define your scope (what's covered, where funds go, bounty %, etc.)
2. (If DAO) Pass a governance proposal
3. Register on-chain
4. Update your Terms of Service and documentation
5. Make a public announcement to inform users and whitehats

It's fast, flexible (DAO or non-DAO), and aligns with industry standards.

Ready to Get Started?

You have 3 ways to adopt:

1. Self-adopt using our guide:

   → Self-Adoption Guide

2. Get help from SEAL (free):

   → Apply for onboarding

3. Adopt via a third-party:

   → Immunefi: Immunefi Integration Form

Find out more about Safe Harbor here

---

If you ever need help or have any questions, don’t hesitate to reach out!

Contact us at: safe-harbor@securityalliance.org

Self-Adoption Guide

This guide walks you through the full process of self-adopting the SEAL Safe Harbor Agreement for your protocol. The goal is to provide whitehats with legal clarity and confidence to rescue funds when it matters most.

To do this effectively, protocols should cover all public and legal bases: defining a clear scope, obtaining DAO approval (if applicable), registering on-chain, updating their terms of service, and making a public announcement.

1. Scope Definition

The first step is defining the scope. This information informs whitehats about how and when they can intervene. It includes which assets are covered, where to send rescued funds, how to contact your team, what bounties apply, and any identity requirements.

• Refer to the scope walkthrough: Scope Definitions & Tips
• DAO Template: DAO Scope Template
• Non-DAO Template: Non-DAO Scope Template

2. DAO Proposal (If applicable)

If you are a DAO, this is a critical step. It formalizes permission from the community and provides legitimacy to the adoption.

• DAOs do not need a legal entity. Safe Harbor was designed to allow on-chain communities to adopt the agreement natively.
• Use the DAO Proposal draft from Step 1 where you defined the scope. Feel free to edit the proposal to reflect your DAO’s tone and format.
• Push your proposal through governance, temp check → formal proposal → Snapshot/Tally/etc.
• (Optional) Include the on-chain adoption call in the proposal itself for a full end-to-end flow.

3. On-Chain Adoption

Whether you're a DAO or a centralized team, you'll need to publish your adoption on-chain. This ensures your terms are publicly visible and enforceable.

If you are NOT doing on-chain via DAO proposal:

• Follow the guide: SEAL Safe Harbor On-Chain Adoption

If you ARE doing this in your DAO proposal:

• On-chain adoption involves two parts:
  1. Creating the AgreementV2 contract (the "terms" container)
  2. Registering it in the Safe Harbor Registry (this is what matters for whitehats)
• The DAO proposal should handle step 2, while step 1 can be done beforehand by following the guide: SEAL Safe Harbor On-Chain Adoption (IMPORTANT: Be sure to set the owner of the agreement to your DAO address)

4. Update Terms of Service & Docs

To ensure all users are informed and legally covered, update your Terms of Service and documentation.

Terms of Service (TOS)

Add the following language to your TOS:

User Agreement to be Bound By Agreement, Consent to Attempted Eligible Funds Rescues and Payment of Bounties

The User hereby acknowledges and agrees to, and consents to be bound by the terms and conditions of, that certain Safe Harbor Agreement for Whitehats, adopted by the Protocol Community on [INSERT DATE HERE] (the ”Whitehat Agreement”), available here https://bafybeigvd7z4iemq7vrdcczgyu2afm7egxwrggftiplydc3vdrdmgccwvu.ipfs.w3s.link, as a "User" and member of the "Protocol Community" thereunder. Without limiting the generality of the foregoing:

• the User hereby consents to Whitehats attempting Eligible Funds Rescues of any and all Tokens deposited into the Protocol by the User and the deduction of Bounties out of User’s deposited Tokens to compensate Eligible Whitehats for successful Eligible Funds Rescues;
• the User acknowledges and agrees that Tokens may be lost, stolen, suffer diminished value, or become disabled or frozen in connection with attempts at Eligible Funds Rescues, and assumes all the risk of the foregoing;
• the User acknowledges and agrees that payment of the Bounty as a deduction from User’s Tokens to an Eligible Whitehat may constitute a taxable disposition by the User of the deducted Tokens, and agrees to assume to all risk of such adverse tax treatment; and
• the User agrees to hold the other Protocol Community Members harmless from any loss, liability or other damages suffered by the User in connection with attempted Eligible Funds Exploits under the Whitehat Agreement.

This is also found in Exhibit D in the legal agreement

Documentation

Under your documentation's "Security" or "Bug Bounty" section, include:

"This protocol has adopted the SEAL Safe Harbor Agreement for Whitehats, which empowers approved security researchers to intervene during active exploits to rescue funds. Full adoption details, scope, and bounty terms are publicly available [here]."

Replace [here] with your actual registry listing or agreement address.

5. Announcement

Once everything is live, it's time to communicate publicly. This signals to whitehats, users, and the broader ecosystem that your protocol is protected.

• Use Twitter, Discord, forums, and governance portals.

• Highlight your on-chain registration, bounty terms, and any DAO vote.

• Example announcement:

  Today, we’re proud to announce that [Protocol Name] has officially adopted the @_seal_org Safe Harbor Agreement - a legal and technical framework that empowers whitehats to rescue funds during active exploits.

  This move brings us into alignment with some of the most security-forward protocols in the space - Uniswap, Pendle, Balancer - as we take real steps to defend our community and user funds.

• Feel free to coordinate with SEAL - we're happy to co-announce and amplify it.

---

If your protocol ever needs help with adoption, SEAL is happy to help answer any questions, walk you through adoption, amplify announcements, etc

📬 Contact us at: safe-harbor@securityalliance.org

Safe Harbor Scope Terms

When adopting Safe Harbor, you'll define specific parameters that control what's covered and how whitehat rescues work. Below is an explanation of each term with tips and best practices.

1. Asset Recovery Address

The address where whitehats must return rescued funds after an exploit.

Tips:

• Use a highly secure smart contract wallet (e.g., Gnosis Safe or governance-controlled address).
• Ensure it can handle large inflows, potentially a significant portion of your TVL.
• Please refer to this framework on Wallet Multisig Security

2. Security Contact

The person or team whitehats must notify after completing a rescue.

Tips:

• Provide multiple points of contact (email, Signal, Telegram) for redundancy.
• Make sure these methods of notification are checked in case of an active exploit. Whitehats should reach out within 6 hours of a rescue

3. Assets Under Scope

The on-chain contracts or accounts that whitehats can legally interact with under Safe Harbor.

Scope Options:

• All: Covers the listed address and all child contracts, both existing and future.
• ExistingOnly: Covers the address and child contracts deployed before adoption.
• FutureOnly: Covers the address and child contracts deployed after adoption.
• None: Covers only the listed address.

Examples:

• All: Use for factories or deployer addresses that create vaults, pools, or markets. Covers all current and future instances.
• None: Use for single vault contracts where funds are concentrated and no child contracts exist.
• ExistingOnly / FutureOnly: Very rarely used; typically for protocols with legal or operational constraints on future contracts.

Tips:

• If your protocol deploys many contracts, include your deployer address EOA/Multisig/Governance Addresses with All. This avoids the need for updates.
• Keep this list current - if you launch new deployments and they aren't covered, whitehats can't legally intervene.

4. Bounty Terms

Defines how whitehats are rewarded for successful intervention.

4.1 Bounty Calculation

As a FYI, the formula to determine the bounty payout to the whitehats is:

bounty = min(bountyPercentage × recoveredAmount, bountyCapUSD)

Predefining this ensures no post-hack negotiation and prevents delays.

4.2 Bounty Percentage

The percentage of recovered funds that a whitehat receives.

Recommendation:

• 10% is standard in the industry.
• Set equal to your bug bounty program's critical exploit payout percentage

4.3 Bounty Cap (USD)

The maximum bounty amount for a single whitehat, in USD.

Recommendation:

• Match or set equal to your bug bounty program’s max payout to avoid incentives for malicious behavior.

4.4 Aggregate Bounty Cap (USD)

The maximum total bounty payout across all whitehats for a single incident. Bounties will be distributed pro-rata.

Rule:

• If you set an Aggregate Bounty Cap, you must set retainable to false so all funds return to the protocol first, then bounties are distributed.

4.5 Retainable

Whether whitehats keep their bounty directly or return everything first.

• True: Whitehat deducts bounty before returning funds.
• False: Whitehat returns all funds; protocol pays bounty afterward.

Rule:

• Cannot set retainable to true if Aggregate Bounty Cap is enabled.

5. Identity Verification

Determines whether whitehats must verify their identity.

Options:

• Anonymous: No KYC (most crypto-native option).
• Pseudonymous: Requires a pseudonym.
• Named: Legal name verification (KYC required).

Tips:

• Most protocols choose Named (KYC) for compliance.
• Some opt for crypto-native option of protecting the whitehat's anonymity.

6. Diligence Requirements

Additional compliance checks for whitehats before bounty payout (applies only if identity = Named).

Generic Template:

<PROTOCOL_NAME> requires all eligible whitehats to undergo Know Your Customer (KYC) verification and be screened against global sanctions lists, including US, UK, and EU regulations. This process ensures that all bounty recipients are compliant with legal and regulatory standards before qualifying for payment.

---

If you ever need help or have any questions, don’t hesitate to reach out!

📬 Contact us at: safe-harbor@securityalliance.org

On-Chain Adoption Guide

This guide explains how protocols can register their Safe Harbor adoption on-chain. Registering ensures your adoption is public, verifiable, and enforceable.

Why On-Chain Adoption Matters

On-chain registration:

• Makes your Safe Harbor adoption public and transparent.
• Signals to whitehats that your protocol is officially covered under the agreement.
• Publishes your terms (scope, bounty, contacts) on-chain in a way that's traceable and verifiable, even if updated later.

How On-Chain Adoption Works

The process involves two steps:

1. Deploy your AgreementV2 contract (containing your scope details)
2. Register the agreement with the Safe Harbor Registry

Three Ways to Deploy and Register

Important Note:

• The address that registers represents your protocol on-chain.
• Most protocols use multisigs or DAOs for the registration step - Be sure to set the owner of the agreement to your multisig or DAO address if you are registering with them.
• The simpliest workflow is to use the SEAL Self-Adoption Tool to deploy your agreement and register it with your multisig/DAO.

1. SEAL Self-Adoption Website + Script/Multisig Registration

1. Navigate to the SEAL Self-Adoption Tool.
2. Fill in your scope details (Asset Recovery Address, Assets Under Scope, Bounty Terms, etc.).
   • WARNING: Be sure to set the owner of the agreement to your multisig or DAO address if you're registering with them.
3. Choose one of the following:
   • Generate an Agreement to deploy your AgreementV2 contract via the SEAL tool
   • Export JSON for use in Foundry scripts
4. Deploy your agreement using the generated parameters
5. Register separately using either:
   • Foundry script (see method 3 below)
   • Multisig registration (see method 2 below)

2. Multisig Registration (Gnosis Safe)

If your protocol uses a multisig, you can register on-chain securely after deploying your agreement.

Steps:

1. First, deploy your AgreementV2 contract:

   • Use the SEAL Self-Adoption Tool to generate the deployment parameters
   • Deploy via the AgreementFactoryV2 using your preferred method
   • WARNING: Be sure to set the owner of the agreement to your multisig address

2. Register with your multisig:

   • Open your Gnosis Safe and go to the Transaction Builder app
   • Enter the Safe Harbor Registry address:
     • Default for most EVM chains: 0x1eaCD100B0546E433fbf4d773109cAD482c34686
     • Full address list: Registry Addresses
   • Select the method: adoptSafeHarbor(address agreementAddress) and input your deployed AgreementV2 contract address
   • Add the transaction and simulate it:
     • You should see a SafeHarborAdoption event with your multisig as the entity
   • Collect signatures and execute

3. Foundry Script / Custom Code

If you prefer deploying and registering via code or need custom integrations, you can use SEAL's Foundry script or write your own.

Using SEAL's Foundry Script:

• Repository: security-alliance/safe-harbor
• Script: registry-contracts/script/v2/AdoptSafeHarborV2.s.sol

Steps:

1. Generate your scope JSON via the SEAL tool or manually prepare it using registry-contracts/agreementDetailsV2.json as a template
2. Paste the JSON into: registry-contracts/agreementDetailsV2.json
3. Run the script:
   • By default, the script will set the deployer as the owner of the agreement
   • You can change this by setting AGREEMENT_OWNER in your .env file to your desired owner address
   • By default, the script will not register the agreement - you can change this by setting DEPLOY_REGISTRY to true in your .env file
   • The script can handle both deployment and registration

Manual Method:

1. Deploy your agreement: AgreementFactoryV2.create(AgreementDetailsV2 memory details, address registry, address owner)
2. Register it: SafeHarborRegistryV2.adoptSafeHarbor(address agreementAddress)
3. Use the deployed Registry & Factory Addresses

Key Contracts

• Agreement Factory: Deploys AgreementV2 contracts
• Safe Harbor Registry: Registers adoption and makes it official
• Deployed Addresses: View Registry & Factory Addresses

---

If you ever need help or have any questions, don't hesitate to reach out! 📬 Contact us at: safe-harbor@securityalliance.org

Safe Harbor for Whitehats

Why You Should Care

Safe Harbor lets whitehats intervene during active exploits to help secure protocol funds. It does so by providing a legal framework that outlines what whitehats can and can't do, how they ought to operate, and protects abiding whitehats in the event of legal action taken by the protocol.

In addition to the legal protections, Safe Harbor also helps whitehats by giving them the following information:

1. What assets are owned by a protocol
2. What is the protocol's (asset recovery address)
3. Who the security contact
4. What KYC requirements (if any) protocols impose onto whitehats
5. What bounty terms whitehats will be awarded under Safe Harbor

This information is all neatly cataloged in the Safe Harbor Registry - an on-chain registry cataloging all protocol adoptions and their adoption details. For more details, review the Safe Harbor for Protocols document. It has also been compiled by Skylock at the Safe Harbor Database.

Whitehat Adoption

If a whitehat reads and understands the entire legal framework, they may later be eligible to participate in a whitehat rescue. These rescues should only be taken in very specific circumstances, and it is important to reiterate the following:

• The framework only applies to active exploits, and it is a violation of the agreement if the whitehat initiates an exploit themselves.
• The protocol is not responsible for ensuring the whitehat follows the law, and the whitehat can not be protected from criminal charges outside the agreement's scope.
• There are nuances that can affect the agreement's enforceability, and whitehats will assume many legal risks by becoming involved.
• If the whitehat decides to proceed with a whitehat rescue, they must follow the process specified in the agreement. This includes transferring rescued funds to the protocol's "Asset Recovery Address" and promptly notifying the protocol of the fund recovery. The whitehat may keep (or later receive) a reward, based on the terms of the agreement.

Safe Harbor may also apply to generalized frontrunner / arbitrage bots. The rules of conduct enforced by Safe Harbor for Prospective and Retrospective whitehats differs in a few key areas.

In the Event of a Hack

Pre-Intervention

In the event of a hack targeting a protocol that has adopted Safe Harbor, whitehats are permitted to take broad actions to secure the protocol's funds. Before taking action, review the following checklist (also present in the Safe Harbor Technical Summary):

• Is this an active, urgent exploit?
• Are you unable to responsibly disclose the exploit (e.g. via a bug bounty program) due to time constraints or other reasons?
• Can you reasonably expect your intervention to be net beneficial, reducing total losses to the protocol and associated entities?
• Are you experienced and confident in your ability to manage execution risk, avoiding unintentional loss of funds?
• Will you avoid intentionally profiting from the exploit in any way other than through the reward granted by the protocol?
• Are you and anyone with whom you directly cooperate during the funds rescue, as well as all funds and addresses used in said rescue, free from OFAC sanctions and/or other connections to sanctioned parties?
• Have you confirmed the agreement has been duly adopted by the protocol community?
• Are you fully aware of the risks associated with your actions, including but not limited to accidental loss of funds, claims and liabilities outside this agreement's scope, and the unclear extent of this agreement's enforceability?

In the event that all the above applies, you may chose to take action to protect the protocol's assets. How you do this depends on the situation - perhaps offensively white-hat hacking a protocol with a proven exploit, or returning funds recovered by your MEV bot from an incident it frontran.

Post-Intervention

After the funds have been recovered, it is your responsibility to ensure their safe return to the owner protocol. We strongly recommend contacting SEAL911 immediately to advise on the fund recovery process and to assist with KYC, protocol communications, and bounty collection. You must also contact the protocol's posted security contact and return all recovered funds to the protocol's asset recovery address within 6 hours of the event, or 48 hours if reason is provided and the protocol has been made aware.

SEAL 911

SEAL 911 is a project designed to give users, developers, and even other security researchers an accessible method to contact a small group of highly trusted security researchers. The group can be reached via the Telegram bot.

Members of SEAL 911 follow a strict CODE OF CONDUCT.

When interacting with SEAL 911, ensure that you give as much information as possible in order to avoid double work by the security researchers.

---

Crisis Handbook - Smart Contract Hack | Google Doc

Actions Checklist

Perform Immediately

• Notify SEAL 911 Bot of the incident. Use this message template to get started.
• Create a War Room with audio and share the invite link with trusted individuals.
• Duplicate this document to allow collaboration and share the link in the War Room.
• Review the Advice to Keep in Mind section.

Perform in Parallel by Role

1. Assign Key Roles to War Room Members:

   • Assign members to specific roles.

2. Analysis:

   • Scope the impact of the attack.
   • Gather Transactions Involved.
   • Gather Affected Addresses.
   • Record Funds Movement.
   • Gather Attacker Information.
   • Investigate the issue and update the Issue Description.
   • Propose workable solutions.

3. Protocol actions:

   • Take immediate corrective/preventative actions to prevent further loss of funds.
   • Pause contracts if possible.
   • Execute pre-made defensive scripts.
   • Prioritize proposed solutions.
   • Validate and execute the solution.
   • Prepare monitoring alerts for situations that require future actions.

4. Web actions:

   • Disable deposits and/or withdrawals as needed in the web UI.
   • Enable front-end IP or Address blacklisting.
   • Create front-end for any user actions necessary (approval revoking, fund migrating, etc.).

5. Communications:

   • Identify social platforms that communications on the incident must be sent to.
   • Prepare messages for incident communication internally and externally.
   • Gather security contacts for any potentially affected downstream protocols (bridges, lending protocols).
   • Notify block explorers (like Etherscan) for attacker address labeling.
   • Continuously monitor social media for users providing additional information that aids whitehat efforts.
   • Monitor War Room efforts and maintain the Event Timeline.

After all of the above is complete, consider Post Incident Actions

Information Gathering

Information will primarily be shared and acted upon in the War Room. As time allows, consolidate intel in the below section to achieve the following:

• Accurately scope the incident impact.
• Inform new War Room members and third parties efficiently.
• Aid external communication.

This is the chief duty of the Scribe.

Issue Description

The issue involves an unauthorized transfer of funds from the protocol's treasury contract due to a vulnerability in the contract's access control mechanism. The attacker exploited this vulnerability to initiate multiple transfers, siphoning funds to an external wallet.

Events Timeline

Record events to construct an overall timeline of the incident. Events worth recording:

• First notice of the incident
• War room creation
• External communications
• Attack transactions
• Transactions performed by the team

Record times in UTC. Use a UTC Time Converter.

Transactions Involved

Record all transactions related to the incident.

Affected Addresses

Record affected addresses related to the incident (protocol contracts, bridges, users, etc.).

Funds Movement

Record funds movement to gather the impact of the incident and organize recovery efforts.

• Original address that held the funds
• Transaction that moved the funds
• Assets and amounts the funds are comprised of
• Destination the funds moved to (Contract, CEX, Bridge, Mixer)
• Recovery Status of the funds

Use Phalcon Tx Explorer to aid in recording funds movement.

Attacker Information

Gather attacker information to aid legal efforts and fund recovery.

Post Incident Actions

1. Confirm the incident has been resolved.
2. Create monitoring alerts for situations requiring future actions.
3. Prepare scripts to perform any actions related to monitoring events in the future.
4. Consider creating additional defensive scripts (pause/upgrade) to use for future situations.
5. Schedule a Post Mortem write-up.
6. Post the write-up to relevant social media.

Appendix

Advice to Keep in Mind

• Limit the War Room occupancy. Be careful not to invite too many people during the early stages. Sensitive information is being shared; be wary.
• Make it clear to War Room members not to publicize information without the protocol’s consent.
• Do not speak to the press/news/publications.

Key Roles

• Operations: Initiates War Room, assigns roles, distributes tasks, herds multisig participants.
  • Person Responsible
• Scribe: Consolidates gathered information for efficiency in knowledge-sharing.
  • Person Responsible
• Strategy Lead: Prioritizes actions, considers trade-offs of decisions.
  • Person Responsible
• Protocol Lead: Responsible for smart-contract actions (pausing, upgrading, etc.).
  • Person Responsible
• Web/Infrastructure Lead: Responsible for updating the front-end, managing servers.
  • Person Responsible
• External Communicator: Social media and user communications.
  • Person Responsible

Suggested Tools and Platforms

SEAL Message Template

Fill out with relevant information and send to SEAL 911 Bot.

Protocol: [Protocol Name]
Attack Tx(s): [Transaction Hash(es)]
Funds at Risk: [Estimated Amount in USD or Token]

[Brief Description of the incident]

Decentralized Incident Response Framework (DeIRF)

A lightweight, end-to-end scaffold for security teams that work without a single authority.
Use it as a menu, not a mandate.

1. Guiding Principles

---

2. Roles and Identities

Tip: Publish a public mapping of handles to real names and keep it in a tamper evident repo.

---

3. Preparation Checklist

---

4. Detection and Triage Flow

1. Alert fires or user reports an issue.
2. First Reporter opens a ticket in the transparent issue tracker (GitHub security advisory or private GitLab issue).
3. Triage Lead checks severity matrix.
4. If P1, spin up a temporary incident channel with a predefined template.
5. Assign Leads and set T-minus deadlines.

---

5. Containment Options

Keep a one-liner command ready for each action and store it in the runbook.

---

6. Eradication and Recovery

1. Patch or replace vulnerable code.
2. Peer review with at least two signers.
3. Deploy to staging with replay of attack scenario.
4. Roll forward to production by multisig or automated pipeline.
5. Verify by monitoring metrics and logs for stability.

---

7. Post-Incident Actions

---

8. Quick-Start Templates

---

9. Pros and Cons of Decentralized IR

---

10. Keep It Alive

• Run quarterly red team drills.
• Rotate secrets on a fixed cadence.
• Review identity proofs every six months.
• Measure mean time to detect and contain.
• Iterate on this framework during each retrospective.

Remember: Simplicity plus strong fundamentals beat heavy processes every time.

Insider Threats (DPRK)

This framework serves as an entry point to understanding the organizational and personal risks related to "Insider Threats," most commonly (though not exclusively) associated with "DPRK IT Workers" - the North Korean hacker-freelancers. This framework is targeted at projects affected by insider threat actors as well as projects wanting to harden their posture against these actors.

Throughout this module, we will discuss:

• Who insider threat actors are and what they do
• How to recognize insider threat actors
• How to interact with a potential threat actor
• How to mitigate the risks and impact of insider threat actors
• How to harden your defenses against insider threat actors
• Potential consequences of insider threats for you and your organization

Table of Contents

• General Information
  • What is an insider threat? Who are DPRK IT Workers?
  • Operational structure and short history of DPRK IT Workers
  • What are the goals of DPRK IT Workers?
  • How many DPRK IT Workers are there?
  • Average DPRK IT Worker Profile
• Techniques, Tactics, and Procedures
  • How can DPRK IT Workers find a job in your company?
  • Am I Interviewing a DPRK IT Worker?
  • Did I hire a DPRK IT Worker?
  • After a DPRK IT Worker is hired by your company
• Mitigating DPRK IT Workers
  • Hardening your hiring processes
  • Hardening your organization
  • I hired a DPRK IT Worker. What now?
  • Data collection
  • Overview of risks to your organization
• Case Studies
  • Story 1
  • Story 2
  • Story 3
• Summary

Overview of risks to your organization

1. Defrauding the company: The company is paying someone whose identity they do not know.
2. Subpar operational security: DPRK IT workers share credentials among themselves in open channels, have a poor command of Git, and unintentionally or intentionally leak the access they are granted to third parties.
3. Extortion: They may try to extort more money after a job is finished.
4. Future hacking activities: They may use the knowledge gained for future hacking activities.
5. Sanctions violations: The DPRK is a sanctioned entity. No company can legally transfer funds to DPRK-related operations.
6. Contribution to the North Korean Military: DPRK IT worker salaries directly contribute to the Military Ministry of North Korea. The workers do not keep the salaries for themselves.
7. Supply-chain compromise: DPRK IT Workers may intentionally introduce vulnerabilities that impact down-stream projects that depend on your software / services (e.g. SafeWallet UI in the ByBit hack).
8. Reputational damage: To your brand and loss of trust of your users and customers.
9. Asset freeze / loss of access to financial services: your assets may be frozen or seized, and financial institutions (e.g. banks, exchanges) may terminate your access if you are suspected of funding sanctioned entities.
10. Criminal investigations: Law enforcement may investigate your involvement and impose fines or press criminal charges against your organization.

General Information

What is an insider threat? Who are DPRK IT Workers?

1. An insider threat refers to the risk posed by individuals within an organization who misuse their authorized access to compromise the organization's security. This misuse can involve malicious actions like data theft or sabotage, but also unintentional actions like negligence (e.g. ignoring security updates) or accidents (e.g. sending sensitive document to the wrong email address) leading to security breaches and/or data leaks.
2. DPRK IT workers are individuals from North Korea (the Democratic People's Republic of Korea) who engage in remote IT work for foreign companies, often using false identities. Their work, while often appearing legitimate, is a source of revenue for the North Korean regime, may be involved in malicious activities, and constitutes a serious violation of international sanctions to send payments to North Korea. "DPRK IT Workers" are synonymous with an "insider threat."
3. Read: OFAC's North Korea Information Technology Workers Advisory
4. Read: Google's advisory on DPRK IT Workers

Operational structure and short history of DPRK IT Workers

1. North Korean IT workers, operating both within the DPRK and abroad, are a significant source of revenue for the country's regime, particularly for its weapons programs. They engage in various IT roles (but are not limited to these roles!), often disguising their identity and location to secure freelance contracts and generate income that is remitted back to North Korea. These workers are primarily based in China and Russia, with some in other parts of Asia, Africa, and Latin America. North Koreans are also observed to run a network of 'facilitators' (or local accomplices) to help them cover their identities and facilitate remote employment. The facilitator lends his or hers digital and physical identity in exchange for compensation from the DPRK IT Workers.
2. Reports of North Korean IT workers operating internationally began to surface around the mid-2010s, with a growing awareness of their role in generating revenue for the regime. The number of DPRK IT workers increased, with a wider geographical spread and a diversification of their activities from the late-2010s to the present.
3. Read: Google's North Korean Cyber Structure and Alignment
4. Read: Google's advisory on DPRK IT Workers expanding scope and scale

What are the goals of DPRK IT Workers?

1. Generating stable revenue for the North Korean regime through remote IT work.
2. Building support networks for North Korean IT-related operations (mules and money laundering).
3. Gaining access to Western companies technology, infrastructure, and identities (both personal and company, digital and physical).
4. Exfiltrating company secrets (intentionally and unintentionally).
5. Extortion (ransomware and blackmail).
6. Avoiding sanctions (North Korean entities are barred from receiving any form of payment from Western countries).
7. Hacking (establishing permanent access to infrastructure in which they can gain a foothold or infiltrate).
8. Malware (infecting high-value targets for future theft).
9. Read: DPRK IT Workers pushing malicious code and stealing 1.3M
10. Read: Highlights from the UN Security Council on DPRK IT Workers

How many DPRK IT Workers are there?

The exact number is hard to estimate. DPRK IT Workers operate in separate 'cells' (different teams distributed over different locations, often without any direct contact with one another), and their organizational structure is flexible (even chaotic). Some workers focus exclusively on the blockchain space, while others are never seen applying outside of Fortune 500 companies. Estimates by different companies and government agencies vary between 2,000 and 15,000 in total. However, it's worth noting that this number includes multiple identities being re-used by the same actor or inactive accounts. We estimate that about 3-5% of all Web3 developers are North Korean, and at any given time, there are at least 200-300 DPRK-related accounts actively seeking employment in Web3 companies.

Average DPRK IT Worker Profile

In the following sections of this framework, we will discuss more advanced methods for detecting deeply nested DPRK IT Workers who may avoid the usual heuristics. However, it is still important to review the most common indicators of North Korean insider threats. If you suspect any of your contributors or have received a report regarding one, this set of questions can help you evaluate if you are dealing with a typical North Korean operative.

1. Did you meet your contributor in real life?
   1. Yes - Significantly lowers the chance that the contributor is North Korean.
   2. No - Red flag.
2. Is your contributor an Asian man in his 20s or 30s?
   1. Yes - Red flag.
   2. No - Lowers the chance that the contributor is North Korean, but they could still be a 'facilitator'.
3. Does your contributor avoid real-life meetings?
   1. Yes - Red flag.
   2. No - Even if they agree to a meeting, North Koreans will often try to postpone it indefinitely.
4. How often do you sync with your contributor, and is their video on during calls?
   1. Often, with video on - Lowers the chance that the contributor is North Korean.
   2. Rarely, or with video off - Red flag. North Koreans will try to appear 'independent' and focus only on technical output.
5. Does your contributor consistently try to recommend someone else for the job? Are those recommendations also for Asian men in their 20s or 30s?
   1. Yes - North Koreans will try to place other North Koreans in your organization.
   2. No - Lowers the chance that the contributor is North Korean.
6. Is your Asian contributor's name 'westernized' (e.g., Victor Lee, James Kano) or extremely generic/popular (e.g., Scott Brown, James Smith)?
   1. Yes - North Koreans have a tendency to use generic, pre-generated fake names.
   2. No - Lowers the chance that the contributor is North Korean.
7. Does the KYC documentation provided by your Asian contributor show an unorthodox combination of nationality and physical appearance (e.g., an Asian man living in Indonesia with a Latin American passport)?
   1. Yes - North Koreans often repurpose stolen identities to fit their fabricated backstory.
   2. No - Lowers the chance that the contributor is North Korean.
8. Does your contributor have poor English communication skills, despite claiming to live in the US?
   1. Yes - It is atypical for someone with a US passport to have poor English skills in an IT job.
   2. No - Lowers the chance that the contributor is North Korean.

We cover more detailed indicators in the section Techniques, Tactics, and Procedures

Techniques, Tactics, and Procedures

This section focuses on avoiding, discovering, and confirming the threat of DPRK IT Workers to your organization. The sections dedicated to answering the questions "Am I interviewing a DPRK IT Worker?" and "Did I hire a DPRK IT Worker?" are interchangeable and both provide strategy outlines for avoiding, discovering, and confirming DPRK-related insider threats. Your organization can use tips from these sections to identify a DPRK IT Worker before you hire them, as well as to identify them after you have made the mistake of hiring one.

This section focuses on dealing with emergent situations to identify potential DPRK IT workers who are attempting to or already have infiltrated your organization. In the next section, (Mitigating DPRK IT Workers), we will discuss strategies to harden your organization to minimize both the impact and the chances of infiltration and how to deal with the fallout of hiring a DPRK IT Worker.

How can DPRK IT Workers find a job in your company?

1. There is no single established channel through which a DPRK IT Worker can approach your company. Applying with an impressive CV and GitHub portfolio through a public channel (LinkedIn/Job Portal) is common; however, we have often observed alternative routes, such as:
   1. Direct outreach to CEO/CTO. They are persistent until clearly denied the opportunity, and even then, the actor may change their identity and try again.
   2. Initiating contact through open-source contributions. An actor will submit valid Pull Requests to your repositories and use this as a way to request a job interview.
   3. Recommendation. A worker will come recommended by another DPRK IT Worker or by a company they previously infiltrated (where the company may or may not be aware the employee is a DPRK IT Worker).
   4. Tech recruiters. Recruiters often prioritize evaluating skillsets over performing background checks. DPRK IT Workers can appear on their radar and be unwittingly pushed by a legitimate tech recruiter to your company.
   5. Bounty/Hackathon participation. DPRK IT Workers look for ANY source of revenue, no matter how small or large. If your company runs free-for-all bounty systems, it's extremely likely that some of the contributors are DPRK IT Workers.
   6. Hired through a "dev shop." If you recruit your employees through an outsourcing agency, you need to ensure their vetting process is appropriate. The outsourcing agency itself can be a victim of DPRK IT Worker infiltration.
2. The bottom line is that there is no single "safe" remote recruitment channel. You should vet your potential employees independently and look beyond their skillset, which can often be impressive. We have observed DPRK IT Workers joining companies by utilizing all the channels mentioned above. Establish a high-quality hiring process to avoid recruiting DPRK IT Workers; do not blindly rely on outsourced solutions.

Am I Interviewing a DPRK IT Worker?

1. The list below can serve as a guide for avoiding hiring a DPRK IT Worker and as an exit-interview guide for verifying if an employee is a DPRK IT Worker.
2. Before discussing the heuristics: Don't over-focus on stereotypical DPRK IT worker characteristics, such as being an Asian male in their 20s or 30s, using specific headphones, or obscuring their background. What you are looking for is evidence of misrepresentation and fraud. Job fraud is not exclusive to North Koreans - approach it as such.
3. Below is a list of 'red flags' that can help you evaluate with higher confidence if you are dealing with a DPRK IT Worker. However, always keep the above point in mind! For every 'obvious' DPRK IT Worker, there will be some who are able to evade most, if not all, of the following flags:
   1. Is their video on? If not, insist they enable their camera.
      1. Some DPRK IT Workers have no problem presenting as themselves (without a facilitator, AI, or disabled video). See if you recognize anyone from this Collection of DPRK IT Workers photos.
   2. Is the background visible or obscured? An obscured background isn't always a red flag, but it can be helpful for the final assessment.
      1. DPRK IT Workers love "stock" backgrounds. You'll often find them using the Golden Gate Bridge as a backdrop. Other times, you may notice them sitting in low-quality housing where the workspace is only divided by temporary walls or rugs.
   3. Read: Detect if it's an AI-generated face or deepfake.
   4. Start with small talk relevant to their claimed nationality and location. This is especially important if you're dealing with someone presenting as an Asian man but providing, for example, Latin American documents/names while claiming to live in Southeast Asia (an identity mismatch). Note: While a smaller number of female DPRK IT workers have been identified, they do exist. In other cases, you might encounter hired female facilitators. If the candidate claims to be in your country, offer an on-site interview. Beware, DPRK IT workers may send a stand-in. Verify that the person attending is the same one from the call.
   5. Keep an open mind about gender, nationality, and experience. DPRK IT workers are known to use facilitators from all over the world. This means you might encounter a non-Korean individual on the call who is, in fact, a DPRK IT worker. Similarly, a DPRK IT worker's portfolio can sometimes be impressive and not far off from their claimed experience. In previous instances, we've found profiles showing 2-3 years of work for reputable organizations.
   6. Go through the candidate's background. Verify the timelines of their claimed experience (e.g., "You worked at Company X from when to when?"). While the candidate answers, observe if they seem to be reading from a script. Try to mix up details from their claimed experience and note their reaction (e.g., "I see you worked at XYZ," when you know from their CV that they didn't). This is good general advice. If the candidate appears to be relying on ChatGPT for answers (reading from the screen), it's a red flag.
   7. Conduct a language comprehension test. If the candidate claims to be Japanese, ask them questions in Japanese. Beware, some DPRK IT workers can speak Japanese or Chinese, though their proficiency is often similar to their English skills (A1/A2 level). See: North Korean failing to answer questions in Japanese despite claiming to be Japanese
   8. Ask if the candidate is at home or a co-working space.
      1. Look for movement in the background.
      2. If they claim to be at home, you can try a quick KYC check: ask them to show their ID card next to their face.
   9. Carefully observe the candidate's screen presentation if they share their screen. Often, you might notice different GitHub, Gmail, or other social network profiles active on their screen than those claimed in their CV. It's best not to give the candidate a chance to prepare for this. Casually ask, "Could you walk us through your best code on GitHub by sharing your screen?"
   10. Evaluating a potential DPRK IT Worker's GitHub profile:
       1. The account creation date is later than the commits in its hosted repositories (an artificially aged account). This is especially suspicious if many repositories follow this pattern and the user claims experience aligning with the age of these manipulated commits. This can be a false positive but is usually easy to clear up. Some users re-upload their old code, pre-dating the GitHub account creation date. A false positive for this particular flag can be deduced from the overall quality of the account.
       2. A high number of followers and accounts followed (e.g., over 200). If the user is a popular developer with a significant online presence, this isn't a red flag. False positives can occur for accounts that automatically follow back or for Developer Relations (DevRel) and recruitment professionals.
       3. A high number of contributors to the user's repositories. If the user is not a popular developer, this is a red flag. Regular developers typically won't have 100+ contributors to their repositories without a significant online presence. This flag has a tendency to be polluted with high numbers of contributors on "copied" repositories, where a DPRK IT Worker has "injected" themselves as an author but has also kept the original contributors' usernames.
       4. Quality of opened Pull Requests and Issues. It's useful to retrieve the full history of Pull Requests and Issues opened by the user and review them for quality. For advanced DPRK IT workers, these may not differ significantly from those of regular developers. Additionally, if a suspicious user was @pinged in a PR or Issue, it might help uncover a previous nickname. Look for automated or spam-like text/code. DPRK IT Workers will often go for "quantity" over "quality." At the same time, some DPRK IT Workers will be authors of perfectly valid Pull Requests and Issues - an artifact of their previous employment or a better credibility-building effort.
       5. Overly informative (full of images and stats) GitHub profile README/About page.
          1. This can be a false positive. Regular developers have been observed to overuse this section.
       6. Avatars.
          1. DPRK IT workers often use AI-generated images (not necessarily faces) as their avatars. They typically use freely accessible models like Stable Diffusion or Midjourney.
          2. "Cartoonish" avatars are also popular: CGI-style images of fictional characters, Minion avatars, and NFT-related avatars (especially Pengu and Doodles).
          3. Having no avatar at all is also common.
          4. Reference: Identifying Suspicious Github Accountsl
       7. Social media links.
          1. In many cases, there will be a Twitter link. It's always worth visiting.
             1. Check the "Media" page for images uploaded by the account owner. Can you find any pictures from conferences or showing their physical appearance? DPRK IT workers usually will not post pictures from physical locations. The exception to this rule would be "facilitator" or "purchased/stolen" accounts.
             2. Look for job-begging tweets.
             3. References:
                1. Nick Franklin Case - A well developed IT Worker persona
                2. Nick Franklin Case - Acivity across different platforms
       8. Suspicious interactions.
          1. Contributions to low-quality external repositories and/or organizations. DPRK IT workers are known to set up "fake" organizations on GitHub, often populated by other IT workers. Similarly, DPRK IT workers will cross-commit to each other's repositories. It's worth checking the profiles of contributors to the potential threat actor's repositories: are these contributors legitimate themselves? A full data dump of the GitHub account may be useful, but cherry-picking a few repositories from the profile is often effective enough for a first pass.
             1. Reference: A counter example - Good looking IT Worker Github Profiles
       9. Repositories.
          1. "Copied repositories." DPRK IT workers will try to boost their credibility by pushing a clone of a legitimate repository to their own account (Google: "How to fake Github history"). They will often edit the .git config and insert their own account data. Usually, they won't remove all original contributors but will insert themselves among them. Use GitHub's search feature to find the original repository by name, commit SHA, or a unique string extracted from within the repository. Compare the actual account creation date with the profile's UI-displayed history: is it consistent, or is the account's creation date more recent than the years of activity displayed? A simple API query to get the account creation date from GitHub may be necessary here.
          2. GitHub's Activity Badge for contributing to an organization. Verify if it's an actual contribution like a PR or commit or just a spam Issue/Comment/PR. This is an often-utilized method for highly popular repositories (e.g., OpenZeppelin, Paradigm) where core developers are reluctant to merge spam PRs.
             1. Reference: DPRK IT Workers faking Github Activity Badges
   11. Evaluating other immediately available data points:
       1. Full Name.
          1. Even if a full name is "fake," it can still be a useful data point. DPRK IT workers rotate their identities, but they need to maintain them for at least some time. Another challenge they face is managing multiple personas; you may catch an "identity confusion" where a DPRK IT worker uses different names in different places, for example, a different name used/mentioned on GitHub than on a call or on other social profiles. It's also possible to notice different names used with the same (or different) GitHub owner's email addresses.
             1. Take extra care with Asian names, especially Chinese names. Chinese citizens often westernize or shorten their full names in various ways. This doesn't necessarily mean they are malicious.
          2. In most cases, DPRK IT workers prefer to use Asian (Japanese, Chinese, Korean) names. However, they are also known to use fake names from all around the world, corresponding to where their "facilitators" are based. This includes American names ("James" being an extremely popular choice) and even European names (e.g., Polish, Ukrainian, Hungarian).
             1. DPRK IT workers may have access to KYC documents issued for their claimed nationality. You should be alarmed by highly unorthodox combinations, such as an Asian man living in Indonesia with Argentinian KYC documents.
       2. Location.
          1. Japan and the USA are extremely popular choices for claimed locations. Additionally, Southeast Asian countries like Thailand, Malaysia, Singapore, or Taiwan are also common. The actual physical location is commonly the DPRK (Pyongyang, border regions), China (border regions), Eastern Russia (Vladivostok), Laos (Vientiane), Indonesia, Vietnam, and parts of Africa. It's possible to obtain the IP address of a potential DPRK IT worker through a DocuSign document that collects HTTP headers. DPRK IT workers are known to utilize "laptop farms," meaning they can hide their IP behind an actual fixed/landline IP address in their claimed country of residence.
       3. OSINT analysis.
          1. We recommend checking each suspicious email address with a service like https://epieos.com. It can provide additional data points, such as a LinkedIn profile, which can uncover further identity mismatches.
             1. On LinkedIn, examine the strength of the actor's connection network.

Did I hire a DPRK IT Worker?

1. The list below serves as a guide for confirming your suspicions if one of your employees is a potential DPRK IT Worker. We're focusing on using non-enterprise flags accessible to even the smallest of projects. The assumption is that your project has limited EDR/SIEM logging infrastructure (you should, however, consider implementing some monitoring infrastructure in the future).
   1. If your organization has EDR/SIEM capability, Read: DTEX advisory on DPRK Insider Threat Kill Chain
   2. Consider using GitHub Enterprise for your organization to have access to more detailed logs.
2. Before discussing the heuristics: Don't focus on negating your suspicion; focus on clearing it up. It doesn't matter if you're checking a long-time employee who provides good technical output, is not Korean/Asian, logs into the workspace using a US-based IP, or came recommended. DPRK IT Workers have been known to successfully evade detection for YEARS. Focus on creating a full profile of your employee and judge it based on the complete picture and any inconsistencies you find.
3. Below is a list of 'red flags' that should prompt immediate action from your side (e.g. a deep background check):
   1. Avoiding real-life meetings. Even if they initially agree to meet, they might come up with explanations as to why they can't. They often cite 'family reasons' or 'travel abroad.' The situation can repeat itself for every single meeting proposal, regardless of the location. You can propose to meet at their location as a final test.
   2. Inconsistencies in work and communication. It's often the case that a single DPRK IT Worker account is operated by a few individuals, especially if your company communication is sparse. One week you may observe good quality and high output; the next week, a significant drop. Similarly, for communication, you may observe the worker being overly 'mute' on all company sync calls or clueless as to what was discussed in previous meetings. They will also often have issues communicating about their code but not with the code development itself (a sign of more than one worker on a single account).
   3. Timezone. If your worker claims to be in Texas (GMT-5) but is located in Pyongyang (GMT+9), you may observe work patterns closer to North Korean time than to Texan time. Note that DPRK IT Workers work around the clock and can circumvent this flag easily.
   4. Bogus work history. Verify if the job history claimed on their CV is real. You can always reach out to the previous company for background information. In most cases, the history will be made up, but there are exceptions. DPRK IT Workers may list legitimate companies for which they did previous work but were let go (without that company's knowledge of their true nature). Sometimes, DPRK IT Workers will list organizations they control, so exercise caution when contacting anyone for background information.
   5. Identity switch. Be on guard if an employee's profile suddenly changes its nickname/identity. DPRK IT Workers do this often, usually when discovered in one of their previous jobs and for fear that someone will notify your company. They may suddenly start using a different GitHub handle (this includes suddenly pushing a Pull Request using a different account than usual), delete their social media accounts, or get banned from LinkedIn. Additionally, they may occasionally 'confuse' their fake identities and log in to your company workspace or a meeting using a completely different account.
   6. Identity mismatch. It should raise questions if your employee is Asian but provides non-Asian KYC documentation along with poor language skills. Run a background check on all the data. Can you find a person with the same name whose identity was potentially stolen or borrowed? Is the address provided legitimate, or does it seem 'random' (e.g., an empty house, a business venue)? Google "(Full Name of your worker) + sentenced" to see if the DPRK IT Worker bought a criminal's identity (an often-seen case with claimed US-based personas). Perform a reverse image search on your worker's profile pictures/avatars. Are there more similar accounts using the exact same image? Beware that DPRK IT Workers have no issues providing credible-looking KYC documentation; some of these documents even pass authentication checks on specialized services.
   7. Recommending other suspicious accounts for work. DPRK IT Workers will leverage their initial foothold in your organization to propose other DPRK IT Workers for a job. Their recommendations will usually follow the same patterns. Many organizations fall for it and hire multiple workers (sometimes, as much as 50-70% of the entire company is composed of DPRK IT Workers if such tactics succeed). Additionally, check if the potential DPRK IT Worker hasn't already added some of their 'friends' to your organization without your knowledge.
   8. Proximity to other suspicious/spam accounts. Don't be fooled by GitHub or Twitter accounts that are over 10 years old. DPRK IT Workers can easily source these. However, check if your worker has any meaningful history of interaction with their followers/following. Or, do all accounts in proximity to your worker appear spam-like or like bots?
   9. Poor social skills. It's usually (but not always) the case that a DPRK IT Worker will have trouble with 'small talk.' This isn't necessarily because of cultural differences (DPRK IT Workers are educated on Western culture and language as part of their job). It's often because of the sheer volume of remote gigs they handle and how confusing it can be. A DPRK IT Worker will prefer to always steer the conversation toward technical details.
   10. Review Workspace logs (IP addresses). Check if the IP addresses used to log in to your infrastructure are coming from the same location as claimed by the worker. VPNs, proxies, or Russian ISPs are red flags, as are highly inconsistent IP ranges (a mix of the sources mentioned). Beware that DPRK IT Workers are known to utilize "Laptop Farms." Read: North Korea Infiltrates U.S. Remote Jobs - With the Help of Everyday Americans
   11. Payments. North Koreans can organize a 'drop' bank account to receive wire transfers; however, their preferred method of receiving a salary will be through cryptocurrency, usually at a flat rate that they will not try to negotiate. In most cases, DPRK IT Workers will work at a discount to industry standards without complaining (25-50% discount). It may be the case that the worker's CEX account gets frozen, and they will come back to your organization for help unfreezing it (by providing proof of employment).

After a DPRK IT Worker is hired by your company:

1. The main goal of a DPRK IT Worker is to keep their job and salary coming for as long as possible. It's worth understanding that DPRK IT Workers themselves vary in quality. For more 'senior' workers, keeping the job will be easy as their output and technical skills are high. For 'junior' ones, the engagement may end on the basis of poor performance.
   1. We have observed cases where DPRK IT Workers are fine with taking a salary cut to help a project stay afloat, as long as they continue to be paid.
2. The highest risk to your organization, which occurs immediately after you on-board the DPRK IT Worker, is a data and secrets leak. DPRK IT Workers do not care about your organization's and their operational security. When you assign access to a single DPRK IT Worker, you can be sure more individuals are using the same access. Unbeknownst to you, everything that's private to this single worker is now accessible over a (usually) poorly secured internal DPRK IT Worker network.
3. We have observed DPRK IT Workers passing access or sensitive information to DPRK Hacking teams. This is not often the case, as the goal of the DPRK IT Worker is to keep their job and salary as opposed to a one-time hack. However, if the target is high-value, they won't hesitate or may not even have a say in whether or not their employer is targeted for a hack.
4. Some DPRK IT Workers also perform tasks adjacent to malicious campaigns like the "Contagious Interview." Read: North Korean Threat Actors lure tech job seekers as fake recruiters and Two Campaigns by North Korea Bad Actors target job hunters. Your North Korean employee may leverage the credibility granted by being employed at your company to conduct malware-related campaigns in the present and future. This could significantly affect your brand.
5. A DPRK IT Worker will try to escalate their access if possible, whether by adding new members (who will also be getting paid) or by getting permissions to release builds and packages. Additionally, we have encountered situations where DPRK IT Workers were added as signers to the multisig wallets of the entire project as part of the dev team!
6. DPRK IT Workers won't report code vulnerabilities to you and may leave them for future exploitation. First, they generally do not care about and are not invested in the success of your project to protect it from being hacked. Second, they may intentionally leave the backdoor with the intent to use it in the future. Lastly, they may simply miss the vulnerability because they are overworked across numerous remote gigs they're performing at once.

In the next section Mitigating DPRK IT Workers we will be discussing ways to harden your organization and employees against the DPRK IT Worker threat.

Mitigating DPRK IT Workers

This section discusses ways you can harden your organization against DPRK IT Workers, both before and after a potential hiring. All of the strategies covered in the prior section, Techniques, Tactics, and Procedures, still apply but serve a more 'active' role to identify DPRK IT Workers during recruiting or within your organization. Here, we will discuss mitigation strategies that limit the effects of a DPRK IT Worker infiltration and what you should do after identifying a successful infiltration.

Hardening your hiring processes

1. Apply all the steps from the sections Am I Interviewing a DPRK IT Worker? and Did I hire a DPRK IT Worker?. It's important to educate all of your non-DPRK employees on these points, especially people responsible for hiring, developer relations, talent hunting, and community management.
2. Introduce a culture of background checks. Do not take a prospective developer's claims at face value. Even the most basic OSINT check can often discover deep inconsistencies. Check GitHub commit history, check Twitter history, and Google the full name of the developer.
   1. Is the work experience claimed in the CV reflected on GitHub?
   2. Does the potential employee indicate any physical presence anywhere?
   3. Is the potential employee writing non-AI-generated posts and replying to anything other than job offers on Twitter?
   4. Did you find any name collisions after searching for the potential employee's name in Google?
   5. Did you check the potential employee's nickname in Google? Maybe they have already appeared as a threat actor in a past report?
   6. Remember the best discovery rule: You're looking for misrepresentations, mismatches, and obfuscation, not for North Koreans specifically. Tick your boxes on the first three and only then proceed to decide if you're potentially dealing with a North Korean.
3. Do not try to undercut developer market salaries. DPRK IT Workers will always accept low-ball offers without much hesitation. If you're looking for a cheap hire, you are at a higher chance of hiring a DPRK IT Worker.
4. ALWAYS perform your own due diligence on new remote employees. Do not settle for recommendations from third parties; they could be victims themselves.
5. You could ask about North Korea on call and observe the reaction. There's a so-called "F**k Kim Jong Un" test, where interviewer is asking to repeat the phrase and North Koreans are banned from saying it and they drop the call immediately. Obviously, it won't be effective for 'facilitators' but it will most likely be effective for North Koreans themselves. Do not rely on it as a panacea.
6. Regardless of our tips of not focusing on "Asian man in his 20-30s" that particular appearance is still the most common (If not cloaked under the generative AI). Similarly, Korean-English accents.

Hardening your organization

1. Define and implement tight access control rules for all of your employees, especially remote ones. Avoid giving privileged access to workers who did not pass 100% of the tests and filtering criteria for DPRK IT Workers (all the points already discussed). Specific examples of privileged access include:
   1. Do not give admin permissions to your GitHub organization and repositories, including for build releases, adding members, and repository settings.
   2. Do not give publishing permissions on any package managers. The publishers of your packages are a critical supply chain risk; they need to be 100% vetted.
   3. Do not add your remote employees as multisignature wallet signers. The signer role should be reserved only for high-trust individuals, not based on the dedication of the developer you are working with.
   4. Do not give unlimited access to cloud instances. Scope permissions to the minimal access required for each individual or team, including setting minimal expiration times for access tokens (e.g. access tokens should expire within hours, not weeks).
2. Define a lead developer - a highly trusted individual you've met in real life and are sure of their background - as the code reviewer, publisher, signer, and image builder. This individual's role should be to double-check all of the remote workers' work and actions within your organization at all times. Make sure the lead developer is not a DPRK IT Worker.
3. Silo your remote workers from the most critical infrastructure. If you choose to provision access to such infrastructure, always create a threat model to understand the 'worst-case' scenario and potential mitigation approaches.
4. Monitor your logs for IP addresses, user sessions, and timestamped access. Monitor your remote contributors' actions for any sudden changes (identity changes) and potential secrets leaks through their private accounts. You can obtain such information from Google, Slack or Github Workspaces, depending on your organization setup and tiers.
5. DO NOT allow hired contributors to use throwaway Github accounts for the work at your company! It's part of the DPRK IT Worker tactics to save their main accounts from being discovered.
6. If your project allows, it may be beneficial to establish a public codebase on GitHub and have your remote workers make at least some public contributions related to your project. If all of your codebase is supposed to stay private, at least list all of the contributors (CODEOWNERS) in a special repository created only for such purpose. Security researchers like SEAL911 scan such public codebases and will notify you privately if they suspect DPRK IT Workers are contributing to your project.

I hired a DPRK IT Worker. What now?

1. Contact security professionals if you're unable to handle the situation alone. You can reach out to SEAL911 (@seal_911_bot on Telegram).
2. You do not need to end the engagement abruptly. It's important to maintain a facade while you deal with access revocation and mitigate any immediate risks to your organization. Act normally, but start preparing an actionable plan immediately and aim to remove the DPRK IT Worker within the next few days at most. If your organization is properly siloed from insider threats, you shouldn't have much of an issue firing the worker almost immediately after conducting a post-mortem review.
3. Check if you did not hire more than one DPRK IT Worker. In the majority of cases, we find more DPRK IT Workers within the same organization. They do not always come as a recommendation from an already-discovered DPRK IT Worker; they simply already know how to abuse your hiring process.
4. At the same time, you should immediately cease any further payments to the DPRK IT Worker. It's illegal. You can cite temporary financial issues as the reason for the delay if confronted by the worker and you still need a bit of time to deal with the situation.
5. List all infrastructure endpoints the DPRK IT Worker had access to, both sensitive and not. Useful, for the next steps.
6. Review the current and past work of the accounts in question. The code does not necessarily need to be malicious, but it can be of overall poor quality. Pay extra attention to added dependencies or edited CI/CD files.
7. Review the permissions that these actors have or had in your organization. Revoke them.
8. Review all of the files and links previously provided by the DPRK IT Worker and who opened them. The issue may extend beyond your technical workers. Look back to see if you did not potentially run malware-infested code or give them remote desktop access to your or your developers' machines.
9. Set up a final confirmation call after all access is revoked and you are certain your organization is safe from any insider threats. Attempt to perform KYC under some pretense. Do not settle for document scans, as these are easily obtainable. Insist on a "video call" KYC, where the actor must show the physical document they previously provided next to their face.
10. Attempt to geolocate them. Send a document that tracks the IP address used to open it. Look for VPN usage or IP addresses in the DPRK/Eastern Russian range.
11. Collect all on-chain/payroll data on funds transferred to the actor. If an actor is confirmed as DPRK-related, you will be required to file a Suspicious Activity Report (SAR). We would appreciate you sharing this data with SEAL911 later for public security reasons and future investigations. The data will remain private.
12. You do not need to inform the DPRK IT Worker about the actual reasons for termination. You can cite downsizing, poor performance, lack of cultural fit, or any other reason.
13. In the post-mortem phase, you will need to halt all development on the affected infrastructure. For companies that hired a DPRK IT Worker as a "Core Engineer," this may sometimes mean several weeks of re-auditing all code and infrastructure. You should stop and do it. At the same time, build a threat model to prevent the situation from recurring and to limit its effects if it does happen again. You can remove the DPRK IT Worker's code from your codebase. DPRK IT Workers will claim this code as part of their work experience in their future job searches. The decision is ultimately yours. While not removing the code helps security researchers like those at SEAL911 track these workers, our recommendation is to remove it to protect your project and deny adding credibility to DPRK IT Worker.

Data collection

1. You should collect the following data before firing the DPRK IT Worker. This data will help organizations like SEAL with future mitigation and the discovery of other actors.
   1. Full Legal Name
   2. Phone
   3. Email(s)
   4. Location (City/State)
   5. LinkedIn
   6. Telegram/Discord
   7. GitHub
   8. Copy of Resume
   9. Date Hired
   10. Sourcing (Where were they hired from? Telegram, Staffing, Recruiter, etc.)
   11. Company Email (Yes/No)
   12. IP addresses (from email or any other sources at your disposal)
   13. Managed Laptop (Yes/No)
       1. Shipment address (for the laptop or other items)
   14. KYC data (ID/Passport/Bills document scans)
   15. Photos/Screenshots (physical appearance, potentially from a video call)
   16. Payment data (Extremely important!)
       1. On-chain addresses provided for payment
       2. Bank data
   17. Did they refer anyone else?
   18. Were they referred by someone else?

Overview of risks to your organization

1. Defrauding the company: The company is paying someone whose identity they do not know.
2. Subpar operational security: DPRK IT workers share credentials among themselves in open channels, have a poor command of Git, and unintentionally or intentionally leak the access they are granted to third parties.
3. Extortion: They may try to extort more money after a job is finished.
4. Future hacking activities: They may use the knowledge gained for future hacking activities.
5. Sanctions violations: The DPRK is a sanctioned entity. No company can legally transfer funds to DPRK-related operations.
6. Contribution to the North Korean Military: DPRK IT worker salaries directly contribute to the Military Ministry of North Korea. The workers do not keep the salaries for themselves.

Case Studies

Here are a few deviations from the usual DPRK IT Worker patterns. As mentioned a few times already, the goal is to always be open-minded about threat actor tactics. They are known to evolve and adapt while also pushing their methods further. The examples below are anonymized, but they are real cases we have encountered in the past:

Story 1

Background: A GitHub profile created in 2013, with no flagged "copied repositories" (indicating original code), an active and verified Twitter account from 2012, and no history of nickname changes on any platform. The user claimed to be Japanese, which was reflected in his posts and 10+ years of digital activity. The nicknames were "relevant" to Web3/Blockchain (e.g., using a "0x" prefix or "sol" in the name). A Rust developer with experience in Solana was looking to get hired by a Solana project.

Conclusion: This was a DPRK IT Worker, confirmed by independent sources who had also been "spammed" by the same actor. The most likely reason for avoiding most software flags was a "stolen" account. DPRK operatives managed to get their hands on the GitHub and Twitter handles of a Japanese citizen, which had been lying dormant without ANY activity for 10+ years. They then proceeded to build a history on these accounts for almost two years before starting to apply for jobs and messaging other developers. It's worth noting that no event history was present for this GitHub account, as the original owner had never used it after signing up. This allowed them to build a "perfect" dummy history with no event data present in the GitHub Archive. This absence of data, along with a significant gap in Twitter activity between 2013 and 2022, contributed to flagging this particular actor.

Story 2

Background: An actor who had worked for three years at a popular security company. (An example of a perfect backstory for future employment.) The actor was usually delegated auxiliary tasks, which he completed diligently and on time. He was reluctant to accept promotions or on-site invitations, citing his own business as the reason. The company was fine with this, as he was an auxiliary worker. His GitHub profile was created in 2021 and had a single, yet consistent, name change. The actor used his GitHub account only for work at that company and did not maintain any social media profiles. There was no overly informative README/About page, no avatar, and he consistently used a single Gmail address.

Conclusion: This was a DPRK IT Worker. By cross-referencing our existing database and performing an extremely deep analysis of commits from actors we suspected were connected to him, we finally found his old nickname associated with two commits to an already known -but old and inactive - account of a known DPRK IT Worker. Confirmation was only possible through a video call with the company's participation. (On-call KYC and a few other tactics were used; the threat actor decided to abandon the call and delete his profiles.)

Story 3

Background: An actor with a consistent identity across all relevant platforms (GitHub, Twitter, LinkedIn). He was referred by a legitimate company and had already been working with the affected company for a year. He claimed to be based in Canada (using an IP from a Laptop Farm), spoke good English, performed his tasks diligently and on time (the company claimed he was selected as a top candidate), had no issues with video calls, and used his own physical appearance (no Gen-AI).

Conclusion: This was a DPRK IT Worker. We scanned contributors to a few of his repositories and found that all of them were high-confidence DPRK IT Workers. From their profiles, we managed to pinpoint a history of identity rotations (changes in legal names). The final confirmation was only possible with the company's participation. The actor was "cut off" from access to company infrastructure and given the pretext of a potential breach the company suspected. This gave them a reason to perform additional KYC - "to make sure the (suspected) dev account is not compromised." The actor was asked to go outside his claimed location and take a "selfie" in front of the house where he supposedly lived. He refused and resigned immediately, blocking all accounts.

Summary

• Who are DPRK IT Workers? They are North Korean individuals, often operating from abroad (primarily China and Russia), who use fraudulent identities to secure remote IT jobs. Their primary goal is to generate revenue for the North Korean regime, which may involve legitimate work but also opens the door to espionage, data theft, extortion, and future hacking activities.
• How to Spot DPRK IT Workers During Hiring:
  • Focus on detecting fraud and misrepresentation, not stereotypes. Look for inconsistencies across their CV, digital profiles, and interview answers.
  • During video interviews, insist the camera is on. Watch for AI-generated faces, obscured or generic backgrounds, and an inability to answer small-talk questions related to their claimed location or nationality.
  • Scrutinize their GitHub profile for red flags like a recent account creation date with years of "faked" commit history, "copied" repositories from legitimate projects, spam-like contributions, or interactions with other suspicious accounts.
  • Check their social media (LinkedIn, Twitter) for a lack of personal photos, a history of job-begging posts, and no evidence of a physical presence at conferences or events.
  • Be wary of highly unorthodox identity combinations, such as an Asian individual living in one country while providing KYC documents from a completely different continent.
• How to Verify an Existing Employee:
  • Watch for behavioral patterns like consistently avoiding in-person meetings with repeated excuses or work patterns that don't match their claimed time zone.
  • Audit workspace logs for suspicious IP addresses (VPNs, proxies, known sanctioned regions).
  • Be on high alert if an employee suddenly changes their name or GitHub handle, or deletes social media accounts, as this often happens after being discovered elsewhere.
  • Verify their claimed work history independently. Be cautious if they recommend other candidates, as they often leverage their position to bring in more DPRK operatives.
• How to Harden Your Organization:
  • Implement a "least privilege" principle for access control. New and remote employees should not have admin rights, permission to publish packages, or be signers on multisig wallets.
  • Appoint a trusted, fully-vetted individual to review all code and actions from remote contributors before they are merged or deployed.
  • Perform your own due diligence on all remote hires. Do not rely solely on third-party recruiters or recommendations, as they can also be victims.
  • Avoid the temptation to hire based on the lowest salary offer, as DPRK IT workers often work at a significant discount.
• What to Do After Discovering a DPRK IT Worker:
  • Do not fire them immediately. Maintain a normal appearance to avoid tipping them off while you secure your organization.
  • Immediately stop all payments, as funding them is a sanctions violation. If confronted, use a pretext like "financial issues" to buy time.
  • Systematically revoke all access to code repositories, cloud infrastructure, and internal systems. At the same time, collect all available data (KYC docs, crypto addresses, emails, resumes) for reporting.
  • Conduct a full security audit of all their code contributions, paying close attention to dependencies, build files (CI/CD), and potential backdoors.
  • Once your systems are secure, terminate their contract using a business-related reason (e.g., downsizing, change in direction) and report the incident to law enforcement.

What Is It

This resource is a collection of best practices written in an abstract or general fashion to be applicable regardless of the specific technology. It serves as a comprehensive guide to help you secure various aspects of your Web3 projects and build resilience against potential threats.

This guide aims to centralize existing information, so you might not see novel features but rather a well-organized compilation of security-related topics, from simpler ones to more complex ones. The goal is to provide a comprehensive resource that brings together diverse security insights and practices into one accessible place.

Our hope is that these resources will help expand your security skill set.

What It Isn't

This resource isn't just a compilation of existing information. While it may initially seem like a collection of curated content, its primary focus is on providing in-depth, practical guidance.

Unlike other curations, compilations, or blog posts that often focus on the latest technologies, this guide delves into underlying concepts and technical aspects essential for securing Web3 projects. It’s not meant to be read like a "story" but rather used as a reference to enhance your understanding and application of security practices.

The content may not always follow the latest state-of-the-art technologies, as its focus is on fundamental security principles that are broadly applicable. Our aim is to provide valuable insights and practical advice to help you secure your projects effectively.

This guide is not intended to be offensive, though it might include strong examples to illustrate particular points. Our goal is to ensure clarity and effectiveness in conveying security best practices.

Contribute to the Security Framework

The Security Framework is an open and collaborative project. Whether you are part of the Security Alliance or not, we welcome your contributions! Help us to build the documentation and improve security in the ecosystem.

This mdBook-style handbook is designed for easy collaboration and automatic deployment through continuous integration. If you'd like to join our effort, feel free to fix typos, contribute new sections, or propose enhancements.

On each page, you will find a "Suggest an edit" button at the top-right corner. Clicking this sends you to the GitHub.com where you can suggest edits using their web interface.

If you want to contribute in a more organized manner, please read below.

Contributing

Before you start editing, adding or removing content, please read the code of conduct and make yourself familiar with the overall structure.

The source is hosted in github repository at github.com/security-alliance/frameworks.

The content of the Frameworks main website (.org) comes from the main branch, and when contributing to several frameworks, or generic changes, we would like you to open a PR into the development branch (.dev)

⚠️ Please sign and verify every commit.

Once a new update is warranted, the content from development is merged into main.

Framework-specific branches and Stewards

To understand how to contribute, follow this process:

1. Check for a framework-specific branch: First, check if there's a Steward for the specific framework you're interested in, and reach out. We usually have separate branches pre-develop for frameworks with stewards. Their naming convention is fw_framework_name, for example fw_opsec, fw_community_mgmt - the naming should be intuitive. For more information about stewards and their responsibilities, see the Stewards section.

2. Fork the right branch: Ideally, you will fork these framework-specific branches, since they will probably have more updated information than what's available in the develop branch.

3. Submit PR to framework specific branch: Once you have your suggestions, submit a PR and let the steward or maintainer know you're ready for a review. Feel free to assign reviewers as well. Once submited, you'll be able to see the deployment through Vercel's automation and make any final fixes.

4. Submit PR to develop: After reviews, a steward, a maintainer, or even yourself can submit a PR from the framework specific branch to the develop branch.

5. Become a steward: If there's no specific branch created, then that framework is still "headless," which means you can become its steward! See more in the Stewards section.

Development Environment Setup

Choose the development approach that works best for you:

Option A: DevContainer with VSCode (Recommended)

The easiest way to get started is using our pre-configured devcontainer with VSCode:

1. Prerequisites: VSCode with Dev Containers extension
2. Open the project: VSCode will detect the devcontainer configuration
3. Reopen in container: Command Palette (Ctrl+Shift+P) → "Dev Containers: Reopen in Container"
4. Start developing: All tools are pre-installed and ready to use

Option B: DevContainer CLI Only (No VSCode Required)

Using DevContainer CLI:

• Install DevContainer CLI

git clone https://github.com/security-alliance/frameworks.git
cd frameworks && git checkout develop
devcontainer up --workspace-folder .
devcontainer exec --workspace-folder . bash
# Get the IP address of the container, by running `hostname -I | awk '{print $1}'`. Should be printed automatically in the terminal after the creation as well
# Inside container: just serve
# Access the mdBook at http://<IP>:3000

Option C: Local Installation

If you prefer to install dependencies locally on your machine:

Prerequisites:

• Rust/cargo (For building/serving mdBook)
• markdownlint-cli2 (For linting markdown files)
• GNU Aspell (For spell checking) - Note: For macOs you can use Homebrew to install aspell. Just run brew install aspell.
• just (For running commands)
• Docker (Optional: For running the devcontainer)
• GitHub CLI (Optional: For using gh to interact with GitHub)

Setup:

1. Install all prerequisites listed above
2. Clone the repository:

   git clone https://github.com/security-alliance/frameworks.git
   cd frameworks && git checkout develop
   

3. Start the development server:

   just serve
   

(Optional) Authenticate with GitHub CLI: The GitHub CLI (gh) is already preinstalled in the devcontainer. You can authenticate by running gh auth login in the terminal, making it easy to interact with GitHub directly from your development environment.

Local Development with mdBook

If you want to locally experiment with mdBook, you can run just serve which will automatically run mdBook when installed, serving the project for local viewing.

Handling the Summary

Because of how we handle the .org and .dev domains in different branches, the main outline in src/SUMMARY.md is generated on the fly, based on config/SUMMARY.develop|main. You'll notice both differ - in .org we only publish reviewed frameworks, while in .dev we include most everything.

If you need to modify the outline for a framework, please make sure to update it accordingly in config/SUMMARY.develop.

You may explore existing issues or open a new one for missing content, although a PR is preferred. If you identify missing or unfinished content, feel free to open a PR. First, check existing PRs or branches to make sure your work is not redundant.

Attribution and Tags

Most pages have tags below the heading and a way to add attribution and filtering.

Page Tags

Tags like "Community Manager", "SRE", etc. help categorize content and make it discoverable. To add tags to your page, include them in the frontmatter:

---
tags:
  - Engineer/Developer
  - Security Specialist
  - Devops
  - SRE
---

Tags are currently in an exploratory phase. They are displayed at the top of each page and are also used for filtering and navigation throughout the site.

Attribution

Contributors are managed through a centralized system:

1. There's a contributor 'database' at src/config/contributors.json, where you add contributors or get their information from.

2. The file src/config/using-contributors.md contains all the information needed to understand how to add them to your pages.

To add contributors to a page, you can use frontmatter as shown in the using-contributors guide:

---
title: Your Page Title
contributors:
  - role: wrote
    users: [mattaereal, charlie_dev]
  - role: reviewed
    users: [fredriksvantes, zedt3ster]
---

Structure and collaboration

The book is supposed to cover all important parts of security for web3 projects. For contributors, we recommend focusing on specific topics contained in corresponding pages. It's best to own a single topic and work out all the details. Create a new page and add the category to the sidebar if it's not there yet. Join the discord server, let others know what you are working on in the group channel and collaborate with other contributors writing about related topics. If you are working with multiple people on a significant piece of content, you can have a dedicated branch in the repo for easier coordination.

Style guide

Wiki pages follow standard Markdown with some extensions by mdBook.

The audience of this wiki is technical and the content should reflect that. There are many guides on technical and documentation writing you can learn from, for example you can check this lecture to get started.

Here are main guidelines to follow when writing this wiki:

• Write in an objective, clear and explanatory tone
• Avoid unnecessary simplifications, describe the technical reality
• Avoid using too long and complex sentences or paragraphs
  • Use concise and clear statements
  • Break down your text using block-quotes, bullet points or images
• Always link your resources and verify them
• Use bullet points or tables for topics which require enumerating
• Highlight keywords to support scanning and skimming through the article
• Provide visualizations to explain the topic better
• When using acronyms or a technical jargon, make sure to introduce it first
• Web3 is changing fast, write the content to be as much future proof as possible
• Don't use LLMs to generate the text
  • We don't accept texts fully generated by AI, however we recommend using it to fix grammar or phrasing
• Consider creating tutorials and hands-on guides documenting technical steps
• Add recommended reading at the top, point to topics which are dependencies of yours
• You can use mermaid diagrams for visualizations

Goal is to produce a credible neutral text which is formal, well-structured, and maintains a clear progression of ideas. The content should be purely technical and shouldn't waste space on introducing high level/well known concepts. Introductory topics are necessary and can use comparisons, historical anecdotes, and concrete examples to make complex concepts more accessible.

Content standardization

The wiki uses American English over British spelling. Terminology, capitalization and nomenclature should match across all pages. Use Ethereum.org guide for the reference.

Usage of images and visualizations is encouraged. If you are using an image created by a third party, make sure its license allows it and provide link to the original. For creating your own visualizations, we suggest excalidraw.com.

Feel free to use emojis or icons where it fits, for example in block-quotes.

Linking resources

When adding an external link, you can use it directly in the text or on the bottom of the page in "Resources" section.

When linking resources use descriptive names, such as inevitableeth.com instead of generic phrases like this wiki.

Don't overwhelm reader with too many resources within the text.

When linking a page within this framework, use a relative path and if it references specific topic within the page, use a link to heading IDs.

For other important links, add a section on the bottom of the page with list of resources. Resources should have a name or short description with a link and alternative link to its archived mirror. We strongly suggest adding a link to the latest snapshot from archive.org.

In-page notices

We use block-quote notices at the top of the page to provide readers with appropriate context regarding the content of the page.

Incomplete pages

Pages with minimal content which need more work to cover the topic need to include a notice:

⚠️ This article is a stub, help the framework by contributing and expanding it.

Anything else?

This page is also opened for contributors! Suggest improvements to our style and guidelines in the github repo.

About this page

Originally based from the Ethereum Protocol Fellows

Contributors

This is the current list of individuals who have made substantial contributions to the project and deserve recognition.

Stewards

What is a Framework Steward?

A framework steward is the champion and caretaker for an individual security framework (most frameworks here are currently available for adoption). This role goes beyond casual contribution. It's about taking ownership and helping guide the framework's development through community engagement.

The Steward's Role

A framework steward is a project management role, responsible for:

• Rallying collaborators: Recruit contributors who share your passion for specific security challenges
• Managing contributions: Help triage GitHub issues and coordinate improvements
• Advocating for adoption: Work with SEAL to promote your framework within your networks and the broader Web3 community
• Creating content: Work with SEAL to write blog posts, host workshops, or share best practices related to your framework
• Representing the community: Be a voice for practitioners who use and rely on these standards

The core SEAL team will support you throughout this journey, helping you focus on specific challenges rather than drowning in administrative tasks.

Why Become a Steward?

Recognition and Growth

• Earn achievement badges: Receive public recognition with roles like Security Framework Ambassador or DAO Safeguards Steward
• Build your reputation: Establish yourself as a thought leader in Web3 security
• Develop new skills: Gain experience in open-source governance, technical writing, and community building

Tangible Benefits

• Access exclusive events: Receive tickets to security conferences and invite-only Security Alliance gatherings
• Showcase your expertise: Get featured through SEAL's official channels, including our blog and social media
• Connect with peers: Build relationships with other security professionals who share your interests

Lasting Impact

• Shape industry standards: Help develop frameworks that could become foundational to Web3 security
• Prevent security incidents: Your work will directly contribute to a safer ecosystem
• Leave a legacy: Carve your name into the DNA of Web3 security practices for years to come

Stewardship in Action: What It Looks Like

Time Commitment

Being a steward doesn't mean giving up your day job. We're looking for contributors who can dedicate approximately 3 hours per week to their framework. This might include:

• Reviewing pull requests and GitHub issues
• Participating in sporadic steward meetings
• Creating occasional content or presentations
• Engaging with the community on Discord

Support Structure

You won't be working alone. You will have:

• Access to a dedicated channel on our Discord server
• Coordination calls with the SEAL team as needed
• Documentation templates and contribution guidelines
• Access to technical advisors when needed

How to Apply

Ready to become a framework steward? Here's how to get started:

1. Review the proposed frameworks at frameworks.securityalliance.org and identify which one aligns with your expertise and interests.
2. Join our steward candidates Telegram channel and introduce yourself to let us know which Framework you want to adopt.

We're looking for diverse perspectives and experiences, and you don't need to have decades of experience. Passion, dedication, and a willingness to learn are just as important.

Join Us in Building a Safer Web3

The "Adopt a Framework" campaign isn't just about improving documentation. You'll be part of a movement where security becomes a shared responsibility across the Web3 ecosystem.

By becoming a steward, you're taking an active role in preventing the next major hack, protecting user funds, and ensuring that innovation can continue without compromising safety.

We're just getting started, and we need your expertise.

Have questions about the stewardship program or ideas for improving it? You can use the potential stewards Telegram channel for that too! 🙂