금융분야 오픈소스 관리 실무 가이드

• 1: 폐쇄망 운영과 망분리 전환
• 2: 거버넌스: 관리 조직과 승인 체계
• 3: 식별: 쓰고 있는 오픈소스를 빠짐없이 찾기
• 4: 이슈 파악과 해결: 취약점과 라이선스
• 5: 사용 승인: 무엇을 어떤 근거로 허용하는가
• 6: 관리: 사내 운영 시스템의 지속 점검과 감사 대응
• 7: 자가점검: 우리 체계의 빈 곳 찾기
• 8: 산출물: 바로 쓰는 양식과 레시피
• 8.1: 자가점검 워크북
• 8.2: 정책·절차 템플릿
• 8.3: 감사 증적 목록
• 8.4: 도구 구축 레시피

flowchart LR
    P0["0. 폐쇄망 운영<br>(공통 전제)"] --> P1["1. 거버넌스<br>(관리 조직)"]
    P1 --> P2["2. 식별"]
    P2 --> P3["3. 이슈<br>파악·해결"]
    P3 --> P4["4. 사용 승인"]
    P4 --> P5["5. 관리<br>(지속 모니터링)"]
    P5 --> P6["6. 자가점검"]
    P6 -. "부족한 단계로 돌아가 보완" .-> P2

    style P0 fill:#2d3748,color:#fff
    style P1 fill:#2d3748,color:#fff
    style P2 fill:#2b6cb0,color:#fff
    style P3 fill:#2b6cb0,color:#fff
    style P4 fill:#2b6cb0,color:#fff
    style P5 fill:#2b6cb0,color:#fff
    style P6 fill:#276749,color:#fff

1 - 폐쇄망 운영과 망분리 전환

왜 폐쇄망을 먼저 다루는가

일반적인 오픈소스 실무는 인터넷 연결을 전제한다. 패키지 관리자로 의존성을 내려받고, 온라인 취약점 데이터베이스를 조회하며, 클라우드 기반 스캐너를 쓴다. 금융권의 중요 업무망과 핵심 시스템에서는 이 전제가 성립하지 않는다. 외부 통신이 차단된 환경에서는 오픈소스를 들여오는 일 자체가 통제 대상이 되고, 취약점 정보를 어떻게 얻을지가 먼저 풀어야 할 문제가 된다.

금융분야 오픈소스 소프트웨어 활용·관리 안내서(금융감독원·금융보안원, 2022, 이하 FSEC 안내서)는 관리 절차를 식별, 이슈 파악 및 해결, 사용 승인, 관리 네 단계로 제시한다. 그러나 폐쇄망에서는 “식별"보다 앞서 “어떻게 들여올 것인가"라는 관문을 먼저 통과해야 한다. 이 가이드가 폐쇄망을 0번 섹션으로 끌어올린 이유다.

함께 다뤄야 할 두 가지 현실

폐쇄망을 “고정된 물리적 망분리"로만 전제하면 가이드가 곧 낡는다. 규제 환경이 전환 중이기 때문이다. 금융위원회는 금융분야 망분리 개선 로드맵(2024-08-13)을 발표했고, 이어 전자금융감독규정과 시행세칙 개정이 2025-02-05에 시행됐다. 이 개정으로 오랫동안 유지되던 물리적 망분리 중심 규제가 자율보안·위험기반 접근으로 바뀌기 시작했다. 고유식별정보와 개인신용정보를 처리하지 않는 연구·개발 목적 업무는 금융회사가 자체 위험평가와 망분리 대체 정보보호통제 적용, 정보보호위원회 승인을 거쳐 망분리 예외를 적용할 수 있다. 내부 업무망에서 클라우드 기반 응용소프트웨어(SaaS, Software as a Service)를 쓰는 범위 확대 등 그 밖의 완화는 로드맵의 후속 단계로 추진 중이다.

따라서 금융권 담당자는 두 현실을 동시에 안고 일한다.

첫째, 중요 업무와 핵심 시스템에는 폐쇄망이 그대로 남아 있다. 반입 통제, 사내 미러, 오프라인 취약점 관리가 여전히 필요하다.

둘째, 연구·개발 등 예외가 열린 영역에서는 망분리 없이 일할 수 있게 됐다. 다만 규제 완화가 통제 면제를 뜻하지는 않는다. 망분리에 기대 자동으로 보호받던 부분을, 이제는 스스로 위험을 평가하고 통제를 설계하고 그 이행을 입증해야 한다. 책임이 규칙 준수에서 자율 입증으로 옮겨 갔다.

반입 통제

폐쇄망에서 오픈소스를 들여오는 경로는 외부 구간에서 받아 검증하고 격리한 뒤 망연계 시스템(망간 자료전송)으로 내부망에 이관하는 흐름이다.

flowchart LR
    subgraph EXT["외부 구간 (인터넷 연결)"]
        A["공식 배포처에서 수령"] --> B["무결성 검증<br>(체크섬 대조)"]
        B --> C["SBOM 생성<br>취약점 사전 점검"]
    end
    C --> D["반입 묶음 구성<br>악성코드 검사"]
    D --> E["망간 자료전송"]
    subgraph INT["내부망"]
        F["해시 재확인<br>결과 검토"] --> G["사내 미러 등록"]
        G --> H["반입 승인 기록<br>(감사 증적)"]
    end
    E --> F

    style EXT fill:#f7fafc,stroke:#a0aec0
    style INT fill:#f7fafc,stroke:#a0aec0
    style D fill:#744210,color:#fff
    style E fill:#2d3748,color:#fff
    style H fill:#276749,color:#fff

반입 절차는 다음을 포함한다.

• 무결성 검증: 내려받은 산출물의 해시값을 공식 배포처가 게시한 값과 대조한다.
• 악성코드 검사: 반입 구간에서 백신·악성코드 검사를 거친다.
• 구성요소 식별: 들여오는 산출물의 구성요소를 SBOM(Software Bill of Materials)으로 기록한다. 이 SBOM은 ISO/IEC 5230의 SBOM 관리(§3.3.1)가 요구하는 입증자료가 된다. [ISO 요구]
• 반입 승인 기록: 누가 무엇을 왜 반입했는지, 검증 결과와 함께 남긴다. 이 기록은 감사 증적이 된다.

반입 절차 예제

한 라이브러리를 외부 구간에서 받아 내부망으로 옮기는 과정을 예로 든다. 도구 이름은 예시이며, 조직이 이미 쓰는 동급 도구로 바꿔도 된다.

외부 구간(인터넷 연결 가능 구역)에서 산출물을 받고 무결성을 확인한다.

# 1) 공식 배포처에서 산출물과 서명·체크섬을 함께 받는다
curl -LO https://example.org/lib/foo-1.2.3.tar.gz
curl -LO https://example.org/lib/foo-1.2.3.tar.gz.sha256

# 2) 게시된 해시와 대조해 무결성을 검증한다
sha256sum -c foo-1.2.3.tar.gz.sha256

# 3) 반입 단위의 구성요소를 SBOM으로 기록한다 (CycloneDX 형식)
syft foo-1.2.3.tar.gz -o cyclonedx-json > foo-1.2.3.sbom.json

# 4) 외부 구간에서 취약점을 미리 점검해 결과를 함께 반입 대상에 포함한다
grype sbom:foo-1.2.3.sbom.json -o json > foo-1.2.3.vuln.json

