How to Prepare for a Security Assessment Estimate

This document helps teams prepare for a security assessment estimate. Thorough preparation enables the technical team to evaluate the scope efficiently and provide an accurate estimate without unnecessary delays. Please review the checklist below and prepare the required materials in advance to help the technical team estimate the time and effort needed.

Language requirement

Please provide all documentation in English.

Smart Contract Audit

Access to the code repository or deployment addresses
Commit hash or branch to be audited
Scope definition (in-scope contracts or files)
Out-of-scope components (e.g., mocks, scripts, vendored libraries)
Testing framework (e.g., Foundry, Hardhat, Brownie)
Architecture and technical documentation (whitepaper, specifications, or README)
Target blockchain networks
For forked code: original project, upstream repository, and upstream commit hash

Blockchain Protocol Audit

Protocol overview, target Layer 1 or Layer 2 networks, and development stage
Access to code repositories, with target branches, commit hashes, and in-scope modules
Out-of-scope components and dependencies
For forked protocols: upstream repository, base version or commit, and summary of changes
Architecture documentation, technical specifications, and system diagrams
Security model, trust assumptions, and validator or permission design
Custom or modified subsystems (e.g., consensus, P2P networking, VM, state management, or bridges)
Custom or modified cryptographic libraries and dependencies
Build, deployment, and local testnet instructions, along with test suites and coverage
Security concerns or areas requiring special attention

Web Application & API Penetration Testing

List of domains and subdomains
API documentation (e.g., OpenAPI/Swagger specification or Postman collection)

For example:
- GET /api1/abc/xyz
- POST /api1/abc/xyz
- PUT /api1/abc/xyz
- DELETE /api1/abc/xyz
Number of in-scope API operations (endpoint + HTTP method)
User roles and test accounts (e.g., User, Admin, Backoffice)

Mobile Application Penetration Testing

Target platforms (iOS, Android, or both)
Access method:
- APK and/or IPA file
- TestFlight, Play Store, or App Store link
List of domains and subdomains
API documentation (e.g., OpenAPI/Swagger specification or Postman collection)

For example:
- GET /api1/abc/xyz
- POST /api1/abc/xyz
- PUT /api1/abc/xyz
- DELETE /api1/abc/xyz
Number of in-scope API operations (endpoint + HTTP method)
User roles and test accounts (e.g., User, Premium User)

Secure Code Review

Access to the code repository
Target branch and commit hash
In-scope repositories, modules, and files
Out-of-scope components
Programming languages and frameworks
Application overview, critical workflows, and integrations
Architecture and technical documentation

Desktop Application Penetration Testing

Target platforms and OS versions (Windows, macOS, Linux)
Application installer or installation/access instructions
Application framework (e.g., .NET, Java, Electron)
In-scope components and exclusions (client, backend/API, local services)
API documentation (e.g., OpenAPI/Swagger specification or Postman collection), if in scope:

For example:
- GET /api1/abc/xyz
- POST /api1/abc/xyz
- PUT /api1/abc/xyz
- DELETE /api1/abc/xyz
Number of in-scope API operations (endpoint + HTTP method)
User roles and test accounts (e.g., User, Admin, Backoffice)

Browser Extension Penetration Testing

Target browsers (Chrome, Firefox, Edge, Safari)
Extension version and installation package or store link
Extension overview, critical workflows, and integrations
In-scope components and exclusions (extension, backend/API, companion desktop application)
Source code repository and build instructions, if available
API documentation (e.g., OpenAPI/Swagger specification or Postman collection), if in scope:

For example:
- GET /api1/abc/xyz
- POST /api1/abc/xyz
- PUT /api1/abc/xyz
- DELETE /api1/abc/xyz
Number of in-scope API operations (endpoint + HTTP method)
User roles and test accounts (e.g., User, Admin, Backoffice)

Cloud & Infrastructure Assessment

Cloud provider (AWS, GCP, Azure, etc.)
In-scope accounts, projects, subscriptions, and regions
In-scope environments (production, staging, development)
In-scope services and assets, with approximate counts (e.g., EC2, EKS, S3, RDS, Lambda, GKE, Cloud SQL, Kubernetes clusters, load balancers, IAM)
Architecture diagram

Threat-Led Penetration Testing (TLPT)

Primary assessment objective and success criteria

For example:
- Gain access to the internal network
- Compromise a standard user account
- Obtain privileged or administrator access
- Access a critical system or sensitive data
- Test security monitoring and incident response
Critical business services and workflows to assess
Key security concerns and scenarios of interest, if known
Starting access and assumed attacker privileges
In-scope assets and approximate counts (e.g., 2 applications, 2 internal subnets, 20 servers, and 1 Active Directory domain)
In-scope identities and target roles
Out-of-scope assets, activities, and testing restrictions

Red Teaming

Primary assessment objective and success criteria

For example:
- Determine whether an external attacker can access critical systems or sensitive data
- Evaluate security monitoring and incident response
Approximate number of internet-facing domains and subdomains
Companies, brands, or business units in scope
Main public websites or domains associated with the scope
Critical business services, systems, and data to protect
Permitted objectives and target systems after initial access
Scope exclusions and operational restrictions
Whether the security monitoring team will be informed, and any notification requirements

Proof of Reserves

Organization overview, business activities, and audit frequency
In-scope reserve assets, blockchain networks, and approximate number of addresses
Wallet architecture (single-signature, multisignature, or smart contracts) and staked assets
Method for demonstrating address ownership (e.g., signed messages or test transactions)
Customer liability data format, approximate number of balance records, and access to a replica database for verification
Customer liability verification method, if applicable (e.g., Merkle tree generation, zero-knowledge (ZK) proofs, or a custom cryptographic proof mechanism)

AI Red Teaming

System overview, intended use cases, and priority risk scenarios (e.g., jailbreaks, data leakage, agent over-privilege)
In-scope models (providers, versions, hosting), input/output modalities, and inference endpoints
Agent architecture, tool/API execution capabilities, permission model, and MCP integrations
RAG workflows, connected vector databases, and knowledge sources
Existing guardrails, system prompts, content filters, and safety policies
Testing environment access, test accounts, and any constraints or rate limits

CyberSec Advisory

Project overview, technology stack (smart contracts, dApps, protocols, infrastructure), and development stage
Security goals, priorities, and success criteria for the engagement
Preferred advisory model (advisor-led or client-led) and requested weekly capacity
Architecture documentation, known security concerns, and existing security controls
Expected advisory activities (e.g., architecture reviews, threat modeling, secure SDLC guidance, or audit coordination)
Key milestones, audit roadmap, and target launch dates

Let’s secure the decentralized world together. 🚀

Smart Contract Audit​

Blockchain Protocol Audit​

Web Application & API Penetration Testing​

Mobile Application Penetration Testing​

Secure Code Review​

Desktop Application Penetration Testing​

Browser Extension Penetration Testing​

Cloud & Infrastructure Assessment​

Network Penetration Testing​

Threat-Led Penetration Testing (TLPT)​

Red Teaming​

Proof of Reserves​

AI Red Teaming​

CyberSec Advisory​