Warto spojrzeć, czego wymaga się od łańcuchów dostaw, które świat uznaje za krytyczne. Wytwórca leków dokumentuje pochodzenie, skład i historię badań każdego składnika, który sprzedaje. Wytwórca samolotów śledzi historię certyfikacji każdego montowanego elementu i przechowuje te zapisy przez cały okres eksploatacji płatowca. Producent żywności musi wykazać, gdzie składnik wyrósł, gdzie go przetworzono i przewieziono, i musi przedstawić ten zapis w ciągu godzin od zdarzenia skażenia. Organy nadzoru badają zapisy, kontrolują obiekty i wyciągają konsekwencje, gdy dokumentacja się nie broni.

Teraz warto spojrzeć, czego wymaga się od organizacji budujących na cyfrowym łańcuchu dostaw. Od zespołu włączającego skrypt zewnętrzny na ogół nie wymaga się udokumentowania, skąd ten skrypt pochodzi, kto go napisał ani co ze sobą niesie. Od firmy dodającej integrację z siecią dostarczania treści nie wymaga się wykazania, że to, co ten dostawca dostarcza, zostało wobec czegokolwiek zweryfikowane. Od operatora stawiającego interfejs przeglądarkowy przed układem sterowania nie wymaga się zmapowania tego, co ten interfejs wczytuje, przed podłączeniem go. Dla większości organizacji, w większości jurysdykcji, na większej części tego łańcucha dostaw nie ma obowiązku dokumentowania, badania, weryfikowania ani monitorowania tego, co się włącza i wykonuje.

Nie jest to niczyja nieostrożność. Ramy, które umożliwiłyby ochronę systematyczną, pisano dla elementów, a to jest problem złożeń. Do ochrony pojedynczych części istnieją dopracowane narzędzia. Do zobaczenia łańcucha jako całości istnieje bardzo niewiele.

Cyfrowy łańcuch dostaw nie jest jednym łańcuchem. Jest ośmioma warstwami działającymi jednocześnie: sieci i infrastruktura, oprogramowanie i oprogramowanie układowe, sprzęt i urządzenia, usługi i zestawy narzędzi programistycznych, kod i biblioteki, dane i modele, zasoby i pliki, a także interfejs, w którym wszystko to zbiega się w to, co człowiek rzeczywiście widzi.

Opracowanie obejmuje to, co wnosi każda warstwa, jakie dowody dla niej istnieją i dlaczego ekspozycja nie jest sumą podatności w poszczególnych warstwach, a zbiorem dróg między nimi.

Element może zmienić właściciela bez zmiany choćby jednego wiersza kodu. Domena rozwiązuje się tak samo, skrypt ma ten sam skrót, a ruch jest identyczny, bo jest identyczny. Zmieniło się to, kto decyduje, co ten element zrobi dalej, a tego nie widać w przechwyceniu.

Opracowanie obejmuje cztery sposoby, w jakie kontrola rzeczywiście się przemieszcza, odstęp między przekazaniem a chwilą, gdy ktoś to zauważa, sześć udokumentowanych przypadków z datami, a także powód, dla którego monitorowanie, które by je wychwyciło, znajduje się w rejestrach, sprawozdaniach i zapisach repozytoriów, a nie w sieci.

Wykazy składników, poświadczenia kompilacji, oświadczenia o możliwości wykorzystania podatności, raporty o zabezpieczeniach, polityki przeglądarki, oceny stanu, wykrywanie powierzchni ataku i weryfikacja rzeczywistej własności. Dziewięć kategorii, co ustala każda z nich i w którym dokładnie punkcie każda się zatrzymuje.

Opracowanie wprost nazywa to, co dodaje ta metoda: krok między miejscem, gdzie kończy się wykrywanie zewnętrzne, a miejscem, gdzie zaczyna się ustalanie własności. Określa też cztery pojęcia, na których opiera się ta praca, i wyjaśnia, dlaczego nieujawniony dostawca zwykle nie jest dostawcą ukrywanym.

Przechwycenie, identyfikacja, przypisanie i uzgodnienie, stosowane do każdego dostawcy, którego wskazują dowody, i powtarzane wobec poziomów poniżej. Lista dostawców zapisuje decyzje; aplikacja zapisuje zachowanie, a te dwa rozchodzą się od dnia podpisania umowy.

Opracowanie obejmuje pełny cykl, osie obserwacji i przypisania, po których biegnie, sposób przypisania hosta do firmy oraz to, co się dzieje, gdy się to nie udaje, a także zawartość produktu końcowego.