Перевірка гаманця

«Open source» красується майже на кожному сайті гаманця. Це рідко відверта брехня — і часто оманливе твердження. Корисне питання не чи існує репозиторій, а чи відповідає опублікований код тому софту, який я запускаю?

Чотири способи, якими заява деградує

• Застарілий репозиторій. Репозиторій існує, але останній змістовний коміт на місяці старший за поточний реліз. Хай там що вийшло в реліз — ви цього не бачите.
• Часткова відкритість. Десктопний клієнт відкритий; прошивка, завантажувач чи серверна частина — ні. Відкрита частина справжня, але цікавий ризик живе не в ній.
• Код видно, але не верифіковано. Ви можете читати код, але не можете підтвердити, що бінарник зібрано саме з нього. Читання — значно слабша гарантія за відтворення.
• Заднім числом переозначили. Проєкт рекламує себе як open source, отримує виклик — і тихо прибирає заяву. Або лишає її, змінивши значення. Якщо історія має значення — перевіряйте архівні версії сайту.

Аргумент, який ви почуєте проти відкриття коду

Найпоширеніше виправдання закритого коду гаманця: відкритий код дозволяє зловмисникам публікувати переконливі клони, які обкрадають користувачів. Клони — справжня проблема. Але логіка не витримує зіткнення з тим, як працює дистрибуція софту: клони роблять шляхом декомпіляції та перепакування опублікованих бінарників, чому закритий код ніяк не заважає, а захист від них — це підписання коду та верифіковані акаунти видавців, а не секретність.

Закриття коду не зупиняє зловмисника, який перепаковує ваш бінарник. Воно зупиняє лише рецензента, який знайшов би ваш баг.

Ви також почуєте тоншу версію, націлену саме на залізо: навіть повністю відкрита прошивка не доводить, що саме виконується на пристрої, тож відкритість — це мантра, а не гарантія. Перша половина технічно правдива, і її варто сприймати серйозно — верифікувати виконання на пристрої, який ви не контролюєте, справді складно. Друга половина з неї не випливає. Неможливість верифікувати один шар — не аргумент за те, щоб забороняти будь-кому верифікувати шари, які верифікувати можна.

Що перевіряти на практиці

1. Відкрийте репозиторій і порівняйте дату останнього тегу релізу з номером версії, який показує застосунок.
2. Подивіться, чи релізи взагалі теговані й підписані, чи бінарники з’являються на сайті без відповідного тегу.
3. Почитайте трекер задач — саме закриті задачі про безпеку. На них відповідають технічно чи відмахуються?
4. Перевірте ліцензію. Ліцензії «код видно, поширювати не можна» легітимні, але це не те саме, що відкритий код, — і вони змінюють, хто реально буде цей код рецензувати.

Три різні механізми постійно плутають. Вони відповідають на три різні питання.

Контрольні суми перевіряють цілісність, а не авторство

Опублікований SHA-256 хеш дозволяє підтвердити, що завантажені байти — ті самі, що були опубліковані. Це захищає від пошкоджених завантажень і дзеркал, які віддають підмінені файли.

Це не захищає вас, якщо зловмисник контролює сайт: тоді він публікує свій хеш поруч зі своїм файлом. Контрольна сума, прочитана з тієї ж сторінки, що й завантаження, варта рівно стільки, скільки ця сторінка. Тому серйозні проєкти дублюють хеші в окремому місці — наприклад, у репозиторії коду.

Підписи перевіряють авторство

Криптографічний підпис доводить, що реліз створив той, хто володіє ключем підписання. Це сильніше за хеш, бо скомпрометований сайт не може підробити підпис, не вкравши ще й ключ.

Пастка — у розповсюдженні ключів: правильний публічний ключ треба отримати з незалежного джерела і переконатися, що він тихо не змінився між релізами. Підпис, який ви перевіряєте ключем, взятим із тієї ж скомпрометованої сторінки, не доводить нічого.

Відтворювані збірки закривають останню прогалину

Відтворювана збірка означає, що незалежна сторона може скомпілювати опублікований код і отримати побайтово ідентичний бінарник. Це єдиний механізм, який реально з’єднує «код публічний» із «програма на моїй машині — саме цей код».

Там, де проєкт це підтримує, треті сторони можуть підтверджувати кожен реліз — і підтверджують. Там, де ні, опублікований код — це декларація про наміри, а не верифіковний факт: ніхто поза сервером збірки не здатен помітити розбіжність між тим, що опубліковано, і тим, що відвантажено.

