U stelt het vast door uw beheerder of ontwikkelaar om bewijs te vragen. Zelf iets installeren of uitvoeren op de webshop is daarvoor niet nodig. Dat bewijs bestaat uit drie lagen die u apart moet bekijken:
- de Magento-versie, inclusief een eventuele beveiligingsrelease met een -pN-achtervoegsel;
- de status van individuele patches volgens de Quality Patches Tool (QPT) van Adobe;
- losse of handmatig toegevoegde patches, bijvoorbeeld via de Composer-configuratie van het project.
Pas als u die drie lagen naast elkaar ziet, weet u wat er aantoonbaar is toegepast. Wat niet gedocumenteerd is, blijft onbekend. Het is dus niet automatisch veilig, en ook niet automatisch ontbrekend.
Drie soorten "patches" die vaak door elkaar lopen
1. Beveiligingsreleases (de -pN-versie). Adobe beschrijft security patch releases als een afzonderlijk releasebegrip met een -pN-suffix. Ze bevatten beveiligingswijzigingen en kunnen ook kritieke hotfixes en bepaalde niet-achterwaartscompatibele wijzigingen bevatten. Adobe vermeldt daarnaast dat securitypatches met extended support niet beschikbaar zijn voor Magento Open Source. Bron: Adobe security patches overview.
Vraag uw beheerder om de softwarepakketversie, inclusief een eventueel -pN-achtervoegsel.
2. Individuele patches via de Quality Patches Tool. Volgens Adobe toont QPT welke individuele patches beschikbaar zijn voor de geïnstalleerde softwareversie. Per patch staan een ID, titel, type, status en details vermeld. De status kent onder meer *Applied* en *Not applied*. Bron: Adobe Quality Patches Tool usage.
Vraag uw beheerder om het originele QPT-statusrapport, het overzicht van handmatige patches en het deploymentlog. Het is geen volledige veiligheidsscan en geen bewijs dat de hele shop veilig is.
3. Losse of handmatige patches. Ontwikkelaars voegen soms zelf patches toe. Dat kan een fix van een extensieleverancier zijn, een eigen correctie of een patch die via de projectconfiguratie wordt meegenomen. Zulke wijzigingen verschijnen niet noodzakelijk in een QPT-rapport.
*Ons advies:* vraag hier apart naar. Juist hier zit vaak de grootste blinde vlek.
Waarom u niet zomaar extra patches laat toepassen
Adobe beschrijft dat u met QPT afzonderlijke patches kunt toepassen en terugdraaien. Adobe waarschuwt ook dat veel individuele patches de complexiteit vergroten en een latere upgrade moeilijker kunnen maken. Bron: Adobe Quality Patches Tool usage.
*Ons advies:* houd de inventarisatie gescheiden van het onderhoud. Eerst brengt u in kaart wat er is. Daarna beslist u samen met uw beheerder wat zinvol is, en wijzigingen test u eerst buiten de live shop. Laat tijdens de inventarisatie dus niets installeren of aanpassen op productie.
Controlelijst: wat vraagt u aan uw beheerder?
Vraag om de volgende stukken. Elk punt is ons praktisch advies, geen officiële Adobe-procedure.
1. Editie en installatiemethode. Gaat het om Magento Open Source of Adobe Commerce, en hoe is de shop geïnstalleerd en wordt hij uitgerold? 2. Exacte softwarepakketversie, inclusief een eventueel -pN-achtervoegsel. 3. Versie van de Quality Patches Tool die in het project aanwezig is, als die er al is. 4. Het originele QPT-statusrapport, liefst ongewijzigd en met datum. 5. Overzicht van handmatige patches, inclusief de patchconfiguratie in Composer, als die wordt gebruikt. 6. Deploymentlog waaruit blijkt wanneer welke wijziging live is gezet. 7. Per wijziging: de bron (Adobe, een extensieleverancier of eigen werk), de datum, de verantwoordelijke en bewijs van testen en van een terugzetmogelijkheid.
Zo ziet een leesbaar patchregister eruit
Vraag uw beheerder om per regel in gewone zinnen te noteren:
- welke patch of release het is;
- waar die vandaan komt;
- wanneer die is toegepast en wie dat deed;
- waar die getest is en hoe die terug te draaien is;
- welke status is aangetoond, en met welk document.
Spreek één regel af: wat niet aangetoond is, wordt als "onbekend" genoteerd. Er komt dus geen "vermoedelijk toegepast" en geen "zal wel in orde zijn". Zo ziet u meteen waar nog bewijs ontbreekt, zonder dat iemand iets hoeft te verzinnen.
Typische onbekenden zijn:
- handmatige wijzigingen uit het verleden zonder documentatie;
- patches van een vorige ontwikkelaar;
- wijzigingen die rechtstreeks op de server zijn gedaan;
- de vraag of maatwerk of extensies een patch beïnvloeden.
Die punten blijven onbekend tot iemand ze controleert en vastlegt.
Veelgestelde vragen
Is een QPT-rapport met veel "Applied" een bewijs dat mijn shop veilig is? Nee. Adobe beschrijft QPT als een overzicht van beschikbare individuele patches en hun status voor uw softwareversie (bron). Handmatige patches, extensies, maatwerk en hosting vallen daar niet volledig onder.
Mijn versie eindigt op -p plus een cijfer. Ben ik dan bij? Dat achtervoegsel betekent dat het om een beveiligingsrelease gaat (bron). Of het de meest recente is en of het genoeg is voor uw situatie, blijkt niet uit het nummer alleen. Laat uw beheerder dat onderbouwen.
Kan ik dit zelf nakijken in de Magento-admin? Een volledig beeld krijgt u daar niet. Het bewijs zit in projectbestanden, rapporten en logs die uw beheerder beheert. Vraag die stukken op in plaats van zelf iets te installeren of uit te voeren.
Hulp bij uw bestaande Magento-webshop
Crydogs helpt eigenaars van bestaande Magento-webshops met onderhoud, upgrades, bugfixes, beveiligingspatches, snelheid, Hyvä-omzetting en hosting. De Magento-ervaring achter de dienst gaat terug tot 2008, toen nog onder de naam Magento-shops.be. Wilt u hulp bij het opvragen of opstellen van een leesbaar patchregister? Neem contact op via https://crydogs.com/#contact.
Bekijk onze Magento-dienst voor onderhoud, upgrades en hosting. Doe een vrijblijvende aanvraag.
