De gevaren van afhankelijkheid van externe code

Er zijn een paar hele goede dingen over de manier waarop software op internet werkt. Om te beginnen is er een enorm onofficieel netwerk van miljoenen mensen die bijdragen aan een enorme opslagplaats van codefragmenten die veel meer miljoenen applicaties van stroom voorzien.

Telkens wanneer u een kleine link onder aan een webpagina ziet met de tekst 'Powered by So-And-So', ziet u dit samenwerkingseffect in actie.

En natuurlijk is de belangrijkste reden dat mensen deze derde partij delen en samenwerken, is dat het je vele uren in ontwikkelingstijd kan besparen, omdat je niet opnieuw iets uitvindt dat al bestaat. Maar zelfs met deze grote voordelen van het systeem voor het delen van code met derden, zijn er tal van redenen waarom u deze codefragmenten misschien niet zou willen gebruiken, want we zullen het binnenkort te zien krijgen ...

1.Potentiële beveiligingsrisico's

Omdat bijna alle code die iets op het web aanstuurt open source is, is het een goede gok dat als er een kwaadwillige payload is in een bepaalde applicatie, deze snel zal worden ontdekt door de gemeenschap van ontwikkelaars en snel zal worden gecorrigeerd.

Maar veel van deze codefragmenten worden honderden of zelfs duizenden keren per dag gedownload en niet elk administratief team slaagt er goed in een beveiligd systeem voor het delen van codes te onderhouden.

Hoe groter en complexer een toepassing, des te gemakkelijker het te infecteren door enkele regels code op een onbekende plaats toe te voegen. Bijna niemand neemt de tijd om elke coderegel in een toepassing kritisch te bekijken, omdat ze er over het algemeen van uitgaan dat de code kan worden vertrouwd.

Een zeer bekwame programmeur kan het kwaadwillende karakter van de code meestal goed verdoezelen en alleen een andere zeer bekwame programmeur zal uitzoeken wat het doel ervan is ... als het kwaadaardige codefragment wordt gedetecteerd.

2. Jij bent het niet

Dit is eigenlijk een combinatie van problemen. De eerste is dat u mogelijk aan verschillende licentievoorwaarden onderworpen bent. Wanneer u meerdere codefragmenten gebruikt op een enkele webpagina of toepassing, is het mogelijk dat u bent onderworpen aan verschillende licentievoorwaarden en -voorwaarden, en sommige ervan kunnen zelfs in strijd zijn met elkaar.

Natuurlijk vindt bijna niemand het vervelend om deze saaie lijsten met algemene voorwaarden te lezen, maar dat kan een vergissing zijn. Het zou met name een vergissing zijn als een voorwaarde in de licentieovereenkomst ertoe zou leiden dat u een overtreding begaat van een bepaalde wet in uw eigen land of in het land waar uw server zich bevindt.

Het andere probleem is dat als je geen code hebt, je er geen controle over hebt en je niet per se alles begrijpt wat het doet of hoe het werkt. Dat betekent dat als iemand de code iets verandert, u misschien vastzit aan die verandering, vooral als u updates, patches, upgrades en nieuwe versies trouw installeert zodra ze als stabiel worden vrijgegeven, of als u volledig afhankelijk bent van levering van inhoud. netwerken voor uw externe oplossingen.

3. Je krijgt vaak veel meer dan je nodig hebt

Code van derden werkt meestal om het gewenste werk te doen, maar soms bevat het allerlei extra functies die u niet nodig heeft en waarschijnlijk nooit zult gebruiken. In sommige gevallen kunt u die extra functies niet of helemaal niet meer verwijderen. U moet mogelijk ook een compromis sluiten. De functie kan iets doen dat heel dicht in de buurt komt van wat u van plan bent, maar niet precies wat u van plan bent. Je handelt ontzagwekkends omwille van minder werk om te doen, en dat is niet altijd een goede ruil.

4. Meerdere niveaus van afhankelijkheid van derden kunnen tot echte problemen leiden

Veel open source-projecten gebruiken dezelfde codefragmenten van derden op verschillende manieren om hun software te produceren. Meestal is dat geen slechte zaak, maar het kan tot problemen leiden. Tegenwoordig installeren veel ontwikkelaars niet eens de fragmenten die ze gebruiken, maar halen ze ze tijdens runtime uit content delivery-netwerken op aanvraag. Het gevaar hiervan werd spectaculair geïllustreerd door het Left-Pad-incident van 2016.

Elke keten is slechts zo sterk als de zwakste schakel. Deze keten van afhankelijkheden betekent dat als een link ergens in de keten wordt verbroken of aangetast, de hele keten het risico loopt op een defect. In sommige situaties kan dat behoorlijk kostbaar zijn. Niemand zou de kracht in de 11 coderegels in die goedaardige kleine functie genaamd Linker Pad hebben vermoed, maar toen die bepaalde kettingslink faalde, bracht dit veel grote websites krijsend tot stilstand. Het grootste deel was dat de meeste mensen die Left-Pad gebruikten er geen idee van hadden dat ze het gebruikten, wat het deed, of hoe het probleem op te lossen. Zoals vermeld in item 2, begrijpt u het misschien niet altijd als u het niet bezit.

Left-Pad was een zeer eenvoudige functie die gewoon een paar spaties aan de linkerkant van een regel toevoegt om er zeker van te zijn dat de lijn de juiste lengte heeft. Nu is het probleem hier dat elke competente programmeur die functionaliteit gemakkelijk zou kunnen repliceren. Het is absoluut niet nodig dat een toepassing afhankelijk is van deze externe functie en toch gebruiken duizenden websites software waarin het is opgenomen, waaronder Netflix, Facebook en Reddit. Het was gewoon een meevaller dat het in dit geval een heel eenvoudige functie was die de ketting brak, en niet een of andere echt gecompliceerde functie met een eigen keten van afhankelijkheden.

De bottom line is als je het zelf kunt bouwen, zou je waarschijnlijk moeten!

Uiteindelijk is de beslissing om in uw project codeblokken van derden te gebruiken, een reeks ingewikkelde beslissingen die nooit lichtvaardig mogen worden genomen. De factoren die u moet overwegen, zijn beveiliging, legaliteit, kosten, tijd en stabiliteit.

Om het besluitvormingsproces eenvoudiger te maken, zal de volgende testvoorwaarde waarschijnlijk helpen.

ALS een van deze factoren waar is:

  • de gewenste functie is eenvoudig
  • jij (of je team) hebt de mogelijkheid om de functie te maken
  • er is voldoende tijd om de functie te creëren
  • uw applicatie heeft een goede beveiliging nodig
  • u maakt zich zorgen over mogelijke juridische problemen in verband met licenties van derden
  • het is belangrijk dat uw toepassing nooit faalt

DAN zou je het zelf moeten bouwen,

ANDERS kan het efficiënter zijn om de functies van derden te gebruiken, op voorwaarde dat u zich bewust bent van de potentiële problemen en dat u een strategie hebt opgesteld voor wat u zult doen als die problemen zich voordoen.

header afbeelding met dank aan Stephanie Tucker

Bogdan Rancea

Bogdan is een van de oprichters van Inspired Mag en heeft in die periode bijna 6 jarenlange ervaring opgebouwd. In zijn vrije tijd studeert hij graag klassieke muziek en onderzoekt hij beeldende kunst. Hij is ook behoorlijk geobsedeerd door fixies. Hij is al eigenaar van 5.