-

Waarom digitale projecten met open source veiliger zijn dan je denkt

Vaak worden bij digitale projecten open source componenten ingezet om sneller tot een resultaat te komen – en daar zijn goede redenen voor.

De golf aan digitale evoluties blijft in snel tempo voortrazen en overspoelt bedrijven jaar na jaar met nieuwe tools en mogelijkheden. Wie denkt dat hij of zij z’n digitale projecten probleemloos kan uitwerken door zelf een volledige digitale omgeving vanaf nul uit de grond te stampen, heeft het mis. Bestaande componenten zijn immers veel robuuster en veiliger dan nieuwe, zelfgemaakte bouwstenen: ze zijn onder handen genomen en getest door een heleboel mensen én ze bewijzen elke dag opnieuw hun waarde in bestaande digitale omgevingen.

Techgiganten gaan overstag voor open source

De shift naar open source software zien we ook bevestigd worden in de markt. Zo nam IBM onlangs nog de grote open source speler Red Hat over voor een bedrag van maar liefst 34 miljard dollar. Ook Adobe, dat traditioneel symbool staat voor gesloten, zelf ontwikkelde software, stuurde met de acquisitie van e-commergegigant Magento – dat gebaseerd is op open source software – een duidelijk signaal de wereld in. Dit soort overnames door klassieke techgiganten toont aan hoe het klassieke, proprietary technologielandschap steeds meer in de richting van open source opschuift. Ook het aantal open source gebaseerde bedrijven dat naar de beurs trekt, blijft nog elke maand groeien.

Wie is verantwoordelijk bij open source?

Even terug naar de digitale projecten van daarnet. Want wat er ná de oplevering van een digitale oplossing gebeurt, is minstens even belangrijk als het bouwproces. Wie is er immers verantwoordelijk voor de blijvende gezondheid en performantie van je digitale code zodra je website of applicatie is opgeleverd? En wat als er een beveiligingslek wordt ontdekt – wie kan of moét het dan snel voor je updaten? Word je als bedrijf geacht om zelf van mogelijke problemen op de hoogte te blijven en ze vervolgens zelf op te lossen, of beter nog, erop te anticiperen? Of blijft dat de verantwoordelijkheid van je hostingprovider of die van de websitebouwer waarmee je contract misschien al lang is afgelopen? Belangrijke kwesties waar je maar beter op tijd over nadenkt om zo op voorhand goede afspraken op papier te kunnen zetten.

Praktijkvoorbeeld: software-ondersteuning bij PHP

Ter illustratie een voorbeeld vanuit de hoek van de programmeertaal PHP, die door een open source community wordt onderhouden. Onder andere de populaire contentmanagementsystemen Drupal en WordPress en de frameworks Laravel en Symfony draaien op PHP. In de praktijk maakt dus bijna tachtig procent van alle websites op het internet direct of indirect gebruik van PHP.

Eind vorig jaar besliste de PHP-community om een aantal oudere versies van het PHP-script niet langer te ondersteunen. Begrijpelijk: ook jij bent waarschijnlijk al een hele tijd afgestapt van Windows 98 – en voor programmeertalen geldt hetzelfde principe. Programmeurs die kennis hebben van oude systemen om ze te kunnen onderhouden, zijn dun gezaaid in de competitieve arbeidsmarkt van vandaag.

Ook programmeertalen maken een proces van natuurlijke evolutie door. Zo verschijnt er bijvoorbeeld elk jaar een nieuwe versie van PHP, die vervolgens drie jaar lang wordt ondersteund. Na die drie jaar ben je dus vrijwel verplicht om je huidige softwareversie bij te werken. Voor software waar vier vijfde van het web gebruik van maakt, betekent dat natuurlijk een hele aanpassing – telkens weer opnieuw. De vraag is dan of je bedrijf erop voorzien is om met die onvermijdelijke cyclus van updates en veranderingen om te gaan.

Het belang van beveiligingsupdates

