Detecting the Exfiltration of Source Code and Research Assets

By Robert Knudsen, Computer forensics and cybersecurity examiner, Global Digital Forensics

Why Silent Intellectual Property Theft Is More Damaging Than Loud Ransomware

While a ransomware attack announces itself immediately by locking screens and demanding payment, state sponsored actors and unscrupulous competitors stealing intellectual property want you to never know they were there. When an intruder or insider quietly clones a Git source code repository, exports CAD engineering schematics or copies pharmaceutical and chemical research data, your daily operations continue uninterrupted, until a foreign or domestic competitor releases a knockoff product at half your R&D cost, eroding your enterprise valuation.

Combining Network Exfiltration Forensics With Expert Source Code Review

Global Digital Forensics protects technology companies, manufacturers and financial firms through both proactive security hardening and reactive litigation support. Under the direction of intellectual property counsel, our forensic examiners audit Git version control logs, developer workstation artifacts and cloud egress telemetry to trace repository cloning and test whether it was authorized. When litigation advances to inspecting a competitor software product under a protective order, our SourceScan platform and source code expert witnesses dissect millions of lines of code to identify structural copying, copied comments and shared algorithmic bugs even when variable names were disguised.

Copying Versus Independent Development Is the Question the Statutes Ask

Two federal statutes frame nearly every intellectual property exfiltration matter we support, and each one tells the examiner what to look for. The Defend Trade Secrets Act, at 18 U.S.C. 1839, defines improper means to include theft, breach of a duty to maintain secrecy and "espionage through electronic or other means", and then states that improper means "does not include reverse engineering, independent derivation, or any other lawful means of acquisition". The defendant's answer in a source code case is almost always independent derivation, so the examination traces a path as well as a resemblance. The Computer Fraud and Abuse Act, at 18 U.S.C. 1030, reaches a person who intentionally accesses a computer without authorization or exceeds authorized access and obtains information, and after the Supreme Court narrowed exceeds authorized access in 2021, counsel look to the record for whether the actor reached areas of the system beyond their authorized access, as distinct from using permitted access for a bad purpose.

Those definitions shape the two halves of the work. The access half asks how the code or design data left: which account cloned the repository, from what address, with which SSH key or personal access token, and whether that account was permitted to do so. The similarity half asks whether the competitor's product contains the client's code or data, and whether the overlap is explained by shared open source libraries, common frameworks or published specifications rather than copying. Each half supports the other: the access half traces the taking, the similarity half compares the use, and together they are how the examination answers the independent development defense. Done together, under the direction of intellectual property counsel, they are built to give the court a chain from the repository event to the competing product, which is what injunctions and damages awards rest on.

What Repository Logs and Developer Workstations Record

Modern source control platforms keep more than most engineering leaders realize. GitHub, GitLab and Bitbucket audit logs record repository clones, fetches and pushes by user and token, the creation and use of personal access tokens and deploy keys, changes to repository visibility and collaborator lists, and the IP addresses behind each action. Those records are where the examiner looks for who pulled the full history of a repository the week before resigning and whether a token survived the offboarding. On the developer workstation, the local .git directory carries its own evidence: the remote origins configured, the reflog of every checkout, the timestamps of the objects and the credential helper entries. Around it sit the usual Windows and macOS artifacts, including shellbags, recent documents, cloud sync client logs and the browser history that can show a personal GitHub account signed in alongside the corporate one.

For engineering data outside of source control, the record is different and just as useful. CAD vaults and product lifecycle management systems keep check out and export logs. Laboratory information systems record query and export events. File servers keep access audit trails when auditing has been enabled, and cloud storage platforms keep download and share events by account. In each case the examiner confirms retention and configuration first, since a platform logs exports when it is set to and keeps audit records for its retention window. We say plainly in the report which sources were available and how each was configured, because a complete account of the record's coverage is what keeps the findings grounded in fact. Robert Knudsen leads this analysis, and the trade secret forensics service page describes the full scope.

Cloud development platforms widen the record further. Continuous integration systems log every build and the credentials that triggered it, artifact repositories record who downloaded compiled packages, and cloud storage holding design files keeps object access logs when they are enabled. Those sources matter because a departing engineer may pull the compiled artifacts or the documentation that explains them in place of cloning the repository. We map all of them in the scoping conversation, rank them by how quickly their retention expires and preserve in that order. The ranking is itself documented, so where a source had already aged out before the engagement the report records the date, and counsel know which questions rest on the remaining sources.

How a Source Code Comparison Runs Under a Protective Order