이 단계의 SBOM은 반입하는 산출물 자체를 식별하는 기록이다. 단일 소스 묶음에는 그 라이브러리가 의존하는 다른 컴포넌트가 동봉되지 않으므로, 전이 의존성은 이 명령으로 펼쳐지지 않는다. 전이 의존성은 각각 별도의 반입 단위로 들어와 사내 미러에 등록되고, 프로젝트 전체의 의존성은 빌드 시점에 프로젝트를 대상으로 SBOM을 생성해 식별한다(2번 섹션).

산출물, SBOM, 취약점 점검 결과, 체크섬을 하나의 반입 묶음으로 만들어 악성코드 검사를 거친 뒤 망간 자료전송으로 내부망에 옮긴다. 내부망에서는 해시를 다시 확인하고, SBOM과 취약점 결과를 검토한 뒤 사내 미러 저장소에 등록한다. 이때 반입 승인 기록을 함께 남긴다.

사내 미러 저장소

폐쇄망 내부에 오픈소스를 공급하는 사내 미러 저장소를 둔다. Nexus, Artifactory 등 저장소 관리 도구를 온프레미스로 운영하거나, 언어별 패키지 저장소를 내부에 미러링한다. 개발자는 인터넷이 아니라 이 사내 미러에서만 의존성을 받는다.

미러는 오픈소스를 보관하는 저장소이면서, 무엇을 어떤 버전으로 쓸지 통제하는 지점이다.

• 반입 단계에서 만든 SBOM을 미러에 함께 등록해, 어떤 버전이 들어와 있는지 고정한다.
• 전이 의존성(직접 선언하지 않았지만 따라 들어오는 하위 의존성)까지 포함해 식별한다.
• 사전 승인되지 않은 컴포넌트는 미러에 올리지 않아, 승인 절차를 우회한 사용을 막는다.

사내 미러가 있으면 개발자가 무엇을 쓰는지 한곳에서 파악되고, 식별(2번 섹션)과 사용 승인(4번 섹션)의 기반이 된다.

오프라인 취약점 관리

폐쇄망에서는 실시간 취약점 정보를 받을 수 없다. 신규 취약점(CVE, Common Vulnerabilities and Exposures)을 인지하는 시점이 늦어지는 구조적 한계가 있으므로, 취약점 데이터를 정기적으로 들여오는 절차를 따로 마련한다.

접근 방식은 두 가지다.

• 외부망에서 스캔한 결과만 반입한다. 인터넷 연결이 가능한 구역에서 SBOM을 대상으로 취약점을 점검하고, 그 결과 보고서를 내부망으로 옮긴다.
• 오프라인 취약점 데이터베이스를 정기적으로 동기화한다. 취약점 점검 도구가 참조하는 데이터베이스를 외부에서 내려받아 내부 미러에 반입하고, 내부 도구가 그 미러를 바라보게 한다.

Grype와 Trivy는 취약점 데이터베이스를 캐시 디렉터리 단위로 받아 옮기는 방식으로, 물리적으로 분리된 폐쇄망(air-gap) 환경의 오프라인 갱신을 지원한다. Dependency-Track은 참조하는 취약점 데이터 소스(국가 취약점 데이터베이스, OSV, GitHub Advisories 등)의 주소를 설정으로 바꿔 내부 미러를 바라보게 할 수 있는데, 데이터 소스별로 미러를 따로 구성해야 해서 난도가 높다. 도입 전에 소규모 구성 검증을 거치기를 권한다. 도구가 오프라인 갱신을 지원하는지가 폐쇄망 취약점 관리의 핵심이다.

오프라인 취약점 데이터베이스 반입 예제

취약점 데이터베이스만 외부에서 받아 내부로 옮기는 흐름을 예로 든다.

외부 구간에서 데이터베이스를 내려받는다.

# 외부 구간: 취약점 DB 아카이브를 내려받는다 (도구별 명령은 예시)
grype db update          # 최신 취약점 DB를 로컬 캐시에 받는다
grype db status          # 받은 DB의 버전·생성 시각을 확인한다

# 받은 DB 캐시 디렉터리를 아카이브로 묶어 반입 대상으로 만든다
tar czf grype-db-$(date +%Y%m%d).tar.gz -C ~/.cache/grype/db .

아카이브의 해시를 확인하고 악성코드 검사를 거쳐 내부망으로 옮긴 뒤, 내부 점검 도구가 이 데이터베이스를 참조하도록 설정한다.

# 내부망: 반입한 DB 아카이브를 점검 도구가 참조하는 위치에 풀어 둔다
tar xzf grype-db-YYYYMMDD.tar.gz -C /opt/grype/db

# 오프라인 모드로 점검한다 (반입한 DB의 위치를 지정하고, 네트워크 갱신을 끈다)
GRYPE_DB_CACHE_DIR=/opt/grype/db GRYPE_DB_AUTO_UPDATE=false grype sbom:foo-1.2.3.sbom.json

Trivy는 데이터베이스를 받는 명령이 다를 뿐 흐름은 같다. 외부 구간에서 캐시를 받아 묶고, 내부에서 풀어 캐시 위치를 지정해 점검한다.

# 외부 구간: Trivy 취약점 DB를 로컬 캐시에 받아 아카이브로 묶는다
trivy image --download-db-only
tar czf trivy-db-$(date +%Y%m%d).tar.gz -C ~/.cache/trivy .

# 내부망: 캐시를 풀고, 갱신 없이 반입한 DB로 점검한다
tar xzf trivy-db-YYYYMMDD.tar.gz -C /opt/trivy
trivy sbom foo-1.2.3.sbom.json --skip-db-update --cache-dir /opt/trivy

자바 프로젝트를 점검하려면 별도의 자바 인덱스 데이터베이스가 필요하므로, 외부 구간에서 trivy image --download-java-db-only로 함께 받아 같은 캐시에 포함한다.

데이터베이스 동기화 주기와 책임자를 정하고, 동기화가 늦어지는 동안 발생할 수 있는 인지 지연을 관리한다. Dependency-Track에 운영 시스템의 SBOM을 등록해 두면, 데이터베이스를 갱신할 때마다 이미 운영 중인 시스템에 영향을 주는 신규 취약점을 자동으로 다시 평가한다. 지속 모니터링은 5번 섹션에서 자세히 다룬다.

폐쇄망에 맞는 도구 선택

폐쇄망에서는 클라우드 기반 스캐너를 쓸 수 없으므로 온프레미스로 설치하는 도구를 쓴다. 도구 자체가 오픈소스라면 그 도구도 반입 대상이 된다.

이 가이드가 도구 페이지에서 다루는 도구는 대부분 오픈소스이고 온프레미스 설치가 가능하다. SBOM 생성에는 Syft, cdxgen, OSV-SCALIBR을, 라이선스 점검에는 FOSSology, SCANOSS를, 취약점 점검과 지속 감시에는 Dependency-Track, Grype, Trivy를 쓸 수 있다. 도구별 설치와 사용법은 각 링크와 도구 페이지에서 다룬다.

전용 플랫폼만이 답은 아니다. 사내에서 GitLab 등 CI 플랫폼을 운영한다면 그에 내장된 의존성 스캐닝 기능으로 지속 점검을 구성할 수 있고, 상용 SCA 도구도 같은 역할을 한다. 실제 금융사의 도구 구성도 이런 조합이 흔하다(관리의 현장 사례 참고).

특정 제품을 단독으로 권하지는 않는다. 폐쇄망에서 도구를 고를 때는 다음 기준으로 본다.

• 온프레미스 설치형으로 제공되는가.
• 취약점 데이터베이스를 오프라인으로 갱신할 수 있는가.
• SBOM 표준 형식(SPDX, CycloneDX)을 입출력하는가.
• 도구 자체의 라이선스가 사내 운영에 문제를 일으키지 않는가.

마지막 기준은 실제로 걸린다. 예를 들어 FOSSLight는 AGPL-3.0이다. 도구를 개조한 버전을 네트워크로 기능을 제공하는 방식으로 쓰면 소스 공개 의무가 생길 수 있으므로 법무 검토 항목으로 둔다.

패치 지연 관리

폐쇄망에서는 취약점 패치도 반입 절차를 다시 거쳐야 하므로 즉시 대응이 어렵다. 신규 취약점이 공개돼도 패치를 받아 검증하고 내부로 옮기는 데 시간이 걸린다. 이 지연을 관리하는 장치를 둔다.

• 사전 승인된 미러로만 패치를 수급해, 출처가 불분명한 긴급 패치의 직접 반입을 막는다.
• 패치를 적용하기 전까지의 임시 완화책(영향 받는 기능 차단, 접근 제한 등)을 절차에 포함한다.
• 취약점의 심각도와 노출 정도에 따라 대응 기한을 정해, 지연이 방치되지 않게 한다.

망분리 예외 시 자체 위험평가

연구·개발 목적 업무에서 망분리 예외를 적용하면 폐쇄망의 자동 보호가 사라진다. 이때 오픈소스에 대한 위험을 스스로 평가하고 통제를 설계해 문서로 남겨야 한다.

자체 위험평가 문서에는 다음을 담는다.

• 대상 업무가 연구·개발 목적에 해당하며 고유식별정보와 개인신용정보를 처리하지 않는다는 판단 근거.
• 망분리 예외 구간에서 쓰는 오픈소스의 목록(SBOM)과 그 취약점·라이선스 위험.
• 금융감독원장이 정하는 망분리 대체 정보보호통제의 적용 내역.
• 인터넷 연결이 열린 만큼 추가되는 위험과 그에 대응하는 보안 통제(반입 검증을 대신할 통제).
• 통제의 이행을 확인하는 방법과 재평가 주기.

망분리 예외의 승인은 오픈소스 조직이 아니라 전사 보안 거버넌스의 소관이다. 이 문서는 정보보호위원회(또는 정보보호최고책임자, CISO)의 승인을 받는다. 승인된 평가서는 오픈소스 사용 승인 단계(4번 섹션)의 근거 자료가 되고, 정기 재평가(5번 섹션)의 대상이 된다. 양식은 산출물로 제공하는 망분리 예외 자체 위험평가서 템플릿을 참고한다.

FSEC 안내서·ISO 표준과의 연결

폐쇄망 운영은 안내서의 식별·관리 단계에 앞서는 전제 조건이면서, 동시에 두 단계의 품질을 좌우한다. 이 페이지의 폐쇄망 절차가 표준 입증자료·안내서 절차·규제와 어떻게 이어지는지는 다음과 같다.

표준별 입증자료와 안내서 절차의 전체 대조는 가이드 개요의 매핑표에서 확인한다.

최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.

2 - 거버넌스: 관리 조직과 승인 체계

금융권 거버넌스의 출발점

금융분야 오픈소스 소프트웨어 활용·관리 안내서(금융감독원·금융보안원, 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 요구]

오픈소스 검토 위원회(OSRB)

오픈소스 검토 위원회(OSRB, Open Source Review Board)는 오픈소스 도입과 사용을 검토하고 승인하는 협의 기구다. 금융권에서 특히 중요한 이유는, 오픈소스 도입 결정에 라이선스 위험, 보안 취약점, 운영 영향이 함께 걸려 있어 한 부서가 단독으로 판단하기 어렵기 때문이다.

위원회는 보통 다음 관점을 함께 본다.

• 법무: 라이선스 의무와 계약·지식재산권 위험.
• 보안: 취약점, 공급망 위험, 유지보수 상태.
• 기술·개발: 기술 적합성, 대체 가능성, 운영 부담.

위원회의 결정과 그 근거를 기록으로 남긴다. 이 기록은 사용 승인 단계(4번 섹션)의 핵심 증적이며, 감사 대응(5번 섹션)에서 다시 쓰인다. 위원회를 매번 소집하기 어렵다면 위험 수준별로 검토를 차등한다. 구체적 방법은 사용 승인에서 다룬다. [본 가이드 권고]

법률 자문과 예산

ISO/IEC 5230은 법률 자문에 접근하는 방법(3.2.2.3)과 인원 배치 및 예산 확인(3.2.2.2)을 입증자료로 요구한다. 금융권은 사내 법무 조직이 있는 경우가 많으므로, 오픈소스 라이선스 사안을 어느 경로로 법무에 올리는지를 정해 문서로 남긴다. 외부 전문 자문이 필요한 사안의 판단 기준도 함께 정한다. [ISO 요구]

예산은 도구 구축과 운영, 교육, 외부 자문에 든다. 신설 조직은 오픈소스 도구가 대부분 오픈소스이고 온프레미스로 설치 가능하다는 점을 활용해 초기 비용을 낮출 수 있다. 도구 선택은 폐쇄망 운영과 관리에서 다룬다.

FSEC 안내서·ISO 표준과의 연결

조직과 역할의 일반 실무는 기존 기업 오픈소스 관리 가이드의 조직 섹션에서 더 자세히 다룬다. 이 페이지는 그 위에 금융권의 검토 위원회와 감사 대비 기록을 더한 것이다.

최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.

3 - 식별: 쓰고 있는 오픈소스를 빠짐없이 찾기

무엇을 식별하는가

오픈소스를 식별한다는 것은 세 종류를 모두 찾아낸다는 뜻이다.

• 신규로 들여오는 오픈소스. 개발자가 새로 도입하는 라이브러리와 그 의존성.
• 이미 운영 중인 시스템에 들어 있는 오픈소스. 도입 시점에 기록하지 못한 레거시.
• 외주 개발사나 전자금융보조업자가 만든 산출물에 포함된 오픈소스. 외주 개발사(업무를 위탁받은 수탁자)와 전자금융보조업자(전자금융거래법상 금융회사를 위해 전자금융거래를 보조하는 자)는 법적으로 다른 범주지만, 산출물의 오픈소스를 식별해야 한다는 점은 같다.

직접 선언한 의존성만이 아니라 그것이 끌어오는 전이 의존성까지 펼쳐야 한다. 실제 위험은 대부분 직접 보지 않는 하위 의존성에 숨어 있다.

금융권에서는 여기에 규제 근거가 붙는다. 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으로 식별하는 일이 금융권에서 특히 중요하다. 운영 시스템의 취약점은 상시적 위험이기 때문이다.

운영 중인 시스템의 식별은 한 번으로 끝나지 않는다. 자산 인벤토리를 만들어 어떤 시스템에 어떤 오픈소스가 들어 있는지 지속적으로 갱신한다. 이 인벤토리는 지속 모니터링(관리)의 기반이 된다. [본 가이드 권고]

제3자와 외주 산출물 식별

FSEC 안내서는 전자금융보조업자가 사용하는 오픈소스의 식별을 점검 항목으로 둔다. 금융권은 외주 개발과 위탁이 많아, 내가 직접 도입하지 않은 오픈소스가 외주 산출물을 통해 들어온다. 이를 식별하지 못하면 관리 범위에 구멍이 생긴다. [FSEC 안내서]

