De gevaren van afhankelijkheid van externe code

Als u zich abonneert op een dienst via een link op deze pagina, kan Reeves and Sons Limited een commissie verdienen. Zie onze ethische uitspraak.

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.

Elke keer dat u onderaan een webpagina een kleine link ziet met de tekst 'Powered by So-And-So', bent u getuige van dit samenwerkingseffect in actie.

En de belangrijkste reden waarom mensen deze uitwisseling en samenwerking met derden leuk vinden, is natuurlijk dat het je vele uren ontwikkelingstijd kan besparen, omdat je niet iets dat al bestaat opnieuw uitvindt.

Maar zelfs met deze grote voordelen van het systeem voor het delen van codes van derden, zijn er genoeg redenen waarom u het gebruik van deze codefragmenten zou willen vermijden, zoals we zo gaan zien...

1. Potentiรซle veiligheidsrisico's

Omdat bijna alle code die iets op het web aanstuurt open source is, is het een goede gok dat als er een kwaadaardige lading in een bepaalde applicatie zit, deze snel ontdekt zal worden door de ontwikkelaarsgemeenschap en snel gecorrigeerd zal worden.

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 gewoonlijk de kwaadaardige aard van de code goed verdoezelen, en alleen een andere zeer bekwame programmeur zal erachter komen wat het doel is ... als het kwaadaardige codefragment wordt gedetecteerd.

2. Je bent niet de eigenaar

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 neemt bijna niemand de moeite om deze vervelende lijsten met algemene voorwaarden te lezen, maar dat kan mogelijk een vergissing zijn.

Het zou met name een vergissing zijn als een voorwaarde in de licentieovereenkomst ervoor zou zorgen dat u een wet overtreedt in uw thuisland of in het land waar uw server zich bevindt.

Het andere probleem is dat als je geen code bezit, je er geen controle over hebt, en dat je niet noodzakelijkerwijs alles begrijpt wat de code doet of hoe deze werkt.

Dat betekent dat als iemand een wijziging in de code aanbrengt, u mogelijk aan die wijziging vastzit, vooral als u getrouw updates, patches, upgrades en nieuwe versies installeert zodra ze als stabiel worden vrijgegeven, of als u volledig afhankelijk bent van de levering van inhoud. netwerken voor uw oplossingen van derden.

3. Je krijgt vaak veel meer dan je nodig hebt

Code van derden werkt meestal om het werk te doen dat u wilt, maar soms bevat deze allerlei extra functies die u niet nodig heeft en waarschijnlijk nooit zult gebruiken.

In sommige gevallen kun je die extra functies niet gemakkelijk of zelfs helemaal niet verwijderen. Het kan ook zijn dat je een compromis moet 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 ruilt geweldigheid omdat je minder werk te doen hebt, 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 niet erg, maar het kan wel tot problemen leiden.

Tegenwoordig installeren veel ontwikkelaars de fragmenten die ze gebruiken niet eens meer, maar halen ze deze tijdens runtime op verzoek uit netwerken voor het leveren van inhoud. Het gevaar hiervan werd op spectaculaire wijze geรฏllustreerd door het Left-Pad Incident van 2016.

Elke ketting is zo sterk als de zwakste schakel. Deze aaneenschakeling van afhankelijkheden betekent dat als een schakel waar dan ook in de keten wordt verbroken of aangetast, de hele keten het risico loopt slecht te functioneren. In sommige situaties kan dat behoorlijk kostbaar zijn.

Niemand had de kracht kunnen vermoeden die schuilgaat in de elf regels code in dat goedaardige kleine functietje genaamd Left-Pad, maar toen die specifieke schakel het begaf, bracht dat veel grote websites tot stilstand.

Het grootste deel ervan was dat de meeste mensen die Left-Pad gebruikten geen idee hadden dat ze het gebruikten, wat het deed of hoe ze het probleem konden oplossen. Zoals vermeld bij punt 2: als u het niet bezit, begrijpt u het misschien niet noodzakelijkerwijs.

Left-Pad was een heel eenvoudige functie die slechts een paar spaties aan de linkerkant van een lijn toevoegt om er zeker van te zijn dat de lijn de juiste lengte heeft. Het probleem hier is dat elke competente programmeur die functionaliteit gemakkelijk kan repliceren.

Het is absoluut niet nodig dat een applicatie afhankelijk is van deze functie van derden, en toch gebruikten duizenden websites software die deze functie bevatte, waaronder Netflix, Facebook en Reddit. Het was gewoon een meevaller dat het in dit geval een heel eenvoudige functie was die de keten verbrak, en niet een heel ingewikkelde functie met zijn 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.

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.

Heb je vragen? Stel ze hier. 0 Reacties

Laat een reactie achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd *

Rating *

Deze site gebruikt Akismet om spam te verminderen. Ontdek hoe uw reactiegegevens worden verwerkt.