Według inżynierów Google’a potrzeba większej odpowiedzialności programistów za to co piszą.

Google chce nowych zasad dla programistów pracujących nad „krytycznymi” projektami

Jeśli Twój projekt oprogramowania open source zostanie uznany za „krytyczny”, w przyszłości możesz mieć znacznie więcej pracy i odpowiedzialności. Ale na razie to tylko kilka pomysłów pochodzących od paru inżynierów Google. Ich zdaniem oprogramowanie open source powinno być bezpieczniejsze niż oprogramowanie zamknięte, ale tylko wtedy, gdy ktoś je sprawdza. Aby przyszłe ataki nie dotyczyły kluczowych projektów oprogramowania typu open source, proponuje się stosować wobec takich projektów nowe „normy”.

Chodzi o to, że jeśli dany projekt zostanie uznany za „krytyczny” (np. cała branża mogłaby decydować, że dany projekt jest „krytyczny”), wymagane byłoby od właścicieli projektów i osób odpowiedzialnych odpowiednie podejście do identyfikacji zagrożeń i uwierzytelniania zmian. Oznaczałoby to koniec dowolnych zmian w kodzie i poddawanie zmian przeglądowi przez stronę trzecią. Tylko czy wtedy jeszcze jest się w ogóle właścicielem takiego kodu, co z prawami autorskimi?

Cele

Firma przedstawiła swoje sugestie w poście na blogu. Google przyznaje, że jego sugestie dotyczące krytycznego oprogramowania open source są uciążliwe dla właścicieli projektów, dlatego spodziewa się oporu. Rob Pike i Eric Brewer argumentują w tym poście, że branża powinna zgodzić się na wspólne zdefiniowanie zestawu „krytycznych” pakietów oprogramowania i stosowanie tych wyższych standardów tylko do tego zestawu. Cele jakie miałyby być osiągnięte to:

• Brak jednostronnych zmian w kodzie. Zmiany wymagałyby przeglądu kodu i zatwierdzenia przez dwie niezależne strony.
• Uwierzytelnianie uczestników procesu rozwoju oprogramowania. Oznacza to, że właściciele i opiekunowie nie mogą być anonimowi; współpracownicy są zobowiązani do korzystania z silnego uwierzytelniania (np. 2FA).
• Muszą być powiadomienia o zmianach ryzyka w oprogramowaniu.
• Stworzenie „zaufania” do procesu tworzenia oprogramowania.

Trzy kluczowe cele postawione ogólnie dla całego oprogramowania open source ujmowane są tak:

• Dowiedz się o lukach w swoim oprogramowaniu.
• Zapobiegaj dodawaniu nowych luk w zabezpieczeniach.
• Napraw lub usuń luki.

Sprawdź oferty pracy na TeamQuest

Open source nie jest wolny od luk

Niedawne ataki na całe łańcuchy dostaw oprogramowania z udziałem SolarWinds obejmowały oprogramowanie zamknięte lub zastrzeżone. Google zauważa jednak, że Oprogramowanie open source powinno być mniej ryzykowne pod względem 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 prawda, zakłada się, że ludzie faktycznie patrzą na kod.

Projekty oprogramowania typu open source, w szczególności Java i JavaScript / Node.js, opierają się na tysiącach bezpośrednich i pośrednich zależności, co utrudnia ich badanie w poszukiwaniu luk.

Inżynierowie Google zauważają, że monitorowanie ich wszystkich jest niepraktyczne i dodają, że wiele pakietów open source nie jest dobrze utrzymywanych. Open source prawdopodobnie w większym stopniu wykorzystuje zależności niż źródła zamknięte i korzysta z szerszej gamy dostawców; liczba odrębnych podmiotów, którym należy zaufać, może być bardzo duża.

Aby stawić czoła atakom branża musi się więc skupić na eliminowaniu większości luk ponieważ osoby atakujące często wykorzystują jedynie znane luki, zamiast znajdować własne. Problem organizacji korzystających z oprogramowania open source polega na tym, że niewiele osób weryfikuje wszystkie używane przez siebie pakiety. Nawet Google uważa to zadanie za trudne: śledzenie tych pakietów wymaga niebanalnej infrastruktury i znacznego wysiłku ręcznego.

Google dysponujemy tymi zasobami i dokładamy wszelkich starań, aby zarządzać używanymi przez nas pakietami open source - w tym utrzymywać prywatne repozytorium wszystkich pakietów open source, których używamy wewnętrznie.

Czy to nie brzmi dla Ciebie jak próba zawłaszczenia kolejnej działki Internetu, po zamiarach Google względem cookies?