Skip to content

Latest commit

 

History

History
27 lines (14 loc) · 2.7 KB

README.md

File metadata and controls

27 lines (14 loc) · 2.7 KB

Simple Security Toolkit

This repo is a collection of practical security-focused guides and checklists for smart contract development, assembled by the Nascent team to share with our portfolio companies and others in the ecosystem who might find it useful. It is not intended to be comprehensive; it skews towards practical and opinionated recommendations that we find to be appropriate particularly for teams developing and managing early versions of a protocol.

Contents

  1. Development Process

One of the most crucial factors in having a secure codebase is a solid development process: "an ounce of prevention is worth a pound of cure." This document gives an example development process that we, at Nascent, have found works well. It walks through the steps from initial design and feature requests -> specification -> evaluation -> implementation -> testing -> deployment -> monitoring.

  1. Audit Readiness Checklist

Audits are expensive, time consuming, and need to be scheduled months in advance. Completing this checklist helps ensure a codebase is ready for outside review and helps catch as much low-hanging fruit as possible. This will allow the auditors to focus their time and attention on identifying deeper and more critical vulnerabilities.

  1. Pre-Launch Security Checklist

Before deploying code to mainnet, teams should complete this checklist to make sure they have taken the necessary steps to enable reporting and responding to potential bugs or security incidents.

  1. Incident Response Plan Template

No project ever expects to have a security incident. Having a plan documented in advance can help a team respond swiftly and calmly in the heat of the moment when adrenaline is running high.

Contributing

Thanks for your interest in contributing! We are very opinionated as to what gets added to this repository. However, we are open to outside contributors putting forth suggestions and encourage you to do so. If you have ideas for a new document, it is likely best to open an issue before starting on a PR to gauge our support. If you have suggestions to existing documents, you can open a PR right away.

Feel free to fork this repo and make it your own. Share your ideas with your team and iterate. If you find things that may be useful to a broader set of teams, consider opening a PR!