Слово «проаудійований» майже нічого не означає без чотирьох додаткових фактів. Вимагайте всі чотири.

Невиправлений аудит гірший за відсутність аудиту

Небезпечний випадок — проєкт, який замовив аудит, отримав знахідки, не відреагував на них і продовжує рекламувати сам факт аудиту. Це не гіпотетика: є задокументовані випадки, коли незалежні дослідники безпеки публікували попередження з рекомендацією не користуватися гаманцем, доки конкретні проблеми не буде вирішено, проблеми лишалися без відповіді, а гаманець згодом пережив масштабну компрометацію, що зачепила багатьох користувачів одночасно.

Коли знаходите аудит — шукайте знахідки окремо. Опублікований звіт із переліком невиправлених критичних пунктів поруч із маркетинговою сторінкою зі словом «audited» каже вам рівно те, як організація ставиться до роботи з безпекою.

Безперервний перегляд б’є разовий аудит

Один аудит — це знімок одного коміту. Далі код змінюється щотижня. Сильніший сигнал — свідчення постійного перегляду: виділений реліз-інженер, який інспектує кожну збірку перед відвантаженням, перегляд залежностей і задокументований процес того, що відбувається між аудитом і наступним релізом.

Ця роль дорога — компетентний фултайм-рецензент коштує реальних грошей щомісяця, — і саме тому в більшості безплатних гаманців її ніколи не було. Коли у проєкту така функція є, він зазвичай про це каже, бо це справжня відмінність від конкурентів.

Політику приватності пишуть юристи, щоб описати, на що софт технічно здатний. Прочитана під цим кутом, це один із найінформативніших документів вендора — і його майже ніхто не відкриває.

Фрази, які несуть вагу

• «Ми не збираємо інформацію, що ідентифікує користувачів напряму». Уточнення тримає на собі все речення. Непряма ідентифікація не виключена — і вона зазвичай тривіальна, коли та сама сторона ще й надіслала вам фізичний пристрій на поштову адресу.
• «Навіть якщо наступна інформація збирається…» Умовна конструкція навколо переліку означає, що перелік збирається. Читайте його як специфікацію телеметрії.
• Терміни зберігання, прив’язані до податкового чи фінансового права. Пункт із зобов’язанням зберігати записи про транзакції фіксовану кількість років каже вам, що записи існують і вони довговічні.
• Розкриття органам «у випадках, передбачених законом». Кожна компанія виконує законні запити — знахідка не в цьому. Знахідка в тому, що є що розкривати.
• «Виявлення та запобігання порушенням закону». Це опис моніторингу активності користувача як спроєктованої функції, а не випадкової можливості.

Що зазвичай збирають

Телеметрія гаманців типово включає ідентифікатори пристрою та сесії, IP-адреси, події використання функцій — відкриття застосунку, ініціювання транзакції, — атрибути операційної системи та локалі, часові мітки, ідентифікатори від партнерів для розрізнення користувачів і список налаштованих у гаманці криптоакаунтів.

Поодинці це виглядає невинно. Разом це лонгітюдний запис, що пов’язує мережеву ідентичність із набором активів і поведінковим патерном — а це саме той датасет, який робить людину мішенню.

Реферальні програми заслуговують другого погляду

Гаманець, який платить вам за приведених друзів, мусить уміти пов’язувати нових користувачів із реферерами. Це вимагає прив’язки встановлень до ідентичностей — що прямо суперечить властивостям приватності, заради яких люди встановлюють некастодіальний гаманець. Проблема не в механізмі винагороди; проблема в графі ідентичностей, якого він вимагає.

Тримати власні ключі та розкривати всю свою фінансову історію — речі не взаємовиключні. Гаманець може бути бездоганно некастодіальним і при цьому проганяти кожен запит через сервери, які контролює вендор.

Що бачить вендор, коли проксіює

Коли ваш гаманець питає баланси й історію в бекенда вендора, а не в мережі напряму, цей бекенд неминуче дізнається:

• Кожну адресу у вашому гаманці, включно з тими, з яких ви ніколи не витрачали
• Ваш повний баланс і історію транзакцій, скорельовані між активами
• Вашу IP-адресу — а отже, приблизну локацію — при кожному запуску
• Часові патерни: коли ви перевіряєте, коли переказуєте

