보안 감사 서비스는 체계적인 프로젝트로, 계약 조합, 계약 업그레이드 등의 변경으로 인해 원래의 감사 업무가 "무의미"해질 수 있습니다.
원저자: @tmel0211
원본 출처: X
참고: 원본 텍스트는 @tmel0211 이 게시한 긴 트윗에서 가져온 것입니다.
OpenZeppelin 및 Safe와 같은 일부 보안 전문가가 온체인 환경에서 감사 보고서를 공개하는 방법을 도입하고 온체인 통화에 대한 통합 인터페이스를 제공하는 ERC-7512 표준을 공동으로 출시했다는 사실을 눈치채셨을 것입니다. 블록체인 산업의 보안. 이것을 어떻게 해석해야 합니까?
제 생각에는 보안 업계에 부족한 점은 투명한 보고가 아니라 표준화된 감사 프로세스와 비즈니스 권리와 책임에 대한 합의입니다. 간단히 말하면:
1) 직감적으로는 Openzepplin, Safe 등 일부 보안업체만 참여하고 있는 것으로 확인되었으며, 국내 유명 보안업체인 SlowMist, BlockSec, Certik, PeckShield 등은 아직 입장을 밝히지 않고 있다. 거물들은 모두 현재 이 문제를 진전시키기 위한 통일된 합의가 없으며 후속 조치를 기다릴 것이라고 말했습니다.
2) 보안 감사 보고서는 통일된 표준에 따라 체인에 저장되며, 현재 Github의 저장 기능과 비교하면 변조 방지 기능만 있을 수 있지만 이 요구 사항이 엄격하지는 않습니다. 감사 회사가 제공하는 보고서는 일반적으로 협력 법적 계약 조건에 구속되며 악의적으로 변조될 가능성이 없으며 그렇게 할 필요도 없습니다.
3) 이 표준의 목적은 보안 회사가 통일된 형식과 표준화된 감사 보고서 콘텐츠를 체인에 출력하도록 안내하고 주로 후속 제3자 회사가 플러그인 분석 및 기타 서비스(파싱 가능성)를 제공할 수 있도록 하는 것입니다. 전반적인 목적은 투명한 계약 호출 형식을 통해 감사 보고서의 다중 시나리오 노출을 늘리는 것입니다. 예를 들어, 플러그인을 개발하면 Etherscan에서 계약을 확인할 때 보안 감사 보고서의 내용을 자동으로 구문 분석할 수 있으며, 마찬가지로 보고서의 시각적 내용도 Uniswap과 같은 트랜잭션 프런트엔드에 통합될 수 있습니다. 그러나 감사 보고서의 내용은 일반적으로 뒤떨어져 있으며 사용자가 제품을 사용할 때 해결된 문제 수를 확인하는 것이 그리 엄격하지 않으며 프로젝트에 문제가 많이 발견되면 상호 작용에 영향을 미치게 됩니다. 어느 정도 심리학.
4) 전체적으로 의미 있는 시도이며, 이를 출발점 으로 감사보고서 - 3자 분석 호출 - 플러그인 프론트엔드 노출 등 보안 감사 노출경로를 점진적으로 탐색하는 것이 가장 좋다. 효과적인 ""책임" 시스템 세트 , 관련된 프로젝트가 많고 보안 회사가 많은 경우 어느 정도 인기를 얻은 후 감사 업계의 현재 혼란을 효과적으로 개선할 수 있습니다.
한마디로 보안 감사 서비스는 체계적인 프로젝트로, 계약 조합, 계약 업그레이드 등의 변경으로 인해 원래의 감사 업무가 "의미 없게" 될 수 있습니다.
본질적으로 보안 감사는 전문성을 활용하여 프로젝트 당사자가 출시 전 문제를 해결하고, 운영 프로세스 중 긴급 상황을 해결하고, 기타 도구, 서비스 및 기타 지원을 보완하여 보안을 향상하도록 돕는 제3자 보안 회사입니다. 프로젝트. 그러나 결국 이는 "아웃소싱" 서비스이지 평생 포괄적이고 걱정 없는 보증이 아닙니다.
더 많은 보안 위험과 위험을 식별하기 위해 보안 회사에만 의존할 수는 없습니다. 시장은 보안 감사에 주의를 기울여야 하지만 보안 감사에 너무 의존할 수는 없습니다. 특히 감사가 보증으로 시장에 도입되면 완전히 바뀔 것입니다. 맛.