Een ander belangrijk aandachtspunt zijn beveiligingslekken in software. Als je bij je bedrijf in je eentje of met je interne team code begint te schrijven op basis van welke programmeertaal dan ook, is de kans erg groot dat je code (onbewust) fouten bevat. Dat heeft helemaal niets te maken met jouw bekwaamheid, maar eerder met een bescheiden en tegelijkertijd onverbiddelijk foutenpercentage waar je als individuele ontwikkelaar niet onderuit kunt. Bij open source software zijn er veel meer ogen die aandachtig meekijken naar dezelfde code, en worden kleine en grotere fouten daardoor veel sneller ontdekt en opgelost.

Sommige softwaresystemen proberen hun gebruikers een handje te helpen door automatische beveiligingsupdates te voorzien. Als het echter over cruciale applicaties gaat, zoals een webshop, wil je natuurlijk eerst zélf de beschikbare updates controleren om je ervan te verzekeren dat ze de vlotte werking van je digitale omgeving niet in het gedrang brengen. Maar wat is dan de beste optie om lekken zo snel mogelijk te dichten en softwareversies bij te werken: volledige automatische updates, of toch maar liever niet?

Als we kijken naar de twee grote spelers op het gebied van open source, Drupal en WordPress, zien we dat ze allebei bewust inzetten op onderling verschillende strategieën. WordPress voorziet in de mogelijkheid tot volledig automatische updates, terwijl Drupal de verantwoordelijkheid om te updaten bij de eigenaar van de applicatie legt. Beide vormen hebben voor- en nadelen. Een hack op een automatisch updatesysteem kan een gigantische impact hebben – denk bijvoorbeeld aan het grootschalige WordPress-incident uit 2016.

Het ontbreken van automatische updates zorgt er aan de andere kant weer voor dat updates per definitie trager worden uitgerold. Dat werd vorig jaar duidelijk bij de ontdekking van een gevaarlijk lek in Drupal, waarbij een mogelijke aanvaller code zou kunnen uitvoeren op blootgelegde systemen. De eerste gevallen van misbruik van dit lek werden al opgemerkt enkele uren nadat het probleem was ontdekt en wereldkundig gemaakt. Aangezien automatische updates bij Drupal niet standaard voorzien zijn, heb je in dat geval dus een partner nodig die ze proactief voor jou kan doorvoeren.

Als we het speelveld voor Drupal in Europa bekijken, zien we een paar spelers die proactief beveiligingsupdates doorvoeren: bijvoorbeeld Dropsolid, die updates opneemt als onderdeel van een breder servicepakket, of de Britse updatespecialist DropGuard.

In een notendop

Los van je keuze voor een bepaalde technologie, blijft het dus vooral zaak om nog vóór de oplevering van je digitale projecten te anticiperen op software-updates en mogelijke beveiligingsproblemen. Op tijd maatregelen treffen, bespaart heel wat kopzorgen. Je bent vaak beter af bij gespecialiseerde bedrijven die één technologie volledig beheren en die je ook na het bouwen van je digitale project ook van A tot Z kunnen begeleiden met aanverwante diensten.

De belangrijkste tips:
  • Overweeg open source als keuze om sneller naar de markt te kunnen gaan: open componenten bieden vanaf de start zowel waarde als volledige vrijheid.
  • Hou je servers up-to-date en zorg ervoor dat je software kiest die volledig ondersteund wordt.
  • Zorg voor bijgewerkte software en plan voldoende tijd en budget.
  • Maak op voorhand goede afspraken voor blijvende service. Zo kun je zorgeloos slapen als er beveiligingsproblemen opduiken.
  • Kies voor een betrouwbare partner die gespecialiseerd is in de software die je gebruikt.
  • Het beste combineer je alle bovenstaande tips om zo je overhead te minimaliseren. Op die manier kun je je volledig inzetten op je digitale doelstellingen.

Kijk dus ook zeker naar wat er gebeurt ná de oplevering van je project en zorg ervoor dat je proactief handelt op het gebied van software-updates. Je bent vaak beter af bij gespecialiseerde bedrijven die één technologie volledig beheren en je dan ook van A tot Z kunnen begeleiden met aanverwante diensten.

Deel dit bericht

Plaats een reactie

Uw e-mailadres wordt niet op de site getoond