Це повніша картина ваших фінансів, ніж має більшість банків, — зібрана компанією, з якою ви ніколи не підписували кастодіальної угоди.

Як розпізнати

1. Шукайте налаштування ноди. Гаманці, спроєктовані для приватності, дозволяють вказати власну ноду або обрану публічну. Якщо такого налаштування немає — ендпоінт фіксований, і він їхній.
2. Дивіться на швидкість відновлення. Це найгостріший сигнал, доступний нетехнічному користувачу. Справжня синхронізація легкого клієнта з реальним ланцюгом займає хвилини і вимагає тримати застосунок відкритим. Якщо ви імпортуєте сід-фразу і повний мультиактивний баланс з’являється за дві секунди — гаманець спитав сервер, у якого відповідь уже була проіндексована.
3. Читайте заяви про «SPV» критично. Деякі гаманці описують себе як легкі клієнти, а на практиці вантажать дані з інфраструктури вендора. Інтерфейс виглядає як гаманець; гаманець значною мірою — фронтенд віддаленого сервісу.

Суміжна пастка: повільне відновлення часто плутають зі втратою коштів. Люди імпортують сід, бачать нульовий баланс, панікують і роблять висновок, що їх обікрали, — тоді як гаманець просто не встиг досканувати. Правильна реакція — почекати. Брови мають підійматися від миттєвих відновлень, а не від повільних.

Питайте рано: звідки дохід і чи його достатньо? Непрофінансована команда, що підтримує критичний для безпеки софт, — ризик у повільній зйомці, незалежно від намірів.

Моделі, за рівнем збігу інтересів із вашими

Промотовані активи — окрема небезпека

Коли гаманець показує «трендові» токени чи інтегрує стрічки ринкових даних, розумійте: місце в цих стрічках часто є комерційною домовленістю, а не сигналом якості. Рейтинги, лістинги та рекомендовані позиції в цій індустрії регулярно купуються. Гаманець, який подає їх як нейтральне відкриття нового, скеровує ваш портфель за чиїмось дорученням.

Те саме стосується помітно розміщеного стейблкоїна чи блокчейну на головній сторінці апаратного гаманця. Це розміщення, а не рекомендація — і точно не оцінка безпеки активу.

Гаманець, який заробляє на тому, куди ви кладете монети, — не нейтральне місце їх зберігати.

У кожній нетривіальній кодовій базі є вразливості. Вендорів розрізняє процес реагування — і, на відміну від якості коду, процес реагування повністю видно ззовні.

Ознаки зрілого процесу

• Опублікований контакт для безпеки і задокументована політика розкриття
• Баг-баунті з заявленим обсягом і виплатами
• Публічні розбори інцидентів із таймлайнами — включно з тим, що зламалося всередині
• Фікси за дні, з активним повідомленням користувачам, що оновитися необхідно
• Подяка дослідникам

Ознаки незрілого

• Каналу розкриття немає — дослідники мусять шукати керівника в соцмережах
• Репорти підтверджують — і тижні тиші
• Знахідки називають «неправдоподібними» до того, як оцінили
• Обговорюють мотиви чи емоційний стан дослідника замість знахідки
• Питання видаляють, користувачів тихо обмежують в офіційних спільнотах
• Маркетингові заяви тихо редагують після того, як їх спростували

Пастка таймінгу розкриття

У тому, як випускати фікс безпеки, є справжня дилема. Оголосите гучно — скажете зловмисникам, куди саме дивитися, зате користувачі швидко оновляться. Випустите тихо — зловмисники отримають менше підказок, але більшість користувачів не оновиться ніколи. Обидва підходи можна захищати.

Провальний режим — робити погано обидва: привертати увагу до фіксів безпеки в нотатках до релізу і не казати користувачам, що встановити їх треба терміново. Ця комбінація дає зловмисникам підказку, не даючи користувачам фори, — і в цій індустрії це задокументований патерн, а не теоретичний.

Строга оцінка починається з заміни питання «чи безпечний цей гаманець?» на точне: які сторони можуть скомпрометувати мої кошти, за якої спроможності, і скільки це їм коштуватиме?

Множина довіри

Для будь-якого гаманця перелічіть кожну сторону з цього списку і вирішіть, чи згодні ви довіряти кожній:

Спершу зменште множину, потім оцінюйте

