보안 감사를 받았다는 말, 어디까지 믿을 수 있을까?

디지털 자산 서비스에 유명 감사 업체의 로고가 붙어 있으면 안심하기 쉽다. 그러나 그 표시만으로 지금 내가 사용하는 코드와 운영 방식이 어디까지 확인됐는지는 알 수 없다.

투자자가 읽어야 할 것은 감사의 존재와 함께 그 대상·시점·발견 사항·수정 확인이다. 검토의 범위를 이해하면 무엇이 확인됐고 어떤 위험이 남는지 더 구체적으로 질문할 수 있다.

감사 기록은 어떤 대상을 어떤 조건에서 검토했는지 설명하는 자료다. 그 범위를 넘어 지금의 모든 자금 경로가 안전하다고 결론내리지는 않는다.

1. 로고에서 원보고서로 이동한다

감사 업체가 직접 공개한 보고서와 프로젝트의 설명을 대조한다. 검토 기간, 대상 코드와 버전, 포함한 기능과 제외한 범위가 실제 사용할 서비스에 대응하는지 읽는다.

Ethereum의 스마트컨트랙트 시험 안내는 일부 입력에 대한 시험의 한계와, 시험·수동 검토 등을 포함하는 감사의 역할을 구분한다. 검토를 통해 오류를 찾을 수 있다는 설명과 모든 가능한 행동의 안전성을 확인했다는 주장은 다르다.

보고서가 없다면 감사 로고의 뜻을 임의로 채우지 않는다. 누가 검토했는지와 무엇을 검토했는지를 함께 확인해야 한다.

심각도별 개수만 보면 수정한 문제와 남겨 둔 문제를 같은 결과로 읽을 수 있다. 아래 항목을 원보고서와 후속 확인 자료에 연결한다.

발견 사항이 적다는 이유만으로 더 안전한 서비스를 골랐다고 단정하지 않는다. 검토 범위와 방법, 공개 수준이 다를 수 있다. 심각도 분류도 업체 간에 같은 뜻인지 확인한다.

동일한 이름의 서비스라도 검토 이후 코드나 설정이 바뀌었을 수 있다. 배포한 네트워크·계약 주소·버전과 주요 변경 기록을 보고서의 대상과 맞춰 본다.

ERC-7512의 감사 기록 제안은 감사 대상의 네트워크·배포 주소와 보고서를 연결하는 정보를 다루면서, 그 기록을 계약 보안의 보증으로 해석하지 않도록 구분한다. 이 제안을 모든 서비스에 구현된 인증 제도로 읽지는 않는다.

보고서의 진위가 확인돼도 현재 운영과의 일치 여부는 별도로 남는다. 바뀐 대상이 다시 검토됐는지 확인할 자료가 필요하다.

누가 기능과 설정을 바꿀 수 있는지, 외부 가격 자료·보관 업체·연결 서비스에 의존하는지 조사한다. 그런 요소를 보고서가 검토했는지도 구분한다.

코드의 결함, 운영 권한의 오용, 외부 자료의 실패와 개인의 잘못된 승인은 서로 다른 경로다. 한 경로의 확인 자료로 다른 경로의 위험까지 없어진 것으로 처리하지 않는다.

위험을 줄이는 조치와 사고 뒤 자금을 회수할 조건도 따로 읽는다. 감사 보고서가 거래 상대방의 상환 능력이나 투자자가 받을 현금까지 보장하는 자료는 아니다.

보안 자료를 읽은 날짜와 대상 버전, 남은 발견 사항, 확인하지 못한 연결을 짧게 남긴다. 주요 기능·권한·외부 의존이 바뀌면 어느 확인을 다시 해야 하는지 적는다.

오랜 감사 이력은 조사 자료가 될 수 있다. 다만 감사 횟수를 단순히 더해 사고 확률을 계산하거나, 보안 자료만으로 토큰의 권리·가격·수익성을 평가하지 않는다.

보안 검토와 투자 경제성은 각각 확인한다. 자금을 어디에 어떤 조건으로 맡기는지 설명할 수 있어야 감사 기록도 실제 판단의 자료가 된다.