금보원, 금융권 SW 공급망 보안 플랫폼 구축…SBOM·취약점 관리 결합

오픈소스와 외부 상용 소프트웨어(SW) 의존이 커지면서 금융권에서도 ‘패치 갭(취약점이 공개된 뒤 보안패치가 적용될 때까지의 시간 차이)’이 사고 위험을 키우는 변수로 떠올랐다.

금융보안원(원장 박상원)은 금융권 취약점 대응 과정을 티켓(업무 단위별 담당·기한·진행상황을 남기는 표준 기록) 중심으로 재구성한 ‘금융권 소프트웨어 공급망 보안 플랫폼’을 2월부터 본격 가동한다.

금융보안원이 이번 플랫폼으로 기대하는 변화는 단순히 취약점 정보를 알리는 ‘공지’에 그치지 않는다. 취약점이 발견된 이후 금융회사와 개발사, 보안 담당자 사이에서 정보가 어떻게 전달되고, 누가 언제 어떤 조치를 했는지까지 이어지는 대응의 흐름 전체를 관리하는 구조를 만드는 데 초점을 맞췄다. 취약점이 나오면 금융사와 개발사가 메일·전화로 산발적으로 확인하던 과정을, 발견부터 조치 확인까지 한 줄로 연결했다는 설명이다.

신지미 금융보안원 SW공급망보안팀 팀장은 “기존에는 유선 중심으로 정보가 오가 체계적으로 관리하기 어려웠다”며 “금융사와 개발사가 정보를 같은 틀로 받아 관리하도록 플랫폼을 만들었다”고 말했다. 변진용 금융보안원 SW공급망보안팀 수석은 “취약점 패치의 개발부터 적용까지 전 과정을 원스톱으로 지원해 패치 갭을 줄이는 구조”라고 설명했다.

‘대시보드’가 아니라 ‘프로세스’…운영 절차 표준화

플랫폼의 핵심은 화면이 아니라 절차다. 금융보안원은 취약점이 확인되면 ▲접수·분류 ▲영향 분석 ▲개발사 패치 개발·배포 ▲금융사 적용 ▲조치 확인·이력화 순으로 흘러가도록 설계했다.

금융권에서는 취약점이 생길 때마다 연락망이 복잡해진다. 금융사 수백곳이 각각 다른 제품·버전을 쓰고, 한 금융사가 여러 개발사와 동시에 연결된다. 금융보안원은 이 구조를 다대다(N대N) 관계로 본다. 확인이 늦어지면 패치 전파도 늦어진다. 조치 여부도 흐려진다. 금융보안원은 티켓으로 묶어 추적하면 전파 속도와 확인 정확도를 끌어올릴 수 있다고 본다.

플랫폼의 3가지 축은 ‘취약점 통합관리·SBOM·버그바운티’

플랫폼은 크게 세 축으로 구성된다. 먼저 취약점 정보를 한 곳으로 모아 관리하기 쉽게 공유하는 데서 출발한다. 버그바운티로 접수된 취약점에는 제보자 정보나 재현 방법처럼 민감한 내용이 섞일 수 있다.

변진용 금융보안원 SW공급망보안팀 수석은 “화이트해커의 정보는 금융사가 알면 안 되는 영역이 있어, 중간에서 필요한 정보만 전달한다”고 설명했다. 금융사는 티켓으로 사용 여부와 조치 상태를 남긴다. 플랫폼은 그 이력을 누적해 같은 제품에서 유사한 취약점이 나올 때 확인 속도를 높이는 기반으로 삼는다.

여기에 소프트웨어 자재명세서(SBOM) 도구를 적용해 영향의 범위를 파악한다. SBOM은 소프트웨어를 구성하는 부품(라이브러리·모듈)과 공급자, 의존 관계를 정리한 목록이다. 금융보안원은 이를 ‘소프트웨어의 DNA’로 설명한다. 취약점이 공개되면 SBOM을 기준으로 어떤 시스템이 영향을 받는지 더 빠르게 가늠할 수 있다는 취지다.

금융보안원은 대표적인 SBOM 국제표준인 ‘소프트웨어 패키지 데이터 교환(SPDX)’, ‘사이클론디엑스(CycloneDX)’ 형식을 지원한다고 밝혔다. 공공 영역에서는 국정원이 SBOM 기본 항목인 NIS-SBOM을 제시해 왔다. 국정원은 SBOM 항목 표준화를 추진하면서 SBOM 정보를 자동 분석하는 시스템 개발도 추진한다고 밝힌 바 있다. 금융보안원은 구축 상황에 따라 추후 NIS-SBOM도 플랫폼에 반영하려고 검토하고 있다.