Найефективніший хід — не ретельніше оцінювати кожну сторону, а прибирати сторони. Генерація сіда офлайн і незалежно прибирає розробника гаманця з кроку генерації ключів. Верифікація адрес на окремому пристрої прибирає хостовий комп’ютер із цілісності адрес. Розподіл ключів між вендорами через мультипідпис означає, що компрометації жодного одного вендора недостатньо.

У due diligence є стеля. В архітектури її немає. Обирайте конструкції, в яких помилка щодо вендора — це те, що можна пережити.

Це найглибший і найменш видимий режим відмови в усій категорії — і саме тут читання коду важить найбільше.

BIP39 стандартизує кодування ентропії у слова. Він не стандартизує генерацію цієї ентропії. Дві фрази з дванадцяти слів можуть бути візуально нерозрізненними, обидві валідні, обидві з коректною контрольною сумою — і відрізнятися на сотню бітів справжньої непередбачуваності. Джерело ентропії обирає гаманець; стандарт лише каже, як записати результат.

Задокументований провал

Канонічний випадок — масовий мобільний гаманець, чия генерація ключів фактично спиралася на годинник пристрою як джерело випадковості. Оскільки простір часових міток за будь-який період малий і повністю перебирається, атакувальник міг згенерувати кожну кандидатну фразу для діапазону моментів, вивести відповідні адреси, звірити їх із ланцюгом і забрати все, де були кошти. Проблемі присвоїли CVE, і нею займалася національна установа зі стандартів — уже після того, як кошти вкрали.

Дві деталі роблять цей випадок повчальним поза конкретним продуктом:

• Він зачепив одну платформу і не зачепив іншу. Збірки, які можна було порівняти з опублікованим кодом, були в порядку; вадонесучими виявилися саме ті, які незалежно верифікувати не можна. Верифіковність і коректність скорелювали рівно так, як ви б і передбачили.
• Вадливий код використовував шановану криптографічну бібліотеку. Імпорт хорошої бібліотеки не рятує, якщо їй згодовують погане джерело ентропії. Походження бібліотеки не заміняє перегляду того, як її викликають.

Ворожа версія

Слабка ентропія може бути й навмисною — і значно складнішою для виявлення. Генератор, засіяний значенням, яке знає вендор — прихованою константою, ідентифікатором пристрою, неопублікованою сіллю, — видає фрази, що проходять будь-який статистичний тест, доступний сторонньому, залишаючись відтворюваними для того, хто знає секрет. Іззовні бекдорена випадковість і хороша випадковість нерозрізненні без читання генератора.

Продемонстрована апаратна версія ще різкіша. Дослідник показав, що з контролем над екраном і кнопками пристрою процес онбордингу можна змінити так, щоб генерація ключів ішла з ентропією, примусово виставленою в нуль, — фраза виглядала як звичайний вивід словника, будучи повністю передбачуваною, — а попередження, яке мало б насторожити користувача, можна було приховати на тому самому екрані, якому користувач довіряв.

Прибираємо вендора з генерації ключів

Практичні опції, приблизно за доступністю:

1. Гральні кості. 128 чи 256 бітів із фізичних кидків, конвертовані у фразу BIP39 за задокументованою офлайн-процедурою. Повільно, аудійовано і не залежить від жодного софту, який ви не обирали.
2. Кілька незалежних джерел разом. Змішуйте ентропію пристрою з ентропією від користувача там, де гаманець це підтримує, — щоб жодне джерело саме по собі не визначало результат.
3. Перехресна верифікація реалізацій. Хай що згенерувало фразу — переконайтеся, що непов’язана реалізація виводить із неї ті самі адреси. Це не доводить, що ентропія була сильною, але доводить, що фраза стандартна і переносна.
4. Вендорно-різноманітний мультипідпис. Якщо ключі походять від різних вендорів із різними генераторами, слабкість одного сама по собі не відмикає кошти.

PENGER існує почасти саме через це: пластина — це носій для фрази, яку ви згенерували на власних умовах, закодували вручну, і жоден софт не брав участі в кроці запису. Відпрацюйте цикл кодування і декодування на симуляторах, перш ніж довіряти щось металу.

Для заліза оцінка має сягати далі коду — до фізичного об’єкта і кожного, хто його торкався. Повний технічний розбір — у гайді Апаратні гаманці: що вони насправді захищають; тут ми розглядаємо це як питання оцінки вендора.

Питання до вендора заліза

