블록체인 보안을 위한 스마트 컨트랙트 감사의 중요성

### 스마트 계약 감사의 중요성: 배포 전 보안 보장
* 🔍 스마트 계약 감사는 취약점을 파악하고 팀에 보안 모범 사례를 교육하는 것을 목표로 **스마트 계약 시스템에 대한 시간 제한이 있는 보안 중심 검토**입니다.
* 💰 작년에만 스마트 컨트랙트에서 **약 40억 달러가 도난당**했으며, 이는 코드를 라이브 블록체인에 배포하기 전에 **감사가 반드시 필요**하다는 점을 강조합니다.
* 🛡 블록체인 환경은 한번 배포된 스마트 컨트랙트는 변경할 수 없기 때문에 **잠재적인 악의적 사용자에 대한 철저한 대비**가 필요합니다.
* 📊 감사는 취약점을 식별할 뿐만 아니라 **개발자의 코드에 대한 이해도**를 높여 **개발자의 효율성**과 **최신 도구에 대한 친숙도**를 향상시킵니다.
* 🔄 많은 프로토콜은 지속적인 보안을 보장하기 위해 **여러 차례의 감사와 공식 검증 및 버그 포상금 프로그램**과 같은 추가 보안 조치를 거칩니다.
* 📅 감사 프로세스는 **일정과 범위에 대한 논의**로 시작하여 감사인이 다양한 도구를 사용하여 취약점을 발견하는 **실제 감사**로 이어집니다.
* 📑 심각도별 조사 결과를 자세히 설명하는 초기 보고서가 작성된 후, 프로토콜 팀은 **최종 보고서를 발행하기 전에 이러한 문제를 해결할 수 있는 시간**을 갖습니다.
* 🤝 성공적인 감사를 위해서는 보안이 일회성 이벤트가 아닌 지속적인 여정임을 강조하면서 **개발자와 감사자 간의 명확한 문서화와 열린 커뮤니케이션**이 필요합니다.

스마트 컨트랙트 감사는 프로토콜이 라이브 블록체인에 배포하기 전에 취약점을 식별하고 보안을 강화할 수 있도록 지원합니다.

smart contract audit is a time-boxed security-based code review on your smart contract system. An auditor's goal is to find as many vulnerabilities as possible and educate the protocol on best security practices and coding best practices moving forward. Auditors use a combination of manual review and automated tools to find these vulnerabilities. Now, why are they so important? Why is it critical that you get an audit before deploying your code base to a live blockchain? For starters, there are entire websites dedicated to how many hacks happen. Last year, we saw the most value ever stolen from smart contracts, with almost 4 billion dollars stolen. Due to the immutability of the blockchain, once a smart contract is deployed, you can't change it, so you better get it right. The blockchain is a permissionless adversarial environment, and your protocol needs to be prepared for malicious users. But even more so than that, an audit can improve your developers' team's understanding of code, improving their speed and effectiveness in implementing features moving forward.

and it can teach your team the latest and greatest tooling in the space. Often, just one smart contract audit isn't even enough, and protocols go on a security journey that includes many audits and many different services like formal verification, competitive audits, and bug bounty programs. We'll break these down in a future video. There are a lot of companies that offer smart contract auditing services like Parallel Bits, Consensus Diligence, Open Zeppelin, Sigma Prime, Spirit Dao, Mixed Bytes, WatchPug, Trust, and of course, Ciphon. Additionally, there's a lot of independent auditors that do great work as well. A typical audit looks like this: price and timeline. First, a protocol needs to reach out, and they can reach out before or after their code is actually finished. Ideally, they reach out sometime before their code is finished so the auditors can have time to slot them in. Once they reach out, the protocol and auditors will discuss how long the audit will take based off of scope and code complexity. The scope of the audit is going to be the exact files

and commit hash that's going to be audited. How long the audit usually depends on how many lines of code/complexity. You can see a very, very rough approximation of how long an audit takes on your screen. Now, of course, this depends from The Firm audit to audit and tool to Tool, so take these with a very large grain of salt. Additionally, it's this duration that sets the price and same thing at the time of recording. Prices range wildly depending on who's doing the audit, how many people are doing the audit, how complex the code is, and more. And these initial conversations are really just to get a ballpark estimate and Slot you in to the auditor schedule commit hash down payment start date. Once you have a commit hash, you can finalize the start date and final price. The commit hash is the unique ID of the code base that you're working with, so the Auditors can know exactly what code they're going to be looking at. Some Auditors will ask for a down payment in order to schedule you in. Audit Begins. The Auditors will use every tool in

their Arsenal to find as many vulnerabilities in your code as possible. We'll give you some tricks in a minute to make this a successful step. Initial report after the time period ends. The Auditors will give you an initial report that looks something like this, with all their findings listed by severity, usually categorized into highs, mediums, lows, informational/non-critical, and gas efficiencies. Highs, mediums, and lows represent the severity of impact and likelihood of each vulnerability. Informational, gas, and non-critical are findings to improve the efficiency of our code, code structure, readability, and best practice improvements that are not necessarily vulnerabilities but more ways to improve your code. Mitigation Begins. The protocol's team will then have an agreed-upon time to fix the vulnerabilities found in the initial Auto report. Sometimes, depending on the severity of the findings, this might mean you have to start from scratch, but more times than not, you can just implement the recommendations the Auditors give you. This is usually much shorter than the audit itself. Final report after the protocol makes these changes. The auto

