Kort sagt: En patch management-proces fastlægger, hvordan opdateringer forløber fra indgang til dokumentation: hvilken klasse en patch hører til, i hvilket vindue den indspilles, hvordan der testes og rulles tilbage, hvem der genstarter, og hvordan succesen dokumenteres. Rutineopdateringer kører planlagt i takt, nødpatches følger en på forhånd aftalt hurtig vej. Sådan bliver brandslukning til et gentageligt forløb.
Når hver patch er en nødsituation
Om aftenen den 21.10.2026 udspillede det samme mønster sig i mange virksomheder. Rettelserne var der, BSI (det tyske forbundsagentur for informationssikkerhed) pressede på, og spørgsmålene begyndte: Må vi bare opdatere nu? Hvem tester? Hvem genstarter tjenesterne? Hvem fortæller direktionen, at shoppen er væk et øjeblik? Og hvordan beviser vi bagefter, at det lykkedes?
I virksomheder uden proces skal alt dette afklares i øjeblikket. I virksomheder med proces ligger svaret allerede fast. Forskellen ligger ikke i teknikken, men i aftaler, der blev truffet på forhånd.
Byggestenene i en patch management-proces
En bæredygtig proces skelner først efter, hvor meget en patch haster. Tre klasser er som regel nok:
| Klasse | Typisk anledning | Vindue | Test | Godkendelse |
|---|---|---|---|---|
| Rutine | fejlrettelser, sikkerhedsopdateringer med lav risiko | fast månedlig termin | staging, standardtests | it, efter plan |
| Hastende | høj vurdering, system offentligt tilgængeligt | fremrykket med kort varsel | forkortet, vigtigste forløb | it-chef |
| Nød | kritisk sårbarhed, angreb meldt, f.eks. PHP2Shell | straks | røgtest efter indspilning | på forhånd givet nødgodkendelse |
Hvem der tildeler hvilken klasse, bør ligge lige så fast som kriterierne for det. Selve vurderingen hører til det foregående trin, se Sårbarhedshåndtering for mindre og mellemstore virksomheder.
Vigtig er den på forhånd givne nødgodkendelse. Direktionen beslutter én gang i ro og mag, at der ved nødpatches må handles straks, også selv om det betyder en kort afbrydelse. I en nødsituation behøver ingen så at indhente en tilladelse om natten.
Lige så vigtige er rollerne. For hvert system bør det ligge fast, hvem der indspiller opdateringer, hvem der fagligt tester, om shoppen eller portalen virker bagefter, og hvem der informeres. Ved udliciterede systemer hører hostingudbyder og bureau udtrykkeligt med, med navn og kontaktmulighed. Det faste vedligeholdelsesvindue bør være kendt internt, så salg og kundeservice ved, hvornår korte afbrydelser er mulige.
Mål desuden, hvor lang tid jeres proces faktisk tager: fra offentliggørelsen af en patch til den dokumenterede afslutning, adskilt efter klasse. Disse egne værdier viser, hvor det går i stå, og gør forbedringer synlige. En proces, hvis varighed ingen kender, kan næppe styres.
Forløbet af en patch i otte trin
Hver patch, uanset klasse, gennemløber de samme stationer. Kun tempo og testdybde er forskellige.
- Indgang: Melding eller tilgængelig opdatering registreres med dato og kilde.
- Klassificering: Fastlæg klassen, bestem berørte systemer ud fra oversigten.
- Forberedelse: Backup eller snapshot, beskriv tilbagevejen, informér de involverede.
- Test: først i staging eller på et mindre kritisk system.
- Indspilning: i det aftalte vindue, system for system.
- Genstart: alle berørte tjenester og processer, ikke kun pakkerne.
- Dokumentation: fastholdelse af pakkestatus, changelog-post og processtart.
- Kontrol: kontrollér funktionen, og hold ved sikkerhedssårbarheder desuden øje med spor af et tidligere indbrud.
Trin 6 glemmes forbavsende ofte. PHP indlæser sin kode, når processerne starter. Så længe gamle PHP-FPM-workers eller Apache-processer med mod_php kører, arbejder de videre med den gamle, sårbare status. Hvorfor det er sådan, og hvordan man genstarter rigtigt, står under Efter opdateringen: Genstart PHP-FPM og alle workers.
Dokumentation, der tæller senere
En patch uden bilag er i tvivlstilfælde ikke indspillet, i hvert fald over for kunder, forsikringsselskaber eller revisorer. Fasthold pr. system, hvilken pakkestatus der er installeret, om CVE-numrene står i changelog, og hvornår de kørende processer blev startet. På Debian- og Ubuntu-systemer hjælper læsende kommandoer som disse (tilpas pakkenavnet til jeres system):
# Indeholder den installerede pakke rettelserne?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Hvornår blev de kørende PHP-FPM-processer startet?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
Ligger processernes starttidspunkt før pakkens installation, mangler genstarten. Udførligt beskriver det Dokumentér CVE-numre i pakkens changelog.
En patch lukker en sårbarhed for fremtiden. Den fjerner ikke skadelig software, der blev indsmuglet tidligere, og beviser ikke, at der ikke skete noget før. Ved nødpatches hører en sporsøgning derfor fast med til forløbet.
Automatisér, hvor det er sikkert
Automatiske sikkerhedsopdateringer til styresystempakker aflaster meget rutinearbejde. De aflaster dog kun, hvis der findes backups, nogen læser resultaterne, og de berørte tjenester også genstartes. Hvordan man sætter det op under Linux, og hvilke grænser der er, beskriver Automatiske sikkerhedsopdateringer på Linux-servere.
Containere kræver deres egen vej. Dér opdateres der ikke i det kørende system, men imaget med den rettede PHP-version bygges på ny og udrulles. En patch-proces, der kun kender servere, overser let disse systemer. Tag derfor også build-pipelines og image-registre med på listen over patchveje, med en ansvarlig person og den samme dokumentation som ved klassiske servere: Hvilken PHP-version kører i den udrullede container, og siden hvornår?
Applikationer, CMS og plugins kræver som regel en egen, afprøvet vej, fordi opdateringer dér oftere ændrer funktioner. Den faste månedlige termin er det rette sted for det. Det vigtige er til sidst, at alle veje løber sammen i den samme dokumentation: ét sted, hvor man kan se, hvilket system der står på hvilken version.
Hvordan hjælper PHP SOS konkret?
- Vi skriver sammen med jer patchklasser, vinduer og godkendelser ned, tilpasset jeres systemer og jeres organisation.
- Vi opsætter automatiske sikkerhedsopdateringer med genstartskontrol og underretning, hvor det er fornuftigt.
- Vi overtager nødpatches inklusive genstart, dokumentation og sporsøgning via vores PHP-patchservice.
- Vi fører dokumentationen pr. system, så I kan fremlægge den for kunder, forsikringsselskaber eller revisorer.
Konklusion: Patch management virker ukomplekst, så længe det fungerer. Netop det er målet: Når den næste kritiske melding kommer, kører et indøvet forløb, og ingen behøver at improvisere.
Ofte stillede spørgsmål
Hvad er forskellen på patch management og sårbarhedshåndtering?
Sårbarhedshåndtering registrerer og vurderer sårbarheder og beslutter, hvad der skal gøres. Patch management gennemfører beslutningen: teste opdateringer, indspille dem, genstarte tjenester og dokumentere succesen. Begge griber ind i hinanden.
Bør sikkerhedsopdateringer indspilles automatisk?
For styresystempakker er det ofte fornuftigt, forudsat at der findes backups, og at der kontrolleres efter kørslen. Det vigtige er, at de berørte tjenester også genstarter. Ved PHP bliver der ellers gamle processer tilbage med den sårbare kode i hukommelsen.
Hvordan dokumenterer jeg, at en patch virkelig virker?
Med den installerede pakkestatus og CVE-numrene i pakkens changelog, tidspunktet for installationen og starttidspunktet for de kørende processer, som skal ligge efter installationen.
Hvad gør man, hvis en opdatering ødelægger noget?
Til det findes tilbagevejen: en backup eller snapshot før opdateringen og et beskrevet forløb til at rulle tilbage. Ved sikkerhedsopdateringer bør tilbagerulning være undtagelsen og kombineres med en midlertidig foranstaltning.