Analiza Składników Oprogramowania

Wprowadzenie

Każdy system i prawie wszystkie aplikacje wykorzystują komponenty oprogramowania open source software (OSS). Wiąże się to z ryzykiem dla tworzonych aplikacji oprogramowania. Ryzyka te można podzielić na 5 kategorii:

• Kontrola wersji: ryzyko zmian wprowadzonych przez nowe wersje całego komponentu OSS i jego bibliotek składowych

• Bezpieczeństwo: ryzyko wystąpienia luk w komponentach przy wykorzystaniu słownika powszechnie znanych podatności oraz zagrożeń Common Vulnerabilities and Exposures (CVE)

• Licencja: ryzyko prawne związane z prawem własności intelektualnej

• Rozwój: ryzyko niezgodności między istniejącym kodem źródłowym aplikacji własnej a wykorzystywanym oprogramowaniem open source

• Wsparcie: ryzyko słabej dokumentacji i przestarzałych komponentów oprogramowania

Dla organizacji intensywnie korzystających z komponentów open source powstała potrzeba pomocy w automatyzacji analizy i oceny ryzyka. Doprowadziło to do powstania nowej klasy produktów tj. Analiza Składników Oprogramowania (Software Composition Analysis, SCA), które pomaga zarządzać ryzykiem open source. SCA dąży do wykrycia wszystkich komponentów stron trzecich używanych w aplikacji oprogramowania, aby pomóc zmniejszyć ryzyko związane z lukami bezpieczeństwa, wymogami licencyjnymi i przestarzałymi komponentami.

Produkty SCA

Produkty SCA zazwyczaj działają w następujący sposób:

1. Silnik SCA skanuje kod źródłowy oprogramowania oraz powiązane artefakty używane do kompilacji aplikacji oprogramowania.
2. Silnik SCA identyfikuje komponenty open source i ich wersje, a zazwyczaj informacje te są przechowywane w bazie danych, tworząc katalog open source używanych w zeskanowanej aplikacji.
3. Katalog komponentów jest następnie porównywany z bazami danych odnoszącymi się do znanych luk bezpieczeństwa dla każdego komponentu, wymogów licencyjnych dotyczących korzystania z komponentu oraz historycznych wersji komponentu:
   1. w celu wykrywania luk bezpieczeństwa, porównanie to zazwyczaj odbywa się na podstawie znanych luk bezpieczeństwa (CVE),
   2. niektóre produkty korzystają z dodatkowej, własnej bazy danych dotyczącej luk bezpieczeństwa,
   3. pobranie informacji o licencji i ocena jej typu,
   4. wersje komponentów są pobierane z popularnych repozytoriów open source, takich jak GitHub, Maven, PyPi i wiele innych
4. Kalkulowany zostaje scoring ryzyka dla komponentów open source i jego składowych.

Zastosowania

Ponieważ SCA wpływa na różne funkcje w organizacjach, różne zespoły mogą korzystać z danych w zależności od wielkości i struktury korporacji. Dział IT często korzysta z SCA do implementacji i operacyjnego korzystania z technologii, a do typowych interesariuszy należą:

• główny dyrektor IT (CIO) - w zakresie zapewnienia właściwego procesu oceniania jakości używanego oprogramowania i zasobów niezbędnych dla jego poprawnego działania procesu,
• główny dyrektor ds. technologii (CTO) - w zakresie dopuszczalności technologii i kryteriów dopuszczalności oprogramowania,
• główni architekci przedsiębiorstwa - w celu uwzględnienia jakości komponentów w trakcie projektowania architektury rozwiązania,
• szef działu bezpieczeństwa informacji (CSO/CISO) w zakresie monitorowania i oceny ryzyka związanego z bezpieczeństwem oprogramowania,
• szef działu compliance (CCO) - w zakresie zgodności z regulacjami w tym zarządzaniem ryzykiem własności intelektualnej.

W zależności od możliwości produktu SCA, może on być implementowany bezpośrednio w zintegrowanym środowisku programistycznym (IDE) oraz jako krok łańcucha ciągłego wytwarzania oprogramowania CI/CD pipeline. Może być także wdrożony jako dedykowany etap w procesie kontroli jakości oprogramowania.

Produkty SCA, a zwłaszcza ich zdolność do generowania zestawienia składników oprogramowania (Software Bill of Materials, SBOM), są wymagane w niektórych krajach, w celu egzekwowania bezpieczeństwa oprogramowania dostarczanego do publicznych agencji.

Innym powszechnym zastosowaniem SCA jest technologicznej dogłębnej analizy przedsiębiorstwa (Due diligence) dla celów jego wyceny. Przed transakcją fuzji i przejęcia (M&A), firmy doradcze oceniają ryzyko związane z oprogramowaniem firmy przejmowanej.

Zobacz też

• Wolne oprogramowanie
• Common Vulnerabilities and Exposures