team will do a final audit report exclusively on the fixes made to address the issues brought up in the initial report. Then, hopefully, the protocol and Auditors have a great experience together and will work together in the future to keep web 3 secure. Now, there are a few key things that you can do to make sure your audit is as successful as possible. To get the most out of your audit, you should have clear documentation, a robust test suite, ideally including fuzz or invariant tests, code should be commented and readable, modern best practices are followed, there should be an established communication channel between developers and Auditors during the audit, and an initial video walkthrough of the code should be done before the audit starts. The most important part of the process is going to be during the audit. To get the best results, you want to think of you and your Auditors working together as a team. One of the best ways to do this is to have a dedicated channel where Auditors can ask questions to developers. The developers will always and forever have more context over the

code base than the Auditors ever will because they have spent so much more time working on the code base. The more documentation, context, and information that you can give to the Auditors, the better. This way, it can be easy for anybody to walk through the code and understand what it's supposed to do. In fact, 80 percent of all bugs are actually business logic implementation bugs. This means that these are bugs that have nothing to do with some weird coding error and are just somebody not knowing what the protocol should be doing. So, it's vitally important that the Auditors understand what the code should be doing. Having a modern test suite and tooling can also make Auditors spend less time fidgeting with your tooling and more time finding issues. Post-audit, we highly encourage you to take the recommendations your Auditors give you seriously. Additionally, after an audit, if you make a change to your code base, that new code is now unaudited code. It doesn't matter how small the changes; we've seen a ton of protocols saying, Oh

I'll just slip in one line of code, and sure enough, that's the line of code that gets exploited. And often, depending on the seriousness of your protocol and how many users you want to use it, one audit might not even be enough. Working with multiple auditors and getting more eyes on your code will give you a better chance of finding more vulnerabilities. What an audit isn't. Now, here's the thing: an audit doesn't mean that your code is bug-free. An audit is a security journey between the protocol and the auditor to find as many bugs as possible and teach the protocol different methodologies to stay more secure in the future. Security is a continuous process that is always evolving. No matter how much experience someone has, people at all levels have missed vulnerabilities. On the unfortunate day that that happens, be sure that you and your auditor can jump on a call quickly to try to remedy the situation, and maybe consider getting insurance for your protocol as well. So now, with that being said, now you have a good idea of what a smart contract audit.

entails and what to expect. To end a smart contract audit is a security journey, end-to-end, leveling up your protocol so that you can have all the best practices and security know-how to deploy your code to a live blockchain forever. And of course, if you're looking for an audit, be sure to reach out to the Cyphron team. Link in the description. And as always, stay safe out there, and we'll see you next time.

What is a smart contract audit? How to prepare for a smart contract audit?

Book a smart contract audit here 👇
https://www.cyfrin.io/


Cyfrin Audits

스마트 컨트랙트 감사는 취약점을 파악하고 보안 및 코딩 모범 사례에 대한 프로토콜을 교육하는 데 매우 중요합니다.

작년에 스마트 컨트랙트에서 도난당한 금액이 40억 달러에 육박하는 만큼, 블록체인의 불변성 때문에 배포 전 감사는 필수입니다.

여러 번의 감사와 추가적인 보안 조치가 필요한 경우가 많으며, 다양한 회사와 독립 감사인이 이러한 서비스를 제공합니다.

코드 취약점에 대한 감사 프로세스

감사 기간과 가격은 코드 복잡성과 감사 회사에 따라 다릅니다.

커밋 해시를 사용하여 시작 날짜와 가격을 확정하며, 일부 감사인은 계약금을 요구하기도 합니다.

감사인은 취약점을 심각도별로 분류한 초기 보고서를 제공하고, 이후 프로토콜 팀이 발견한 취약점을 해결할 수 있는 완화 기간을 제공합니다.

0 보안의 협력적인 미래를 목표로 초기 보고서에서 수정한 사항에 대한 최종 감사 보고서를 작성합니다.

성공적인 감사를 위한 핵심 단계에는 명확한 문서화, 강력한 테스트 스위트, 가독성 있는 코드, 최신 모범 사례, 개발자와 감사자 간의 원활한 커뮤니케이션이 포함됩니다.

감사 중에는 감사자가 질문할 수 있는 전용 채널과 코드의 의도된 기능을 이해하는 데 필요한 컨텍스트와 정보를 제공하는 등 팀워크가 매우 중요합니다.

스마트 계약 감사는 코드의 취약점을 식별하는 데 매우 중요하지만, 한 번의 감사로는 충분하지 않을 수 있습니다.

여러 감사인과 협력하면 더 많은 버그를 발견할 가능성이 높아집니다.

보안은 지속적인 프로세스이며, 신속한 대응 계획과 보험을 갖추면 잠재적인 문제를 완화하는 데 도움이 될 수 있습니다.

스마트 콘트랙트 감사는 코드를 라이브 블록체인에 배포하기 전에 프로토콜의 보안과 모범 사례를 강화하는 데 매우 중요합니다.

감사 프로세스는 프로젝트의 보안 노하우 수준을 높이는 것을 목표로 하는 엔드투엔드 여정입니다.

감사가 필요한 경우, 사이프론 팀이 도움을 드릴 수 있습니다.