Kort sagt: En patchprocess fastställer hur uppdateringar löper från ankomst till underlag: i vilken klass en patch hamnar, i vilket fönster den installeras, hur den testas och rullas tillbaka, vem som startar om och hur resultatet styrks. Rutinuppdateringar löper planerat i takt, nödpatchar följer en i förväg överenskommen snabbväg. Så blir brandkårsutryckningar ett upprepbart förlopp.
När varje patch är ett nödfall
På kvällen den 21.10.2026 utspelade sig samma mönster i många företag. Patcharna fanns, BSI (tyska förbundskontoret för informationssäkerhet) uppmanade till skyndsamhet och frågorna började: Får vi bara uppdatera nu? Vem testar? Vem startar om tjänsterna? Vem säger till ledningen att webbshoppen är borta en stund? Och hur bevisar vi efteråt att det lyckades?
I företag utan process måste allt detta klargöras i stunden. I företag med process är svaren redan givna. Skillnaden ligger inte i tekniken utan i överenskommelser som gjorts i förväg.
Byggstenarna i en patchprocess
En hållbar process skiljer först på hur brådskande en patch är. Tre klasser räcker oftast:
| Klass | Typisk anledning | Fönster | Test | Godkännande |
|---|---|---|---|---|
| Rutin | felrättelser, säkerhetsuppdateringar med låg risk | fast månatlig tidpunkt | staging, standardtester | IT, enligt plan |
| Brådskande | hög klassning, systemet är offentligt nåbart | tidigareläggs med kort varsel | förkortat, viktigaste förlopp | IT-chef |
| Nödfall | kritisk lucka, angrepp rapporterade, t.ex. PHP2Shell | omedelbart | rökprov efter installationen | förhandsgodkänt nödgodkännande |
Vem som tilldelar vilken klass bör vara lika fastlagt som kriterierna för det. Själva bedömningen hör till det föregående steget, se Sårbarhetshantering för medelstora företag.
Viktigt är det förhandsgivna nödgodkännandet. Ledningen beslutar en gång i lugn och ro att det är tillåtet att agera direkt vid nödpatchar, även om det innebär ett kort avbrott. I ett skarpt läge behöver då ingen inhämta ett samtycke mitt i natten.
Lika viktiga är rollerna. För varje system bör det stå klart vem som installerar uppdateringar, vem som testar i sak om webbshoppen eller portalen fungerar efteråt och vem som informeras. Vid utlagda system ingår hostingleverantör och byrå uttryckligen, med namn och kontaktuppgifter. Det fasta underhållsfönstret bör vara känt internt så att försäljning och kundservice vet när korta avbrott är möjliga.
Mät dessutom hur lång tid er process faktiskt tar: från att en patch publiceras till belagt avslut, uppdelat efter klass. Era egna värden visar var det hakar upp sig och gör förbättringar synliga. En process vars varaktighet ingen känner till går knappast att styra.
Förloppet för en patch i åtta steg
Varje patch, oavsett klass, passerar samma stationer. Endast tempo och testdjup skiljer.
- Ankomst: Meddelandet eller den tillgängliga uppdateringen registreras, med datum och källa.
- Klassning: Fastställ klass, bestäm berörda system enligt förteckningen.
- Förberedelse: Säkerhetskopia eller snapshot, beskriv återvägen, informera de inblandade.
- Test: först i staging eller på ett mindre kritiskt system.
- Installation: i det överenskomna fönstret, system för system.
- Omstart: alla berörda tjänster och processer, inte bara paketen.
- Underlag: dokumentera paketstatus, changelog-post och processtart.
- Kontroll: kontrollera funktionen och, vid säkerhetsluckor, dessutom leta efter spår av ett tidigare intrång.
Steg 6 glöms förvånansvärt ofta. PHP läser in sin kod när processerna startas. Så länge gamla PHP-FPM-workers eller Apache-processer med mod_php körs fortsätter de arbeta med den gamla, sårbara versionen. Varför det är så och hur man startar om på rätt sätt står under Efter uppdateringen: starta om PHP-FPM och alla workers.
Underlag som räknas senare
En patch utan belägg är i tveksamma fall inte installerad, åtminstone inte gentemot kunder, försäkringsgivare eller granskare. Dokumentera för varje system vilken paketstatus som är installerad, om CVE-numren finns i changeloggen och när de körande processerna startades. På Debian- och Ubuntu-system hjälper läsande kommandon som dessa (anpassa paketnamnet till ert system):
# Innehåller det installerade paketet rättelserna?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# När startades de körande PHP-FPM-processerna?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
Ligger processernas starttid före paketets installation saknas omstarten. Utförligt beskriver detta Styrk CVE-nummer i paketets changelog.
En patch stänger en lucka inför framtiden. Den tar inte bort skadlig kod som smugits in tidigare och bevisar inte att inget har hänt dessförinnan. Vid nödpatchar hör därför en spårsökning till förloppet.
Automatisera där det är säkert
Automatiska säkerhetsuppdateringar för operativsystemets paket avlastar mycket rutinarbete. De avlastar dock bara om säkerhetskopior finns, någon läser resultaten och även de berörda tjänsterna startas om. Hur man ställer in detta under Linux och vilka gränser som finns beskriver Automatiska säkerhetsuppdateringar på Linux-servrar.
Containrar behöver en egen väg. Där uppdateras inte det körande systemet, utan imagen med den rättade PHP-versionen byggs om och rullas ut. En patchprocess som bara känner till servrar förbiser lätt dessa system. Ta därför även med byggpipelines och image-register i listan över patchvägar, med en ansvarig person och samma underlag som för klassiska servrar: Vilken PHP-version körs i den utrullade containern, och sedan när?
Applikationer, CMS och tillägg behöver oftast en egen, testad väg eftersom uppdateringar där oftare ändrar funktioner. Den fasta månadstidpunkten är rätt plats för det. Viktigt är till sist att alla vägar mynnar ut i samma dokumentation: en plats där man ser vilket system som står på vilken nivå.
Hur hjälper PHP SOS konkret?
- Vi skriver tillsammans med er ner patchklasser, fönster och godkännanden, anpassade till era system och er organisation.
- Vi ställer in automatiska säkerhetsuppdateringar med omstartskontroll och avisering där det är rimligt.
- Vi tar över nödpatchar inklusive omstart, underlag och spårsökning via vår PHP-patchtjänst.
- Vi för underlagen per system så att ni kan visa upp dem för kunder, försäkringsgivare eller granskare.
Slutsats: Patchhantering verkar ointressant så länge den fungerar. Just det är målet: När nästa kritiska meddelande kommer löper ett inövat förlopp och ingen behöver improvisera.
Vanliga frågor
Vad är skillnaden mellan patchhantering och sårbarhetshantering?
Sårbarhetshantering registrerar och bedömer luckor och beslutar vad som ska göras. Patchhantering genomför beslutet: testa uppdateringar, installera dem, starta om tjänster och styrka resultatet. De båda greppar in i varandra.
Bör säkerhetsuppdateringar installeras automatiskt?
För operativsystemets paket är det ofta rimligt, förutsatt att säkerhetskopior finns och att resultatet kontrolleras efter körningen. Viktigt är att även de berörda tjänsterna startas om. Annars ligger gamla processer med den sårbara koden kvar i minnet när det gäller PHP.
Hur styrker jag att en patch verkligen fungerar?
Med den installerade paketstatusen och CVE-numren i paketets changelog, tidpunkten för installationen och starttiden för de körande processerna, som måste ligga efter installationen.
Vad gör jag om en uppdatering får något att sluta fungera?
För det finns återvägen: en säkerhetskopia eller snapshot före uppdateringen och ett beskrivet förlopp för att rulla tillbaka. Vid säkerhetsuppdateringar bör tillbakarullning vara undantaget och kombineras med en övergångsåtgärd.