Меньше значит безопаснее: как Obsidian снижает риск атак на цепочку поставок Атаки на цепочку поставок — это злонамеренные обновления, которые проникают в открытый исходный код, используемый многими приложениями. Вот как мы проектируем Obsidian, чтобы гарантировать, что приложение является безопасной и приватной средой для ваших мыслей. Меньше значит безопаснее Это может показаться очевидным, но основной способ, которым мы снижаем риск атак на цепочку поставок, — это избегание зависимости от стороннего кода. У Obsidian небольшое количество зависимостей по сравнению с другими приложениями в нашей категории. Смотрите список открытых библиотек на нашей странице Кредиты. Такие функции, как Bases и Canvas, были реализованы с нуля, вместо того чтобы импортировать готовые библиотеки. Это дает нам полный контроль над тем, что работает в Obsidian. - Для небольших утилитарных функций мы почти всегда переimplementируем их в нашем коде. - Для средних модулей мы форкаем их и храним внутри нашей кодовой базы, если лицензии это позволяют. - Для крупных библиотек, таких как pdf.js, Mermaid и MathJax, мы включаем известные хорошие, зафиксированные по версиям файлы и обновляем их только время от времени или когда выходят исправления безопасности. Мы читаем примечания к релизам, смотрим на изменения в upstream и тщательно тестируем перед переключением. Этот подход сохраняет нашу граф зависимостей мелким с небольшим количеством подзависимостей. Меньшая площадь поверхности снижает вероятность того, что злонамеренное обновление пройдет незамеченным. Что на самом деле входит в приложение Только небольшое количество пакетов является частью приложения, которое вы запускаете, например, Electron, CodeMirror, moment.js. Другие пакеты помогают нам строить приложение и никогда не отправляются пользователям, например, esbuild или eslint. Фиксация версий и lock-файлы Все зависимости строго зафиксированы по версиям и зафиксированы с помощью lock-файла. Lock-файл является источником правды для сборок, поэтому мы получаем детерминированные установки. Это дает нам простой след аудита при проверке изменений. Мы не запускаем постинсталляционные скрипты. Это предотвращает выполнение пакетов произвольного кода во время установки. Медленные, обдуманные обновления Когда мы обновляем зависимости, мы: 1. Читаем журнал изменений зависимости построчно. 2. Проверяем подзависимости, введенные новой версией. 3. Сравниваем с upstream, когда набор изменений большой или рискованный. 4. Запускаем автоматические и ручные тесты на разных платформах и критических пользовательских путях. 5. Фиксируем новый lock-файл только после успешного прохождения этих проверок. На практике мы редко обновляем зависимости, потому что они, как правило, работают и не требуют частых изменений. Когда мы это делаем, мы рассматриваем каждое изменение так, как будто берем новую зависимость. Время — это буфер Мы не спешим с обновлениями. Существует задержка между обновлением любой зависимости и выпуском релиза. Этот разрыв служит окном раннего предупреждения: сообщество и исследователи безопасности часто быстро обнаруживают злонамеренные версии. К тому времени, когда мы готовы к отправке, экосистема обычно уже отметила любые проблемные релизы. — Ни одна мера не может полностью устранить риск цепочки поставок. Но выбор меньшего количества зависимостей, мелкие графы, точные фиксации версий, отсутствие постинсталляции и медленный, основанный на проверках темп обновлений вместе делают Obsidian гораздо менее подверженным влиянию и дают нам длительное время для обнаружения проблем до того, как код достигнет пользователей. Если вам интересно узнать о нашем более широком подходе к безопасности, смотрите нашу страницу безопасности и прошлые аудиты.