제주은행이 오픈소스 스캐너 도입을 서두르는 이유

• 제주은행이 올해 3분기 안에 소프트웨어 구성 분석(SCA) 솔루션을 들여오겠다고 밝힘

  • 이유는 꽤 현실적임. 금융감독원 취약점 공지는 매일 오는데, 내부 서버에 어떤 오픈소스가 어느 버전으로 깔려 있는지 바로 알기 어렵다는 거임
  • 신동일 제주은행 정보보호파트 프로는 “전 서버를 분석해 어느 서버에 어떤 오픈소스와 버전이 있는지 알아야 대응할 수 있다”고 말함

• 금융권도 이제 외부 오픈소스 의존도가 꽤 높아진 상태임

  • 차세대 시스템 구축 과정에서 외주 솔루션과 다양한 라이브러리가 들어오면서, 내부에서 직접 짠 코드만 보면 보안이 끝나는 구조가 아니게 됨
  • 자동화 도구가 없으면 취약점 공지가 올 때마다 관련 부서에 확인 서류를 돌려야 함. 말 그대로 사람이 인벤토리를 뒤지는 방식임

• 제주은행은 이미 2021년 10월부터 사스트(SAST)를 개발 파이프라인에 붙여 쓰고 있음

  • SAST는 프로그램을 실행하기 전에 소스코드 자체를 스캔해서 취약점을 잡는 방식임
  • 예전에는 보안 담당자 중심으로 취약점 점검이 돌아가면서 소스 수정과 재점검을 최대 10차례 반복하는 일도 있었다고 함
  • 이후 형상관리 시스템 이캠스(eCAMS)에 SAST를 연동해서, 개발자가 직접 점검하고 취약점이 있으면 자동으로 반영을 차단하는 흐름을 만들었음

• 이번에 추가되는 SCA는 SAST가 못 보는 영역을 맡음

  • SAST가 자체 개발 코드의 취약점을 찾는다면, SCA는 서버 안에 들어간 외부 오픈소스와 라이브러리 버전을 식별함
  • 취약점 공지가 내려왔을 때 수동 확인 없이 영향받는 서버와 구성요소를 바로 찾는 게 목표임

• 제주은행은 SCA와 기존 SAST를 서로 연동하려는 계획도 밝힘

  • 소스코드 반입 단계부터 배포, 운영까지 이어지는 공급망 보안 프로세스를 자동화하려는 그림임
  • 최근에는 제로 트러스트 도입 컨설팅도 마쳤고, 10개 핵심 과제까지 도출했다고 함

---

기술 맥락

• 제주은행의 선택은 “코드를 잘 검사하자”에서 “운영 중인 소프트웨어 구성까지 계속 추적하자”로 넓어진 거예요. SAST만으로는 직접 작성한 코드의 결함은 볼 수 있지만, 서버 안에 들어간 외부 라이브러리 버전까지 안정적으로 파악하긴 어렵거든요.

• SCA가 중요한 이유는 취약점 대응의 첫 질문이 달라지기 때문이에요. 보안 공지가 오면 패치 자체보다 먼저 “우리 시스템에 해당 버전이 있나”를 알아야 하는데, 이걸 부서별 문서 확인으로 처리하면 금융권 규모에서는 너무 느려져요.

• 제주은행은 이미 eCAMS와 SAST를 묶어 개발 단계의 차단 흐름을 만든 상태예요. 여기에 SCA를 붙이면 개발 단계의 코드 취약점, 배포 이후의 오픈소스 구성, 운영 중 취약점 대응까지 같은 관리 체계 안에 넣을 수 있어요.

• 제로 트러스트 컨설팅까지 언급된 걸 보면, 이건 단순히 스캐너 하나 사는 얘기가 아니에요. 소스 반입, 빌드, 배포, 운영 서버 식별까지 이어지는 공급망 보안 운영 모델을 만들려는 쪽에 가까워요.