금융분야 오픈소스 관리 실무 가이드 신설 (한국어)

content/ko/guide/finance-oss-guide/1-governance/_index.md

@@ -0,0 +1,118 @@
+---
+title: "거버넌스: 관리 조직과 승인 체계"
+linkTitle: "1. 거버넌스"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["금융", "오픈소스", "거버넌스", "OSPO", "OSRB"]
+description: >
+  금융권 오픈소스 관리 조직(OSPO)과 검토 위원회(OSRB)를 어떻게 구성하고 역할을 나누며,
+  법무·보안·기술이 함께 참여하는 승인 거버넌스를 어떻게 세우는지 다룬다.
+---
+
+{{% alert title="이 페이지의 위치" color="info" %}}
+거버넌스는 오픈소스 관리의 기반이다. 누가 책임지고, 누가 검토하며, 누가 승인하는지를 먼저
+정해야 식별, 사용 승인, 관리 단계가 작동한다. FSEC 안내서도 관리 절차에 앞서 관리 조직
+구성과 역할을 별도로 다룬다.
+
+여기서 만드는 문서: 오픈소스 정책, 역할·책임 목록과 담당자 지정 기록.
+{{% /alert %}}
+
+## 금융권 거버넌스의 출발점
+
+금융분야 오픈소스 소프트웨어 활용·관리 안내서(금융감독원·금융보안원, 2022, 이하 FSEC
+안내서)는 관리 조직의 구성과
+운영, 역할 사례를 제시한다. ISO/IEC 5230은 이를 입증자료로 요구한다. 문서화된 정책(3.1.1.1),
+역할과 책임 목록(3.1.2.1), 역할 담당자 명시(3.2.2.1), 법률 자문 접근 방법(3.2.2.3)이 그것이다.
+거버넌스는 이 입증자료들을 만들어 내는 활동이다.
+
+금융권은 여기에 두 가지 조건이 더 붙는다. 첫째, 법무·보안·기술이 분리된 큰 조직 구조에서
+오픈소스 결정을 누가 내리는지가 분명해야 한다. 둘째, 감독 검사와 내외부감사에 대비해 결정의
+근거와 책임 소재를 기록으로 남겨야 한다.
+
+## 오픈소스 프로그램 조직(OSPO)
+
+오픈소스 프로그램 조직(OSPO, Open Source Program Office)은 오픈소스 활용과 관리를 총괄하는
+조직이다. 전담 부서를 두는 큰 회사도 있고, 기존 보안·개발 조직에 역할을 겸하게 하는 회사도
+있다. 규모가 어떻든 책임과 권한은 한곳에 모여야 한다. **[FSEC 안내서]**
+
+OSPO가 맡는 역할은 다음과 같다.
+
+- 오픈소스 정책을 수립하고 갱신한다.
+- 오픈소스 사용 승인 절차를 운영하고 검토 위원회를 소집한다.
+- 식별·취약점·라이선스 관리에 쓰는 도구와 절차를 책임진다.
+- 감사와 감독 검사에 필요한 증적을 관리한다.
+- 법무·보안·개발 부서 사이의 협의를 조정한다.
+
+역할을 정하면 담당자의 이름과 연락처, 지정일을 문서로 남긴다. 이것이 ISO/IEC 5230의 역할
+담당자 명시(3.2.2.1)와 ISO/IEC 18974의 참여자 목록·역할 매핑(4.1.2.3) 입증자료가 된다.
+**[ISO 요구]**
+
+{{% alert title="신설 조직이 먼저 할 일과 운영 조직의 고도화" color="success" %}}
+처음 체계를 세우는 조직은 전담 부서를 갖추기 어렵다. 먼저 오픈소스 관리의 단일 책임자를
+지정하고, 법무·보안·개발에서 한 명씩 겸임으로 참여하는 최소 구성으로 시작한다. 역할과
+담당자를 문서로 남기는 것만으로도 ISO 입증자료 요건을 충족한다.
+
+이미 운영 중인 조직은 역할별 필요 역량을 정의하고, 정기적으로 조직 구성과 역할을 검토해
+변경 이력을 남기며, 성과 지표로 프로그램의 효과를 측정한다.
+{{% /alert %}}
+
+## 오픈소스 검토 위원회(OSRB)
+
+오픈소스 검토 위원회(OSRB, Open Source Review Board)는 오픈소스 도입과 사용을 검토하고
+승인하는 협의 기구다. 금융권에서 특히 중요한 이유는, 오픈소스 도입 결정에 라이선스 위험,
+보안 취약점, 운영 영향이 함께 걸려 있어 한 부서가 단독으로 판단하기 어렵기 때문이다.
+
+위원회는 보통 다음 관점을 함께 본다.
+
+- 법무: 라이선스 의무와 계약·지식재산권 위험.
+- 보안: 취약점, 공급망 위험, 유지보수 상태.
+- 기술·개발: 기술 적합성, 대체 가능성, 운영 부담.
+
+위원회의 결정과 그 근거를 기록으로 남긴다. 이 기록은 사용 승인 단계(4번 섹션)의 핵심 증적이며,
+감사 대응(5번 섹션)에서 다시 쓰인다. 위원회를 매번 소집하기 어렵다면 위험 수준별로 검토를
+차등한다. 구체적 방법은 [사용 승인](../4-approve/)에서 다룬다. **[본 가이드 권고]**
+
+## 법률 자문과 예산
+
+ISO/IEC 5230은 법률 자문에 접근하는 방법(3.2.2.3)과 인원 배치 및 예산 확인(3.2.2.2)을 입증자료로
+요구한다. 금융권은 사내 법무 조직이 있는 경우가 많으므로, 오픈소스 라이선스 사안을 어느
+경로로 법무에 올리는지를 정해 문서로 남긴다. 외부 전문 자문이 필요한 사안의 판단 기준도
+함께 정한다. **[ISO 요구]**
+
+예산은 도구 구축과 운영, 교육, 외부 자문에 든다. 신설 조직은 오픈소스 도구가 대부분
+오픈소스이고 온프레미스로 설치 가능하다는 점을 활용해 초기 비용을 낮출 수 있다. 도구
+선택은 [폐쇄망 운영](../0-closed-network/#폐쇄망에-맞는-도구-선택)과 [관리](../5-manage/)에서 다룬다.
+
+{{% alert title="제3자·외주 적용 시" color="info" %}}
+전자금융보조업자나 외주 개발사가 만든 산출물에 포함된 오픈소스도 거버넌스의 대상이다.
+위원회는 외주 계약에 오픈소스 관리 요구사항(SBOM(Software Bill of Materials) 제출, 라이선스
+고지, 취약점 대응)을 넣을지
+판단하고, 그 책임을 누가 지는지 정한다. 계약과 제안요청서 관리는 [사용 승인](../4-approve/)에서
+구체적으로 다룬다.
+{{% /alert %}}
+
+## FSEC 안내서·ISO 표준과의 연결
+
+| 거버넌스 활동 | ISO/IEC 5230 | ISO/IEC 18974 | FSEC 안내서 |
+|------|------|------|------|
+| 정책 수립·전파 | 3.1.1.1 정책, 3.1.1.2 전파 절차 | — | 거버넌스 |
+| 역할·책임 정의 | 3.1.2.1 역할·책임 목록 | 4.1.2.3 참여자·역할 매핑 | 거버넌스 |
+| 담당자 명시 | 3.2.2.1 담당자 문서 | — | 거버넌스 |
+| 법률 자문 접근 | 3.2.2.3 법률 자문 방법 | — | 거버넌스 |
+| 예산·인원 배치 | 3.2.2.2 인원·예산 확인 | — | 기타 |
+| 미준수 검토·수정 | 3.2.2.5 미준수 검토 절차 | — | 기타 |
+
+조직과 역할의 일반 실무는 기존 [기업 오픈소스 관리 가이드의 조직 섹션](../../opensource_for_enterprise/1-teams/)에서
+더 자세히 다룬다. 이 페이지는 그 위에 금융권의 검토 위원회와 감사 대비 기록을 더한 것이다.
+
+{{% alert title="현장 사례 — 카카오뱅크의 ISO/IEC 5230 인증" color="success" %}}
+카카오뱅크는 KWG 13차 정기 미팅(2022-03)에서 ISO/IEC 5230 인증 사례를 공유했다. 금융권
+규제 환경에서 오픈소스 관리 체계를 세우고 인증까지 이른 거버넌스 구축 사례다.
+
+출처: 하헌관·이민애(카카오뱅크), 13차 공동 세션 "카카오와 카카오뱅크의 ISO/IEC 5230 인증 사례 공유" 중 카카오뱅크 발표분, [KWG 13차 미팅(2022-03) 발표자료](https://github.com/OpenChain-Project/OpenChain-KWG/releases/download/meeting-slides-2022/KakaoBank_ISO_IEC_5230_certification_case.pdf).
+{{% /alert %}}
+
+---
+
+*최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.*

content/ko/guide/finance-oss-guide/2-identify/_index.md

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