레지스트리란 무엇인가
FlareWatch의 역사에서 반복되는 모든 버그 클래스는 번호가 지정된 safeguard로 정제되어 왔습니다. 즉, 한 문단의 규칙, 정당성, 그리고 이를 시행하는 코드 위치에 대한 포인터입니다. 반복되어야 할 버그 클래스나 패턴이 나타나면 새로운 safeguard가 추가됩니다.
레지스트리는 작동 중인 문서이지, 마케팅 자료가 아닙니다. 그 목적은 팀과 팀이 사용하는 감사 우선 검토 루프가 어느 규칙이 어디에 적용되는지에 대해 정직하게 유지하는 것입니다. 레지스트리는 인라인 코드 주석(예: // Safeguard 24)에서 참조되므로 모든 개별 파일의 읽는 사람이 주변 줄을 지배하는 규칙을 찾을 수 있습니다.
이 페이지는 공개 요약입니다. 전체 레지스트리는 소스 리포지토리 내에서 이를 지배하는 코드와 함께 있습니다. 여기서의 목적은 보안 연구원, 그랜트 검토자, 또는 잠재적 기여자에게 레지스트리가 포함하는 카테고리와 이것이 시행하는 규율의 종류에 대한 감각을 제공하는 것입니다.
레지스트리가 필요한 이유
safeguard 레지스트리는 같은 버그를 두 번 방지할 때만 가치가 있습니다. 레지스트리의 실적이 답입니다:
- 각 safeguard는 이것이 방지하는 버그의 이름을 지정합니다. 기억된 사건이 뒤에 있지 않은 규칙은 safeguard가 아니라 스타일 선호도입니다. 스타일 선호도는 레지스트리가 아닌 린트 규칙에 속합니다.
- Safeguards는 문서가 아닌 코드에서 참조됩니다. safeguard를 위반하는 코드 변경은 safeguard 번호가 주변 주석에 있기 때문에 검토 시간에 플래그로 표시됩니다.
- 일부 safeguard는 자동으로 시행됩니다. 일부는 ESLint 규칙 또는 CI에서 실행되는 셸 스크립트를 통해 시행됩니다. 나머지는 작성자 규율과 실제로 잘 작동해 온 감사 우선 검토 패턴에 의존합니다.
- 레지스트리는 테스트로 정직성을 유지합니다. 여러 safeguard는 소스 파일을 문자열로 읽고 안티패턴이 나타나지 않음을 단언하는 회귀 테스트로 고정됩니다. 취약성이 특징입니다: 안티패턴으로 되돌리는 향후 리팩터는 회귀가 프로덕션에 도달하기 전에 테스트에 실패합니다.
카테고리
레지스트리는 도메인별로 구성됩니다. 아래의 카테고리는 안정적이며, 새로운 장애 모드가 발견되면 각 카테고리 내의 특정 safeguard가 추가됩니다.
| 카테고리 | 포함하는 범위 |
|---|---|
| 인증 및 인가 | 세션 검증을 위한 단일 제어점, 모든 경로에서의 지갑 소유권 확인, 액세스 토큰과 리프레시 토큰 간 교차 토큰 거부, 관리자 경로 제한. |
| 데이터 무결성 | 주소 정규화, 프로듀서/컨슈머 경계에서의 단위 변환 계약, 키 빌더 규칙, 그리고 실패를 무시하고 영값으로 병합하는 규칙 금지. |
| 온체인 읽기 | 스마트 계약에서 읽은 모든 값에 대한 단일 구현 규칙, 온체인 레지스트리에서의 계약 주소 해석, 보상 로직 중복 금지 규칙. |
| 표시 정확성 | 중앙 집중식 숫자, 통화 및 날짜 포맷팅, 모든 숫자 표시에서의 널 안전성, APR 대 APY 레이블링 규칙, 실효세율 규칙. |
| 알림 및 공지 | 클라이언트와 서버 전반에 걸친 알림 평가의 단일 정보 소스, 모니터링 지갑으로 확산되는 알림에 대한 명시적 허용 목록, "보상 도착" 알림이 "보상 사용 가능" 알림을 취소하는 우선순위 규칙, 기기 간 해제 동기화. |
| 지속성 및 캐시 | 정규 저장소가 키-값 백엔드 대 localStorage인 경우에 대한 규칙, 마이그레이션 규칙, 배포 범위 서비스 워커 캐시, 실시간 상태를 읽는 경로에 대한 명시적 동적 옵트아웃. |
| UI 및 라이프사이클 | 페이지 준비 게이트, 일시적 영값이 알려진 잔액을 대체하는 것을 방지하는 단조 하한선, 콜드 페치 기간 동안의 스켈레톤 렌더링 규칙. |
| 프로세스 및 도구 | 명시적 기능 출시 동의 규칙, 알림 표면 변경에 대한 전체 테스트 실행, 서버 측 코드의 구조화된 로깅, 지름길 스타일 수정에 대한 검토 규칙. |
대표적인 규칙 몇 가지
이것들은 레지스트리의 특성을 보여주는 공개 안전 요약입니다. 이들은 의역되고 축약되었으며, 정규 텍스트는 코드 옆에 있습니다.
온체인 읽기를 위한 단일 소스 오브 트루스
스마트 컨트랙트에서 읽은 모든 값(청구 가능한 보상, 잔액, 스테이킹 상태, 에포크 데이터, 가격 등)은 서비스 레이어의 정확히 하나의 함수로 계산됩니다. 해당 값이 필요한 모든 기능은 동일한 함수를 가져옵니다. 두 함수가 동일한 값을 계산하면 그 중 하나는 잘못된 것이므로 규칙은 세 번째를 추가하는 것이 아니라 하나를 삭제하는 것입니다.
세션 검증을 위한 단일 병목
FlareWatch의 모든 인증된 경로는 단일 헬퍼를 통해 세션 쿠키를 검증합니다. 어떤 경로 핸들러도 독립적으로 세션 토큰을 검증하지 않습니다. 이 불변성은 서버 측 취소를 보편적으로 만드는 것이며, 검사를 우회하는 우회 경로가 없습니다.
양쪽의 지갑별 소유권 게이팅
지갑별 경로는 클라이언트 측이 아닌 서버 측에서 소유권을 검증합니다. 원래 감사는 클라이언트 측 게이트를 닫았지만 서버 측 엔드포인트는 완전히 게이팅되지 않은 이전 작업 때문에 이 규칙을 설정했습니다. 두 부분은 이제 별도의 명시적 결과물로 추적됩니다(클라이언트에서 닫힘, 서버에서 닫힘). 이는 그러한 실패 모드가 다시 발생하는 것을 방지합니다.
중앙 집중식 포매터 사용, 인라인 금지
모든 숫자, 통화 및 날짜 포매팅은 소수의 중앙 집중식 헬퍼를 통해 이루어집니다. 어떤 컴포넌트도 인라인으로 포매팅하지 않습니다. 이 규칙은 스타일과는 무관합니다. 단일 로케일 또는 통화 정의가 변경되면 애플리케이션의 모든 표면이 이와 함께 업데이트됩니다. 표면 간의 편차는 자동으로 감지되지 않으며 사용자가 발견할 때까지 감지하기 어렵습니다.
단위 변환은 양쪽에 문서화됨
시스템의 두 부분이 단위가 모호할 수 있는 값(초 대 밀리초, 소수점 대 백분율, 소문자 대 체크섬 주소)을 교환할 때, 규칙은 생산자와 소비자 양쪽에 문서화됩니다. 한쪽 끝에만 작성된 주석은 부패합니다. 양쪽 끝에서 주장되는 경계 계약만 리팩터링을 견딥니다.
사용자 작업당 하나의 구현
모든 사용자가 시작한 작업(지갑 감시 추가, 세금 요율 변경, 알림 무시, 로그아웃)은 정확히 하나의 구현을 갖습니다. 이 규칙이 존재하는 이유는 UI의 다른 부분에서 트리거된 작업이 미묘한 방식으로 드리프트하곤 했기 때문입니다. 한 진입점은 캐시를 지우지만 다른 진입점은 그렇지 않으며, "작업 X 후 부실 값" 버그 클래스가 발생했습니다.
음성으로 실패해야 하는 실패 모드
일부 실패 모드는 본질상 자동으로 진행됩니다(잘못 분류된 보상, 알림을 무시하는 단위 불일치, 키-값 저장소에 도달하지 않는 무시 기록). 가능한 한 레지스트리는 이러한 값의 생산자가 계약을 충분히 음성으로 선언하여 향후 변경으로 인해 이를 위반하면 프로덕션에 도달하기 전에 테스트에서 잡음이 크게 나도록 요구합니다.
레지스트리가 진화하는 방식
- 새로운 안전장치. 버그 클래스가 반복되거나 단일 버그가 영구적인 규칙을 정당화할 만큼 비용이 많이 들 때 추가됩니다.
- 대체된 안전장치. 레지스트리에 "superseded" 마커와 교체 항목에 대한 포인터와 함께 유지되므로 코드의 과거 참조가 계속 해석 가능합니다.
- 작업 노트에서 승격됨. 일부 안전장치는 세션 인계 문서에서 비정식 규칙으로 시작되었으며 그 중요성이 입증되면 레지스트리로 승격됩니다.
- 분기별 검토. 임시 lint 예외 및 "다음 분기까지 할 일" 마커는 분기별로 확인됩니다. 기한이 경과한 모든 항목은 해결되거나 명시적으로 연장됩니다.
이것이 공개된 이유
FlareWatch는 내부 레지스트리 전체가 아닌 이 개요를 공개하는 이유는 두 가지입니다.
- 내부 레지스트리에는 팀과 코드 접근 권한이 있는 보안 검토자에게 유용한 코드 레벨 세부 정보(파일 경로, 키-값 스키마 이름, 사건 타임스탬프)가 포함되어 있지만 그러한 접근 권한 없이는 공개하기에 적절하지 않습니다.
- 카테고리와 규율이 실제 이야기입니다. 보조금 검토자나 FlareWatch를 평가하는 보안 연구자는 프로젝트가 어떤 종류인지, 정확성을 얼마나 진지하게 받아들이는지, 작업 루프가 어떻게 작동하는지를 알고 싶어합니다 — 규칙 #91이 어느 파일에 있는지가 아닙니다.
특정 안전장치에 대해 논의하거나 새로운 안전장치를 제안하거나 격차를 보고하고 싶은 연구자는 [email protected]로 연락할 수 있습니다..