Code comparison in litigation happens inside rules the parties negotiate, and the engagement is planned around them. The protective order typically restricts the producing party's code to a secure review room or an isolated machine without network access, limits who may view it and governs how notes and printouts are handled. Before anything is compared, we hash the production and the client's own baseline so that the versions examined are fixed and provable. The first analytical pass strips out what both sides would be expected to share: open source libraries, framework boilerplate, generated code and material from published standards. What remains is the candidate region for copying, and it is there that SourceScan and the examiner look for literal matches, structural correspondence after renaming, preserved comments and misspellings, identical unusual constants and, most persuasively, the same bugs reproduced in the same places.

The findings go into an expert report that explains the method before it states the conclusion, because a judge or jury who understands why identical comments and shared defects indicate copying will give the opinion weight. The report ties the comparison back to the access record described earlier, so that the chain reads from the clone event through the workstation to the competitor's product. Depositions in these matters are long and technical, and the source code expert who wrote the report is the one who sits for them. Our work in a cross border intellectual property matter and in a counterfeit product civil seizure supported by imaging and email analysis illustrates how access evidence and comparison fit together, within the factual scope those case studies describe.

The Preparation That Gives a Source Code Case Its Footing

The most valuable preparation is also the simplest: a record of what the company's own code looked like on a given date. Repositories evolve constantly, and a hashed, dated snapshot of the protected version gives the comparison a fixed reference to meet any argument that the matching code was added after the alleged taking. Tagging releases, archiving hashed copies at milestones and keeping the repository audit log exports on a schedule give counsel that reference. The second is individual credentials. A deploy key or service account used by a whole team produces an access record at the team level, so the examiner ties activity to a person through workstation artifacts and badge data. The third is offboarding that retires personal access tokens, OAuth application grants and SSH keys on the day an engineer leaves.

Engineering teams do best when they hand suspected copies to a protocol from the start. A comparison run under counsel's protocol on controlled equipment keeps the record clear of contamination arguments and ties every conclusion to a documented method. Companies with meaningful code value decide in advance who may touch suspected copies and under what protocol, and keep the source code review and the access analysis separate from the people whose work is in question. Preventive testing matters too. A vulnerability assessment of the repository hosting, the developer VPN and the build pipeline looks for the open doors an outsider would use, and closing them narrows the competing outsider theory when an insider case is argued.

Defend Your Core Intellectual Property and Software Assets

Call Global Digital Forensics at (800) 868-8189 to consult with a senior forensic examiner and source code analyst. The initial consultation is free.

What Repository and Development Logs Record

The guide splits the work into an access half and a similarity half, and the access half depends on what the development platforms recorded. This table lists those sources, what each records and what the examiner confirms about each, so counsel can see which questions the record answers. The third column lists the checks the examiner runs on configuration and attribution. The defense is almost always independent derivation, so the examination traces a path as well as a resemblance.

The garment industry seizure and the counterfeit product matter show onsite imaging and analysis linking communications, inventory and supplier records, within the factual scope each page states, illustrating how access evidence supports an intellectual property claim.

How to Begin and What Happens on the First Call

Our Insider Threat Checklist: Hold the Accounts, Seal the Laptop sets out the items to secure in the order they expire. Bring what you have: the repositories or design systems at issue, who had access to them, when the suspected taking occurred, what the competitor has released and when, and whether intellectual property counsel is already engaged. The examiner asks how source control is hosted and whether audit logging is enabled, how offboarding handles tokens and keys, whether a dated snapshot of the protected version exists and whether any internal comparison has already been attempted. Counsel then receive a written scope covering preservation of the access record, the comparison methodology, the protective order considerations and the timing, with a proposal for each phase. The initial consultation is free, and the hotline at (800) 868-8189 answers 24/7.

Technical References and Further Reading

Related GDF pages for this work: penetration tests and vulnerability assessments.

Earlier reporting on this subject: McAfee and CSIS, Net Losses: Estimating the Global Cost of Cybercrime (archived copy).

Authorities cited in this guide: 18 U.S.C. 1839, Definitions (Defend Trade Secrets Act). Defines improper means and excludes reverse engineering and independent derivation, current codified text at Cornell LII. 18 U.S.C. 1030, Fraud and related activity in connection with computers. Sets the unauthorized access and exceeds authorized access elements of the Computer Fraud and Abuse Act, current codified text. Federal Rule of Evidence 702, Testimony by Expert Witnesses. Governs the admissibility showing for the source code expert's opinions, as amended effective December 1, 2023. NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response. Describes the forensic process phases applied to workstation and server evidence, final version 2006.