버그바운티는 ‘발견’을 ‘조치’로 연결하는 경로로 설계했다. 버그바운티는 취약점을 찾아 신고한 사람에게 포상금을 지급하는 제도다. 금융보안원은 이를 통해 ‘제로데이 취약점(알려지지 않은 취약점)’을 조기에 확보하고, 보안 사각지대를 줄이겠다는 목표를 세웠다. 플랫폼은 제보가 들어오면 검증을 거쳐 개발사와 패치 일정을 조율하고, 이후 금융권에 전파하는 흐름을 한 경로로 묶었다.

운영은 ‘중요 취약점’부터…금융사 참여가 중요

금융보안원은 모든 자산을 한 번에 관리하는 접근을 전제하지 않았다. 중요 취약점과 중요 자산을 중심으로 등록하고, 이에 대한 알림 서비스를 운영한다. 이후 운영 데이터를 쌓아 범위를 넓히는 방식이다.

다만 플랫폼이 작동하려면 참여가 필요하다. 금융사는 사용 제품과 조치 상태를 입력해야 한다. 개발사는 패치 진행 상황을 올려야 한다. 입력이 줄면 이력 추적도 약해진다. 금융보안원은 이 점을 중점으로 보고 있다. 신 팀장은 “운영하면서 실무협의체로 의견을 수렴하고, 필요성이 큰 기능부터 차차 고도화할 예정”이라고 설명했다.

보안 취약점 정보는 식별자가 있어야 널리 공유된다. 대표 체계가 ‘공통 취약점 및 노출(CVE)’ 이다. 버그바운티로 접수되는 취약점은 초기에는 CVE가 없는 경우가 적지 않다. 이런 경우 플랫폼 내부 식별로 먼저 관리한다. 이후 패치 일정과 공개 시점을 조율해 등록 절차로 넘어간다. 이 과정에서 중요한 개념이 조율된 취약점 공개(CVD)다. 제보자와 개발사, 이해관계자가 패치 준비 전 과도한 정보 확산을 막고 공개 시점을 맞춰 피해를 줄이는 절차다.

최근에는 CVE 체계에 대한 의존을 낮추려는 움직임도 나타난다. 유럽을 중심으로 GCVE(글로벌 CVE 할당 체계)가 등장했다. GCVE는 기존 CVE와의 호환을 표방하면서, ‘GNA(번호 부여 기관)’가 중앙 승인 절차 없이 식별자를 배정하는 탈중앙 방식을 제시한다. 금융권 플랫폼이 취약점 정보를 더 넓게 연동하려면, 어느 식별체계를 어떤 원칙으로 받아들일지 운영 기준을 정교하게 세워야 한다는 의미다. 이런 상황에서, 금융보안원은 GCVE의 흐름도 주시하고 있다.

‘특정 도구 권장’ 문제 제기에 “종속 구조 아냐, 표준이면 수용”

한편, 금융보안원의 이번 플랫폼이 자율을 표방하면서도 특정 업체 기반 분석 도구를 사실상 권장한다는 문제 제기에 대해, 금융보안원은 “특정 도구에 종속되는 구조가 아니다”라고 답했다. SBOM은 SPDX, 사이클론디엑스 등 국제표준 형식을 지원하며, 별도의 독자 포맷을 요구하지 않는다는 것이다.

소스코드 제출 권장으로 부담이 커질 수 있다는 지적에는 제출은 선택이라는 입장을 강조했다. 금융보안원은 소스코드, 바이너리(실행파일), 메타데이터, 타 도구로 생성한 SBOM 등 다양한 방식의 제출을 열어두고 있다. 소스코드 또는 메타데이터 제출을 언급한 것은 분석 정확도를 높이기 위한 선택지라는 설명이다.

중복 운영 부담 우려에 대해서는 플랫폼이 오히려 ‘공통 추적’의 기반이 된다고 봤다. 금융보안원은 티켓 기반으로 조치 상태를 남기고, 패치 진행상황을 금융권에 일괄 전파하는 구조가 필요하다는 점을 이유로 들었다.

금융보안원은 SBOM 제출 의무화 논의가 본격화되면, 현장의 혼선이 커질 수 있다는 점도 염두에 뒀다고 설명했다. 신 팀장은 “당장은 의무화가 아니라 지원 플랫폼으로 운영한다”며 “다만 향후 제도 요구가 커질 때 금융사들이 대응 체계를 갖추도록 미리 기반을 마련해 두자는 취지”라고 강조했다.

금융보안원은 이번 플랫폼을 통해 금융사가 자사 SW 취약점 현황과 영향 범위를 더 빠르게 파악하고, 대응 우선순위를 합리적으로 세우도록 지원할 계획이다.

글. 바이라인네트워크
<곽중희 기자>god8889@byline.network