▲

더 적게 의존할수록 안전하다: 공급망 공격 위험을 줄이는 Obsidian의 접근 방식

 (obsidian.md)
10P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 공급망 공격은 오픈소스 코드에 악성 업데이트가 숨어들어오는 방식이며, Obsidian은 이를 최소화하기 위해 외부 의존성 자체를 줄이는 전략을 사용
  • 앱 기능 대부분을 직접 구현하거나, 필요할 경우 포크된 코드를 자체 코드베이스에 포함하여 관리
  • 필수적인 대형 라이브러리(pdf.js, Mermaid, MathJax 등)는 버전 고정을 통해 안전성을 확보하고, 업데이트는 보안 패치가 있을 때만 신중하게 진행
  • 모든 의존성은 lockfile로 고정하며, postinstall 스크립트를 실행하지 않아 설치 시 임의 코드 실행을 차단
  • 이러한 신중한 업데이트 절차와 시간 지연 전략을 통해 Obsidian은 잠재적 위협이 커뮤니티에서 탐지되기 전에 대응 가능

공급망 공격이란 무엇인가

  • 공급망 공격은 오픈소스 생태계에서 악성 업데이트가 배포 코드에 숨어드는 방식
  • 많은 앱들이 오픈 소스 코드를 사용하기 때문에, 하나의 악성 업데이트가 파급적으로 여러 앱에 영향을 주게 됨
  • Obsidian은 의존성을 최소화하는 전략을 통해 이러한 공격 표면을 줄이고, 앱을 안전하게 설계함

의존성 최소화 전략 : Less is Safer

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

실제 앱에 포함되는 요소

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

버전 고정과 lockfile 관리

  • 모든 외부 의존성은 엄격한 버전 고정(pin) 및 lockfile 커밋을 통해 관리함
  • 이를 통해 설치가 항상 재현 가능하며, 변경 내역 추적이 용이함
  • postinstall 스크립트 미실행 정책을 통해, 설치 중 임의의 코드 실행 가능성을 원천적으로 차단

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

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

안정성을 위한 "시간적 여유" : Time is a buffer

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

