For udviklingshuse og softwareleverandører

Et udviklingshus har mere dokumentation end de fleste: hver ændring står i Git, hvert build i pipelinen og hver fejlmelding i ticketsystemet. Alligevel bliver det svært, når en kunde påstår, at softwaren aldrig virkede, når en fratrådt udvikler starter op hos en konkurrent med påfaldende ens kode, eller når et website, I drifter, bliver kompromitteret. Problemet er sjældent, at sporene mangler. Det er, at de bliver ændret, mens I retter fejlen, og at jeres egen forklaring vejer mindre, fordi I er part. Siden her samler, hvad I selv kan sikre, og hvornår en uafhængig sagkyndig skal stå for det.

Typiske situationer

Kunden påstår, at en fejl skyldes jeres software, og I mener, den skyldes kundens konfiguration eller data.
Leverancens indhold bestrides: hvilken version blev leveret, med hvilke komponenter, og blev den installeret som aftalt?
En udvikler er stoppet, og I har mistanke om, at repositories er klonet eller koden genbrugt i et nyt produkt.
En kunde eller modpart hævder, at jeres kode er kopieret fra deres, eller at en AI-kodeassistent har ført fremmed kode ind.
Et website eller en webshop, I står for, er hacket, og kunden vil vide, om indgangen var et plugin, I burde have opdateret.

Det kan I selv

Fastholde versionen, før der rettes. Tag et tag eller en branch på den kørende version, gem konfiguration og logs fra produktionsmiljøet, og notér, hvem der har adgang.
Gemme byggeartefakter. Builds, pakker og afhængighedslister fra den leverede version er det bedste bevis på, hvad kunden faktisk fik.
Bevare platformens auditlog. Git-platformens log over kloning, forks og tokens har begrænset levetid og afhænger af abonnementet. Eksportér den, mens den findes.
Ikke selv undersøge kollegaens maskine. Lad den fratrådte udviklers computer ligge urørt, og luk adgange uden at slette konti.
Skrive ned, hvad I gør. Hvert indgreb i produktionen under en uenighed bør stå i en handlingslog.

Her skal en uvildig ind

Når I er part, og jeres egen analyse af koden eller loggene ikke vil blive godtaget af kunden eller modparten.
Når kodelighed skal vurderes metodisk, med sammenligning, der skelner mellem fælles biblioteker, standardmønstre og egentlig kopiering.
Når et kompromitteret website skal undersøges, og spørgsmålet om ansvar mellem bureau, hostingleverandør og kunde er åbent.
Når produktionsmiljøet skal sikres hos kunden, og I ikke bør være dem, der rører det.

Rollefordeling

Udviklerne kender koden, pipelinen og miljøerne og stiller adgang og forklaringer til rådighed. Den uvildige sikrer repositories, builds og logs med hash og dokumenteret forløb og laver den tekniske sammenligning eller analyse. Ledelsen og advokaten ejer sagen og spørgsmålene. Hvordan et forløb starter, og hvad det hjælper at have parat, står på Når I ringer. Ønsker I en uvildig vurdering af jeres egen sikring, før kunden bestiller noget, er teknisk sparring et alternativ til en hel undersøgelse.

Hvem I får som sagkyndig

Nielco IT drives af John Nielsen, som har været selvstændig siden 2009 og har mere end 30 års erfaring inden for IT-sikkerhed. Der er ingen udviklingsydelser, ingen produkter og ingen partnerskaber med platformleverandører, så Nielco IT konkurrerer ikke med jer. Den Fælles Europæiske Patentdomstol, UPC, er blandt de steder, John har været IT-sagkyndig, sammen med flere danske retskredse. Fortrolighedsaftale underskrives, når I beder om det, og kildekode og forretningshemmeligheder er omfattet af tavshedspligten.

Start her

Er I midt i en uenighed med en kunde, så ring 70 13 63 23, før næste deploy ændrer billedet.

Ydelser til udviklingshuset

Forensisk sikring Kode, builds, databaser og logs fastholdes med verificerbar kopi. Hastesager koster ekstra.
Teknisk undersøgelse Kloning, kodelighed eller et kompromitteret website analyseres.
Uvildig IT-sagkyndig Når uenigheden om leverancen bliver til en tvist.
Kontakt 70 13 63 23 · info@nielcoit.dk.

Afgrænsning

Indholdet gælder civile tvister, interne undersøgelser og uenigheder mellem leverandør og kunde. Der gives ingen vejledning i at bryde licensnøgler, omgå adgangskontrol eller hente kode fra systemer, I ikke har ret til. Se Afgrænsning.