Як зрозуміти, чи команда вже усунула причину, а не лише наслідок

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

Що змінилося

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

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

Що можна вважати встановленим

Офіційні джерела — це статусні сторінки проєкту, security advisories у репозиторії, офіційні повідомлення команди у перевірених каналах. Щоб зрозуміти глибину виправлення, шукайте в цих джерелах такі маркери:

• Опис вразливості. Чи вказано конкретний механізм, яким скористався зловмисник? Загальні формулювання на кшталт «виявлено аномалію» без технічних деталей свідчать про поверхневе пояснення.
• Посилання на коміт або pull request. Чи є пряме посилання на зміну в коді, яка закриває вразливість? Наявність такого посилання дозволяє незалежно перевірити, що саме змінено.
• Залучення зовнішніх аудиторів. Чи підтверджено виправлення незалежною стороною? Це додатний, але не єдиний критерій.
• Постмортем. Чи опубліковано розбір з хронологією, причиною та заходами, які запобігають повторенню?

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

Хто має звернути увагу

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

Непідтверджена частина

Між моментом інциденту та повним розумінням причини завжди є проміжок. У цей період невідоме може включати:

• Чи був це єдиний вектор атаки, чи існують інші, ще не виявлені.
• Чи зачіпає вразливість інші компоненти системи, які використовують той самий патерн.
• Чи були скомпрометовані додаткові ключі чи права доступу, про які команда ще не знає.

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

Як продовжити перевірку

Ось конкретні кроки для самостійної перевірки. Виконуйте їх у такому порядку:

1. Знайдіть первинне джерело. Перейдіть на статусну сторінку проєкту або офіційний репозиторій. Уникайте покладання на перекази в соцмережах.
2. Перевірте наявність технічного опису. Чи вказано клас вразливості (наприклад, перевірка прав доступу, переповнення, логічна помилка)? Загальне «виявлено помилку» без класифікації — недостатньо.
3. Знайдіть зміну в коді. Якщо проєкт має відкритий репозиторій, перевірте наявність коміту з описом виправлення. Зверніть увагу: чи змінено лише параметри (наслідок), чи перероблено логіку (причина).
4. Перевірте наявність постмортему. Чи описано хронологію, кореневу причину та запобіжні заходи? Відсутність постмортему через значний час після інциденту — сигнал, що робота з причиною може бути незавершеною.
5. Оцініть власний ризик. Якщо ви не маєте технічної можливості перевірити код, обмежте взаємодію з продуктом до мінімально необхідного, поки не з’явиться незалежне підтвердження від аудиторів або досвідчених розробників спільноти.

Чого не робити

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

Критерій завершення перевірки

Ви можете вважати, що причина усунута, коли виконані всі умови:

• Опубліковано технічний опис вразливості з вказанням класу та механізму.
• Наявна зміна в коді, яка переробляє логіку, а не лише змінює параметри чи блокує адреси.
• Опубліковано постмортем із описом запобіжних заходів.
• Виправлення підтверджено незалежною стороною (аудитор, досвідчений розробник) або ви самостійно перевірили зміни в коді та переконалися в їх адекватності.

Якщо хочете більше не лише про цей аспект, а про загальний підхід до інцидентів у екосистемі, почніть з базового матеріалу про інциденти без паніки. Загальний розділ Безпека Solana містить усі тематичні матеріали. А якщо вас цікавить, які продукти екосистеми працюють для людей, дивіться каталог продуктів Solana.

Редакція солана.укр