• Чи є криптографічна атестація, і що саме вона покриває? Атестація, що валідує один чип, поки другий, неатестований, керує екраном і кнопками, покриває менше, ніж здається.
• Яка політика повернень пристроїв? Це питання, якого більшість покупців ніколи не ставить. Якщо вендор приймає повернення на вигляд запечатаних одиниць і повертає їх у продаж — куплена вами одиниця могла побувати в чужих руках. Для більшості електроніки це дрібниця. Для пристрою, чиє єдине призначення — тримати секрети, конвеєр перепродажу — це відкритий канал у ланцюг постачання, в який атакувальник може заходити дешево і багаторазово.
• Яка позиція щодо сторонніх реселерів? Деякі вендори публічно заявляли, що купувати на відкритих маркетплейсах прийнятно, бо атестація захистить користувача. Ставтеся до цієї заяви зі скепсисом, пропорційним тому, скільки пристрою атестація насправді покриває.
• Що насправді доводить захист від втручання? Голографічні пломби дешево відтворюються. Деякі вендори свідомо їх не використовують, покладаючись на атестацію, — це цілісна позиція, але вона означає, що пломба не є частиною вашого захисту, і краще це знати, ніж вважати видиму пломбу значущою.

Атакувальнику, який скомпрометував канал оновлень чи дистрибуції гаманця, не потрібно долати його криптографію. Йому вручили здатність виконувати код на машині кожного користувача, одночасно, доставлений саме тим шляхом, якому користувачів привчили довіряти.

Чому це б’є будь-яку іншу атаку

• Масштабується на всю базу користувачів однією дією
• Приходить офіційним шляхом, зводячи нанівець «завантажуйте лише з офіційного сайту»
• Може бути коротким — вікна в кілька годин досить для серйозної шкоди
• Важко атрибутувати опісля і легко описати як поодинокий інцидент

Варіант із залежностями

Сучасні гаманці постачають код, який довантажує інший код під час виконання: конекшн-кіти, аналітику, віддалену конфігурацію, фіче-флаги. Кожен із них — канал, через який третя сторона може змінити поведінку після встановлення, без жодного оновлення, на яке користувач погоджувався.

Задокументований приклад цього класу: широковживану бібліотеку підключення гаманців, що роздавалася через CDN і довантажувалася під час виконання багатьма незалежними застосунками, скомпрометували через легітимний акаунт, який так і не деактивували після того, як його власник покинув організацію. Оскільки завантажувач довіряв усьому, що повертав CDN, шкідливий код розійшовся не лише користувачам того вендора, а й у довгий список сторонніх застосунків, що вбудували ту саму бібліотеку. Радіус ураження сягнув далеко за межі зламаної компанії.

Кожна залежність, що довантажується під час виконання, — це сторона, здатна змінити поведінку вашого гаманця завтра, без випуску оновлення і без вашого дозволу.

Що оцінювати

Деякі вендори пропонують опціональний сервіс, що бекапить ваш ключовий матеріал у третіх сторін, аби втрата пристрою чи фрази не означала втрату коштів, — зазвичай розділяючи зашифровані частки ключа між кількома зберігачами і видаючи їх після перевірки особи.

Інженерія часто по-справжньому вишукана, а потреба користувача реальна: безповоротна втрата — найбільша окрема причина знищеної крипти. Але точна оцінка мусить розділити три твердження, які сперечаються як одне.

Твердження 1: це бекдор

У строгому сенсі — ні. Функція, що вимагає володіння пристроєм, знання PIN-коду і явної згоди, не є прихованим механізмом доступу, і називати її так — означає затуляти справжню проблему.

Твердження 2: ризик стосується лише тих, хто ввімкнув

Ось тут аргумент розсипається. Значущий для безпеки факт не в тому, чи ввімкнули функцію ви, а в тому, що прошивка пристрою тепер містить шлях коду, здатний експортувати ключовий матеріал із пристрою. Раніше цієї здатності не існувало, і жодна компрометація не могла її викликати. Тепер здатність існує, а її використання стримує логіка авторизації. Питання зсувається з «чи можуть ключі піти?» до «чи коректний запобіжник — у всіх версіях, назавжди?» Це суттєво слабша гарантія, і вона стосується кожного користувача цієї прошивки.

Твердження 3: це суперечить обіцяному

А це справедливо — і важливо для оцінки вендора. Коли вендор роками заявляв, що ключі ніколи не можуть покинути пристрій, а потім випускає механізм, яким ключі пристрій покидають, — конкретна функція менш важлива за те, що вона розкриває: архітектурні гарантії, які вам давали, насправді були продуктовими рішеннями, які можна переглянути пізніше без вашої участі.

