Sårbarhedshåndtering, opdateringer og supportperiode

Et softwareprodukt er ikke færdigt, når det er frigivet. Cyber Resilience Act kræver, at fabrikanten håndterer sårbarheder i hele supportperioden, udsender sikkerhedsopdateringer uden betaling og uden unødigt ophold og fortæller brugerne, hvor længe produktet bliver understøttet. Supportperioden er som udgangspunkt mindst fem år. Artiklerne her viser, hvordan processen dokumenteres, så den kan efterprøves af en kunde eller en myndighed, og hvordan releases vurderes for væsentlige ændringer.

Sårbarhederne

• Håndtere eller rette: gennemgang af rettefrister og sårbarhedsregister Egne frister holdt op mod sagerne.
• Politik for koordineret offentliggørelse og det centrale kontaktpunkt: gennemgang af praksis Det, politikken lover, og det, der sker.
• Sårbarheden kan ikke rettes: afbødning, lukning af en funktion eller tilbagetrækning af en version Korrigerende foranstaltninger.
• Når rettelsen er ude: pligten til at offentliggøre oplysninger om sårbarheden, og retten til at vente Indholdet af oplysningerne og tidspunktet.

Opdateringerne

• Sikkerhedsopdateringer adskilt fra funktionsopdateringer Frigivelseshistorikken som bevis.
• Kun nyeste version understøttes: betingelserne i artikel 13, stk. 10, ved hyppige releases To betingelser, der skal holde.
• Sikker distribution af opdateringer: beskrivelsen i dokumentationen og kontrollen i klienten Klienten afviser en forkert pakke.
• Uden betaling og uden unødigt ophold: sikkerhedsopdateringer bag supportaftale eller licensnøgle Vejen frem til kunden.
• Hver sikkerhedsopdatering skal kunne hentes i ti år: opdateringsarkivet Arkiv, hosting og plan.

Releases og ændringer

• Væsentlig ændring: de fire spørgsmål, hver release skal igennem, og hvad et ja betyder Kommissionens prøvesten.
• Skriv de planlagte funktioner ind i risikovurderingen fra start Forudset funktion, ingen ny vurdering.
• I ændrer en andens kommercielle software: ændret produkt eller nyt produkt bygget af komponenter? Hvornår integratoren bliver fabrikant.

Supportperioden og afslutningen

• Supportperioden: begrundelsen i den tekniske dokumentation Forventet brugstid som grundlag.
• Under fem år: de to tilfælde fra Kommissionen, og beviset for forventet brugstid Den korte periode skal bevises.
• Slutdatoen ved købet og beskeden i programmet, når supporten er slut Måned og år, før kunden køber.
• Gamle versioner: salg efter supportens udløb og offentlige arkiver med advarsel Advarslen i arkivet.
• Softwarehuset indstiller driften: underretning af myndighed og brugere Besked, før lukningen virker.
• Jeres licens- og supportvilkår efter CRA: det, der skal ændres før december 2027 Standardvilkår holdt op mod opdateringer uden betaling, supportperiode og slutdato.

Sådan kommer I i gang

Saml de sårbarheder, I har haft i det seneste år, i ét register med dato for kendskab, vurdering, rettelse og offentliggørelse. Læs derefter jeres politik for koordineret offentliggørelse, og se, om sagerne i registret er forløbet, som politikken siger. Fastsæt til sidst supportperioden pr. produkt med en begrundelse, og kontrollér, at datoen står, hvor kunden ser den før købet. Hvordan en virksomhed som kunde læser jeres frister og register, er beskrevet på sitet om leverandøraudit, og organisationens egen sårbarhedsstyring hører under sitet om sikkerhedsaudit.

Hvad det kræver, og hvad det koster at lade være

Processen kræver en fast ejer, et register, der faktisk bruges, og et arkiv, der kan holde opdateringerne tilgængelige i ti år. Uden det kan softwarehuset ikke vise, at en sårbarhed blev håndteret i tide, og en kort eller ubegrundet supportperiode kan blive det første, en myndighed spørger til.

Det skal I lade være med

• At love en fast rettefrist, I ikke kan holde · registret viser, hvad der skete.
• At lægge sikkerhedsopdateringer bag en betalt supportaftale · de skal være uden betaling.
• At sætte supportperioden efter salgsplanen · den skal følge den forventede brug.

Det skal auditten kunne vise

• ☐ Et sårbarhedsregister med datoer for hver sag.
• ☐ En offentlig politik for koordineret offentliggørelse og et kontaktpunkt.
• ☐ En begrundet supportperiode pr. produkt, oplyst ved købet.
• ☐ Et arkiv over sikkerhedsopdateringer og en vurdering af hver release for væsentlig ændring.

Senest gennemgået: november 2026.

Næste skridt

• Håndtere eller rette
• Supportperioden

Læs også: Indberetning efter artikel 14 · SBOM og komponenter

→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT