Har en udvikler taget kildekode med, skal I sikre sporene i jeres egne systemer, før I gør noget andet: Git-historikken, adgangslogs fra kodeplatformen, tokens og nøgler, og udviklerens computer. Mange af sporene ligger hos en ekstern platform som GitHub, GitLab eller Azure DevOps, og logs gemmes kun i en begrænset periode. Luk adgangene kontrolleret, men slet ikke brugere eller repositories.
Artiklen er skrevet til CTO’en eller ejeren i en software- eller IT-virksomhed. Den juridiske side af ophavsret til software og dokumentation af kopiering er beskrevet på advokatsitet. → Ophavsret og software: dokumentation af kopiering
Typiske tegn
- Udvikleren har klonet mange repositories kort før fratrædelsen.
- Kode er pushet til et privat repository eller en privat konto.
- Et konkurrerende produkt dukker op med funktioner eller fejl, der ligner jeres.
- Personlige adgangstokens eller SSH-nøgler er brugt efter fratrædelsen.
- Der er hentet store mængder data fra byggeservere, artefaktlagre eller cloudkonti.
- En kollega har set noget, der ikke passer.
De første timer
1. Udpeg én, der ejer sagen
Det er typisk CTO’en eller ejeren. Hold kredsen lille. Udviklere i teamet kan have kontakt med den tidligere kollega, og selv en uskyldig bemærkning kan advare. → Undgå at advare den, sagen handler om
2. Sikr loggene på kodeplatformen
Kodeplatforme gemmer audit-logs og adgangslogs i en periode, der afhænger af platform og abonnement. Eksportér dem nu. Det gælder især:
- logs over kloning, downloads og eksport af repositories,
- logs over oprettelse og brug af tokens og SSH-nøgler,
- ændringer i medlemskab, rettigheder og forks,
- logs over adgang fra nye IP-adresser eller enheder.
Notér, hvem der eksporterede, hvornår og hvordan. Rør ikke ved selve historikken.
3. Bevar Git-historikken
Git-historikken viser, hvem der har skrevet hvad, og hvornår. Den er vigtig både for at dokumentere jeres egen udvikling og for at sammenligne med et eventuelt konkurrerende produkt. Lav en fuld kopi af de relevante repositories, inklusive alle grene og tags. Undgå at omskrive historikken, fx med force push eller sletning af grene, mens sagen står på.
4. Luk adgangene kontrolleret
Tilbagekald tokens og nøgler, fjern brugeren fra organisationen, og skift fælles hemmeligheder som API-nøgler, adgangskoder til databaser og certifikater. Gør det efter, loggene er gemt, og notér tidspunktet for hver handling. Slet ikke brugeren eller repositories, og slå ikke logning fra. → Udvikleren stopper: GitHub, tokens og private kopier
5. Sikr computeren og de øvrige konti
Udviklerens arbejdscomputer kan rumme lokale kopier, historik fra kommandolinjen, synkronisering til private konti og spor efter USB-enheder. Tag den ud af brug, og få den sikret med en forensisk kopi. Det samme gælder mail, chat og cloudlagre. De generelle trin for de første timer, når en medarbejder er stoppet, er beskrevet her. → Medarbejderen er stoppet: de første 48 timer
6. Tjek byggeservere og cloud
Kode og hemmeligheder ligger også i byggeservere, containerregistre, artefaktlagre og cloudkonti. Tjek logs for adgang og downloads, og gem dem. Er der brugt personlige konti til cloudressourcer, så notér det.
7. Skriv et notat
Skriv kort ned, hvad der har givet mistanke, hvornår I opdagede det, og hvad I har gjort siden. Notér også, om nogen har kigget i computeren, konti eller repositories, og hvad de så. Skriv sagligt og uden konklusioner. Notatet er udgangspunktet for advokaten og den IT-sagkyndige, og det viser, at I har håndteret sporene ordentligt.
Hvem gør hvad?
- CTO eller ejer · Ejer sagen og beslutter rækkefølgen
- DevOps eller IT · Eksporterer logs, lukker adgange, skifter hemmeligheder
- HR · Finder kontrakt, klausuler og fratrædelsesaftale
- Advokat · Vurderer ophavsret, forretningshemmeligheder og krav
- IT-sagkyndig · Sikrer computer og logs og kan sammenligne kode
Det må I ikke gøre
- Slette brugeren eller dens repositories. Logs og historik kan forsvinde med den.
- Omskrive Git-historikken. Den er jeres bedste dokumentation for, hvem der skrev hvad og hvornår.
- Lade et teammedlem undersøge udviklerens computer. Det ændrer spor og gør kollegaen til vidne.
- Skrive til den tidligere udvikler, før I har sikret. Private kopier kan slettes eller flyttes.
- Klone den konkurrerende kode uden at tale med advokaten. Det kan rejse egne spørgsmål om lovlighed.
Sammenligning af kode
Har et konkurrerende produkt funktioner, der ligner jeres, er det fristende selv at sammenligne. Men en sammenligning, der skal bruges i en tvist, skal laves med dokumenteret metode og på materiale, der er lovligt tilvejebragt. Det kan være en opgave for en uvildig IT-sagkyndig eller en skønsmand. Del heller ikke jeres mistanke med kunder eller samarbejdspartnere, før advokaten har vurderet sagen. Saml i mellemtiden det, der er offentligt tilgængeligt om det andet produkt, fx hjemmeside, dokumentation og offentlige repositories, og gem det med dato.
Hvem ejer koden?
Mange tvister handler ikke kun om kopiering, men om hvem der ejer koden. Find ansættelseskontrakt, konsulentaftale og eventuelle aftaler om rettigheder frem. Har udvikleren skrevet dele af koden før ansættelsen eller i sin fritid, kan det blive et tema. Git-historikken og jeres projektstyring kan vise, hvornår koden blev skrevet, og som en del af hvilket arbejde.
Når det er en konsulent eller freelancer
Er det ikke en ansat, men en konsulent eller freelancer, er sporene ofte de samme, men aftalegrundlaget er et andet. Find konsulentaftalen, og se efter, hvad der står om rettigheder, fortrolighed og tilbagelevering. Konsulenter arbejder tit på egne computere og med egne konti, så det kan være sværere at sikre lokale kopier. Desto vigtigere er loggene fra jeres egne platforme. Gem også fakturaer og timeregistreringer, der viser, hvad konsulenten har arbejdet på, og hvornår.
Saml en tidslinje
Lav en enkel tidslinje med de vigtigste hændelser: ansættelse, adgange, opsigelse, kloninger og downloads, sidste arbejdsdag, lukning af adgange og første tegn på et konkurrerende produkt. Henvis for hver hændelse til den log eller det dokument, der viser den. Tidslinjen gør det let for advokaten og en IT-sagkyndig at se, hvad der mangler, og hvad der skal undersøges først.
Forebyg næste gang
Mange af disse sager er lettere at håndtere, hvis rutinerne er på plads på forhånd: adgang efter behov, logning, der gemmes længe nok, og en fast procedure ved fratræden. → Beskyt forretningshemmelighederne, før der sker noget
Hvornår skal I have hjælp udefra?
Få hjælp med det samme, hvis der er tegn på, at kode er flyttet ud, især hvis udvikleren er gået til en konkurrent eller har startet egen virksomhed. Logs udløber, og private kopier kan slettes. En uvildig IT-sagkyndig kan sikre computer og logs, så materialet kan bruges i en tvist og efterprøves af andre. Haster det, så sig det tydeligt. Hastesager koster ekstra. → Pris og tilbud
Denne artikel handler om civile sager, fx om ophavsret og forretningshemmeligheder.
Læs også: Beskyt forretningshemmelighederne, før der sker noget · Dokumentér jeres egen udvikling løbende
→ Tvist med en IT-leverandør eller en kunde · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
