식별: 쓰고 있는 오픈소스를 빠짐없이 찾기
Categories:
식별은 관리의 출발점이다. 무엇을 쓰는지 모르면 취약점도 라이선스 의무도 관리할 수 없다. FSEC 안내서의 첫 절차이고, ISO/IEC 5230의 SBOM 관리(3.3.1)가 요구하는 활동이다.
여기서 만드는 문서: SBOM, 운영 자산 인벤토리.
무엇을 식별하는가
오픈소스를 식별한다는 것은 세 종류를 모두 찾아낸다는 뜻이다.
- 신규로 들여오는 오픈소스. 개발자가 새로 도입하는 라이브러리와 그 의존성.
- 이미 운영 중인 시스템에 들어 있는 오픈소스. 도입 시점에 기록하지 못한 레거시.
- 외주 개발사나 전자금융보조업자가 만든 산출물에 포함된 오픈소스. 외주 개발사(업무를 위탁받은 수탁자)와 전자금융보조업자(전자금융거래법상 금융회사를 위해 전자금융거래를 보조하는 자)는 법적으로 다른 범주지만, 산출물의 오픈소스를 식별해야 한다는 점은 같다.
직접 선언한 의존성만이 아니라 그것이 끌어오는 전이 의존성까지 펼쳐야 한다. 실제 위험은 대부분 직접 보지 않는 하위 의존성에 숨어 있다.
금융권에서는 여기에 규제 근거가 붙는다. 2025-02-05 개정 전의 전자금융감독규정 제21조는 정보처리시스템 구축과 전자금융거래 계약에서 제품의 소유권, 저작권, 지식재산권 귀속을 명확히 하도록 명시했고, FSEC 안내서도 이를 근거로 안내한다. 개정된 현행 제21조는 이를 포함한 계약 관련 내부통제 절차의 수립과 운용을 요구한다. 오픈소스의 출처와 라이선스를 식별하는 일은 이 요구를 충족하는 첫걸음이다. [FSEC 안내서]
SBOM 작성과 기록
식별 결과는 SBOM(Software Bill of Materials)으로 기록한다. SBOM은 소프트웨어를 구성하는 모든 오픈소스 컴포넌트와 그 버전, 라이선스, 의존 관계를 담은 목록이다. 표준 형식으로는 SPDX와 CycloneDX가 널리 쓰인다. [ISO 요구]
SBOM 작성에는 Syft, cdxgen, OSV-SCALIBR 같은 오픈소스 도구를 쓸 수 있다. 모두 온프레미스로 설치 가능하고 표준 형식으로 출력한다. 도구 전체 목록은 도구 페이지에서 다룬다. SBOM을 만들고 관리하는 절차는 ISO/IEC 5230의 SBOM 관리(3.3.1.1)와 컴포넌트 기록(3.3.1.2) 입증자료가 된다.
폐쇄망에서는 오픈소스를 반입하는 단계에서 SBOM을 만들어 사내 미러에 함께 등록한다. 이렇게 하면 무엇이 어떤 버전으로 들어와 있는지 한곳에서 파악된다. 반입 절차와 사내 미러 구성은 폐쇄망 운영에서 다룬다.
운영 중인 시스템의 식별
신규 도입만 관리하면 절반만 보는 것이다. 이미 가동 중인 사내 시스템과 서버에도 오래전 도입한 오픈소스가 들어 있고, 그중 상당수는 도입 기록이 없다. 이 레거시를 SBOM으로 식별하는 일이 금융권에서 특히 중요하다. 운영 시스템의 취약점은 상시적 위험이기 때문이다.
운영 중인 시스템의 식별은 한 번으로 끝나지 않는다. 자산 인벤토리를 만들어 어떤 시스템에 어떤 오픈소스가 들어 있는지 지속적으로 갱신한다. 이 인벤토리는 지속 모니터링(관리)의 기반이 된다. [본 가이드 권고]
제3자와 외주 산출물 식별
FSEC 안내서는 전자금융보조업자가 사용하는 오픈소스의 식별을 점검 항목으로 둔다. 금융권은 외주 개발과 위탁이 많아, 내가 직접 도입하지 않은 오픈소스가 외주 산출물을 통해 들어온다. 이를 식별하지 못하면 관리 범위에 구멍이 생긴다. [FSEC 안내서]
방법은 외주 산출물에 SBOM 제출을 요구하는 것이다. 계약 단계에서 SBOM 제공을 의무로 넣고, 받은 SBOM을 검증한다. 계약과 제안요청서에 넣을 구체적 요구사항은 사용 승인에서 다룬다.
외주사가 제출한 SBOM은 그대로 믿지 말고 검증한다. 받은 SBOM이 실제 산출물과 일치하는지, 누락된 컴포넌트는 없는지 점검 도구로 다시 확인한다. 외주사가 SBOM을 만들 역량이 없다면, 산출물을 직접 스캔해 SBOM을 생성하는 방법을 병행한다.
공급망 보안 플랫폼과의 연계
금융보안원의 금융권 소프트웨어 공급망 보안 플랫폼이 2026년부터 본격 운영된다(개요는 가이드 개요 참고). 금융사는 이 플랫폼에 참여하기 위해 SBOM을 산출하고 제출하는 형식을 미리 갖춰 두는 것이 좋다.
해외에서는 미국과 유럽이 SBOM 제출 의무화를 진행 중이고, 국내 정부도 SW 공급망 보안 가이드라인 1.0(2024-05-13)을 통해 단계적 제도화 방향을 밝혔다. 정부는 2027년 공공부문 SBOM 제출 의무화를 목표로 추진하고 있어, 그 흐름이 금융권으로 확산될 전망이다. 현재 국내 금융권에 SBOM 제출이 일률적으로 의무화된 것은 아니지만, 이 흐름에 선제적으로 대비하는 것이 합리적이다. [본 가이드 권고]
처음 체계를 세우는 조직은 새로 도입하는 오픈소스부터 SBOM을 만들어 기록하기 시작하고, 표준 형식(SPDX 또는 CycloneDX) 하나를 정해 일관되게 쓴다.
이미 운영 중인 조직은 레거시 시스템까지 자산 인벤토리로 식별 범위를 넓히고, 외주 산출물에 SBOM 제출을 요구하며, 공급망 보안 플랫폼 제출 형식에 맞춰 SBOM 산출을 자동화한다.
FSEC 안내서·ISO 표준과의 연결
| 식별 활동 | ISO/IEC 5230 | FSEC 안내서 |
|---|---|---|
| 적용 범위 정의 | 3.1.4.1 프로그램 적용 범위 | 식별 |
| SBOM 작성·관리 | 3.3.1.1 SBOM 관리 절차 | 식별 |
| 컴포넌트 기록 | 3.3.1.2 오픈소스 컴포넌트 기록 | 식별 |
| 제3자·외주 식별 | 3.3.1.1 준용 | 식별(전자금융보조업자) |
SBOM 작성의 일반 실무와 도구 활용은 기존 기업 오픈소스 관리 가이드의 도구 섹션과 ISO/IEC 5230 준수 가이드의 SBOM 조항에서 더 자세히 다룬다.
금융결제원은 KWG 25차 정기 미팅(2025-03)에서 결제 인프라를 대상으로 ISO/IEC 5230:2020을 준수한 사례를 공유했다. 금융 결제 시스템의 오픈소스를 식별하고 관리 체계를 적용한 사례다.
출처: 유대열(금융결제원), “금융결제원의 ISO/IEC 5230:2020 준수 사례”, KWG 25차 미팅(2025-03) 발표자료.
최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.