결론

  • 단일 보안 대책만으로는 공급망 공격 위험을 완전히 제거할 수 없음
  • 그러나 Obsidian은 의존성 최소화, 얕은 그래프, 버전 고정, postinstall 금지, 검토 중심의 느린 업데이트를 병행해 위험을 대폭 감소시키고 있음
  • 이런 절차를 통해 코드가 사용자에게 도달하기 전 위험 탐지 시간도 크게 확보할 수 있음
  • Obsidian의 전체 보안 접근법 및 과거 보안 감사 내역은 공식 security page에서 확인 가능함
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 대부분의 사용자는 Obsidian에서 서드파티 커뮤니티 플러그인을 사용함을 간과하는 의견이 많음, 실제로 Obsidian의 플러그인 보안 모델은 매우 취약함, 플러그인이 볼트 내 모든 파일 접근 권한을 갖게 되어 있음, Obsidian이 직접 더 많은 기능을 내장하는 노력을 기울였다면 보안 위험이 줄었을 것임, 또는 브라우저 확장처럼 플러그인이 사용하는 권한을 명시하고, 허가되지 않은 권한 접근을 차단하는 구조로도 개선 가능함, 이 모두가 “서드파티 의존성이 적다”는 논리보다 훨씬 실제적인 사용자 보안을 제공함

    • 예전 소프트웨어계의 몇몇 인사들이 비디오 게임 디자인의 아이디어가 다른 일반 소프트웨어로 흘러들어오는 사례를 이야기했으나 이제는 거의 들리지 않음, 블리자드와 같은 오래된 게임 회사의 핵심 인력이 World of Warcraft의 플러그인 시스템 초창기 10년간 작동 원리, 문제점, 보안 강화 과정을 자세히 정리한 책을 쓴다면 소프트웨어 전체 생태계에 큰 도움이 될 것임, 많은 프로젝트의 플러그인 시스템은 허술함과 어설픔이 뒤섞여 있음

    • Obsidian 플러그인은 볼트 내 파일뿐 아니라 컴퓨터의 모든 파일에 접근할 수 있음, 예전에 Discord에서 이 점을 지적했지만 무시당한 경험이 있음

    • Arch Linux와 유사하게 생각함, AUR에서 소프트웨어를 직접 관리할 때 엔지니어들도 보안을 어렵게 다룸, 일반 사용자가 보안을 책임지도록 기대하는 것은 무리임

    • 조만간 Obsidian 플러그인 중에서 데이터 유출 사례가 드러날 것이라 생각함, 그때가 되면 팀에서 보안 장치를 도입할 것임, 최소한 인증된 퍼블리셔 시스템 도입이 필요함

    • 상업적으로 Obsidian 플러그인 개발 중임, 일정 수준 이상의 플러그인을 위한 더 높은 수준의 심사 프로세스가 있었으면 함, Arch Linux의 AUR처럼 커뮤니티 관리 저장소와, 더 엄격한 심사 저장소 두 가지를 운영하면 플러그인 검토 속도 개선과 보안 향상에 도움이 될 것임

  • “공급망 공격은 많은 앱에 사용되는 오픈소스 코드에 악성 업데이트가 숨어드는 것”이라는 설명이 있는데, 오픈소스(FOSS)가 아닌 어떤 소스코드든 공격 대상이 될 수 있음, FOSS가 반드시 더 취약하다는 인식은 문제임

  • “설치 중 postinstall 스크립트를 실행하지 않는다”는 방침은 좋은 의도이긴 하지만, 패키지가 이미 손상되었다면 postinstall을 생략해도 남은 코드가 안전하진 않음, 패키지가 정상이라면 postinstall이 합법적 설치를 도울 수도 있음, 실제 사고는 공급망 공격보다는 일반 취약점 패치에서 더 많이 발생하므로, 업데이트를 막는 것이 오히려 위험을 높일 수 있음

    • 오늘날에는 보안 스캐닝이 보통 설치 이후(post install)에 이뤄짐, 설치 중에는 아무 것도 실행되지 않게 막는 게 좋음, 앞으로 설치 단계에서 스캔이나 제한을 하는 기능이 더 많아지길 바람, 일부 상용 툴에서 지원하긴 해도 보편적이지 않음

    • 그래도 빌드 머신을 보호하는 데에는 의미 있음, 임의의 스크립트가 내 수많은 의존성에서 실행되는 걸 걱정하지 않아도 됨

  • 사용자에게 배포하는 모든 코드에 대한 책임은 개발자에게 있음, 의존성을 고정하지 않으면 "인터넷에서 무작위 코드 다운받고 운을 믿는 꼴"임

    • 의존성을 고정하면 이후 보안 패치를 놓칠 수 있음, 이 역시 위험하므로, 새로운 보안 패치가 나오면 이를 인지할 수 있는 시스템이 반드시 필요함, 해당 패치를 백포트하거나 새로운 버전으로 업데이트해야 함

    • 고정된 의존성도 그 자체로 또 다른 의존성을 포함하고 있어, 결국 항상 "무작위 코드 다운받고 희망하는" 구조임, 특히 Electron 기반 앱엔 정말 엄청난 양의 코드가 따라옴

  • 최근 자주 접하는 조언 중, 패치 릴리즈가 나와도 의존성을 업데이트하지 말라는 의견이 있는데 이해가 가지 않음, 업데이트를 하지 않으면 악성코드 설치 위험이 줄 수도 있으나, 보통 패치는 보안 개선 목적임, 최신 패치를 적용하지 않는 것이 현명한 선택인가 궁금함

    • 패치를 적용하는 이유와 변경 내용을 파악하는 것이 핵심임, 모든 소스코드를 다 읽을 시간은 없으니, 주요 도구와 서비스(Npm Audit 등)를 활용해 취약점 요약 정보를 확인함, 나는 반드시 필요하지 않는 한 업데이트를 미루는 전략을 씀, 업데이트는 공격 벡터이면서 버그의 주요 원인이기도 하기 때문임, 그러나 어떤 취약점에 노출됐는지는 반드시 주기적으로 점검함, 사용하지 않는 기능의 취약점이라면 업데이트를 미루기도 함, 정말 중요한 결함만 바로 업데이트함, 보안은 능동적이고 지속적인 프로세스이며 조직의 위험 허용 수준에 따라 대응이 달라져야 함, 단순히 "항상 업데이트" 또는 "절대 업데이트 안 함"이 답이 아님

    • 요즘 Z-WaveJS UI를 업데이트할 때마다 의존성 업데이트가 반복됨, 이런 불만족스러운 패턴 때문에 직접 확인하고 있음, 오늘날은 모두가 의존성을 의존하는 시대라 "끝은 없다", 자동업데이트 한번만 해도 위험함

    • 업데이트 시 개선 또는 퇴보 위험이 항상 존재하며, npm 생태계(Obsidian이 해당됨)에서는 그 위험이 훨씬 큼, npm은 악성 패키지 제거에 사람의 개입이 필요해 처분이 느림, 업데이트를 일부러 늦추면 그나마 방어할 수 있음

    • 최근에는 패치 릴리즈 직후 조금 기다렸다가 설치하는 추세임, 요즘은 사고가 몇 시간 내에 적발되는 경우가 많음, 여러 기업이 npm 감시하며 보안 비즈니스도 하고 있음, pnpm은 패키지 배포 후 X분 이상 지난 패키지만 설치할 수 있게 설정할 수 있음, 나는 최소 24시간 정도는 기다림 pnpm minimumreleaseage 설정

    • 2주 전 내 패키지가 받은 공격은 패치 릴리즈를 노린 것이었음, postinstall 스크립트가 아니었음, 자동화된 스캐닝이 빠르게 적발하므로 이 문제가 이제는 크게 부각되지 않음, 패키지의 취약점 발견 시 즉각 알림이 오고 분명함, version ranges 사용은 공급망 공격 대응에 최악임

  • Electron, CodeMirror, moment.js만 포함해서 패키지가 크지 않다는 주장에 동의하기 힘듦, Electron은 웹뷰 기반으로 엄청난 복잡성을 가진 소프트웨어이며, moment.js는 이미 더 나은 API가 있음, Obsidian의 의존성 관리 수준은 오히려 최소한의 기준일 뿐 특별히 대단한 보안 정책으로 느껴지지 않음, 그래도 보안 감사를 정기적으로 한다는 점은 긍정적임

  • Obsidian 말고 다른 앱을 써왔는데, Obsidian도 관심이 생기기 시작함, Electron 앱이라는 점이 자원을 많이 잡아먹고 네이티브가 아니어서 JS가 늘 불안하게 느껴짐, 내가 너무 옛날 감성인가 궁금함

    • JavaScript는 매우 안전한 언어임, 웹 브라우저가 전세계적으로 JavaScript를 안전하게 실행시키는 성공적인 예임, 각 웹사이트는 서로의 데이터를 읽지 못함, Electron도 JavaScript를 v8 엔진에서 샌드박싱함, 사용자 입력 코드 실행만 피하면 아주 안전함, 공급망 공격 문제는 npm 자체 때문이고, JS 언어 문제는 아님, npm이 패키지 배포 시 보안 정책을 더 엄격하게 적용할 책임이 있음

    • 자바스크립트는 어느 기준으로 측정하든 세계에서 가장 많이 사용되는 언어 중 하나임, 거의 모든 컴퓨터와 스마트폰에서 돌아감, 그만큼 보안 이슈가 더 자주 발견됨, 네이티브 앱이라고 해서 더 안전하다는 근거는 없음

    • Electron 앱이 문제가 되진 않음, GitHub, VS Code, Slack, Discord, Postman 모두 Electron 기반임, 나는 자주 묻고 싶음, 마크다운 노트앱에서 정말 성능이 문제가 될 수 있는 무슨 작업을 하나? 혹시 정말 옛날 노트북으로 Lynx 브라우저에 텍스트 전용으로 보나 궁금할 정도임

    • Electron은 그닥 좋아하지 않음(그래서 tauri 좋아함), 그래도 Obsidian 자체는 매우 훌륭해서 Electron 탓에 외면할 필요 없음, MCP와 연동해서 개인용 지식베이스로 쓰기도 좋아서 추천함

    • Electron이 무겁긴 함, PC에선 별 문제 안되지만 모바일에서는 노트 수천 개가 쌓이면 플러그인 없이도 앱 시작이 느려짐, 유저들은 빠른 기록용 플러그인/앱으로 우회하고 있지만, 더 가벼운 네이티브 Obsidian가 있었으면 하는 바람임

  • Obsidian은 Electron 기반이고 그 특성상 무거움과 보안 취약 위험이 따름

    • 하지만 모든 플랫폼에서 똑같은 UX와 네이티브 수준의 접근성을 지원함

  • Emacs와 Org-Roam을 사용하며, 네트워크 연결 없는 VM(Qubes OS의 Qube)에서 운영함, Emacs에서 실행되는 모든 코드를 직접 검토할 수 없음

  • 네이티브 앱과 공급망 위험을 더 낮추고 싶은 경우, GTK 기반이고 주요 리눅스 배포판에서 패키징된 Zim 위키가 대안임 Zim 위키 바로가기

    • Zim 위키는 네이티브 모바일 앱과 동기화 기능이 없는데, 이 점 때문에 Obsidian에 끌림, 플러그인만 무작위로 설치하지 않으면 충분히 보안적으로 괜찮음
답변달기