Sikkerhed og vedligeholdelse

Afhængigheder og opdateringer: hold appens fundament ved lige

En app kan virke upåklageligt og stadig være på vej mod et driftsproblem. Pakker, runtime, buildværktøjer og GitHub Actions ændrer sig uden for jeres egen kode. En enkel vedligeholdelsesrutine gør det muligt at opdage sikkerhedshuller og udløbet support, mens en opdatering stadig kan testes roligt.

En dependency er også kode, appen stoler på

De fleste apps bruger biblioteker til login, database, PDF, formularer, betaling, frontend og mange andre opgaver. Dertil kommer runtime, operativsystem, container, buildpipeline og de actions, som udgiver løsningen. Fejl eller ondsindede ændringer i den kæde kan påvirke appen, selv om jeres egen funktionalitet ikke er ændret.

Direkte afhængigheder

Pakker, plugins og SDK'er, som projektet selv har valgt i eksempelvis package.json, pyproject.toml eller csproj.

Indirekte afhængigheder

Pakker, som de valgte pakker selv bruger. De ses typisk i dependency graph og lockfile.

Runtime og platform

Eksempelvis Node.js, Python, .NET, databaseversion, container-baseimage og cloudens valgte runtime.

Bygge- og udgivelseskæde

Package registry, CI/CD, GitHub Actions, IDE-udvidelser og andre værktøjer, der kan påvirke det udgivne resultat.

OWASP behandler i 2025 fejl i softwareforsyningskæden som en selvstændig risiko og anbefaler blandt andet versionsoverblik, overvågning af sårbarheder, fjernelse af ubrugt software og en løbende plan for opdateringer gennem appens levetid.

Få et reproducerbart billede af det, der faktisk kører

Et versionsinterval i en manifestfil fortæller ikke altid præcist, hvilken indirekte pakke der blev installeret. Derfor skal manifest og lockfile høre sammen og ligge i repositoryet. Deployment skal bruge projektets låste installation i stedet for stille at vælge nyere pakker under hver build.

Find manifestet: Dokumentér package manager, projektmapper og de filer, hvor direkte afhængigheder vælges.
Bevar lockfilen: Commit den lockfile, som hører til package manageren, og gennemgå den sammen med manifestændringer.
Lås runtime: Angiv den understøttede runtime i projekt og hosting, så lokal udvikling, CI og produktion ikke driver fra hinanden.
Registrér produktionen: Notér hvilken commit, runtime og buildartefakt der er udgivet. Et lokalt package tree er ikke nødvendigvis identisk med produktion.

Eksempel for npm: npm dokumenterer, atnpm cikræver en eksisterende lockfile, stopper hvis den ikke passer til package.json og ikke omskriver afhængighedsfilerne. Andre økosystemer har egne mekanismer; brug den valgte package managers officielle metode.

Lad alarmer skabe overblik – ikke automatisk produktion

GitHub kan vise Dependabot-alarmer, når en kendt sårbarhed rammer en registreret afhængighed, og kan oprette pull requests til sikkerheds- eller versionsopdateringer. Det er en indbakke til vurdering, ikke et bevis på at ændringen er sikker at udgive.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5

Eksemplet opretter ugentlige versionsforslag for et npm-projekt. Tidsplan, mapper, økosystem og antal åbne pull requests skal tilpasses repositoryet. Sikkerhedsalarmer aktiveres i repositoryets sikkerhedsindstillinger; de opstår ikke alene, fordi filen ovenfor findes.

Udpeg en ejer: En navngiven person eller rolle skal modtage, vurdere og afslutte alarmer.
Sortér efter reel risiko: Se på om den ramte funktion bruges, om pakken ligger i produktion, om data eller adgang kan påvirkes, og om en rettelse findes.
Dokumentér udsættelse: En accepteret risiko skal have begrundelse, midlertidig beskyttelse, ansvarlig og dato for ny vurdering.
Husk begrænsningen: GitHub understreger, at Dependabot ikke finder alle sikkerhedsproblemer. Hold også øje med den valgte platforms egne sikkerhedsmeddelelser.

Vurder opdateringen efter konsekvens – ikke kun versionsnummer

