Vid incidentrapportering inom mjukvaruutveckling handlar det om två olika saker som ofta blandas ihop: en sårbarhet eller fel i mjukvaran som ni bygger och levererar, och en incident i er egen utvecklingsmiljö — miljön där ni skapar den mjukvaran. Vad ni registrerar, vem som måste veta det och vilka följande steg som hör till det skiljer sig åt beroende på typ. Om man inte gör denna åtskillnad missar man ofta den incident som betyder mest: en kontaminering i build-pipeline som sprider sig via koden till alla kunder som använder den.
En sårbarhet i levererad kod påverkar kunden direkt: den kör mjukvaran, så den löper risken. En incident i utvecklingsmiljön — en stulen åtkomstnyckel, ett komprometterat build-konto, ett läckage i källkodslagret — påverkar initialt er, men kan påverka varje kund som arbetar med den koden. För båda gäller att en säkerhetsfrågelista eller revisor inte frågar om något någonsin har gått fel, utan om ni kan visa vad ni har registrerat om det och lärt er av det.
Vad ni registrerar vid en incident i koden
Vid en sårbarhet eller fel i levererad mjukvara handlar det om: när det upptäcktes, av vem eller vad (internt test, kundanmälan, skanning, extern utredare), vilken del av mjukvaran det påverkar, vad den möjliga effekten är, vilken åtgärd som vidtogs och på vilket datum, och vem inom er organisation som är ansvarig för uppföljningen. En bra registrering gör också tydligt om en fix har distribuerats till alla kunder som använder den aktuella versionen, eller endast till den som anmälde det. Det senare är precis vad en köpare frågar om i en frågelista: inte om ni någonsin hade en sårbarhet, utan om er process garanterar att alla som påverkas av det också får det att veta.
Vad ni registrerar vid en incident i utvecklingsmiljön
En incident i er egen utvecklingsmiljö — ett komprometterat konto med åtkomst till källkoden, en build-server som reagerar på ett oväntat sätt, ett beroende som senare visar sig vara skadligt — kräver en något annorlunda registrering. Här handlar det om: vilket system eller konto det gällde, vem som hade åtkomst under perioden då det var ett problem, om det finns tecken på att kod har ändrats eller lästs, och vilka kunder som möjligen använder mjukvara som byggdes eller levererades under den perioden. Det här är den typ av incident där åtkomstkontroll i utvecklingsmiljön direkt spelar in: utan en aktuell översikt över vem som får göra vad var, är denna utredningsfråga vid en incident betydligt svårare att besvara.
Vem ni informerar, och vem ni inte gör
Om ni själva är föremål för skyldigheten enligt cybersäkerhetslagen eller inte avgör vem ni informerar om en incident. Enheter som själva har klassificerats som väsentlig eller viktig har en anmälningsplikt till sin tillsynsmyndighet; vad som exakt krävs och inom vilken tidsram framgår av direktivet och den nationella lagen, och skiljer sig åt beroende på situation. Ett mjukvaruföretag som påverkas via leverantörskedjan — det vill säga inte är skyldigt själv, men levererar till en kund som är det — har inte denna anmälningsplikt till tillsynsmyndigheten, men har vanligtvis ett avtalsenligt åtagande att informera kunden. Det gör din egen registrering inte mindre viktig: en kund som frågar om ni någonsin har haft en incident vill se ett konkret svar, inte en bedömning i efterhand.
Ett levande register, inte ett arkiv
Incidentregistrering fungerar bäst som ett levande dokument: en lista där status, bevis och ansvarig återfinns för varje incident, istället för en separat rapport som försvinner i en mapp efter avslutande. Det överensstämmer med hur den bredare skyldigheten att vidta åtgärder är utformad, med tio åtgärder som var och en kräver en status och en ansvarig. Den som vill se hur incidentregistrering förhåller sig till de övriga nio åtgärderna hittar denna överblick på sidan med alla ämnen per situation.
Huruvida din organisation själv omfattas av skyldigheten att vidta åtgärder, påverkas via leveranskedjan eller ingen av delarna kan du se med ett par frågor via NIS2-kontrollen som ger en indikation med ett par frågor. Den som vill veta exakt var informationen på secria.eu kommer ifrån och hur den uppdateras läser det på sidan om hur det fungerar. Och den som efter läsning vill veta vad ett abonnemang lägger till det som här är gratis hittar det tydligt presenterat under överblicken över vad som ingår.
Denna text är en allmän förklaring och ingen juridisk rådgivning om din egen situation. För ett omdöme om din specifika incidentprocess eller anmälningsplikt kan du vända dig till en jurist eller till den tillsynsmyndighet som är behörig för din sektor.