방법은 외주 산출물에 SBOM 제출을 요구하는 것이다. 계약 단계에서 SBOM 제공을 의무로 넣고, 받은 SBOM을 검증한다. 계약과 제안요청서에 넣을 구체적 요구사항은 사용 승인에서 다룬다.

공급망 보안 플랫폼과의 연계

금융보안원의 금융권 소프트웨어 공급망 보안 플랫폼이 2026년부터 본격 운영된다(개요는 가이드 개요 참고). 금융사는 이 플랫폼에 참여하기 위해 SBOM을 산출하고 제출하는 형식을 미리 갖춰 두는 것이 좋다.

해외에서는 미국과 유럽이 SBOM 제출 의무화를 진행 중이고, 국내 정부도 SW 공급망 보안 가이드라인 1.0(2024-05-13)을 통해 단계적 제도화 방향을 밝혔다. 정부는 2027년 공공부문 SBOM 제출 의무화를 목표로 추진하고 있어, 그 흐름이 금융권으로 확산될 전망이다. 현재 국내 금융권에 SBOM 제출이 일률적으로 의무화된 것은 아니지만, 이 흐름에 선제적으로 대비하는 것이 합리적이다. [본 가이드 권고]

FSEC 안내서·ISO 표준과의 연결

SBOM 작성의 일반 실무와 도구 활용은 기존 기업 오픈소스 관리 가이드의 도구 섹션과 ISO/IEC 5230 준수 가이드의 SBOM 조항에서 더 자세히 다룬다.

최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.

4 - 이슈 파악과 해결: 취약점과 라이선스

취약점 탐지에서 조치까지

ISO/IEC 18974는 SBOM(Software Bill of Materials)에 담긴 각 오픈소스 컴포넌트에 보안 보증 활동을 적용하도록 요구한다. 탐지부터 해결까지의 전 과정을 절차로 만들고, 각 취약점에 대한 수행 기록을 남겨야 한다. 절차는 다음 흐름을 따른다. [ISO 요구]

• 탐지: SBOM의 각 컴포넌트에 알려진 취약점(CVE, Common Vulnerabilities and Exposures)이 있는지 점검한다.
• 평가: 탐지된 취약점에 위험·영향 점수를 매긴다. 공통 취약점 등급 체계(CVSS, Common Vulnerability Scoring System)를 쓴다.
• 조치 결정: 각 취약점에 필요한 수정 또는 완화 단계를 정하고 문서로 남긴다. 조치가 필요 없다고 판단한 경우 그 판단 근거도 기록한다.
• 조치 수행: 위험 점수에 따라 패치, 버전 교체, 완화 설정 등을 수행한다.
• 지속 대응: 운영 중 새로 공개되는 취약점을 모니터링하고 영향받는 시스템에 대응한다.

flowchart LR
    A["탐지<br>(SBOM 대조)"] --> B["평가<br>(CVSS 점수)"]
    B --> C{"조치가<br>필요한가?"}
    C -- 예 --> D["조치 수행<br>패치·교체·완화"]
    C -- 아니오 --> E["불필요 판단 근거 기록<br>(VEX)"]
    D --> F["조치 기록"]
    E --> G["지속 대응<br>(신규 취약점 모니터링)"]
    F --> G
    G --> A

    style A fill:#2b6cb0,color:#fff
    style D fill:#c53030,color:#fff
    style E fill:#744210,color:#fff
    style F fill:#276749,color:#fff
    style G fill:#2d3748,color:#fff

이 절차가 ISO/IEC 18974의 취약점 탐지·해결 절차(4.3.2.1)이고, 그 수행 기록이 취약점·조치 기록(4.3.2.2)이다. 조치가 필요 없다고 판단한 결과를 VEX(Vulnerability Exploitability eXchange) 형식으로 남기면, 같은 취약점을 반복 검토하지 않아도 된다.

취약점 점검과 지속 감시 예제

SBOM을 취약점 관리 도구에 등록하면, 도구가 새로운 취약점이 공개될 때마다 영향받는 컴포넌트를 다시 알려 준다. Dependency-Track에 운영 시스템의 SBOM을 등록하는 방식을 예로 든다. 도구는 예시이며 동급 도구로 바꿔도 된다.

# SBOM을 Dependency-Track 프로젝트에 업로드한다 (API 예시)
curl -X POST "https://dtrack.internal/api/v1/bom" \
  -H "X-Api-Key: $DT_APIKEY" \
  -F "project=$PROJECT_UUID" \
  -F "bom=@foo-1.2.3.sbom.json"

업로드 후에는 도구가 취약점 데이터베이스와 대조해 취약점 목록을 만든다. 폐쇄망에서는 이 데이터베이스를 오프라인으로 갱신한다. 한 번의 점검으로 끝나는 것이 아니라, 데이터베이스를 갱신할 때마다 이미 등록된 SBOM이 다시 평가돼 신규 취약점이 자동으로 드러난다. 운영 시스템의 지속 모니터링은 관리에서 더 다룬다.

명령줄에서 한 번 점검할 때는 Grype나 Trivy를 쓸 수 있다.

# SBOM을 입력으로 취약점을 점검한다
grype sbom:foo-1.2.3.sbom.json

대응 기한

탐지만으로는 부족하다. 심각도에 따라 언제까지 조치할지 기한을 정해 두어야 지연이 방치되지 않는다. 심각도와 노출 정도를 함께 보아 우선순위를 매기고, 등급별 대응 기한을 정책에 명시한다. 아래는 기한을 정하는 예시이며, 조직의 위험 수용 수준에 맞춰 조정한다. [본 가이드 권고]

기한 내 조치가 어려운 경우의 임시 완화책과 예외 승인 절차도 함께 정한다.

라이선스 이슈 해결

취약점과 함께 풀어야 할 다른 이슈는 라이선스다. 식별한 오픈소스의 라이선스 의무를 확인하고, 의무를 충족하지 못하는 사용을 찾아 해결한다. ISO/IEC 5230은 이를 라이선스 사용 사례 처리 절차(3.3.2.1)로 요구한다. [ISO 요구]

금융권에서 라이선스 이슈는 배포 여부에 따라 성격이 달라진다. 이 가이드는 두 경우를 나눠 본다.

• 외부로 배포하는 소프트웨어(대외 서비스, 고객 앱): GPL 계열 등 배포 기반 라이선스의 의무(고지, 경우에 따라 소스 공개)가 발생한다. 라이선스 의무를 충족하는 절차를 갖춰야 한다.
• 외부로 배포하지 않는 사내 운영 시스템: 배포가 없어 GPL 등의 소스 공개 의무는 약하지만, 라이선스 호환성과 사용 조건은 여전히 확인한다.

FSEC 안내서도 외부 배포 시 GPL 계열 사용에 대한 소스 공개정책 마련을 점검 항목으로 둔다. 배포 소프트웨어와 사내 운영 시스템의 범위 구분은 관리에서 더 다룬다.

라이선스 점검에는 FOSSology, SCANOSS 같은 오픈소스 도구를 쓸 수 있다. 다만 도구 자체의 라이선스도 확인한다. FOSSLight(AGPL-3.0)의 사례는 폐쇄망 운영의 도구 선택에서 다룬다.

FSEC 안내서·ISO 표준과의 연결

취약점 대응 절차의 조항별 상세는 ISO/IEC 18974 준수 가이드의 보안 보증 조항에서, 8가지 처리 방법은 표준 관행 구현 조항에서 더 자세히 다룬다.

최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.

5 - 사용 승인: 무엇을 어떤 근거로 허용하는가

사용 승인 워크플로

사용 승인은 “이 오픈소스를 이 용도로 써도 되는가"에 답하는 절차다. 답의 근거는 앞 단계에서 나온다. 식별로 무엇인지 알고, 이슈 파악·해결로 취약점과 라이선스 의무를 파악한 뒤, 그 결과를 놓고 승인 여부를 정한다.

기본 흐름은 요청, 검토, 결정, 기록이다.

• 요청: 사용하려는 오픈소스와 용도, 배포 여부를 신청한다.
• 검토: 라이선스 의무, 보안 취약점, 기술 적합성을 함께 본다. 검토 주체는 거버넌스에서 정한 오픈소스 검토 위원회(OSRB, Open Source Review Board)다.
• 결정: 승인, 조건부 승인(완화 조치를 전제로 허용), 반려 중 하나로 정한다.
• 기록: 결정과 그 근거를 남긴다. 이 기록이 감사 증적이 된다.

flowchart LR
    A["요청<br>(오픈소스·용도·배포 여부)"] --> B{"위험이<br>낮은가?"}
    B -- "예 (사전 기준 충족)" --> C["자동 승인"]
    B -- 아니오 --> D["OSRB 검토<br>법무·보안·기술"]
    D --> E["승인"]
    D --> F["조건부 승인<br>(완화 조치 전제)"]
    D --> G["반려"]
    C --> H["결정·근거 기록<br>(감사 증적)"]
    E --> H
    F --> H
    G --> H

    style C fill:#276749,color:#fff
    style D fill:#2b6cb0,color:#fff
    style G fill:#c53030,color:#fff
    style H fill:#2d3748,color:#fff

망분리 예외가 걸린 사용은 이 워크플로와 별도로, 자체 위험평가서에 대한 정보보호위원회(CISO)의 승인이 먼저 필요하다. 아래 절에서 다룬다.

모든 사용을 같은 무게로 검토할 필요는 없다. 위험이 낮은 사용은 사전에 정한 기준으로 자동 승인하고, 배포 소프트웨어에 들어가거나 라이선스 의무가 큰 사용만 위원회에 올리는 식으로 차등한다. ISO/IEC 5230은 라이선스 의무사항 검토 절차(3.1.5.1)를 입증자료로 요구한다. [ISO 요구]

망분리 예외 시 자체 위험평가

전자금융감독규정 개정(2025-02-05 시행)으로 고유식별정보와 개인신용정보를 처리하지 않는 연구·개발 목적 업무는 자체 위험평가와 망분리 대체 정보보호통제 적용을 거쳐 망분리 예외를 적용할 수 있다. 망분리 예외 자체의 승인은 오픈소스 검토 위원회가 아니라 전사 보안 거버넌스, 곧 정보보호위원회(또는 정보보호최고책임자, CISO)의 소관이다.

오픈소스 사용 승인은 이 절차와 맞물린다. 위험평가서에 들어가는 오픈소스 위험 정보(SBOM, 취약점, 라이선스)는 식별과 이슈 파악·해결 단계에서 나오므로, 오픈소스 관리 조직은 그 정보를 제공하고 검토를 지원한다. 망분리 예외 구간에서 쓸 오픈소스의 사용 승인을 검토할 때는 승인된 위험평가서를 근거 문서로 함께 보고, 그 결정을 기록한다. 평가서에 무엇을 담는지는 폐쇄망 운영의 자체 위험평가에서 다룬다. [본 가이드 권고]

외주 계약과 제안요청서

금융권은 외주 개발과 위탁이 많아, 사용 승인은 계약 단계로 거슬러 올라간다. 외주 산출물에 포함될 오픈소스를 통제하려면, 계약과 제안요청서에 오픈소스 관리 요구사항을 미리 넣어야 한다.

계약에 넣을 요구사항은 다음과 같다.

• SBOM(Software Bill of Materials) 제출: 산출물에 포함된 오픈소스의 목록을 표준 형식으로 제출하도록 요구한다.
• 라이선스 의무 이행: 라이선스 고지와 의무 이행의 책임을 명시한다.
• 취약점 대응: 취약점이 발견됐을 때의 대응 의무와 기한을 정한다.
• 소유권·권리 귀속: 산출물의 소유권, 저작권, 지식재산권 귀속을 명확히 한다.

마지막 항목은 전자금융감독규정 제21조와 닿는다. 2025-02-05 개정 전의 제21조는 정보처리시스템 구축과 전자금융거래 계약에서 제품의 소유권·저작권·지식재산권 귀속을 명확히 하도록 명시했고, FSEC 안내서도 이를 근거로 권리 귀속 관리를 안내한다. 개정된 현행 제21조는 세부 항목을 나열하는 대신 계약의 안전성과 신뢰성, 공정성을 확보하기 위한 내부통제 절차를 수립하고 운용하도록 요구하는데, 권리 귀속 명확화는 그 내부통제의 핵심 내용으로 여전히 유효한 실무다. 외주 계약에 오픈소스 관련 권리 귀속을 분명히 적는 것은 이 요구를 충족하는 일이다. [FSEC 안내서]

FSEC 안내서·ISO 표준과의 연결

승인 프로세스의 일반 실무는 기존 기업 오픈소스 관리 가이드의 프로세스 섹션에서 더 자세히 다룬다. 정책·절차 양식은 정책·절차 템플릿을 금융 맥락으로 보강해 쓰며, 보강한 골격은 산출물의 금융 정책·절차 템플릿으로 제공한다.

최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.

6 - 관리: 사내 운영 시스템의 지속 점검과 감사 대응

배포 소프트웨어와 사내 운영 시스템의 구분

오픈소스 관리의 초점은 흔히 외부로 배포하는 소프트웨어에 맞춰진다. 배포가 라이선스 의무를 일으키기 때문이다. 그러나 금융권에서 오픈소스가 가장 많이 쓰이는 곳은 외부로 배포되지 않는 사내 운영 시스템이다. 계정계와 정보계, 사내 금융 관리 시스템, 내부 서버가 그렇다. 이 가이드는 두 범위를 나눠 다룬다.

• 배포 소프트웨어(대외 서비스, 고객 앱): 라이선스 의무(고지, 경우에 따라 소스 제공)가 중심이다. ISO/IEC 5230의 영역이다.
• 사내 운영 시스템과 서버(비배포): 외부 배포가 없어 소스 공개 의무는 약하지만, 보안 취약점과 공급망 위험은 오히려 크고 상시적이다. 취약점 지속 점검, 자산 인벤토리, 정기 재평가가 중심이다. ISO/IEC 18974와 운영 복원력의 영역이다.

이 페이지는 두 번째 범위, 곧 사내 운영 시스템의 관리에 집중한다. 금융권 특유의 강조점이기 때문이다. 유럽연합의 디지털 운영 복원력법(DORA, Digital Operational Resilience Act)이 ICT 운영 복원력과 오픈소스 취약점·패치 관리를 요구하는 것도 같은 맥락이다. [본 가이드 권고]

운영 자산 인벤토리

지속 점검의 출발은 무엇이 가동 중인지 아는 것이다. 운영 중인 사내 시스템과 서버에 어떤 오픈소스가 들어 있는지 목록으로 만든다. 신규 도입만이 아니라 이미 오래 운영 중인 레거시까지 SBOM(Software Bill of Materials)으로 식별한다. 도입 기록이 없는 레거시를 빠뜨리면 점검 범위에 구멍이 생긴다.

