Darmowe nie oznacza dobre - przykładem programy open-source
Jeśli chętnie korzystacie z oprogramowania typu open source, to lepiej dobrze się zastanówcie. Najnowsze badania dowodzą bowiem, że większość zawiera poważne luki, które mogą stanowić zagrożenie dla użytkowników.
W dzisiejszych czasach produkcja programów nie jest łatwa, gdyż potrzebne są kosztowne licencje umożliwiające legalne korzystanie z nowoczesnych technologii. Deweloperzy chętnie sięgają więc po oprogramowanie open source, które pozwala znacznie ograniczyć koszty realizacji projektów. Tymczasem nie jest to tak dobry pomysł, jak można by sądzić, gdyż może to stwarzać zagrożenie dla użytkowników.
Firma Lineaje postanowiła przyjrzeć się bliżej darmowemu oprogramowaniu i sprawdziła dziesiątki tysięcy projektów open source, odkrywając w nich masę luk bezpieczeństwa. Z badania wynika, że aż 82 procent programów open source, z których korzysta wielu z nas, ze względu na brak poprawek stwarza ryzyko dla użytkownika. Eksperci dodają, że wielu programistów używa kodu pochodzącego z innych projektów, przenosząc tym samym luki w zabezpieczeniach do własnego oprogramowania.
Darmowe nie zawsze znaczy lepsze
Jednym z najbardziej niepokojących odkryć przeprowadzonego badania jest również zależność wielu firm od zewnętrznych programistów – polegają na nich również duże przedsiębiorstwa. Z raportu wynika bowiem, że około 32 procent oprogramowania oferowanego przez firmę Apache Software Foundation zostało napisane przez nią samą. Resztę natomiast wykonali zewnętrzni współpracownicy. Dotyczy to również popularnego serwera HTTP, który obsługuje obecnie znaczną część wszystkich witryn internetowych. Wykorzystano w nim około 320 projektów open source, które zawierają sporo luk, zaś według raportu Lineaje, Apache nie jest w stanie ich wszystkich załatać.
Zdaniem współzałożyciela i dyrektora generalnego Lineaje, Javeda Hasana, producenci powinni zrozumieć, że oprogramowanie open source wiąże się z ryzykiem. Programiści nie mogą bowiem dokładnie sprawdzić wszystkich jego komponentów, zaś większość z nich nie jest ekspertami ds. bezpieczeństwa i nie potrafiłoby wykryć ewentualnego zagrożenia. Jego zdaniem należy więc stworzyć narzędzia do zarządzania łańcuchem dostaw oprogramowania w celu poprawy monitorowania ryzyka. W przeciwnym wypadku wiele programów będzie stanowiło zagrożenie dla ich użytkowników. A co gorsza jego zlikwidowanie może być utrudnione lub wręcz niemożliwe.
Innymi słowy nie wszystko co możemy pozyskać za darmo, jest dla nas bezpieczne i warto mieć to na uwadze.
Więcej:PS6 będzie gorszy od Xboxa Magnusa; nowa generacja konsol przekroczy barierę 30 GB RAM
Komentarze czytelników
slawomirl Legionista
Ostatnio czytałem raport Linux Fundation (której członkiem jest również Microsoft), że statystycznie zamknięty projekt korzysta z około 200 otwartych projektów.
Więc jak się by twórcy tego raportu do tego odnieśli? Skoro zamknięty projekt korzysta z otwartego, to raczej dziedziczy wszystkie błędy.
W raporcie LF były też inne, ważne tezy, ale nie chcę mi się go ponownie czytać.
slawomirl Legionista
A mnie denerwuje, jak ktoś mówi, że w OpenSource panują inne (niższe) standardy pisania kodu. Sam piszę kod, a w korporacjach także robi się code-review, bo sam swoich błędów nie zobaczysz. W dodatku, to twierdzenie, że dokumentacja jest zbędna, jak kod jest dobrze napisany. Przecież w korporacjach także są standardy czytelności, czy nawet korzystają z narzędzi generującej dokumentację z kodu lub/i odwrotnie.
Jerry_D Senator
Ja w ogóle miałem na myśli sprawdzanie zewnętrzne i to, że jak masz kod to łatwiej przejrzeć kod, niż dekompilować program, albo masz program jako "czarną skrzynkę" i robisz fuzzing, wprowadzając losowe dane, a potem na podstawie efektów próbujesz się domyślać jak program działa i z czego wynikają ewentualne błędy.
Ale z tym, że łatwiej wytropić błędy w cudzym, to masz rację. I to nie tylko w kodzie, ale nawet w zwykłym tekście własnych błędów człowiek nie widzi.
Narmo Generał
ale po prostu łatwiej odnaleźć błędy, gdy masz dostęp do kodu.
Ja bym powiedział, że łatwiej jest znaleźć błędy w cudzym kodzie :)
W wypadku programów Open Source może być też więcej chętnych do sprawdzania.
Jerry_D Senator
"Jakoś Linux i Mozilla pokazują, że większość błędów jest łatana w parę dni."
Parę lat temu ktoś zrobił ciekawą analizę i wynikało, że wśród przeglądarek Mozilli najdłużej zabierało łatanie luk (najwięcej dni od zgłoszenia do łatki). Nie wiem jak jest obecnie, może się zmieniło na lepsze.
"Nie raz czytałem art o nowej, super podatności, na którą dzień wcześniej zainstalowałem poprawkę."
A to dlatego, że w branży standardem jest tzw. "responsible disclosure", czyli publiczne ujawnianie podatności dopiero, gdy twórcy mają już dostępną łatkę, nie dlatego, że wszystko jest tak błyskawicznie łatane. W praktyce przyjęło się czekać półtora miesiąca, aż twórcy zareagują, a jeśli mają temat gdzieś, wtedy następuje "full disclosure", czyli pełne ujawnienie, niezależnie od tego czy błąd jest załatany, czy nie (termin zazwyczaj jest wydłużany, jeśli twórcy problemem się zajęli, ale potrzebują więcej czasu). To często skuteczna metoda na takich, którzy z różnych powodów podatności naprawić nie chcą.
I ogólnie rzeczywiście w projektach open source odnajduje się więcej błędów, co oczywiście nie oznacza, że są z założenia gorsze, ale po prostu łatwiej odnaleźć błędy, gdy masz dostęp do kodu.
GRYOnline.pl:
tvgry.pl:
