Google оголосила про розширення механізму Binary Transparency на екосистему Android, запроваджуючи публічний криптографічний реєстр усіх своїх продукційних застосунків і модулів ОС; це безпосередньо стосується всіх користувачів Android-пристроїв із сервісами Google і розробників, які покладаються на довіру до оновлень, і вимагає від корпоративних команд безпеки переглянути моделі контролю автентичності мобільного ПЗ, спираючись не лише на підпис коду, але й на перевірюваний «реєстр намірів» постачальника.

Технічні деталі: що саме змінюється в Android

Розширений механізм Binary Transparency для Android логічно продовжує вже наявну ініціативу Pixel Binary Transparency, але виходить далеко за межі прошивок окремих пристроїв. Ключові елементи:

• Публічний криптографічний реєстр бінарних файлів — Google веде відкритий журнал «лише для додавання» з криптографічним захистом, у якому публікуються метадані про продукційні версії:
  • застосунків Google (включно з Google Play Services та окремими застосунками);
  • Mainline-модулів Android, які оновлюються динамічно, поза стандартним циклом релізу ОС.
• Гарантія «сертифіката намірів» — сам цифровий підпис лишається підтвердженням походження бінарника, але Google підкреслює, що цього недостатньо: підпис не гарантує, що саме цей артефакт був «задуманий» і «схвалений» до випуску. Binary Transparency додає другий рівень: якщо бінарник не представлений у реєстрі, Google не вважає його продукційною версією.
• Часове обмеження для повноти охоплення — усі продукційні Android-застосунки Google, випущені після 1 травня 2026 року, мають мати відповідний запис у реєстрі. Це дає зрозумілу межу, після якої відсутність запису стає надійним індикатором аномалії.
• Публічна перевірюваність — будь-який зацікавлений учасник (користувач, дослідник, корпоративна команда безпеки) може самостійно перевірити, що конкретний встановлений пакет:
  • має підпис Google;
  • і одночасно присутній у реєстрі Binary Transparency з коректною криптографічною зв’язаністю.
• Інструменти верифікації — Google публікує засоби перевірки стану прозорості для підтримуваних типів ПЗ. Це критично для автоматизації: можна інтегрувати перевірки в MDM-системи або в процеси аудиту пристроїв.

За своєю конструкцією це рішення близьке до Certificate Transparency: там уся екосистема TLS-сертифікатів спирається на відкриті, криптографічно зв’язані журнали для виявлення помилково виданих або зловмисних сертифікатів. Подібно до цього, Binary Transparency перетворює кожен бінарний артефакт Google на елемент перевірюваного журналу, де спроба «заднім числом» видалити або непомітно замінити запис виявляється через порушення криптографічного ланцюжка. Концептуально це збігається з описом MITRE-техніки Supply Chain Compromise (T1195), де захист будується навколо контролю цілісності компонентів на шляху від розробника до кінцевого користувача.

Контекст загроз: чому одного підпису коду вже недостатньо

Сучасні атаки на ланцюг постачання дедалі частіше націлені не на кінцевий пристрій, а на сам процес випуску оновлень. В початковому матеріалі наводиться приклад компрометації інсталяційних програм DAEMON Tools, що поширювалися з офіційного сайту й були підписані легітимними сертифікатами розробника, але містили «легкий» бекдор, який потім підтягав імплант QUIC RAT. Це ілюстрація важливої тенденції:

• зловмисники отримують доступ до інфраструктури розробника (репозиторії, CI/CD, облікові записи підпису);
• вбудовують шкідливий код у легітимний продукт, зберігаючи коректний цифровий підпис;
• поширюють скомпрометовану версію через стандартні канали оновлень.

У таких сценаріях захист, побудований лише на перевірці підпису коду та джерела завантаження, завідомо програє: саме на ці механізми й спирається атакувальний. Це відповідає техніці Subvert Trust Controls (T1553), коли компрометуються або зловживаються довірені механізми перевірки цілісності та автентичності.

Google прямо констатує: підпис — це «сертифікат походження», але не «сертифікат намірів». Можна мати коректно підписаний бінарник, який розробник ніколи не планував випускати в обіг. Binary Transparency якраз і націлений на цей прошарок між процесом збирання і фактом публічного релізу.

Оцінка впливу: кому важливо враховувати Binary Transparency уже зараз

Користувачі та корпоративні парки Android

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