운영 자산 인벤토리는 식별 단계(식별)에서 만든 SBOM을 운영 시스템 기준으로 모은 것이다. 어떤 시스템이 어떤 컴포넌트를 쓰는지 연결해 두면, 신규 취약점이 공개됐을 때 영향받는 시스템을 곧바로 찾을 수 있다.

지속 취약점 모니터링

운영 단계의 핵심은 상시 감시다. 신규 취약점(CVE, Common Vulnerabilities and Exposures)이 공개될 때마다 영향받는 운영 시스템을 역추적하는 구조를 갖춘다. 이는 ISO/IEC 18974의 취약점 탐지·해결 절차(4.3.2.1)를 운영 단계로 이어 가는 활동이다. [ISO 요구]

방법은 운영 시스템의 SBOM을 취약점 관리 도구에 등록해 두는 것이다. Dependency-Track에 SBOM을 등록하면, 취약점 데이터베이스가 갱신될 때마다 등록된 모든 SBOM이 다시 평가돼 신규 취약점이 자동으로 드러난다. 서버와 컨테이너, 파일시스템은 Trivy로 주기적으로 스캔한다. 사내에서 GitLab 등 CI 플랫폼을 운영한다면 내장 의존성 스캐닝으로 같은 지속 점검을 구성할 수 있고, 상용 SCA 도구도 같은 역할을 한다.

그림: 운영 시스템별로 SBOM을 등록한 Dependency-Track 프로젝트 목록. 신규 취약점이 공개되면 이 목록에서 영향받는 시스템이 드러난다. 화면은 cdxgen·Dependency-Track 튜토리얼의 캡처를 재사용했다.

주기 스캔 예제

운영 서버를 정기적으로 스캔해 결과를 남기는 흐름을 예로 든다. 도구는 예시이며 동급 도구로 바꿔도 된다.

# 운영 서버의 파일시스템을 스캔해 결과를 날짜별로 보관한다
trivy fs --format json --output /var/log/oss-scan/$(date +%Y%m%d).json /opt/app

# 폐쇄망에서는 취약점 DB를 오프라인으로 갱신해 두고 자동 갱신을 끈다
TRIVY_SKIP_DB_UPDATE=true trivy fs /opt/app

폐쇄망에서는 취약점 데이터베이스를 오프라인으로 갱신한다. 갱신 절차는 폐쇄망 운영에서 다룬다. 스캔 결과는 다음에서 다룰 감사 증적으로 보관한다.

정기 재평가

지속 모니터링이 자동 감시라면, 정기 재평가는 사람이 주기적으로 점검 체계 자체를 다시 보는 활동이다. 분기나 반기 같은 정기 점검과 함께, 시스템 변경 시점의 재점검을 절차로 만든다. ISO/IEC 18974는 프로그램의 주기적 검토와 변경 증거(4.1.2.5)를 입증자료로 요구한다. [ISO 요구]

망분리 예외를 적용한 시스템은 자체 위험평가를 정기적으로 갱신한다. 규제 완화로 망분리에서 벗어난 만큼, 자율보안의 책임이 재평가 주기와 함께 이어진다. 자체 위험평가서는 사용 승인에서 다룬다.

감사 증적 관리

금융권은 내외부감사와 금융감독원의 정보기술(IT) 검사에 대비해야 한다. 관리 단계의 점검 기록은 그 자체로 감사 증적이 된다. 무엇을 언제 점검했고 어떤 취약점에 어떻게 대응했는지의 기록을 보관하면, 감사와 검사에서 요구하는 증적을 따로 만들 필요가 없다.

ISO 입증자료 체계를 감사 증적으로 재활용하는 것이 효율적이다. ISO/IEC 18974가 요구하는 취약점·조치 기록, ISO/IEC 5230이 요구하는 컴플라이언스 산출물 생성·보관(3.4.1.1, 3.4.1.2)이 그대로 감사 대응 자료가 된다. 증적을 어디에 얼마나 보관할지 정하고, 위변조를 막는 기록 방식을 갖춘다. [본 가이드 권고]

무엇을 보관할지의 체크리스트와 보관 위치 명세는 산출물로 제공하는 감사 증적 목록을 쓴다.

FSEC 안내서·ISO 표준과의 연결

지속 모니터링과 보안 보증의 조항별 상세는 ISO/IEC 18974 준수 가이드에서 더 자세히 다룬다.

최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.

7 - 자가점검: 우리 체계의 빈 곳 찾기

자가점검을 쓰는 방법

이 점검표는 통과·불합격을 가리는 시험이 아니다. 자사가 어디까지 갖췄는지 가늠하고 다음에 무엇을 할지 찾는 도구다. FSEC 안내서가 비규제 자율 점검이듯, 이 점검표도 모범 실무 기준이다. [FSEC 안내서]

각 항목은 관련 ISO 입증자료, 권장 도구, 자세히 다루는 가이드 섹션과 연결돼 있다. 충족하지 못한 항목이 있으면 연결된 섹션으로 가서 방법을 확인한다. 권장 도구는 예시이며 도구 이름의 첫 등장에 사용법 페이지를 링크했다. FSEC 안내서가 쓰는 다섯 분류, 곧 식별, 이슈 파악 및 해결, 승인, 관리, 기타의 순서를 따른다.

식별

이슈 파악 및 해결

승인

관리

기타

기타 분류는 앞의 네 단계를 떠받치는 기반이다. FSEC 안내서도 선택 기준, 예외 승인, 역할 문서, 인력, 예산, 정책 인식, 법률 자문을 별도 분류로 둔다.

자가점검 워크북

위 점검 항목을 점검 결과 기록, ISO 입증자료, 담당자, 목표 기한과 함께 한 시트로 묶은 자가점검 워크북을 산출물로 제공한다. 항목별 권장 도구는 이 페이지의 표에서 확인한다.

ISO 입증자료와의 교차 참조

이 점검표의 항목은 ISO/IEC 5230과 18974의 입증자료에 연결된다. 점검 항목을 충족하면서 근거 문서를 남기면, 그 문서가 그대로 ISO 자가 인증의 입증자료가 된다. 전 항목 점검을 마친 뒤 모든 요구사항의 충족을 확인하는 문서를 작성하면, 그 문서는 ISO/IEC 5230의 요구사항 충족 확인(3.6.1.1) 입증자료가 된다. 입증자료의 조항별 상세는 ISO/IEC 5230 준수 가이드와 ISO/IEC 18974 준수 가이드에서, 전체 매핑은 가이드 개요의 대조표에서 확인한다.

최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.

8 - 산출물: 바로 쓰는 양식과 레시피

이 가이드는 본문과 함께 바로 쓸 수 있는 네 가지 산출물을 제공한다. 본문이 “무엇을 왜 하는지"를 설명한다면, 산출물은 “그것을 어떤 양식으로 남기는지"를 채워 준다. 각 산출물은 조직 상황에 맞게 고쳐 쓰는 것을 전제로 한다.

최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.

8.1 - 자가점검 워크북

이 워크북은 자가점검 페이지의 점검 항목을 기록용 양식으로 옮긴 것이다. 점검만 하고 끝내지 않고, 부족한 부분의 담당자와 기한을 적어 개선 계획으로 잇기 위한 것이다.

쓰는 방법

각 항목의 충족 상태를 세 단계로 표시한다.

