How do you find out who had access to your source code after a leak?

A competitor launches a feature that behaves very like yours. Your leadership asks one question: who had our code?

You check the repository access log. It lists forty people over four years. It shows who cloned the repository, not who opened which file, and nothing about what they did with the clone. The agency’s list is a spreadsheet. The freelancer’s access ended last year, but their laptop was never checked.

After weeks of work, you have a list of people who could have copied it. Not a list of people who did.

Everyone with repository access holds all of it. Once it is cloned, nothing records who opened what. The trail is long: employees, agencies, freelancers, customers and their IT staff.

Without a record, any action risks accusing the wrong person.

Weeks of investigation that end in a list of suspects, not a finding. Strained relationships with people who did nothing. A weaker legal position, because you cannot show who had what.

Repository access logs show who could clone, not what was opened or what happened to the clone. Exit interviews and device checks cover the people you know about, not contractors, freelancers or old backups.

Forensic comparison of code is evidence after the fact, slow and costly, and weak if the code was rewritten. Asking everyone to confirm deletion gives a signed statement, with no check that it is true.

First, lock your business logic. Most of a codebase is boilerplate: screens, logins, forms, reports, connections to other systems. It looks much the same in every product. Your business logic, the rules that make your product yours, sits separately in its own files. NakodaX scans your repository and suggests those files. You review the list and decide what to protect.

The protected files open only through a licence or an approved change session. Every key request, licence change, session and key reveal is recorded. The change sessions show who asked, who approved and when the window closed, and the person who asks cannot approve, so every opening has two named people behind it.

The runtime view shows each deployment, its licence and when it last checked in. Copies of the locked files outside those channels are ciphertext, so what an incident puts at risk is small and known.

It records who opened the protected files. It cannot say who copied files that were never locked. A person in an approved change session could read the real files during that window, and the record shows who and when.

It does not name a culprit. It narrows who had the chance. Today it works with Python, JavaScript, TypeScript and SQL.