Er zit open-source code in bijna elk softwareontwikkelingsproject dat je maar kunt bedenken. Ontwikkelaars zijn er dol op. Maar u moet de verborgen risico's begrijpen en weten hoe u ze kunt minimaliseren, anders kunt u uw toepassing blootstellen aan onbekende beveiligingsproblemen.
Coding vóór open source
Coding vóór open source
h2>
Er waren eens softwareontwikkelaars die alles vanaf het begin schreven. Toen begonnen codebibliotheken, toolkits en andere add-ons te verschijnen. Je zou een voorsprong kunnen krijgen door een toolkit te gebruiken om wat functionaliteit te bieden, zoals een rapportagemodule of een interface-widget. U kunt deze als kant-en-klare volledig gevormde componenten in uw project opnemen en meteen gebruiken. Het alternatief was tijd, geld en ontwikkelingsinspanningen verspillen door het wiel opnieuw uit te vinden.
Natuurlijk zou je in de loop van de tijd je eigen bibliotheek met routines en modules opbouwen die intern waren geschreven. Dus toen je een nieuwe coderoutine of interface-element aan het ontwikkelen was, had je drie opties. Schrijf het zelf, hergebruik wat eerder geschreven interne code of koop in een bibliotheek of toolkit.
The Rise of Open Source
De komst van open-sourcecode veranderde dat allemaal. Open-source software maakt de broncode van een project vrij beschikbaar voor gebruik door anderen, binnen de grenzen van een “meestal goedaardige” licentie. De groei en acceptatie van open source zijn beide onthutsend geweest. Het woord proliferatie lijkt het niet te dekken. Er is een fenomenale toename van open source software, en niet alleen in termen van het verbijsterende aantal open source projecten en producten die er zijn, maar ook in het gebruik van open source binnen commerciële producten.
< p>Open-sourcesoftware bereikte een paar jaar geleden een kritieke massa en is van een nichepositie aan de zijlijn geëvolueerd naar een volledig omarmde mainstream-ontwikkelingsbron. Omdat het werd aangedreven en ontwikkeld door een gemeenschap en niet door een traditionele commerciële onderneming, werd het ook als een soort amateur beschouwd.
Advertentie
Nu voelt het alsof open source volwassen en volwassen is geworden. En het heeft. Maar de grootste verandering was een bredere waardering van open source, een begrip van de voordelen die het met zich meebrengt en de erkenning dat het opnemen van open source in uw product niets is om u voor te schamen.
Schattingen suggereren dat niet-triviale softwareprojecten hooguit 20 procent van de originele code schrijven. De overige 80 procent is open source. De belangrijkste open-source repository-hostingsite, GitHub, bereikte meer dan 100 miljoen repositories in 2018. En er zijn veel andere gehoste Git-platforms, zoals GitLab en BitBucket.
Open source is een fenomeen in softwareontwikkeling. Maar het zijn niet allemaal rozen in de ontwikkelingstuin. Er zijn problemen waarvan u op de hoogte moet zijn en die u moet oplossen.
De beveiligingsproblemen
Het gebruik van open-sourcecomponenten in grote softwareprojecten verlaagt de ontwikkelingskosten, verkort de end-to-end ontwikkelingstijd en er wordt beweerd dat het innovatie bevordert. Omdat het uw ontwikkelingspersoneel bevrijdt van het alledaagse, kunnen ze zich concentreren op de unieke en marktaantrekkelijke aspecten van uw product.
Er zijn enkele open-sourceproducten die een commerciële entiteit hebben. De organisatie geeft hun product vrij onder een schema met dubbele licenties. Een commerciële versie heeft een officieel, professioneel ondersteuningskanaal en kan andere voordelen bevatten, zoals eigen extra's die bij het product worden geleverd. Ze brengen ook een door de gemeenschap ondersteunde versie uit die zal profiteren van de codeerinspanningen van het commerciële team en van de bijdragen van de eigen gemeenschap. Aanzienlijke bijdragen van de gemeenschap zullen ook terugkeren naar de commerciële versie.
De meeste open-sourceprojecten zijn echter volledig community-gedreven. Ze hebben misschien de steun van commerciële entiteiten, maar die steun zijn donaties en sponsoring, geen codebijdragen.
Advertentie
Ongeacht hun herkomst, zijn de open-sourcecomponenten die worden gekozen om te worden opgenomen in nieuwe ontwikkelingsprojecten over het algemeen gevestigde en gerenommeerde projecten op zich. Ze hebben een hoge mate van vertrouwen verdiend. Maar dat is niet altijd het geval. Soms is de functionaliteit die u nodig hebt beschikbaar, maar deze zit vervat in een nieuw en enigszins onbewezen project. Maar je hebt de broncode, toch? Je kunt er een code-review van doen.
Vanuit veiligheidsoogpunt is open source niet meer of minder veilig dan eigen, eigengemaakte code. Het is tenslotte allemaal door mensen geschreven code. Voorstanders van open source wijzen op de wet van Eric S. Raymond die hij noemde ter ere van Linus Torvalds, waarin staat dat “als we genoeg oog hebben, alle bugs oppervlakkig zijn.” Met voldoende mensen die de code bekijken en bètatesten, moeten problemen snel worden geïdentificeerd, gekarakteriseerd en opgelost.
Dat is waar voor zover het gaat. Maar beveiligingsproblemen zijn niet per se bugs. Een kwetsbaarheid kan een omstandigheid zijn die ontstaat als neveneffect van complexe logica in een project van vele broncodemodules die miljoenen regels code beslaan. Het product doet wat het moet doen, dus het lijkt te werken zoals bedoeld. En dus doorstaat het codebeoordeling, productverificatie, veldtesten en krijgt het een schone gezondheidsverklaring.
Afgezien van blind geluk en toeval, zal die beoordelings-, test-, proef- en release-loop geen beveiligingsproblemen aan het licht brengen.
Waarom open source aantrekkelijk is voor hackers
Bovendien zijn er aspecten van open source die positief aantrekkelijk zijn voor hackers en dreigingsactoren. Ze kunnen ook de broncode zien. Ze kunnen kwetsbaarheden zoeken met een andere mindset dan de gemiddelde community-bijdrager die, hoewel ze misschien een competente ontwikkelaar zijn, waarschijnlijk geen echte beveiligingsachtergrond heeft.
Natuurlijk, bijdragers aan open source komen in alle smaken met gevarieerde achtergronden. Sommigen van hen zullen ongetwijfeld ervaring hebben met beveiliging in de echte wereld, maar ze zullen in de minderheid zijn. Bedreigingsacteurs zijn een heel ander beest. En ze zijn niet beperkt tot het vinden van kwetsbaarheden, ze kunnen ze ook injecteren.
Advertentie
Er zijn veel gevallen geweest waarin een dreigingsactor een kwetsbaarheid heeft geïntroduceerd via een patch die ze hebben gemaakt en bij een project hebben ingediend. Het vond zijn weg door code-review, in de code-base, en in de volgende release van het product.
Misschien was het ultieme voorbeeld hiervan een JavaScript-component genaamd event-stream. Dit open-sourceproject werd onderhouden door één enkele ontwikkelaar. De last van het rentmeesterschap van het project ontgroeide hem. Hij werd overgehaald om het over te dragen aan een nieuwe beheerder.
De nieuwe beheerder was een bedreiging. Ze namen het project over, lieten het korte tijd normaal draaien en voegden er kwaadaardige code aan toe. Elke kopie van elk ander programma dat die softwarecomponent gebruikte, kaapte stilletjes bepaalde soorten Bitcoin-portemonnee voor de dreigingsactor.
Wat u kunt doen om het risico te verminderen
Zoals met veel aspecten van beveiliging, beheert u dit risico door controles toe te passen. Dat vereist governance, oftewel beleid en procedures. Gelukkig is er software die kan helpen.
Maak een Open Source Register
U moet de open source die u gebruikt kwantificeren. Maak een register met een lijst van de open-sourcecomponenten die u in uw projecten gebruikt. Maak een lijst van elk open-sourceonderdeel, de versie of versies die u hebt gebruikt, de projecten waarin u ze hebt gebruikt, wat de nieuwste versie is en waar deze kan worden gedownload. In de ontwerpdocumentatie voor elk van uw projecten moet u de open-sourcecomponenten vermelden die in gebruik zijn.
De duivel zit in de details. Vergeet de afhankelijkheden en hiërarchische aard van veel van open source niet. Open-sourceprojecten gebruiken vaak andere projecten in zichzelf, genest als Russische poppen, of ze vereisen dat andere open-sourcecomponenten op de doelcomputer worden geïnstalleerd, zodat ze er gebruik van kunnen maken.
Advertentie
Verdiep je in deze afhankelijkheden en vermeld ze in je open-sourceregister.
Automatische audits uitvoeren
Kwetsbaarheden in open-sourcepakketten zijn een groot probleem voor NPM, de pakketbeheerder voor JavaScript. Om dit aan te pakken, hebben ze een automatische audittool gemaakt die scant op verouderde pakketten met beveiligingsupdates.
Dit heeft natuurlijk zijn beperkingen en het is belangrijk om bewust te zijn en niet volledig te vertrouwen op automatische tooling. Het vangt alleen pakketten met bekende kwetsbaarheden en updates. Als het pakket een kwetsbaarheid heeft, maar niet is bijgewerkt om het te verhelpen, zal de NPM-audit u niets vertellen.
GERELATEERD: Controleer uw NPM-afhankelijkheden, Zij zijn verantwoordelijk voor 86% van de beveiligingsbugs
Maak een kwetsbaarheidskaart
Uw open source register geeft u een duidelijk beeld van de open source die u gebruikt. De volgende stap is het in kaart brengen van bekende kwetsbaarheden op dat register. Soms kunnen deze worden ontdekt door naar de startpagina van het project te gaan en de lijst met bekende problemen te bekijken.
De Nationale Kwetsbaarheid Database (NVD) geeft je een veel gedetailleerder beeld. U kunt hun zoekpagina gebruiken om producten op naam op te zoeken om erachter te komen welke veelvoorkomende kwetsbaarheden en blootstellingen van invloed zijn op die softwarecomponent. De NVD is een geweldige hulpbron, ook al duurt het even voordat je eraan gewend bent het formaat te ontrafelen.
Update je register en kwetsbaarheidskaart
Dit is natuurlijk iets waar je op moet letten. Er worden voortdurend nieuwe kwetsbaarheden ontdekt, dus de beveiligingsstatus van uw product bij de lancering zal in de loop van de tijd waarschijnlijk langzaam verslechteren.
Advertentie
We erkennen deze nieuwe behoefte en er zijn commerciële (Black Duck, WhiteSource) toepassingen die hierbij helpen. Ze kunnen uw projecten scannen en open source-code identificeren en automatisch kwetsbaarheden opzoeken. Sommige hiervan (FOSSA) bieden een gratis niveau.
Statische analyse van uw codebase & #8212;inclusief de open-sourcecomponenten" zou sowieso een standaard onderdeel moeten zijn van uw ontwikkelingsdiscipline. Tools zoals Coverity Scan kunnen defecten in uw code vinden, zoals bufferoverlopen die tot kwetsbaarheden kunnen leiden. Het geeft zelfs advies over hoe ze kunnen worden gecorrigeerd.
Controleer de Open Source-licenties en houd u eraan
Zorg ervoor dat u de licenties begrijpt die van kracht zijn op de open source die u gebruikt . Er zijn veel verschillende licenties, dus controleer of u aan alle vereisten voldoet. Betrek uw licentie- of nalevingsfunctionaris erbij, als u die heeft.
Het niet naleven van een open-sourcelicentie kan leiden tot rechtszaken. Open source-projecten reageren net zo snel op inbreuken op licenties als commerciële softwarebedrijven.
Update uw open source-componenten
Omdat kwetsbaarheden worden verholpen door de gemeenschappen van de open source u gebruik, zorg ervoor dat u uw versies bijwerkt, zodat u van deze oplossingen kunt profiteren. Open source gebruikt een “pull” model. Ze kondigen een nieuwe oplossing aan en dan moet je die nieuwe versie gaan downloaden. Dit is het tegenovergestelde van veel commerciële software die een “push” model waar updates worden verzonden naar de geregistreerde gebruikers.
Advertentie
Bewaak de projectpagina's voor aankondigingen van nieuwe versies en download en test de nieuwe builds.
De kosten van open source
Open-source software is gratis te verkrijgen, maar brengt beheer- en governance-overhead met zich mee. De implicaties moeten worden begrepen en beheerst om het veilig en met minimaal risico te gebruiken.