Google proponuje ustanowienie nowych zasad w celu poprawy bezpieczeństwa oprogramowania typu open source

Bezpieczeństwo oprogramowania open source przyciągnęło uwagę branży, ale rozwiązania wymagają konsensusu co do wyzwań i współpracy przy ich wdrażaniu.

Problem jest złożony i należy uwzględnić wiele aspektów, między innymi z łańcucha dostaw, zarządzania zależnościami, tożsamości. W tym celu firma Google niedawno wydała strukturę („Poznaj, zapobiegaj, napraw”), która wyjaśnia, w jaki sposób branża może myśleć o lukach w oprogramowaniu typu open source i konkretnych obszarach, które należy najpierw rozwiązać.

Google wyjaśnia swoje powody:

„Dzięki niedawnym wydarzeniom świat oprogramowania uzyskał głębsze zrozumienie rzeczywistego ryzyka ataków na łańcuch dostaw. Oprogramowanie open source powinno być mniej ryzykowne z punktu widzenia bezpieczeństwa, ponieważ cały kod i zależności są otwarte i dostępne do wglądu i weryfikacji. I chociaż jest to generalnie prawdą, zakłada się, że ludzie faktycznie wykonują te prace kontrolne. Przy tak wielu zależnościach niemożliwe jest monitorowanie ich wszystkich, a wiele pakietów open source nie jest dobrze zarządzanych.

„Często zdarza się, że program jest zależny, bezpośrednio lub pośrednio, od tysięcy pakietów i bibliotek. Na przykład Kubernetes jest teraz zależny od około 1000 pakietów. Open source prawdopodobnie wykorzystuje zależności, a nie oprogramowanie własnościowe i pochodzi od szerszego zakresu dostawców; liczba niezależnych podmiotów, którym można zaufać, może być bardzo duża. To sprawia, że ​​niezwykle trudno jest zrozumieć, w jaki sposób oprogramowanie open source jest wykorzystywane w produktach i jakie luki w zabezpieczeniach mogą być istotne. Nie ma również gwarancji, że to, co zostało zbudowane, będzie zgodne z kodem źródłowym.

W ramach zaproponowanych przez Google sugeruje się podzielenie tej trudności na trzy w dużej mierze niezależne obszary problemowe, z których każdy ma określone cele:

Poznaj luki w swoim oprogramowaniu

Poznanie luk w zabezpieczeniach oprogramowania jest trudniejsze, niż można by się spodziewać Z wielu powodów. tak ok istnieją mechanizmy zgłaszania podatności, nie jest jasne, czy rzeczywiście wpływają one na określone wersje używanego oprogramowania:

• Cel: dokładne dane o lukach: Po pierwsze, niezwykle ważne jest, aby uchwycić dokładne metadane dotyczące podatności ze wszystkich dostępnych źródeł danych. Na przykład wiedza, która wersja wprowadziła lukę, pomaga określić, czy dotyczy ona oprogramowania, a wiedza, kiedy zostało ono załatane, zapewnia dokładne i terminowe poprawki (oraz wąskie okno na ewentualną eksploatację). W idealnym przypadku ten przepływ pracy klasyfikacji powinien być zautomatyzowany.
• Po drugie, większość luk znajduje się w zależnościach, a nie w kodzie, który piszesz lub bezpośrednio kontrolujesz. Dlatego nawet jeśli kod się nie zmienia, krajobraz luk w zabezpieczeniach oprogramowania może się stale zmieniać - niektóre są naprawiane, a inne dodawane.
• Cel: Standardowy schemat baz danych zawierających luki w zabezpieczeniach Do śledzenia i utrzymywania luk w zabezpieczeniach typu open source, zrozumienia ich konsekwencji i zarządzania ich środkami zaradczymi wymagane są standardy infrastrukturalne i branżowe. Standardowy schemat podatności umożliwiłby uruchamianie wspólnych narzędzi w wielu bazach danych luk i uprościłby zadanie śledzenia, zwłaszcza gdy luki w wielu językach lub podsystemach.

Unikaj dodawania nowych luk w zabezpieczeniach

Idealnie byłoby uniknąć tworzenia luk w zabezpieczeniach I chociaż narzędzia do testowania i analizy mogą pomóc, zapobieganie zawsze będzie trudnym tematem.

tutaj Google proponuje skupienie się na dwóch konkretnych aspektach:

• Zrozum ryzyko przy podejmowaniu decyzji o nowej zależności
• Usprawnij krytyczne procesy tworzenia oprogramowania

Napraw lub usuń luki

Google przyznaje, że ogólny problem z naprawą jest poza jej zakresem, ale wydawca uważa, że ​​aktorzy mogą zrobić znacznie więcej, aby rozwiązać ten problem specyficzne dla zarządzania lukami w zależnościach.

Wspomina również o: 

„Dziś na tym froncie niewiele się pomaga, ale gdy poprawiamy dokładność, warto zainwestować w nowe procesy i narzędzia.

„Jedną z opcji jest oczywiście bezpośrednie załatanie luki. Jeśli możesz to zrobić w sposób zgodny z poprzednimi wersjami, rozwiązanie jest dostępne dla każdego. Ale wyzwanie polega na tym, że jest mało prawdopodobne, abyś miał doświadczenie z problemem lub bezpośrednią umiejętnością wprowadzania zmian. Naprawienie luki w zabezpieczeniach zakłada również, że osoby odpowiedzialne za konserwację oprogramowania są świadome problemu oraz posiadają wiedzę i zasoby umożliwiające jej ujawnienie.

źródło: https://security.googleblog.com