En kritisk sårbarhed i aktiv produktionskode kræver en anden reaktion end en udviklingspakke, som ikke indgår i det udgivne resultat. Omvendt kan en stor versionsopgradering berøre datamigrering, login eller buildformat, selv om der ikke er en sikkerhedsalarm. Vurder ændringens konkrete vej gennem appen.

Afgræns påvirkningen: Find direkte eller indirekte ejerpakke, berørte funktioner, miljøer og data.
Læs primærkilden: Kontrollér leverandørens sikkerhedsmeddelelse, release notes og migrationsvejledning.
Opdatér isoleret: Brug en særskilt branch og et test- eller previewmiljø, og behold lockfileændringen i samme review.
Test det berørte: Kør build og automatiske tests samt de brugerrejser, integrationer og dataoperationer, pakken indgår i.
Udgiv kontrolleret: Følg normal godkendelse, overvåg fejl og kritiske handlinger, og hav en realistisk tilbagevej.

OWASP anbefaler at afprøve en rettet dependency i et testmiljø og bruge relevante unit-, integrations-, funktions- eller sikkerhedstests før produktion. Et grønt build alene beviser ikke, at login, betaling eller databehandling stadig virker.

Runtime har også en slutdato

En understøttet runtime modtager fejl- og sikkerhedsrettelser; en udløbet runtime kan blive et blindt punkt, selv om applikationspakkerne er opdaterede. Kontrollér den officielle livscyklus for den runtime, database og hostingvariant, som appen faktisk bruger, og planlæg migrering før supporten udløber.

For Node.js anbefaler projektet kun Active LTS eller Maintenance LTS til produktion. Den aktuelle status ændrer sig over tid, så gem ikke en gammel versionsliste i en intern guide; link til den officielle oversigt og registrér jeres egen valgte version, ejer og seneste kontrol.

Typiske fejl

Alle forslag flettes automatisk: En ny version kan bryde API'er, ændre standarder eller kræve en ny runtime.
Alle alarmer ignoreres: En lang, ufordelt liste skjuler den sårbarhed, som faktisk rammer produktionen.
Lockfilen mangler eller omskrives i CI: Samme commit kan ende med forskellige pakker på forskellige tidspunkter.
Kun direkte pakker kontrolleres: Den sårbare komponent ligger ofte længere nede i dependency graph.
Runtime glemmes: Bibliotekerne ser opdaterede ud, mens selve kørselmiljøet er uden normal support.
Store bunker opdateres samlet: Når noget fejler, er årsag og sikker rollback sværere at finde.
AI vælger pakken uden kildekontrol: Navn, vedligeholdelse, rettigheder og officiel dokumentation bliver ikke vurderet.

Tjekliste til sikker vedligeholdelse

☐ Manifest, lockfile, package manager og projektmapper er kendte og versionsstyrede.
☐ Produktionens commit, runtime og buildproces kan identificeres.
☐ Runtime, database, baseimage og andre platformkomponenter har kendt supportstatus.
☐ Sikkerhedsalarmer er aktiveret, og en navngiven rolle modtager dem.
☐ Direkte og indirekte dependencies kan ses i et dependency graph eller tilsvarende overblik.
☐ Ubrugte pakker, plugins, actions og værktøjer fjernes efter kontrol.
☐ Opdateringsforslag går gennem branch, review og relevant test.
☐ Kritiske brugerrejser testes, når deres biblioteker eller runtime ændres.
☐ Udsatte sikkerhedsrettelser har dokumenteret risiko, beskyttelse, ejer og genbesøgsdato.
☐ Deployment bruger en reproducerbar installation og stopper ved uoverensstemmelse.
☐ Efter udgivelse kontrolleres logs, fejlrate og de påvirkede funktioner.
☐ Tilbagevejen tager højde for både kode, lockfile, runtime og eventuelle dataændringer.

Relaterede guides

GitHub Actions til automatiske kontroller Teststrategi for de berørte brugerrejser Testmiljø og rollback ved opdateringer Driftsdokumentation med runtime og ansvar Se hele guidebiblioteket

Officielle kilder

Værktøjer og kommandoer afhænger af projektets stack. Brug den valgte package manager, runtime, cloud og hostingplatforms aktuelle dokumentation, når rutinen omsættes til konkrete handlinger.