들어가며,
평균 7년 이상 운영된 1,000여 개 시스템을 대상으로 오픈소스 사용 기준, 개발환경 표준화, 소스코드 품질관리 정책을 수립하고, 이후 4년간 정책 변경관리와 운영 업무를 이어오고 있습니다. 이 과정에서 확인한 가장 큰 변화는 오픈소스 관리가 단순한 사용 승인이나 취약점 점검에 머물 수 없다는 점이었습니다.
오픈소스 리스크를 제대로 관리하려면, 먼저 우리 조직이 어떤 SW를 어디서 어떻게 쓰고 있는지 볼 수 있어야 합니다. 이 글에서는 오픈소스 관리가 3자 점검으로 확대되는 과정에서 확인한 고객의 Pain과, SW 자산 가시성이 왜 중요한지에 대해 이야기해보려 합니다.
3자 점검이란, 개발 산출물과 운영 환경을 대상으로 보안취약점, 잠재결함, 라이선스, EOS 등의 리스크를 분석/점검하고 조치 이행을 관리하는 활동입니다.오픈소스 관리에서 3자 점검으로
4년 전, 처음에는 오픈소스 관리가 중심이었습니다.
개발 과정에서 사용하는 오픈소스의 라이선스를 확인하고, 보안취약점을 점검하고, 필요한 경우 조치 가이드를 제공하는 일이 주요 업무였습니다. 오픈소스를 안전하게 사용하도록 기준을 만들고, 점검 결과를 관리하는 것이 핵심이었습니다.
하지만 오픈소스는 한 가지 형태로만 존재하지 않습니다. OS, Web/WAS, Kubernetes(K8s)처럼 운영 환경에 직접 설치되는 유형도 있고, 애플리케이션 개발 시 라이브러리 형태로 포함되는 유형도 있습니다. 개발자들이 사용하는 오픈소스까지 분석하다 보니 자연스럽게 소스코드 내 오픈소스 사용 현황까지 관리하게 되었습니다.
이 과정에서 업무는 운영 중인 시스템의 보안취약점, 잠재 결함, EOS, 라이선스 이슈까지 함께 관리하는 3자 점검 체계로 확장되었습니다. 개발팀이 만든 소스코드, 애플리케이션에 포함된 오픈소스, 운영 환경에서 사용 중인 소프트웨어까지 점검 범위가 넓어진 것입니다.
그러면서 자연스럽게 더 근본적인 질문을 마주하게 되었습니다.
"우리는 점검해야 할 SW를 정확히 알고 있는가?"
점검 도구를 적용하고 결과를 분석하는 일도 중요하지만, 그보다 먼저 필요한 것은 점검 대상의 명확한 식별입니다. 어떤 시스템을 점검해야 하는지, 어떤 애플리케이션이 운영 중인지, 어떤 서버에 어떤 소프트웨어가 설치되어 있는지, 어떤 오픈소스 컴포넌트가 포함되어 있는지 알아야 리스크도 찾을 수 있습니다.
이 경험은 오픈소스 거버넌스가 단순히 오픈소스 사용 승인이나 취약점 점검만으로 끝나지 않는다는 점을 보여주었습니다.
고객의 Pain은 ‘점검 결과’보다 ‘가시성 부족’에서 시작된다
3자 점검에서 이슈가 발견되면 빠른 조치가 필요합니다. 하지만 실제 현장에서는 시스템 릴리즈 계획, SW 버전 업데이트 , 예산 확보 등의 문제로 즉시 조치가 어려운 경우가 많습니다. 그래서 점검 결과보다는 조치 계획의 현실성을 더 자주 질문받게 됩니다.
하지만, 이것보다 더 큰 어려움은 조직 내 SW 현황이 한눈에 보이지 않는다는 점이었습니다.
개발팀은 소스코드와 라이브러리 기준으로 시스템을 바라봅니다. 운영팀은 서버, 패키지, 설치 소프트웨어 기준으로 관리합니다. 보안팀은 취약점과 조치 현황을 중심으로 봅니다. IT기획 담당자는 전사 관점에서 비용, 정책, 리스크를 함께 보고 싶어 합니다.
각 조직의 관점은 모두 필요합니다. 문제는 이 정보들이 서로 연결되어 있지 않을 때 발생합니다.
같은 시스템을 두고도 부서마다 다른 목록을 가지고 있고, 담당자별로 관리 기준이 다르며, 점검 대상과 운영 대상이 일치하지 않는 경우도 있습니다. 이럴 때 점검 결과가 나와도 "누가 조치해야 하는지", "어떤 시스템에 영향이 있는지", "정책상 예외로 볼 수 있는지"를 판단하기 어렵습니다.
결국 고객의 Pain은 SW가 보이지 않으면 리스크도, 비용도, 책임도 명확하게 관리하기 어렵다는 것입니다.
SBOM 이 해결책이 될 수 있을까?
최근 SW 공급망을 통한 보안 위협이 반복되면서 SBOM(Software Bill of Materials)에 대한 관심도 높아지고있습니다.
SBOM이 중요한 이유는 취약점 대응 속도와 직접 연결되기 때문입니다. 특정 오픈소스 취약점이 공개되었을 때 조직이 가장 먼저 해야 할 일은 영향 범위를 확인하는 것입니다. 취약한 컴포넌트를 어느 시스템이 사용하고 있는지, 어떤 버전이 적용되어 있는지, 운영 중인 서비스에 영향이 있는지 빠르게 파악해야 합니다.
SBOM은 이 문제를 가장 빨리 해결할 수 있는 데이터입니다. SBOM이 없거나 최신 상태로 관리되지 않으면 대응은 담당자 문의와 수작업 확인에 의존하게 됩니다. 개발 산출물을 다시 확인하고, 운영 서버 정보를 비교하고, 시스템 담당자에게 사용 여부를 확인하는 과정에서 시간이 지연됩니다. 이 지연은 단순한 업무 비효율이 아니라, 보안 리스크로 이어질 수 있습니다.
실제로 특정 오픈소스 취약점 이슈가 발생했을 때, SBOM과 3자 점검 체계가 연결되어 있었기 때문에 약 2시간 만에 영향 시스템을 식별하고 임원 보고까지 완료한 경험이 있습니다. 이 경험은 SBOM이 단순 산출물이 아니라 리스크 대응 속도를 좌우하는 운영 데이터라는 점을 보여주었습니다.. (Axios 이슈 발생했을 때 2시간 만에 리스크 식별하고 임원 보고까지 완료. )
하지만 SBOM만으로 모든 문제가 해결되는 것은 아닙니다. 시중에 많은 SCA도구들이 SBOM을 관리하는 기능을 제공하고 있어서 SCA 로 SW 자산을 식별할 수 있다고 생각하기 쉽습니다.
그러나, 3자 점검같은 운영체계가 없었다면 SBOM은 어떻게 활용되었을까요? SBOM은 데이터일 뿐, 이것을 어떤 정책으로 운영할지는 시스템 오너가 조직 기준에 맞춰 판단하는 정책과 프로세스가 더 중요합니다.
SBOM은 해결책 그 자체라기보다 리스크 대응을 가능하게 하는 중요한 기반 데이터입니다.
정책은 문서가 아니라 실행 기준이어야 한다
3자 점검 서비스 운영 시 자주 확인되는 또 다른 어려움은 정책 관리입니다.
많은 조직은 이미 보안취약점 관리 정책, 오픈소스 사용 정책, 라이선스 검토 기준, EOS대응 기준을 가지고 있습니다. 하지만 실제 현장에서는 정책이 운영 방식과 맞지 않아 어려움이 발생합니다.
예를 들어 정책에는 "고위험 취약점은 조치해야 한다"고 되어 있지만, 실제로는 서비스 영향도, 릴리즈 일정, 운영 중단 가능성, 대체 버전 존재 여부를 함께 고려해야 합니다. 정책에는 "오픈소스 사용 시 사전 검토가 필요하다"고 되어 있지만, 개발 현장에서는 수많은 라이브러리가 CI/CD 과정에서 빠르게 추가되고 변경됩니다.
이처럼 정책이 현장의 속도와 기술 환경을 따라가지 못하면 정책은 지켜야 할 기준이 아니라 부담스러운 절차가 됩니다. 반대로 정책이 너무 느슨하면 조직은 리스크를 통제할 수 없습니다.
중요한 것은 정책을 현실적인 운영 기준으로 만드는 일입니다.
어떤 SW를 관리 대상으로 볼 것인지, 취약점 등급별 조치 기준은 무엇인지, 예외 승인은 누가 어떤 근거로 판단할 것인지, 조치 이력은 어디에 남길 것인지가 명확해야 합니다. 그리고 이 기준은 SW 자산 정보, SBOM, 점검 결과, 조치 프로세스와 연결되어야 합니다.
정책 관리는 문서를 정비하는 일이 아니라, 조직이 SW 리스크를 일관되게 판단하고 실행할 수 있도록 만드는 일이어야 합니다.
오픈소스 리스크는 다양한 관점에서 관리해야 한다.
SCA 도구로 소스코드나 바이너리를 스캔하면 보안취약점, 위험 라이선스, EOS 같은 리스크를 식별할 수 있습니다. 하지만 도구가 발견한 결과만을 오픈소스 리스크 관리라고 보면 한계가 있습니다.
중요한 것은 발견된 리스크가 어떤 시스템에 영향을 주는지, 왜 발생했는지, 누가 조치해야 하는지, 정책상 예외로 볼 수 있는지, 향후 같은 문제가 반복되지 않도록 어떤 기준을 보완해야 하는지까지 연결해 보는 것입니다.
결국 오픈소스 리스크 관리는 점검 결과를 나열하는 일이 아닙니다. SW를 식별하고, 리스크를 판단하고, 조치 이행을 추적하고, 정책을 개선하는 운영 활동입니다.
그리고 이 모든 과정의 출발점은 SW 자산에 대한 가시성입니다.
마치며
오픈소스 관리에서 시작된 업무가 3자 점검으로 확대된 것은 자연스러운 흐름이었습니다. 오픈소스를 안전하게 사용하려면 무엇을 사용하는지 알아야 하고, 소스코드와 오픈소스를 점검하려면 어떤 시스템이 대상인지 알아야 합니다. 취약점과 라이선스 리스크를 조치하려면 책임 조직과 판단 기준도 명확해야 합니다.
이제 오픈소스 거버넌스는 별도의 점검 활동으로만 볼 수 없습니다. 오픈소스 리스크를 제대로 관리하려면 조직이 보유하고 사용하는 SW를 볼 수 있어야 합니다. 보이지 않는 SW는 관리할 수 없습니다. 관리되지 않는 SW는 보안 리스크, 운영 리스크, 비용 리스크로 돌아옵니다.
오픈소스 리스크 관리는 결국 SW 자산에 대한 가시성에서 시작됩니다. 다음 글에서는 이 가시성을 기반으로 SW 자산관리를 어떻게 바라봐야 하는지, 그리고 SBOM·점검 결과·정책·조치 이력을 어떻게 연결해야 하는지 이야기해보겠습니다.
강윤미, 아날로그를 좋아하는 IT 기획자
엔지니어와 조직 사이에서,
SW/IT 거버넌스 전략을 만들어가고 있습니다.
#오픈소스거버넌스 #SW리스크 #People&Process