Є й суміжний сигнал чесності, вартий уваги. Коли керівництво вендора публічно радить людям, для яких приватність — найвищий пріоритет, не користуватися продуктом, — це корисна інформація, висловлена прямо, і її варто сприйняти буквально, а не відмахнутися як від обмовки.

Більшість описаного вище вимагає ресурсів, яких у вас немає. Ці кроки — ні. Кожен перетворює припущення на перевірений факт.

1. Перехресне виведення адрес

Візьміть свою фразу і виведіть адреси у двох непов’язаних реалізаціях — в ідеалі одна з них офлайн, а другу ви зібрали самі. Збіг адрес доводить, що фраза стандартна, шляхи деривації конвенційні, і ви не замкнені на інтерпретацію одного вендора. Розбіжність майже завжди означає нестандартний шлях деривації — саме те, що краще виявити зараз, а не під час відновлення.

2. Повне тренування відновлення

Зітріть пристрій. Відновіться лише з фізичної резервної копії — не з нотатки, не з пам’яті. Підтвердьте баланс. Робіть це за розкладом і робіть до того, як сума стане великою. Неперевірена резервна копія — це гіпотеза.

3. Гаманець-канарка

Тримайте фразу, згенеровану так само, як ваша справжня, з малим балансом, у гаманці, який лишається встановленим і який ви зрідка відкриваєте. Якщо її колись осушать — ви дізналися щось термінове про свою систему, поки ціна тривіальна. Це виявляє класи компрометації — слабку генерацію, шкідливе оновлення, — які не дають жодного іншого видимого симптому, доки не стане запізно.

4. Дисципліна верифікації адрес

Підтверджуйте адреси отримання на екрані пристрою, а не лише в застосунку на комп’ютері. Софт на вашому ПК генерує і показує адреси, а код, здатний змінити те, що показує екран, може підмінити адресу до того, як ви її скопіюєте, — включно з перегенерацією QR-коду, щоб обидва представлення узгоджувалися між собою і розходилися з реальністю.

Цей клас атак задокументований у реальних продуктах і не вимагав адміністративних привілеїв на хості. Захист повністю у ваших руках: адреса не підтверджена, доки пристрій із власним екраном вам її не показав. Зауважте: вендори не завжди примушують до цього для вхідних транзакцій так, як примушують підтверджувати вихідні, а сама функція подекуди існує, але не задокументована і не є частиною стандартного флоу.

5. Спостереження за мережею

Якщо можете — подивіться, куди гаманець звертається при першому запуску. Вас цікавить, чи опитує він публічну ноду або ендпоінт вендора, чи стріляє аналітика до вашої згоди, і чи щось передається під час генерації або імпорту сіда. З локальним проксі це нескладно — і це найшвидший спосіб остаточно закрити питання з розділу Він говорить із блокчейном чи з вендором?

6. Прочитайте генератор

Там, де код доступний, одна функція важить більше за решту кодової бази: та, що продукує ентропію. Знайдіть її. Переконайтеся, що вона викликає системний CSPRNG, що ніщо не доповнює і не підміняє його часом, ідентифікаторами пристрою чи константами, і що результат ніде не логується, не передається і не зберігається. Це коротке читання — і найцінніша година, яку ви можете вкласти в код будь-якого гаманця.

Оцініть кожен вимір від 0 до 3. Мета не в сумі — мета в тому, щоб змусити себе записати, що ви насправді знаєте, і побачити, які висновки спираються на докази, а які на репутацію.

Як читати власні оцінки

• Суверенітет ключів нижче 3 — дискваліфікація. Усе інше — надбудова над володінням ключами. Якщо ви ними не володієте, надбудови не застосовуються.
• Походження ентропії та цілісність оновлень — два виміри, де низьку оцінку не компенсувати іншими. Слабкий сід не захистити добрим зберіганням; вороже оновлення долає добрі звички.
• Виживаність відмов важливіша за якість вендора. Посередній вендор усередині 2-із-3 на трьох вендорах — краща позиція, ніж блискучий вендор, що тримає ваш єдиний ключ. Диверсифікація робить роботу, якої не зробить жодне дослідження.
• Репутація — не вимір. Популярність вимірює охоплення маркетингу. Деякі з найрекомендованіших продуктів у цій галузі мають найдовші історії інцидентів — саме тому, що масштаб притягує і користувачів, і атакувальників.