Nedávno firma SAS zveřejnila trochu žalostnou výzvu, aby podniky omezily počet projektů využívajících kód open source na poněkud svévolně stanovené procento. Vypadá to ale spíše jako pokus o protest proti vzestupu open source programovacího jazyka R pro datovou vědu a analýzy, tedy na trhu, kde SAS dominuje.
Je v tom však skryté i něco dobrého: Používání open source zodpovědným způsobem znamená vědět, co používáte, abyste to mohli sledovat a udržovat.
Většina podniků si ani neuvědomuje, kolik open source kódu jejich vývojáři využívají a jakým zranitelnostem je to může vystavit. Nemůžete posoudit zabezpečení, ani spravovat opravy u projektů open source, u kterých ani netušíte, že na ně spoléháte.
Studie dodavatelského řetězce softwaru Sonatype 2016 zjistila, že komponenty třetích stran obsahují osmdesát až devadesát procent kódu v typickém podnikovém prostředí Java – a jedna ze šestnácti z těchto komponent, které podniky stahují, obsahuje zranitelnost zabezpečení.
Starší komponenty mají dokonce třikrát tolik bezpečnostních chyb než novější varianty a více než polovina komponent používaných v podnikových aplikacích je starší než dva roky. Dva roky poté, co byla zjištěna chyba Krvácejícího srdce (Heartbleed), byla nadpoloviční většina verzí OpenSSL testovaných ve společnosti Cisco Security Research stále zranitelná.
V roce 2014 zjistila společnost Veracode, že komponenty open source a komponenty od nezávislých dodavatelů použité v podnikových webových aplikacích způsobily průměrně 24 známých zranitelností v každé z pěti tisíc kontrolovaných aplikací.
„Dokonce i ty softwarové společnosti, které vědí, že používají kód open source, možná potřebují nástroje pro lepší správu. Podniky jen málokdy vědí, kolik kódu open source využívají,“ uvádí Rami Sass, výkonný ředitel a spoluzakladatel služby WhiteSource, která se zaměřuje na monitorování a správu kódu open source.
„Organizace, jako jsou banky, společnosti poskytující finanční služby či mediální podniky, mívají v současné době velká oddělení softwarového inženýrství.
Často je ale překvapí zjištění, jak rozsáhlé je jejich využívání kódu open source a jak málo z toho jejich manuální inventarizační procesy sledují. Průměrně najdou trojnásobek počtu komponent, než si mysleli, že mají. Někdy je to až desetkrát více.“
To ale neznamená, že by nebylo dobré, aby vaši vývojáři využívali open source, zvláště pokud směřujete k DevOps, protože je k dispozici mnoho užitečných nástrojů v oblastech, kde vás psaní vlastního kódu nijak neodliší od konkurence.
„Používání kódu open source ve firmách má smysl, protože chcete, aby se vaši vývojáři zaměřili na vaše klíčové aktivity,“ vysvětluje Sass. „Stejně jako potřebujete to, co bylo už vynalezené, potřebujete také znovu použít to, co už se otestovalo a udržuje se komunitou, abyste nemuseli dělat veškerou tuto těžkou práci sami. To je důvod, proč všichni milují open source – ale bohužel má open source i své vlastní problémy.“
Závazky z licencí
V minulosti se firmy často velmi zabývaly licenčními aspekty open source. „Open source je zdarma, ale nese s sebou mnoho úskalí,“ upozorňuje Sass. Licencování kódu open source může být pro komerční organizace minovým polem.
Rostoucí počet projektů sice využívá benevolentní (permissive) licence, jako jsou licence MIT a Apache, které mají minimální požadavky na to, jak lze kód redistribuovat, ale jiné licence mají už poněkud náročnější požadavky.
Nedávné pokyny Googlu k tomu, jak tato firma využívá open source, zahrnují poznámky, jaké licence, jako je například AGPL, jsou interně zakázané z důvodu jejich požadavků na zveřejnění kódu odvozených děl.
Dokonce i softwarové projekty, které jsou označené jako public domain a „bezplatné pro libovolné použití“ je nutné zvažovat opatrně, protože publikovat software jako public domain není vůbec snadné.
Pokud jste komerční organizace, musíte se vyhnout softwaru, který je bezplatný pouze pro nekomerční využití, což zahrnuje několik licencí Creative Commons.
To samozřejmě neznamená, že se musíte vyhnout využití open source, ale potřebujete chápat důsledky licencí, které přijímáte využitím těchto projektů.
Vzájemně propojená povaha projektů open source to může ještě více zkomplikovat, protože mnoho lidí pomocí správce balíčků npm zjistilo po zápasu s názvy balíčků, že vývojář nezveřejnil řadu balíčků, na kterých závisejí další projekty.
„Jedna komponenta open source může mít závislosti na mnoha dalších obdobných komponentách. Kdykoli vývojář takovou komponentu použije, přináší to s sebou celý strom závislostí, a ta často není vůbec viditelná. Musíte znát svůj inventář těchto komponent, ale většina organizací to nezvládá,“ upozorňuje Sass.
Vezměme si takzvané licence copyleft, jako je GPL, které obecně vyžadují, abyste publikovali veškeré změny, které uděláte v jejich kódu.
„Průměrný podnik bude používat některé komponenty open source s licencí GPL,“ tvrdí Sass. „Z celkových 300 komponent to bude možná jedna nebo dvě či tři s GPL. To je téměř vždy překvapí.“
Potřebujete nejen vědět, jaký kód open source používáte, ale je také nutné sledovat projekty open source, do kterých vaši vývojáři mohou přispívat kódem.
Jedním ze způsobů, jak to lze dělat, je využívat GitHub Business. Přestože většina organizací jej považuje pouze za cloudovou službu, která jim ušetří problémy s provozem GitHub Enterprise na jejich vlastních serverech, poskytuje také kontrolu nad identitami, pod kterými vývojáři vaší organizace využívají repozitáře GitHub a přispívají do nich.
„Naši zákazníci chtějí více přímého spojení s vývojáři, projekty a komunito, a k tomu GitHub dobře poslouží. Kód open source je pro naše zákazníky cenný. Mají z něho prospěch a chtějí do něj přispívat. Chtějí mít přístup k široké škále nástrojů platformy, do které naši partneři přispívají,“ uvádí Connor Sears, šéf produktového designu v GitHubu.
GitHub Business se integruje s vašimi existujícími nástroji pro správu identit, ať už jde o Azure Active Directory, Okta nebo o další systémy identity kompatibilní se standardy SAML či SCIM, jako jsou OneLogin a Shibboleth.
To znamená, že pokud vývojáři z vašeho podniku stáhnou kód open source, přispějí zpět do projektu nebo vytvoří fork pro interní projekt, dělají to z oficiálních firemních účtů, nad kterými budete mít kontrolu i tehdy, pokud by z vaší firmy odešli. Nepracují tedy na GitHubu pod svými osobními účty.
Otázka zabezpečení
Další klíčovou oblastí při používání kódu open source je, abyste si zajistili aktualizaci v případě nalezení problémů se zabezpečením. „Když vývojář použije zranitelnou komponentu open source a integruje ji do vašeho softwaru, přináší to zranitelnost i vám a vašim zákazníkům,“ upozorňuje Sass.
Skutečným problémem však není, že existují zranitelnosti, protože ty budou vždy, ale to, že mohou zůstat neopravené. Vždy najdete zastaralé knihovny či zranitelné komponenty a téměř vždy objevíte licence, které podnik nebude chtít používat.
„Dobrou věcí na open source je, že problémy lze celkem snadno vyřešit, jakmile o nich víte. Obvykle to nevyžaduje obrovské úsilí jít a zaktualizovat komponenty, přestože někdy dochází k problémům s kompatibilitou. Obyčejně existuje někdo v komunitě open source, kdo se již snažil problém vyřešit,“ vysvětluje Sass.
Aplikování těchto oprav systematicky znamená sledování a správu vámi používaného kódu open source stejně jako ostatních částí vašeho dodavatelského řetězce – a dělat to manuálně není efektivní.
Nástroje pro analýzu skladby softwaru, jako jsou WhiteSource, Black Duck, Palamida (nedávno koupená společností Flexera), Sonatype Nexus, Synopsys nebo Veracode, vám pomohou celý proces automatizovat.
Například WhiteSource má pluginy pro populární nástroje a služby pro správu zdrojů, jako je například Visual Studio Team Services a Jenkins, a je součástí balíku Visual Studio 2017, takže dokáže automaticky sbírat podrobnosti o komponentách open source, které vaši vývojáři používají, a vytvářet reporty ukazující, jaké zranitelnosti zabezpečení se našly a co je potřeba udělat pro zmírnění problémů.
Můžete také získat reporty o licencích, které tyto komponenty používají, a dokonce nastavit zásady, které reagují na licenční problémy a zranitelnosti zabezpečení.
„Můžete používat blacklist i whitelist pro licence. Zákazníci často používají blacklist pro licence typu GPL a whitelist pro benevolentní licence typu MIT,“ vysvětluje Sass.
Podle něj můžete mít také zásady týkající se zranitelností zabezpečení. Pokud vývojář použije novou knihovnu open source se známou zranitelností zabezpečení, lze ji zablokovat. Je možné také odeslat upozornění o nově zjištěné zranitelnosti v knihovně, a není přitom nutné čekat na to, až se spustí vytváření reportu.
Tyto zásady mohou být přímo provázené s vývojářským pracovním postupem prostřednictvím serveru pro sestavení nebo pomocí integrace se systémy jako Git, GitHub, JIRA a Artefactory.
Pokud například používáte kontinuální integraci a vývojář použije novou knihovnu, která používá licenci jako GPL nebo má závažnou zranitelnost zabezpečení, zásada zareaguje, sestavení se nezdaří a vývojář dostane upozornění na problém s knihovnou.
Když se někdo pokusí přidat nový artefakt do repozitáře, lze nastavit zásady a blokovat ho. Pokud přidá knihovnu, která má zranitelnost zabezpečení se středním nebo nízkým dopadem, může se přesměrovat upozornění na pracovníka zabezpečení, takže se bude rozhodovacího procesu účastnit více než jedna osoba.
Přemýšlejte o tom jako o změně způsobu řízení, které nastává ve vývojovém procesu dříve, a jako o automatizaci práce související s dodržováním předpisů. „Dokážete najít problém, co nejdříve je to možné, a můžete zablokovat vstup komponenty do vašeho prostředí,“ dodává Sass.
WhiteSource má také plugin pro prohlížeče navržený tak, aby pomáhal vývojářům lépe volit, jaké komponenty open source použít. Když vývojáři navštíví webovou stránku, která zmiňuje komponenty open source, plugin je porovná s databází WhiteSource a zobrazí překryvné okno s podrobnostmi o licenci, známých zranitelnostech a zásadách vaší společnosti.
Pokud chcete dodržovat regulační finanční standardy jako PCI-DSS a FS-ISAC, je nutné využívat zásady pomáhající řídit využívání komponent open source a komponent třetích stran.
Pro používání kódu open source zatím neexistují standardní zásady, které by byly široce přijímané v podnicích v dalších oborech, ale Sass se domnívá, že se objeví, zejména protože například americká vláda začala takovéto zásady sama pro sebe už vytvářet.
„Vláda směřuje do oblasti open source.Mají podle pravidel nyní vydávat určité jimi vytvořené množství kódu v rámci open source a chtějí to regulovat pomocí zásad. Jakmile to udělají, budou je velké organizace určitě následovat,“ předpokládá Sass.
Šéfové IT si nemohou dovolit zavírat oči před množstvím komponent open source, jaké podnikoví vývojáři používají. Místo toho je nezbytné to začít sledovat a řídit, aby se zajistila kontrola nad problémy s licencováním a zabezpečením.
„Výhody výrazně převažují nad nevýhodami,“ uvádí Sass. „Potřebujete to jen spravovat, takže open source můžete používat a zvýšit pomocí něj produktivitu – nemusíte se obávat.“
Tento příspěvek vyšel v Computerworldu 6/2017. Časopis (starší čísla i předplatné těch nadcházejících) si můžete objednat na adrese našeho vydavatelství.
PŘEDPLATNÉ
ČLÁNKY DO MAILU