• 미충족: 관련 활동이나 문서가 없다.
• 부분 충족: 활동은 있으나 문서나 기록이 부족하다.
• 충족: 활동과 근거 문서를 모두 갖췄다.

부분 충족이나 미충족 항목에는 근거 문서가 무엇이어야 하는지, 누가 언제까지 갖출지를 적는다. 충족 항목에는 근거 문서의 이름과 위치를 적어, 그대로 ISO 자가 인증의 입증자료로 쓸 수 있게 한다.

아래 표를 복사해 조직의 점검 기록으로 채운다. 상태 칸에는 미충족·부분·충족 중 하나를 적는다.

식별

이슈 파악 및 해결

승인

관리

기타

각 점검 항목을 자세히 다루는 가이드 섹션은 자가점검 페이지의 표에서 링크로 연결돼 있다.

최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.

8.2 - 정책·절차 템플릿

여기 담은 양식은 금융권 고유 항목을 보강한 골격이다. 일반 오픈소스 정책과 프로세스 양식은 기존 정책·절차 템플릿 가이드를 쓰고, 금융권에서 추가로 필요한 반입 통제, 망분리 예외 위험평가, 외주 SBOM 요구는 아래 양식으로 채운다.

금융 오픈소스 정책 (보강 항목)

기존 오픈소스 정책에 금융권 고유 항목을 더한다. 아래는 정책에 포함할 항목의 골격이다.

1. 목적과 적용 범위
   - 배포 소프트웨어와 사내 운영 시스템을 모두 포함한다.
   - 폐쇄망과 망분리 예외 구간을 구분해 적용한다.

2. 식별
   - 신규·레거시·외주 산출물의 오픈소스를 SBOM으로 식별한다.

3. 이슈 파악 및 해결
   - 취약점 심각도별 대응 기한: [조직이 정한 기한].
   - 외부 배포 시 GPL 계열 소스 공개 정책: [정책 내용].

4. 사용 승인
   - 승인 주체(오픈소스 검토 위원회) 구성과 권한.
   - 위험 수준별 승인 단계(자동 승인 기준과 위원회 상정 기준).

5. 관리
   - 운영 시스템 지속 모니터링과 정기 재평가 주기: [분기/반기 등].
   - 감사 증적 보관 기간: [조직이 정한 기간].

6. 망분리 예외
   - 자체 위험평가 의무와 재평가 주기.

7. 역할과 책임, 예산, 법률 자문 접근, 정책 전파

오픈소스 반입 절차서 (폐쇄망)

폐쇄망에 오픈소스를 들여오는 절차의 골격이다. 자세한 설명은 폐쇄망 운영을 참고한다.

반입 신청
  - 신청자, 대상 오픈소스와 버전, 용도, 반입 사유

외부 구간 검증
  - 공식 배포처 확인, 체크섬 대조(무결성)
  - 악성코드 검사
  - SBOM 생성
  - 취약점 사전 점검

반입 승인
  - 검증 결과 검토, 승인 여부 결정
  - 승인자, 승인 일시 기록

내부 이관
  - 망간 자료전송, 내부망에서 해시 재확인
  - 사내 미러 등록(SBOM 함께 등록)

기록 보관
  - 위 전 과정을 감사 증적으로 보관

사용 승인 신청·검토 양식

[신청]
  - 신청자 / 소속 / 신청일
  - 대상 오픈소스 / 버전 / 라이선스
  - 사용 용도 / 배포 여부(대외 배포 / 사내 운영)
  - 첨부: SBOM, 취약점 점검 결과

[검토] (오픈소스 검토 위원회)
  - 법무: 라이선스 의무·계약·권리 귀속 검토 의견
  - 보안: 취약점·공급망·유지보수 상태 검토 의견
  - 기술: 적합성·대체 가능성 검토 의견

[결정]
  - 승인 / 조건부 승인(조건: ___) / 반려
  - 결정자 / 결정일 / 근거

[신청]
  - 신청자: 김OO / 디지털채널개발팀 / 2026-05-12
  - 대상 오픈소스: Apache Kafka / 3.9.x / Apache-2.0
  - 사용 용도: 사내 이벤트 스트리밍(거래 알림 적재) / 사내 운영(비배포)
  - 첨부: kafka-3.9.sbom.json, 취약점 점검 결과(심각 0, 높음 0)

[검토] (오픈소스 검토 위원회, 2026-05-19)
  - 법무: Apache-2.0, 비배포 사용으로 고지 의무 없음. 이상 없음.
  - 보안: 알려진 심각 취약점 없음. 사내 미러 경유 반입 확인. 이상 없음.
  - 기술: 기존 메시징 표준과 부합. 운영팀 운영 역량 확보 확인.

[결정]
  - 조건부 승인 (조건: 운영 시스템 SBOM을 Dependency-Track에 등록해 지속 모니터링 대상에 포함)
  - 결정자: 오픈소스 검토 위원회 / 2026-05-19 / 검토 의견 3건 종합

망분리 예외 자체 위험평가서

전자금융감독규정 개정(2025-02-05 시행)에 따라 고유식별정보와 개인신용정보를 처리하지 않는 연구·개발 목적 업무에 망분리 예외를 적용할 때 작성한다. 자세한 설명은 폐쇄망 운영의 자체 위험평가를 참고한다.

1. 대상 업무
   - 업무명 / 시스템명
   - 연구·개발 목적 해당 여부와 판단 근거
   - 고유식별정보·개인신용정보 미처리 확인

2. 사용 오픈소스
   - SBOM(대상 구간에서 쓰는 오픈소스 목록)
   - 취약점·라이선스 위험 평가

3. 추가 위험과 통제
   - 인터넷 연결로 추가되는 위험
   - 망분리 대체 정보보호통제 적용 내역
   - 반입 검증을 대신할 보안 통제

4. 이행 확인과 재평가
   - 통제 이행 확인 방법
   - 재평가 주기: [조직이 정한 주기, 통상 연 1회 이상]

5. 검토와 승인
   - 작성자 / 작성일
   - 검토: 정보보호 부서, 오픈소스 관리 조직(위험 정보 확인)
   - 승인: 정보보호위원회 또는 정보보호최고책임자(CISO) / 승인일

1. 대상 업무
   - 업무명: 사기거래 탐지 모델 연구 / 시스템명: FDS 연구 검증 환경
   - 연구·개발 목적 해당: 예 — 운영 서비스와 분리된 모델 연구·검증 전용 환경
   - 고유식별정보·개인신용정보 미처리: 확인 — 비식별 처리된 표본 데이터만 사용

2. 사용 오픈소스
   - SBOM: fds-research-env.sbom.json (Python 계열 187개 컴포넌트)
   - 위험 평가: 심각 취약점 0건, 카피레프트 라이선스 0건(전부 Apache-2.0·BSD·MIT)

3. 추가 위험과 통제
   - 추가 위험: 외부 패키지 저장소 직접 접근으로 인한 미검증 컴포넌트 유입
   - 대체 정보보호통제: 망분리 대체 정보보호통제 기준에 따른 단말 통제·접근 기록
   - 보안 통제: 사내 미러 우선 사용, 주 1회 환경 전체 취약점 스캔

4. 이행 확인과 재평가
   - 이행 확인: 분기별 통제 운영 점검(정보보호 부서)
   - 재평가 주기: 연 1회 및 환경 구성 변경 시

