Nowoczesne praktyki tworzenia oprogramowania i często korzystanie z bibliotek open source sprawiają, że zabezpieczenie łańcucha dostaw oprogramowania jest ważniejsze niż kiedykolwiek.

Niektóre z tych kodów są niemal wszechobecne. Log4Shell, który spowodował spustoszenie w całej branży, był efektem wykorzystania starego błędu w popularnym komponencie logowania Java, log4j. Budujemy przemysł, który nie stoi na barkach gigantów, ale na barkach garstki opiekunów aplikacji i komponentów, którzy utrzymują naszą globalną infrastrukturę w dobrym stanie w wolnym czasie i z dobroci serca.

Zobacz również:

• Oficjalna premiera modelu Llama 3
• IBM prezentuje modele fundamentalne generatywnej AI

Rozproszony rozwój zwiększa ryzyko

Nie chodzi o to, by pozbawić pracy serwisantów; są oni niezbędną częścią współczesnego łańcucha dostaw oprogramowania, dostarczając wszystko, od małych modułów po całe platformy oparte na kontenerach. Bez wątpienia są niedoceniani i zbyt nisko opłacani w stosunku do tego, jak ważny jest ich kod.

Można oczekiwać dalszego zwiększania liczby cyberataków, ponieważ coraz więcej kodu powstaje jako efekt pracy grup. Jak możemy chronić siebie i nasze aplikacje? Po pierwsze i najważniejsze, musimy zrozumieć, że łańcuch dostaw oprogramowania istnieje w rzeczywistości, że nie budujemy kodu w izolacji i nie robimy tego już od dłuższego czasu, jeśli w ogóle kiedykolwiek to robiliśmy. Otwarte źródła i biblioteki stron trzecich są istotną częścią tego, jak tworzymy oprogramowanie, a ich znaczenie będzie tylko rosło.

Jakie kroki możemy podjąć, aby zabezpieczyć łańcuch dostaw oprogramowania? Wiele pracy włożono w dostarczenie narzędzi do zarządzania zestawem materiałów do produkcji oprogramowania: skanowanie kodu w poszukiwaniu bibliotek, analiza statyczna i dynamiczna, dodawanie podpisów cyfrowych i haseł do kodu oraz umieszczanie tego wszystkiego w zarządzanych repozytoriach. Jednak brakuje jednej części obrazu: Jak zwalidować tę pracę i sprawdzić kod, którego używamy? W końcu, jednym z odwiecznych porzekadeł dotyczących bezpieczeństwa pozostaje "ufaj, ale sprawdzaj".

Zabezpieczanie łańcucha dostaw oprogramowania

Musimy ufać kodowi, którego używamy, ale musimy także zweryfikować, czy jest on godny zaufania. Musimy również robić to pod presją czasu, z kodem natywnym w chmurze dostarczającym nowe kompilacje w miarę zmian kodu w repozytoriach. Z pomocą przychodzi automatyzacja z platformami takimi jak GitHub, zapewniając ciągłą integrację i ciągłe dostarczanie (CI/CD).

Sprawy stają się bardziej złożone, gdy pracujemy z technologiami takimi jak Kubernetes, które zostały zaprojektowane w oparciu o filozofię mieszania i dopasowywania architektur mikroserwisów i kontenerów. Podczas gdy nasz kod może działać w odizolowanych kontenerach, działa on w zagnieżdżonych abstrakcyjnych userlandach, a każdy plik dockerfile gromadzi wybór zależności, z których wiele nie jest w pełni udokumentowanych. Jak możemy zaufać liście materiałów w kontenerach, których używamy?

Przedstawiamy Ratify: przepływ pracy do weryfikacji artefaktów

Ratify, opracowany przez Microsoft, to rozszerzalny framework weryfikacyjny dla obrazów kontenerów i innych artefaktów, który może badać i używać niestandardowych polityk, które tworzysz do zatwierdzania wdrożeń w Kubernetes. Ratify może używać i koordynować dowolną liczbę niestandardowych weryfikatorów dla rzeczy takich jak podpisy, SBoMs, wyniki skanowania i tak dalej.

Obrazy i inne komponenty korzystają z narzędzia do podpisywania i weryfikacji Notary V2 oraz specyfikacji ORAS (OCI Registry As Storage) Artifact. ORAS jest częścią definicji rejestru Open Container Initiative, rozszerzając ją do przechowywania czegokolwiek, nie tylko kontenerów. Dobrze sprawdza się jako sposób na złożenie listy materiałów do oprogramowania. Co ciekawe, istnieje wspólna cecha pomiędzy definicją rozproszonego instalatora aplikacji Bindle i manifestem ORAS, dzięki czemu łatwo jest przejść od SBOM do zweryfikowanego rozproszonego instalatora aplikacji. Razem te dwa elementy dostarczają graf łańcucha dostaw, który może być parsowany i używany jako część schematu weryfikacji wewnątrz klastra Kubernetes.