• організацій із великими парками Android-пристроїв;
• компаній, які покладаються на Google Play Services для критичних бізнес-процесів;
• секторів із жорсткими вимогами до цілісності ПЗ (фінанси, охорона здоров’я, держоргани),

нова інфраструктура змінює базову модель довіри. З’являється можливість:

• формально зафіксувати вимогу: на пристрої можуть бути присутні лише ті компоненти Google, які підтверджені в реєстрі Binary Transparency;
• вбудувати цю перевірку в процеси приймального тестування образів прошивок і регулярного комплаєнс-аудиту пристроїв;
• швидше виявляти «аномальні» інсталяції (нестандартні збірки, сторонні прошивки, модифіковані пакети Google).

Виробники пристроїв та оператори

Для OEM-партнерів і операторів, які поширюють власні збірки Android, ризик «непомітної» модифікації передвстановленого ПЗ від Google знижується: будь-які відмінності від продукційного бінарника будуть відображені відсутністю або невідповідністю запису в реєстрі. Це особливо важливо там, де в ланцюгу беруть участь кілька сторін (Google — OEM — дистриб’ютор — кінцевий користувач), що добре описано в техніці Trusted Relationship (T1199).

Дослідники та регулятори

Відкритий характер реєстру дає додатковий інструмент для:

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

Якщо організації проігнорують новий канал перевірки, наслідки можуть бути такими:

• неможливість оперативно відрізнити скомпрометований білд від легітимного під час інцидентів постачання;
• обмежена доказова база під час розглядів (юридичних або з партнерами);
• додаткові «сліпі зони» в управлінні вразливостями мобільного парку.

Практичні рекомендації для фахівців із безпеки та ІТ-команд

1. Планування переходу до 1 травня 2026 року

Хоча повне охоплення Binary Transparency для продукційних застосунків Google задекларовано з дати після 1 травня 2026 року, готуватися варто заздалегідь:

• оновити внутрішні політики: додати вимогу перевірки наявності бінарників Google у реєстрі Binary Transparency до профільних стандартів безпеки для мобільних пристроїв;
• врахувати цю можливість у дорожніх картах MDM/EMM-платформ і засобів інвентаризації ПЗ;
• закласти в вимоги до постачальників прошивок (OEM, інтегратори) обов’язок не вимикати й не обходити механізми прозорості.

2. Інтеграція перевірки в процеси управління пристроями

Після появи стабільних інструментів перевірки доцільно:

• запровадити періодичну перевірку всіх пристроїв: чи відповідають версії Google Play Services, Mainline-модулів і ключових застосунків записам у реєстрі;
• використовувати результати перевірки як критерій комплаєнса: пристрої з розбіжностями позначати як потенційно скомпрометовані або такі, що не відповідають вимогам;
• логувати й корелювати результати в SIEM для раннього виявлення масових аномалій (наприклад, якщо в одному регіоні раптово багато пристроїв не відповідають реєстру для одного й того ж компонента).

3. Перегляд моделей загроз для ланцюга постачання мобільного ПЗ

Командам, які вже моделюють загрози за методиками, сумісними з MITRE ATT&CK, варто:

• оновити сценарії, пов’язані з Supply Chain Compromise (T1195), з урахуванням нового джерела сигналів — розбіжностей із реєстром Binary Transparency;
• додати кроки з перевірки реєстру до планів реагування на інциденти, що зачіпають оновлення Android або поведінку застосунків Google;
• адаптувати контрольні запитання під час аудиту постачальників, які беруть участь у випуску образів Android.

4. Навчання та комунікація

Щоб уникнути неправильного трактування можливостей Binary Transparency:

• донести до внутрішніх команд, що це не заміна стандартної перевірки підпису коду, а додатковий шар контролю;
• пояснити, що відсутність запису в реєстрі для нових версій ПЗ Google після 1 травня 2026 року слід розглядати як тригер для розслідування, а не автоматично як доказ зловмисності (потрібні винятки на випадок затримок або помилок публікації);
• синхронізувати очікування з юридичними та комплаєнс-підрозділами: поява публічного реєстру розширює можливості доведення добросовісності під час спорів щодо цілісності ПЗ.

Ключовий висновок: Google переводить довіру до своїх Android-компонентів із площини «ми віримо підпису» в площину «ми перевіряємо підпис і наявність у публічному реєстрі намірів», тож організаціям уже зараз слід запланувати включення перевірок Binary Transparency у процеси управління мобільними пристроями та реагування на інциденти, щоб до 1 травня 2026 року цей механізм працював як стандартний елемент контролю ланцюга постачання ПЗ.