Skip to main content
DFINITY takes the security of our software products seriously, including all source code repositories under the DFINITY GitHub organization.

​
Bug Bounty Program

The DFINITY Foundation operates an Internet Computer (ICP) Bug Bounty program that rewards researchers for finding and reporting vulnerabilities.

​
Eligibility

Before reporting a vulnerability, please:
  1. Review the bug bounty policy at dfinity.org/bug-bounty
  2. Check the scope and eligibility criteria to determine if your finding qualifies
  3. Understand the reward structure for different severity levels

​
Rewards

The bug bounty program offers rewards based on:
  • Severity - Critical, High, Medium, or Low impact
  • Exploitability - Ease of exploitation
  • Impact - Potential damage to the network, users, or assets
  • Quality - Completeness and clarity of the report

​
Reporting a Vulnerability

Do not disclose vulnerabilities publicly. Public disclosure could be exploited by attackers before a fix is available.

​
Reporting Methods

1

Preferred: HackenProof (Recommended)

Report through HackenProofAdvantages:
  • Streamlined disclosure process
  • Faster Bug Bounty payouts
  • Structured communication channel
2

Alternative: Email

Send an email to: [email protected]Include the following information:
  • Description of the vulnerability
  • Steps to reproduce the vulnerability
  • Risk rating (Critical/High/Medium/Low)
  • Proof of concept (if applicable)
  • Any other relevant information

​
What to Include in Your Report

  • Clear, concise summary of the vulnerability
  • Affected components or systems
  • Vulnerability type (e.g., buffer overflow, injection, cryptographic weakness)
  • Detailed steps to reproduce the issue
  • Required preconditions or setup
  • Expected vs. actual behavior
  • Screenshots or logs if applicable
  • Potential consequences if exploited
  • Affected user groups or systems
  • Your assessment of severity
  • Proof of concept code (if safe to share)
  • Network captures or logs
  • Links to related vulnerabilities or research

​
Response Timeline

We will respond to your report within 72 hours and work with you to fix the vulnerability as soon as possible.

​
Security Update Process

Once a security vulnerability is reported, the DFINITY Foundation follows a structured process:
1

Investigation

  • Confirm the vulnerability
  • Assess severity and impact
  • Assign to appropriate security team
2

Fix Development

  • Develop and test a fix
  • Ensure no regression or new vulnerabilities
  • Prepare documentation updates
3

Release

  • Release a new version including the fix
  • Follow Network Nervous System (NNS) upgrade process for protocol changes
4

Announcement

  • Announce the security fix in release notes
  • Provide guidance to node operators if needed
  • Credit researchers (with permission)

​
Coordinated Disclosure

We practice responsible disclosure:
  • Vulnerabilities are kept confidential until a fix is deployed
  • We coordinate with reporters on disclosure timing
  • Public disclosure occurs only after fixes are widely deployed

​
Security Best Practices

​
For Contributors

Follow security best practices when contributing to the Internet Computer codebase.

​
Secure Coding Guidelines

Input Validation

Always validate and sanitize external inputs

Error Handling

Handle errors gracefully without leaking sensitive information

Cryptography

Use established cryptographic libraries, never roll your own

Dependencies

Keep dependencies updated and audit for known vulnerabilities

​
Code Review Focus Areas

​
For Node Operators

​
Infrastructure Security

  • Keep IC-OS updated with latest security patches
  • Minimize exposed network services
  • Use firewall rules to restrict access
  • Enable security monitoring and logging
  • Secure storage of cryptographic keys
  • Use Hardware Security Modules (HSMs) where appropriate
  • Implement key rotation procedures
  • Maintain secure backups
  • Limit administrative access
  • Use strong authentication mechanisms
  • Implement principle of least privilege
  • Audit access logs regularly
  • Monitor for unusual network activity
  • Set up alerting for security events
  • Participate in security advisories
  • Stay informed about IC security updates

​
For Canister Developers

​
Smart Contract Security

Canister developers should follow best practices to prevent vulnerabilities in their code.

Access Controls

Implement proper authorization checks in all canister methods

Input Validation

Validate all inputs, especially from untrusted callers

Cycles Management

Protect against cycles draining attacks

State Management

Handle state transitions atomically and safely

​
Testing for Security

  • Fuzz testing - Use property-based testing to find edge cases
  • Security audits - Consider third-party security audits for critical canisters
  • Formal verification - Use formal methods where applicable
  • Penetration testing - Test attack scenarios before deployment

​
Dependency Management

​
Vulnerability Scanning

The repository uses cargo-deny for dependency auditing: 
# Check for known vulnerabilities
cargo deny check advisories

# Check for license compliance
cargo deny check licenses

# Check for supply chain security
cargo deny check bans
Configuration is maintained in deny.toml at the repository root.

​
Supply Chain Security

1

Trusted Sources

Only use dependencies from reputable sources (crates.io, verified publishers)
2

Version Pinning

Pin dependency versions in Cargo.lock for reproducibility
3

Regular Updates

Keep dependencies updated to receive security patches
4

Audit Trail

Review dependency changes in pull requests

​
Security Tooling

​
Static Analysis

  • Clippy - Rust linter with security-relevant checks
  • Rustfmt - Consistent code formatting reduces bugs
  • Cargo-audit - Check for known vulnerabilities in dependencies

​
Dynamic Analysis

  • Fuzzing - See rs/fuzzers/ for fuzz testing infrastructure
  • System tests - End-to-end security testing
  • Canister testing - Use PocketIC for security test scenarios

​
Build Reproducibility

The Internet Computer provides verification of build reproducibility: 
# Verify IC-OS update images by proposal number
curl -fsSL https://raw.githubusercontent.com/dfinity/ic/{COMMIT_ID}/ci/scripts/repro-check | \
    python3 - -p <proposal_number>

# Verify by git commit
curl -fsSL https://raw.githubusercontent.com/dfinity/ic/{COMMIT_ID}/ci/scripts/repro-check | \
    python3 - -c {COMMIT_ID}
This ensures deployed code matches the published source.

​
Communication

​
Preferred Language

We prefer all security communications to be in English for consistency and clarity.

​
Confidentiality

  • Security reports are kept confidential
  • Access is limited to security team members
  • Reporter identity is protected (unless permission is given for attribution)

​
Security Advisories

Security advisories are published:
  • Through NNS proposals for protocol upgrades
  • In release notes on GitHub
  • On the DFINITY Forum for community awareness

Bug Bounty Program

Official bug bounty program details

HackenProof Platform

Report vulnerabilities through HackenProof

Contributing Guide

Guidelines for secure contributions

Testing Guide

Security testing practices

​
Disclaimer

This security policy is subject to change at any time. Check the latest version for updates.

​
Contact Information

Build docs developers (and LLMs) love

Get started for freeTalk to us