Менше означає безпечніше: як обсидіан знижує ризик атак на ланцюжок поставок Атаки на ланцюжок поставок – це шкідливі оновлення, які проникають у відкритий вихідний код, який використовується багатьма програмами. Ось як ми розробляємо Obsidian, щоб гарантувати, що додаток є безпечним і приватним середовищем для ваших думок. Менше означає безпечніше Це може здатися очевидним, але основний спосіб знизити ризик атак на ланцюжок поставок — це уникати залежності від стороннього коду. Obsidian має низьку кількість залежностей у порівнянні з іншими програмами в нашій категорії. Перегляньте список бібліотек з відкритим вихідним кодом на нашій сторінці Кредити. Такі функції, як Bases і Canvas, були реалізовані з нуля, а не імпортували готові бібліотеки. Це дає нам повний контроль над тим, що працює в обсидіані. - Для невеликих службових функцій ми майже завжди повторно реалізуємо їх у нашому коді. - Для середніх модулів ми розгалужуємо їх і зберігаємо всередині нашої кодової бази, якщо ліцензії це дозволяють. - Для великих бібліотек, таких як pdf.js, Mermaid, і MathJax, ми включаємо відомі файли, заблоковані версіями, і оновлюємося лише час від часу, або коли вирішуються проблеми безпеки. Ми читаємо примітки до випуску, дивимося на зміни в апстрімі та ретельно тестуємо перед переходом. Цей підхід робить наш граф залежностей неглибоким з невеликою кількістю підзалежностей. Менша площа поверхні знижує ймовірність проскоку шкідливого оновлення. Що насправді постачається в додатку Лише кілька пакетів є частиною програми, яку ви використовуєте, наприклад, Electron, CodeMirror moment.js. Інші пакети допомагають нам створити додаток і ніколи не відправляти його користувачам, наприклад, esbuild або eslint. Закріплення версій і файли блокування Усі залежності строго закріплені за версіями та фіксуються за допомогою файла блокування. Файл блокування є джерелом істини для збірок, тому ми отримуємо детерміновані встановлення. Це дає нам простий контрольний слід під час перегляду змін. Ми не виконуємо скрипти після встановлення. Це запобігає виконанню пакетами довільного коду під час встановлення. Повільні, навмисні оновлення Коли ми оновлюємо залежності, ми: 1. Прочитайте журнал змін залежності рядок за рядком. 2. Перевірте підзалежності, введені новою версією. 3. Диференціація в апстрімі, коли набір змін великий або ризикований. 4. Проводьте автоматизовані та ручні тести на різних платформах і критичних шляхах користувачів. 5. Зафіксуйте новий файл блокування лише після того, як ці перевірки пройдуть. На практиці ми рідко оновлюємо залежності, тому що вони в цілому працюють і не вимагають частих змін. Коли ми це робимо, ми ставимося до кожної зміни так, ніби беремо нову залежність. Час – це буфер Ми не поспішаємо з оновленнями. Існує затримка між оновленням будь-якої залежності та надсиланням релізу. Ця прогалина діє як вікно раннього попередження: дослідники спільноти та безпеки часто швидко виявляють шкідливі версії. На той час, коли ми будемо готові до відправлення, екосистема зазвичай позначає будь-які проблемні випуски. — Жоден окремий захід не може усунути ризик ланцюга поставок. Але вибір меншої кількості залежностей, поверхневих графіків, точних контактів версій, відсутності постінсталяції та повільної, важкої рецензією періодичності оновлення разом роблять Obsidian набагато менш схильним до впливу та дають нам довгий період для виявлення проблем, перш ніж код дійде до користувачів. Якщо вас цікавить наш ширший підхід до безпеки, перегляньте нашу сторінку безпеки та попередні аудити.