Hypernode back-up

Bij de totstandkoming van Magento 2 is afscheid genomen van security patches. Wanneer er een kritiek security lek gedicht moet worden, biedt Magento de oplossing in de vorm van een versie-update. Wat vindt de Magento community daarvan: maakt het het leven van een developer makkelijker, of levert het juist problemen op? Ik ging op onderzoek en hoor graag jouw ervaringen.

Waarom heeft Magento voor security updates gekozen?

Navraag leerde mij dat het antwoord op deze vraag ‘composer’ is. Magento wilde met Magento 2 het versiebeheer voor developers vele malen makkelijker maken, en maakte Magento 2 daarom volledig composer-based. Kortgezegd: composer is een dependency management tool voor PHP. Wanneer je dus een Magento versie update, update composer ook direct alle afhankelijke software. “One command to rule them all”, aldus Ray Bogman van Magento. Een absoluut tijdbesparende oplossing voor developers dus.

Voorwaarde is wel dat alle afhankelijke software (bijvoorbeeld extensies) ook composer-based is. Maar dat zijn alle extensies die aangeboden worden via de Magento Marketplace, en deze breidt elke dag nog uit.

Klinkt goed! Maar zijn er ook nadelen?

Blijkbaar, want we zien op ons hostingplatform dat het doorvoeren van Magento 2 security updates niet in dezelfde snelheid gebeurt als dat Magento 1 patches worden geïmplementeerd. Waar Magento 1 patches in de meeste gevallen binnen 4 weken na release op shops doorgevoerd zijn, wordt deze snelheid bij lange na niet gehaald voor Magento 2 updates.

  • Ter illustratie: 4 weken na de release van de security versies 2.1.15 en 2.2.6 (o.a. Cross-Site Scripting (XSS)) waren dit de cijfers op ons platform:
    15% was geüpdated naar 2.1.15
    3% was geüpdated naar 2.2.6

De updates betreffen vergelijkbare kritieke lekken als de M1 patches, dus de noodzaak zou even hoog moeten zijn. Waarom gebeurt dat dan niet, wat speelt er op dit vlak? Dit was voor mij de aanleiding om navraag te doen bij een aantal development bureaus van verschillende omvang. Het leverde me de volgende redenen op.

De updates hebben grotere implicaties dan patches

Waar je bij een patch maar een klein gedeelte van de code overschrijft, update je met een versie-update de volledige code. Je voert ook functionele wijzigingen/verbeteringen door. Dat is mooi, maar daarmee heeft de update vaak grotere implicaties dan een patch.

Functionele verbeteringen wil je liever op je eigen tempo doorvoeren. Wanneer je zeker weet dat de compatibiliteit in orde is en er niets kapot gaat. En voordat je dat zeker weet, gaat er net even wat meer tijd in zitten (best ironisch). De klant zit vaak niet te wachten op die extra uren en/of hoeft die extra functionaliteit helemaal niet. En jij had wat functionaliteit betreft misschien liever op een zelfgekozen moment naar een major versie-update gewerkt.

En sommige Magento updates zijn ingrijpender dan andere. Zo is er een groot verschil tussen een minor (van 2.2.x naar 2.2.x) of major update (van 2.x naar 2.x). Zeker major updates kunnen weken in beslag nemen. Maar: voor elke major versie brengt Magento een security versie uit, dus je zal nooit vanuit security oogpunt gedwongen worden tot een plotselinge major update. Correct me if I’m wrong!

Afhankelijkheid van extensies

Een nieuwe versie van Magento betekent dat ook extensies hun compatibiliteit moeten waarborgen met een nieuwe versie. Extensies die composer-based zijn worden automatisch meegenomen door composer. Maar dan moet de extensiebouwer wel een update beschikbaar hebben gesteld. En daarnaast wordt er in de praktijk ook nog flink gebruik gemaakt van extensies die niet composer-based zijn.

De afgelopen maanden heb ik gemerkt dat vooral dit punt, de afhankelijkheid van extensiebouwers, voor veel frustratie zorgt. Een nieuwe compatibele versie laat soms lang op zich wachten. En zolang die er niet is, kan de Magento security update niet doorgevoerd worden.

Twee kritische kanttekeningen die ik ook heb gehoord:

  • Zolang de extensiebouwer niet een nieuwe update uitgebracht heeft die in de releasenotes expliciet aangeeft compatible te zijn met de nieuwe Magento versie, kan composer de update blokkeren. Dit is niet altijd terecht, want soms is de huidige extensie-versie nog prima compatible en kan de Magento update dus handmatig zonder problemen doorgevoerd worden.
  • Dan is echter nog de vraag: wil je dat wel? Er zijn ook bureaus die strak willen vasthouden aan hun versiebeheer-processen en dus de versies ‘gelijk’ willen laten lopen. Dat voorkomt fouten en slordigheden. Begrijpelijk en ook verstandig. Maar dan blijft nog wel dat de update relatief lang op zich laat wachten en een shop tot die tijd wellicht onnodig lang onbeschermd blijft.

De afhankelijkheid van extensiemakers blijkt een heikel punt te zijn. Worden extensiemakers verrast door de Magento updates? Zijn ze zich niet bewust van deze afhankelijkheid?

De update bevat bugs

Soms wordt binnen de community al snel bekend dat een versie-update bugs bevat, of dat binnen afzienbare tijd een nieuwe versie gereleased zal worden. Dan wacht je natuurlijk liever even op de nieuwste versie. Veel bureaus bouwen tegenwoordig al standaard een wachtperiode in voordat ze daadwerkelijk gaan updaten. Ze monitoren dan eerst even de reacties binnen de community.

Custom code

Ook gehoord, maar gelukkig niet veel: de standaardfunctionaliteit van Magento 2 schiet soms nog tekort, waardoor er custom werk is verricht. Bij elke update is deze code een sterk vertragende factor.

Security versie-updates: een vloek of een zegen?

Herken je bovengenoemde issues helemaal niet en bevalt deze keuze van Magento je eigenlijk erg goed? Laat graag van je horen. Of loop je er juist wel tegenaan en merk je dat het je security processen vertraagd? Dan ben ik erg benieuwd waar je precies tegenaan loopt. Misschien kunnen we krachten bundelen en bottlenecks gezamenlijk aanpakken.

Wil je reageren op dit artikel? Doe dat dan in een reactie op onze Facebook-post of in deze Twitter-feed.

 

 

Scan je eigen Magento shop op veiligheidslekken