5. 검토와 승인
   - 작성자: 박OO(FDS연구팀) / 2026-04-02
   - 검토: 정보보호 부서(2026-04-09), 오픈소스 관리 조직(SBOM·위험 평가 확인)
   - 승인: 정보보호위원회 / 2026-04-16

이 평가서는 사용 승인의 승인 근거가 되고, 관리에서 정기적으로 갱신한다.

최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.

8.3 - 감사 증적 목록

금융권은 내외부감사와 금융감독원의 정보기술(IT) 검사에 대비해 오픈소스 관리 활동의 증적을 보관해야 한다. 관리 단계의 점검 기록이 그대로 증적이 되므로, 따로 만들지 말고 평소 활동에서 나오는 기록을 체계적으로 모은다. 자세한 맥락은 관리를 참고한다.

증적 체크리스트

아래 증적은 ISO/IEC 5230·18974의 입증자료와 겹친다. ISO 자가 인증을 준비하며 만든 문서가 그대로 감사 증적이 된다. 보관 위치와 기간은 조직 규정에 맞게 정한다.

보관·관리 원칙

증적은 만드는 것만큼 지키는 것이 중요하다.

• 보관 기간을 정한다. 감사 주기와 규정 요구를 고려해 정하고, 전자금융거래 기록 보존 기간 등 규정상 보존 기간과 어긋나지 않는지 확인한 뒤, 산출물 보관 절차(ISO/IEC 5230 3.4.1.2)에 명시한다.
• 위변조를 막는다. 기록을 나중에 고칠 수 없는 방식(추가만 가능한 로그, 접근 통제)으로 남긴다.
• 추적할 수 있게 한다. 누가 언제 무엇을 했는지 알 수 있도록 기록에 행위자와 시각을 남긴다.
• 검사 대응을 미리 점검한다. 정기 재평가 때 증적이 빠짐없이 보관되는지 함께 확인한다.

최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.

8.4 - 도구 구축 레시피

이 레시피는 폐쇄망에서 SBOM(Software Bill of Materials) 생성과 지속 취약점 감시를 구축하는 예제다. 빠른 출발점으로 기존 cdxgen과 Dependency-Track 파이프라인 튜토리얼을 금융권 기준으로 정리했다. 특정 제품을 권하기보다, 오픈소스·온프레미스 도구로 구축하는 방법을 보여 주는 것이 목적이다.

Dependency-Track 구축

Dependency-Track은 SBOM을 등록해 두면 취약점 데이터베이스가 갱신될 때마다 영향받는 컴포넌트를 자동으로 다시 평가한다. 운영 시스템의 지속 모니터링에 쓴다. 아래는 API 서버와 프런트엔드를 함께 띄우는 docker-compose 예제다.

# docker-compose.yml
volumes:
  dependency-track:

services:
  dtrack-apiserver:
    image: dependencytrack/apiserver:latest
    deploy:
      resources:
        limits:
          memory: 12288m
        reservations:
          memory: 8192m
    ports:
      - "8081:8080"
    volumes:
      - "dependency-track:/data"
    restart: unless-stopped

  dtrack-frontend:
    image: dependencytrack/frontend:latest
    depends_on:
      - dtrack-apiserver
    environment:
      - API_BASE_URL=http://localhost:8081
    ports:
      - "8080:8080"
    restart: unless-stopped

폐쇄망에서는 image 값을 사내 레지스트리 주소로 바꾼다. 예를 들어 dependencytrack/apiserver:latest 대신 registry.internal/dependencytrack/apiserver:4.x처럼 사내에 미러링한 이미지를 가리킨다. 버전 태그는 latest 대신 검증한 고정 버전을 쓰는 것이 안전하다.

API_BASE_URL은 사용자의 브라우저가 API 서버를 호출할 때 쓰는 주소이므로, 사내 서버에 올릴 때는 localhost 대신 그 서버의 호스트명으로 바꾼다(예: http://dtrack.internal:8081).

띄운 뒤 접속해 첫 관리자 비밀번호를 바꾸고, SBOM 업로드에 쓸 API 키를 발급한다.

# 서비스를 올린다
docker compose up -d

# 상태를 확인한다
docker compose ps

환경에 따라 docker compose(플러그인) 대신 docker-compose(하이픈) 명령을 써야 할 수 있다. 하이픈 명령(구버전 v1)은 예제의 deploy.resources 메모리 제한을 무시하므로, 제한을 적용하려면 --compatibility 옵션을 함께 준다.

그림: 구축을 마치고 SBOM을 등록하면 보게 되는 Dependency-Track 대시보드. 화면은 cdxgen·Dependency-Track 튜토리얼의 캡처를 재사용했다. 계정 설정과 API 키 발급의 단계별 화면도 그 튜토리얼에 있다.

SBOM 생성과 등록 연동

cdxgen으로 프로젝트의 SBOM을 만들고, 그 결과를 Dependency-Track에 업로드한다. 업로드된 SBOM은 이후 취약점 데이터베이스가 갱신될 때마다 자동으로 재평가된다. cdxgen은 언어 생태계에 따라 의존성을 해석하면서 빌드 도구와 패키지 저장소에 접근하므로, 폐쇄망에서는 npm·Maven 등의 저장소 설정이 사내 미러를 가리키도록 해 둔 상태에서 실행한다.

# 1) cdxgen으로 CycloneDX 형식 SBOM을 생성한다
#    -r 은 하위 디렉터리의 여러 매니페스트를 재귀로 수집한다
cdxgen --spec-version 1.6 -r -o sbom.json /path/to/project

# 2) Dependency-Track 프로젝트에 SBOM을 업로드한다
curl -X POST "http://localhost:8081/api/v1/bom" \
  -H "X-Api-Key: ${DT_API_KEY}" \
  -F "projectName=my-service" \
  -F "projectVersion=1.0.0" \
  -F "autoCreate=true" \
  -F "bom=@sbom.json"

cdxgen 최신 버전은 CycloneDX 1.7을 기본으로 생성하는데, Dependency-Track 버전에 따라 1.6까지만 받는 경우가 있다. 업로드가 거부되면 위처럼 --spec-version 1.6을 지정해 형식을 맞춘다. autoCreate=true는 같은 이름·버전의 프로젝트가 없으면 새로 만든다. 운영 시스템마다 프로젝트를 두고 SBOM을 등록하면, 신규 취약점이 공개될 때 영향받는 시스템을 한곳에서 파악할 수 있다. 이 흐름은 관리에서 다룬 지속 모니터링을 구현한 것이다.

오프라인 취약점 데이터베이스

폐쇄망에서는 Dependency-Track이 참조하는 취약점 데이터 소스의 주소를 관리 화면에서 내부 미러로 바꿔 구성한다. 데이터 소스별 미러 구성의 난도와 사전 검증, 명령줄 점검 도구(Grype, Trivy)의 캐시 반입 방식은 폐쇄망 운영의 오프라인 취약점 관리에서 다룬다.

도구 선택 기준

이 레시피는 cdxgen과 Dependency-Track을 예로 들었으나, 같은 일을 하는 다른 오픈소스 도구로 바꿔도 된다. 도구를 고를 때는 폐쇄망 운영에서 제시한 기준(온프레미스 설치, 오프라인 데이터베이스 갱신, 표준 형식 입출력, 도구 자체의 라이선스)을 따른다. 도구별 설치와 사용법은 도구 페이지에 정리돼 있다.

최종 검토일: 2026-06-10. 이 페이지는 규제 변화 시, 그리고 연 1회 정기적으로 재검토한다.