인공지능 시대 오픈소스 리스크, 이제는 스캔만으로 못 버틴다

• 오픈소스는 이제 “편하게 가져다 쓰는 코드”가 아니라 제품 신뢰도를 좌우하는 공급망 이슈가 됐음

  • 모바일 앱, 금융 서비스, 의료 시스템, 국가 핵심 인프라까지 오픈소스 없이 돌아가는 소프트웨어를 찾기 어려운 수준임
  • 개발 생산성과 혁신 속도를 올려주는 건 맞지만, 어떤 오픈소스를 쓰는지 모르면 사고가 났을 때 영향 범위도 못 잡는다는 게 문제임

• Log4Shell은 그 현실을 제대로 보여준 사건이었음

  • 2021년 Log4Shell 취약점 때 많은 기업이 자기 시스템에 어떤 오픈소스가 들어가 있는지조차 제대로 파악하지 못했음
  • 2025년 React2Shell 사례도 언급됐는데, React를 직접 쓰지 않는 조직까지 복잡한 공급망 때문에 간접 영향을 받을 수 있다는 포인트임
  • 결국 직접 의존성만 보는 시대가 아니라, 전이 의존성까지 따라가야 하는 시대가 된 거임

• 규제 압박도 커지고 있음

  • 유럽연합 사이버복원력법, 미국 SBOM 의무화, 국내 소프트웨어 공급망 보안 가이드라인, 디지털의료제품법까지 언급됨
  • 오픈소스 관리 체계를 입증하지 못하면 시장 진입 자체가 어려워지는 환경이 만들어지고 있음
  • 보안팀만의 선택이 아니라 제품 출시와 사업 확장에 직접 걸리는 문제가 된 셈임

• 글에서 제일 강조하는 출발점은 “반입 제어”임

  • 흔히 오픈소스 거버넌스를 SBOM 생성이나 취약점 스캔부터 떠올리지만, 기고문은 외부 오픈소스가 조직 안으로 들어오는 순간부터 통제해야 한다고 봄
  • 개발자가 외부 공개 저장소에 바로 접근하기 전에 사내 저장소를 거치게 하고, 모든 반입 이력을 남기는 구조가 필요하다는 주장임
  • 라이선스와 취약점 검증을 통과한 컴포넌트만 승인 저장소에 올리고, 개발자 빌드 환경이 그 저장소를 참조하도록 해야 검증 안 된 의존성 유입을 줄일 수 있음

• 내부 오픈소스 포털도 단순 편의 기능이 아님

  • 승인된 오픈소스 목록, 권장 버전, 라이선스 정보를 개발자가 볼 수 있어야 함
  • 새 취약점이 공개되면 영향받는 프로젝트와 권장 패치 버전을 안내할 수 있어야 함
  • 신규 오픈소스 도입 요청과 승인 워크플로도 한곳에서 처리하면, 개발자가 매번 보안팀에 물어보지 않아도 의사결정이 빨라짐

• 반입 이후에는 소프트웨어 개발 생명주기 전체를 봐야 함

  • 도입 당시 안전했던 컴포넌트도 시간이 지나 새 취약점이 나오거나 라이선스 정책이 바뀔 수 있음
  • 그래서 사용 중인 오픈소스 목록을 계속 최신 상태로 유지하고, 신규 취약점 정보를 보유 자산과 매핑하는 프로세스가 필요함
  • 이 접근은 보안을 개발과 운영 흐름 속에 넣는 DevSecOps 원칙과 맞닿아 있음

• 자동화의 핵심은 CI/CD 파이프라인에 SCA 도구를 넣는 것임

  • 코드가 커밋되고 빌드되는 시점마다 의존성을 분석해 SBOM을 만들고 취약점을 검출하도록 구성하는 방식임
  • 다만 자동 스캐닝은 알람을 많이 만들 수 있어서, 중요한 위협을 선별하는 우선순위 정책도 같이 필요함
  • 자동화만 있고 우선순위가 없으면 개발팀 입장에서는 경고 피로만 쌓일 수 있음

• 조직 구조로는 OSPO가 필요하다고 봄

  • OSPO는 오픈소스 정책과 프로세스를 만들고, 기술 인프라를 고르고 운영하며, 경영진에게 리스크와 비즈니스 가치를 함께 전달하는 역할임
  • 개발, 보안, 법무, 사업 부서가 같이 얽히는 주제라 특정 부서 혼자 맡기 어렵다는 지적도 나옴
  • 경영진 차원의 권한 부여가 있어야 실제 의사결정 경로가 조직 전체에 먹힌다는 얘기임

• 인공지능 시대에는 관리 대상이 더 넓어짐

  • 머신러닝 프레임워크, 모델, 학습 데이터까지 오픈소스 형태로 유통되기 때문임
  • 전통적인 취약점, 공급망 위협, AI-BOM 같은 영역까지 거버넌스가 다뤄야 할 범위가 커지고 있음
  • 결국 오픈소스를 얼마나 잘 관리하며 활용하는지가 제품 신뢰도와 기업 경쟁력으로 이어진다는 결론임

---

기술 맥락

• 이 글의 핵심 선택은 오픈소스를 “나중에 스캔”하는 방식에서 “처음 들어올 때부터 통제”하는 방식으로 바꾸자는 거예요. 이미 제품 곳곳에 퍼진 뒤에는 어떤 서비스가 영향을 받는지 찾는 비용이 너무 커지거든요.

• SBOM이 중요한 이유도 단순 문서 제출 때문만은 아니에요. 취약점이 공개됐을 때 어떤 버전의 어떤 컴포넌트가 어느 제품에 들어갔는지 알아야 패치 우선순위를 정할 수 있어요. 이 정보가 없으면 대응은 보안 업무가 아니라 수색 작업이 돼요.

• CI/CD에 SCA 도구를 붙이는 건 개발 속도를 막기 위해서가 아니에요. 커밋과 빌드 시점에 의존성 문제를 빨리 발견해야 나중에 릴리스 직전 대형 수정으로 번지지 않거든요. 다만 경고가 너무 많으면 개발자가 무시하게 되니, 위험도 기반 우선순위가 꼭 같이 필요해요.

• OSPO가 필요한 이유는 오픈소스 결정이 기술만의 문제가 아니기 때문이에요. 취약점은 보안팀, 라이선스는 법무, 배포 일정은 개발팀, 제품 책임은 사업팀과 연결돼요. 이걸 한 조직이 조율하지 않으면 정책은 있어도 실제 현장에서는 각자 다른 기준으로 움직이게 돼요.