Firmachain v0.5.1-patch2: 네트워크를 멈추지 않고 보안 패치를 배포하다
2026년 1월, CometBFT의 BFT Time 구현에 관한 중요 보안 취약점 CSA-2026-001이 공개되었다. Firmachain은 공개 일정에 맞춰 패치된 CometBFT를 반영한 v0.5.1-patch2를 준비했다. 빠른 대응이 필요했지만, 서두르는 것만으로는 충분하지 않았다. 검증자가 체인을 멈추거나 거버넌스 업그레이드를 거치지 않고도 안전하게 적용할 수 있는 릴리스가 되어야 했다.
취약점과 대응 원칙
CSA-2026-001은 CometBFT의 합의 계층에서 블록 타임스탬프에 영향을 줄 수 있는 취약점이었다. 블록 시간은 체인 내부의 여러 모듈과 스마트 컨트랙트가 참조할 수 있기 때문에, 문제의 영향이 합의 엔진 한 곳에만 머문다고 볼 수 없었다. 공식 패치 버전으로 올리는 것이 필요한 대응이었다.
보안 이슈에서는 변경 범위를 불필요하게 넓히지 않는 것이 중요하다. 이번 릴리스의 원칙을 다음과 같이 정했다.
- CometBFT의 공식 수정사항만 필요한 범위에서 반영한다.
- 체인 프로토콜 버전은 v0.5.1로 유지한다.
- 업그레이드 높이나 거버넌스 제안 없이 교체 가능한 바이너리 패치로 제공한다.
- 로컬, 개발망과 테스트넷에서 운영에 가까운 경로를 확인한 뒤 공개한다.
맡은 역할
- 소프트웨어 엔지니어 및 개발팀 리드
- 보안 패치 릴리스 오너
- 브랜치와 PR, 테스트 계획 및 릴리스 노트 조율
- 검증자와 풀노드 운영자를 위한 적용 절차 정리
기간: 2026년 1월
최소 변경으로 패치하기
Firmachain의 CometBFT 의존성을 v0.38.18에서 패치가 적용된 v0.38.21로 올렸다. Firmachain 바이너리는 v0.5.1-patch에서 v0.5.1-patch2로 변경했지만 체인 버전은 v0.5.1을 유지했다. 합의 상태를 바꾸는 기능 업그레이드가 아니었기 때문에 특정 블록 높이에서 모든 노드가 동시에 전환할 필요가 없었다.
이 선택은 단순히 배포를 쉽게 만들기 위한 것이 아니었다. 보안 수정과 무관한 변경을 제외하면 검증해야 할 범위가 분명해지고, 운영자가 기존 설정을 유지한 채 새 바이너리를 적용할 수 있다. 긴급한 상황일수록 무엇을 바꾸지 않는지를 명확히 하는 것이 위험을 줄였다.
운영 경로를 중심으로 한 검증
보안 패치는 빨리 배포해야 하지만, 검증되지 않은 바이너리가 운영 체인에 새로운 장애를 만들 수도 있다. 그래서 환경별로 실제 운영자가 거치는 경로를 중심으로 확인했다.
- 로컬: 단위 테스트와 CLI 명령 검증
- 개발망: 단위 테스트, CLI 및 E2E 테스트
- Imperium-4 테스트넷: 스마트 컨트랙트 트랜잭션과 state sync 검증
특히 스마트 컨트랙트 실행과 state sync를 릴리스의 중요한 확인 항목으로 두었다. 합의 엔진이 정상적으로 시작된다는 사실만으로는 충분하지 않았다. 기존 애플리케이션 기능이 계속 동작하고, 새로운 노드가 네트워크 상태를 받아 운영에 참여할 수 있어야 했다.
테스트 결과와 적용 방법은 릴리스 노트와 운영 가이드에 연결했다. 검증자가 자신의 일정에 맞춰 바이너리를 교체하고 문제가 생겼을 때 확인할 지점을 알 수 있도록, 개발팀 내부의 판단을 운영자가 실행할 수 있는 정보로 바꾸는 과정도 릴리스의 일부였다.
롤링 업그레이드
v0.5.1-patch2는 네트워크 전체가 같은 순간에 멈추는 방식이 아니라 각 검증자와 풀노드가 순차적으로 바이너리를 교체하는 롤링 업그레이드로 배포할 수 있었다. 업그레이드 높이와 거버넌스 제안이 필요하지 않았고, 운영자는 준비되는 시점에 새 버전을 적용할 수 있었다.
그 결과 네트워크를 중단하지 않으면서도 필수 보안 수정사항을 빠르게 확산시킬 수 있었다. 변경의 긴급성과 운영 안정성을 서로 반대되는 목표로 두지 않고, 패치의 범위와 배포 방식을 조정해 함께 만족시키려 했다.
배운 점
이번 대응은 보안 릴리스에서 속도와 신뢰가 어떻게 함께 만들어지는지를 보여주었다. 빠른 릴리스는 테스트를 줄이는 데서 나오지 않았다. 변경 범위를 최소화하고, 위험한 경로를 먼저 정하며, 개발과 검증자 커뮤니케이션을 병렬로 준비했기 때문에 가능했다.
또한 분산 네트워크의 보안은 개발팀이 패치된 코드를 공개하는 순간 끝나지 않는다. 독립적으로 운영되는 노드들이 수정사항의 필요성을 이해하고 실제로 적용해야 비로소 네트워크의 위험이 줄어든다. 릴리스 엔지니어링은 바이너리를 만드는 작업이면서, 여러 운영자가 안전하게 같은 방향으로 움직일 수 있게 만드는 조율의 작업이었다.
기술과 관련 링크
- 메인넷: Cosmos 기반 Firmachain Colosseum
- 합의 엔진: CometBFT v0.38.21
- 릴리스 방식: 체인 버전 v0.5.1을 유지하는 비파괴적 바이너리 패치
- Firmachain v0.5.1-patch2 릴리스 노트
- CSA-2026-001 보안 권고
- CometBFT v0.38.21
기술: Cosmos 기반 메인넷, CometBFT, 보안 패치, 릴리스 엔지니어링, 네트워크 안정성