W poszukiwaniu przewagi konkurencyjnej firmy coraz częściej korzystają z wyspecjalizowanych systemów oprogramowania. W efekcie posiadane przez nie zasoby IT stają się składanką systemów różnych dostawców. Może to zagrażać bezpieczeństwu informacji. Wraz ze wzrostem liczby rozwiązań rośnie liczba miejsc, które wymagają różnych form zabezpieczeń i uprawnień dostępowych. Sprawia to, że włamywacze mają do dyspozycji więcej potencjalnych punktów, przez które mogą próbować się dostać do zasobów firmy. Ponieważ w celu optymalizowania wydajności i produktywności firmy korzystają z coraz większej integracji systemów, atak może szybko się rozprzestrzenić.
Ataki za pośrednictwem łańcucha dostaw oprogramowania — wykorzystujące oprogramowanie zewnętrznych dostawców w celu przeniknięcia do organizacji — stały się dziś praktycznie powszechne. W 2020 r. złośliwy kod wstrzyknięty w aktualizację oprogramowania firmy SolarWinds najpierw zaatakował departamenty rządu federalnego, a potem rozprzestrzenił się na skalę globalną, zarażając około 18 tys. organizacji. W marcu tego roku w związku z luką w oprogramowaniu Exchange Server firmy Microsoft naruszone zostały zabezpieczenia ponad 20 tys. amerykańskich organizacji.
Nierzadko najwyższe ryzyko stwarzają pozornie mniej istotni partnerzy z łańcucha dostaw – ich rola nie wydaje się być znacząca, przez co nie dostrzega się w nich potencjalnego źródła zagrożenia. Jedno z największych naruszeń ochrony danych w historii to dokonany w 2013 r. atak na amerykańską sieć sklepów Target, zrealizowany poprzez włamanie do oprogramowania systemu klimatyzacji partnera tej firmy. Bezpieczeństwo łańcucha dostaw zyskało taką uwagę mediów, że stało się przedmiotem nowego rozporządzenia wykonawczego prosto z Białego Domu.
Nie można zatem ignorować zagrożeń atakami opartymi na łańcuchu dostaw oprogramowania, jednak z drugiej strony na uwagę zasługują również obiecujące rozwiązania techniczne. Wiele organizacji musi pogodzić te dwie perspektywy. W praktyce może to zmuszać twórców oprogramowania do podjęcia decyzji: albo dokładamy starań, aby spełniać najwyższe standardy bezpieczeństwa, albo rezygnujemy z niedogodności i tarć, skupiając się na tworzeniu kodu.
Jednym ze sposobów pogodzenia tych pozornie przeciwstawnych trendów jest zmiana procesu podpisywania oprogramowania. Służy on zapewnieniu niepodważalnego dowodu, że przed wdrożeniem oprogramowanie nie zostało zmodyfikowane ani uszkodzone.
W tradycyjnych technikach podpisywania kodu stosuje się klucze kryptograficzne np. do weryfikacji autora i integralności zawartości repozytorium oprogramowania. Obciąża to programistów koniecznością generowania kluczy i przechowywania ich w bezpiecznym miejscu. Niektórym to obciążenie może wydawać się zbyt duże, więc przestają podpisywać swój kod (co jest szkodliwe z punktu widzenia zabezpieczeń) albo piszą mniej kodu (co nie służy innowacyjności). Oba podejścia mają konsekwencje dla innych programistów. Obecnie dużą część oprogramowania na świecie tworzy się na zasadach otwartego źródła, co oznacza, że każdy może taki kod wykorzystać i dostosować — w tej sytuacji kluczowe znaczenie ma kwestia pochodzenia. Dotyczy to w takim samym stopniu oprogramowania komercyjnego, które coraz częściej bazuje na publicznie dostępnym kodzie źródłowym.
A jednak to właśnie segment otwartego źródła zaczyna być liderem w tworzeniu coraz bardziej przyjaznego dla programistów środowiska podpisywania oprogramowania. Projekt ten nosi nazwę sigstore i zastępuje klucze o długim czasie życia kluczami efemerycznymi powiązanymi z istniejącymi identyfikatorami (np. adresy e-mail i loginy do mediów społecznościowych). Generuje on także publiczny, niezmienny dziennik całej aktywności. Oba te elementy w gruncie rzeczy zdejmują z programistów obowiązek podpisywania oprogramowania, dzięki czemu mogą zająć się tym, w czym są najlepsi. Co więcej, system niebazujący na kluczach, które mogą zostać skradzione lub zgubione, jest z natury bezpieczniejszy.
Projekt błyskawicznie się rozwija. Od czasu jego uruchomienia w 2019 r. do jego twórców — firm Red Hat i Google oraz Uniwersytetu Purdue — dołączyły inne organizacje, a patronat nad projektem objęła Linux Foundation. Poszerzono także jego zakres, powołując do życia takie projekty pochodne jak Cosign (podpisywanie kontenerów i ogólnych artefaktów oprogramowania), Rekor (dziennik transparentności) i Fulcio (organ certyfikacji). Rozpoczęto także współpracę z innymi inicjatywami opartymi na otwartym źródle, m.in. z projektem Tekton Chains (pobocznym przedsięwzięciem w ramach projektu Tekton CI/CD).
To nie tylko ważne czynniki rokujące sukces. Wskazują one także możliwy sposób wdrażania projektu sigstore: jako funkcji zintegrowanej w ramach szerszej technologii. Wszelkie działania zmierzające do wprowadzenia funkcji sigstore do istniejącego zestawu narzędzi programistów przybliżają osiągnięcie jednego z kluczowych celów projektu, jakim jest uproszczenie i zautomatyzowanie cyfrowego podpisywania, tak aby stało się częścią niewidzialnej infrastruktury, a programiści ani go nie zauważali, ani nie musieli się nim przejmować.