Ratify łączy te koncepcje razem, dodając silnik przepływu pracy, aby zastosować zasady do rachunku materiałów oprogramowania, weryfikując wiele różnych łańcuchów dostaw w całym kodzie i jego zależnościach. W jego sercu znajduje się koordynator, który zarządza przepływem polityk w całym obrazie kontenera. Jest on rozszerzalny, więc może pracować w publicznych i prywatnych rejestrach, używając znanego modelu wtyczek, który jest podobny do tych używanych w Kubernetes.

Polityki Ratify

Model polityki używany przez Ratify jest oparty na znanych narzędziach, oferując sposób na szybkie wdrożenie podstawowych polityk przy użyciu własnych konfiguracji, jak również bardziej złożonych polityk zbudowanych przy użyciu Open Policy Agent. Będzie również działać w różnych punktach cyklu życia aplikacji, podłączając się do systemów CI/CD w celu weryfikacji artefaktów w czasie budowania oraz do Kubernetes w celu zapewnienia, że kod nie został zmieniony pomiędzy budową a uruchomieniem. Ważne jest, aby mieć tryb weryfikacji, który działa w całym stosie, zapewniając, że unikasz ataków na łańcuch dostaw, które mogą wystąpić w kodzie podczas budowania, w repozytoriach i rejestrach oraz w czasie uruchamiania.

Posiadanie jednego narzędzia do obsługi weryfikacji w całym cyklu życia oprogramowania jest ważne, ponieważ zapewnia, że wystarczy tylko raz napisać zasady. Różne narzędzia dla różnych scenariuszy zwiększają ryzyko błędów transkrypcji i tłumaczenia w politykach; posiadanie jednego narzędzia i jednego formatu polityk pomaga uniknąć tego ryzyka. Możesz również skorzystać z zewnętrznego narzędzia do testowania polityk.

Jak zbudować pierwszą politykę Ratify?

Zespół Ratify ma trochę kodu demo w swoim repozytorium GitHub, który pokazuje jak używać Ratify z Gatekeeper w Kubernetes. Ratify instaluje się za pomocą wykresu Helm, przynosząc kilka przykładowych szablonów konfiguracji. Możesz użyć ich do przetestowania operacji Ratify, na przykład, blokując wszystkie obrazy, które nie mają podpisu. Gatekeeper będzie negował wszelkie obrazy kontenerów, które nie są podpisane, blokując ich uruchomienie.

Pliki zasad są napisane w YAML, więc można je edytować w Visual Studio Code lub innych narzędziach, korzystając z narzędzi do formatowania kodu. Składają się one na prosty silnik reguł, przeprowadzający artefakty przez weryfikację. Czy pochodzą one z zatwierdzonego rejestru? Czy sprawdzasz artefakt więcej niż jeden raz dla różnych sygnatur? Czy artefakty w Twoim prywatnym rejestrze są bardziej zaufane niż artefakty z rejestrów publicznych? Czy wszystkie twoje silniki weryfikacyjne zgadzają się, gdy przeprowadzasz wielokrotne sprawdzanie? Okazuje się, że reguły dla weryfikacji runtime są dość proste do zdefiniowania, choć jest mało prawdopodobne, że tak będzie w przypadku weryfikacji działającej w systemie CI/CD, gdzie trzeba określić stan wielu różnych artefaktów i z podpisami z wielu różnych źródeł zaufania.

Ratify jest obecnie interesującą wstępną propozycją dla zestawu narzędzi, które mogą zarządzać wszystkimi elementami w zestawieniu materiałów oprogramowania. Chociaż nie zapobiegnie to zero-day wpływającym na długo ukryte błędy, może szybko określić, jaki kod jest dotknięty, tworząc reguły, aby zapobiec jego użyciu i uruchomieniu.

W sytuacji, gdy ryzyko związane z łańcuchem dostaw znajduje się w centrum uwagi, ważne jest, aby branża uważnie przyglądała się propozycjom takim jak ta i pracowała nad nimi w przestrzeni publicznej. Dobrze jest widzieć, że Microsoft już zobowiązał się do udostępnienia Ratify z Cloud Native Computing Foundation, gdzie powinien uzyskać kontrolę od szerszej społeczności rozwoju Kubernetes, której potrzebuje.

Źródło: Info World