공급망 공격 위험을 줄이는 Obsidian의 접근 방식

• 공급망 공격은 애플리케이션에서 널리 사용되는 오픈 소스 코드를 통해 악성 업데이트가 침투하는 현상임
• Obsidian은 타사 코드 의존성 최소화를 통해 공격 표면을 줄이는 전략을 채택함
• 주요 기능들은 직접 구현하거나, 필요한 경우 포크 후 내부 관리함
• 모든 의존성은 버전 고정 및 lockfile로 관리하며, postinstall 스크립트 차단으로 추가 위험을 방지함
• 업데이트 검토 및 배포 지연 절차를 통해 잠재적 문제가 사전에 발견될 수 있도록 함

공급망 공격이란 무엇인가

• 공급망 공격은 오픈 소스 코드에 악성 업데이트가 끼어드는 현상임
• 많은 앱들이 오픈 소스 코드를 사용하기 때문에, 하나의 악성 업데이트가 파급적으로 여러 앱에 영향을 주는 구조임
• Obsidian은 사용자의 생각을 안전하게 보호하는 환경을 목표로, 자체 설계의 보안 정책을 강조함

의존성 최소화 전략

• Obsidian은 카테고리 내 다른 앱과 비교해 매우 적은 수의 외부 라이브러리에 의존함
• 주요 기능(예: Bases, Canvas)은 외부 라이브러리 도입 대신 자체 구현 진행
  • 이를 통해 실행되는 코드에 대한 완전한 제어력 확보 가능함
• 소규모 유틸리티 함수는 거의 항상 개발팀이 직접 구현함
• 중간 규모 모듈은 라이선스 허용 시 포크하여 코드베이스에 포함함
• 대형 라이브러리(pdf.js, Mermaid, MathJax 등)는 검증된 버전을 잠궈서 포함하고, 중요 보안 이슈가 발견될 때에만 최소한으로 업그레이드함
• 모든 외부 변경 사항을 상세히 검토하고, 철저한 테스트 절차 수행함
• 이러한 방식으로 서브 의존성 개수도 최소화하여, 악성 코드가 유입될 일차적인 위험 자체를 줄이는 구조임

실제 앱에 포함되는 요소

• 실제로 사용자가 실행하는 앱에는 Electron, CodeMirror, moment.js 등 아주 소수의 패키지만 포함됨
• 그 외의 개발 도구들은 앱 빌드 과정에만 사용되고, 최종 사용자에게는 전달되지 않음

버전 고정과 lockfile 관리

• 모든 외부 의존성은 엄격한 버전 고정 및 lockfile 커밋을 통해 관리함
• lockfile은 빌드의 기준이 되기 때문에, 설치 결과의 일관성 및 검토 이력 확보가 가능함
• postinstall 스크립트 미실행 정책을 통해, 설치 중 임의의 코드 실행 가능성을 원천적으로 차단함

느리고 신중한 업데이트 절차

• 의존성 업그레이드가 필요할 때에는 아래와 같은 체계적 검토 절차를 진행함
  • 변경 기록(changelog) 세밀 검토
  • 새 버전에서 추가된 하위 의존성 확인
  • 변화 폭이 크거나 위험 요소가 있는 경우 코드 diff 직접 확인
  • 주요 경로 및 플랫폼에 대해 자동/수동 테스트 실시
  • 위 모든 단계 통과 이후에만 lockfile 커밋 진행
• 대부분의 의존성은 자주 변경이 필요하지 않기 때문에, 업데이트 빈도 자체가 낮음
• 새로운 외부 코드 도입은 기존 의존성 신규 채택 수준의 경계로 관리함

안정성을 위한 "시간적 여유"

• 각종 업그레이드는 즉시 배포하지 않고 일정 기간 지연시킴
• 이 기간 동안 오픈 소스 커뮤니티 및 보안 연구자들이 악성 버전을 탐지할 수 있는 사전 대응 창구로 작용함
• 실제 배포 시점에는 이미 문제가 확인될 확률이 높아, 위험 최소화에 효과적임

결론

• 단일 보안 대책만으로는 공급망 공격 위험을 완전히 제거할 수 없음

• 그러나 Obsidian은 의존성 최소화, 얕은 그래프, 버전 고정, postinstall 금지, 검토 중심의 느린 업데이트를 병행해 위험을 대폭 감소시키고 있음

• 이런 절차를 통해 코드가 사용자에게 도달하기 전 위험 탐지 시간도 크게 확보할 수 있음

• Obsidian의 전체 보안 접근법 및 과거 보안 감사 내역은 공식 security page에서 확인 가능함