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

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

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

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

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

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

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

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

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

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

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