Source Code Exfiltration Patterns in Technology and Semiconductor Firms

Source code theft in technology and semiconductor firms follows a pattern, not a moment. It builds over weeks, moves through channels that legacy security tools were never built to watch, and by the time anyone notices a file missing, the damage is already baked into a competitor's roadmap. Across documented insider risk investigations, the shape of the problem doesn't really change from case to case. It rarely looks like the breach headlines. It looks like someone doing their job, quietly, for months, right up until they don't.

Source code is the compounded record of years of engineering decisions, failed prototypes, and tuned parameters that a rival would need years and comparable capital to rebuild from scratch. In semiconductors, that record includes process recipes, chip architecture designs, and manufacturing parameters, the output of R&D budgets measured in the billions. The $556 billion semiconductor industry lives on the margin between what's proprietary and what's public, and the multiyear ASML trade secret litigation is a blunt reminder of how much rides on a single breach of that line.

A stolen customer database tends to surface fast, because someone notices fraudulent charges or a breach notification law forces a company's hand. Stolen source code can sit quietly inside a competitor's product roadmap for months or years before anyone connects the dots. The Department of Justice's Disruptive Technology Strike Force has brought charges over the past three years spanning electric vehicle technology, silicon carbide semiconductor technology, and source code tied to autonomous vehicle systems. Nearly all of these cases share the same thread, and it's the thread that makes detection genuinely hard: the person moving the data had a real login, real repository access, and a real job.

The recurring cast: who actually exfiltrates source code and why

Three types show up again and again across enforcement cases and insider risk research, and each one needs a different way of watching for it.

The departing employee is by far the most common. Motivated by a competitive edge at the next job or a straightforward payday, this person often starts staging data weeks or months before turning in a resignation letter. The nation-state-enabled insider works on a longer clock and hides better; take the case of former Google engineer Linwei Ding, where investigators found more than 500 unique confidential files at his home and he was convicted of stealing over 2,000 pages of sensitive material, all under access that looked entirely legitimate on paper.

The fraudulent contractor is the newer archetype. 2025 gave it a full stage, as companies leaned harder on contract labor to fill technical roles they couldn't staff fast enough any other way. North Korea's remote IT worker campaign is the most documented version of this, and the tells are specific: geolocation that doesn't match a claimed home base, repository cloning that happens well outside standard working hours.

Exfiltration doesn't always run in a straight line from employee to competitor, either. The indictment of TSMC and Tokyo Electron, the first prosecution of a corporation under Taiwan's National Security Act for stealing national core critical technology, shows theft sometimes moves through a supply chain partner instead of the primary employer. Motive shapes tempo, too: financial gain tends to produce fast, high-volume transfers, while espionage tends to produce slow, surgical access that never trips an obvious wire. Build a detection program that only catches the fast pattern, and the slow one walks right past it.

This isn't a rare-event problem. Eighty-three percent of organizations had at least one insider-related incident in the past year.

How exfiltration actually unfolds: the staged timeline before departure

A single file transfer is almost never the whole story. The risk lives in the pattern that builds across weeks or months, and the pre-departure window carries the strongest signal of all.

The 2026 Ponemon report found a 720% surge in data exfiltration activity in the 24 hours before a layoff, measured against an employee's own baseline. That number gets attention, and it should. But the surge is only the visible tip; the staging underneath it commonly starts as much as six months before anyone announces a formal departure.

The sequence tends to run the same way, case after case. It starts with reconnaissance: unusual access to repositories outside someone's normal scope, reading architecture documents that have nothing to do with the current sprint. Then aggregation, where the behavior shifts from touching individual files for a task to cloning entire repositories or pulling whole sets of builds and dependencies as a package. Next comes compression and obfuscation, archiving directories into zip or tar files and renaming them so it's not obvious what's inside. Finally, transfer: the packaged data moves to a personal cloud account, a removable drive, or a personal code repository, often in off-hours or during the last few days on the job.

Looked at one at a time, each step can pass for routine work. An engineer clones a repo, or someone zips a folder before the weekend. Only the sequence, seen across a person's full activity timeline, gives away intent. That's exactly why insider-driven incidents can take weeks or months to detect and contain, a pattern consistent across insider risk research. Teams that look at single events instead of the shape of a timeline are set up to miss this, no matter how sharp their analysts are.

The specific channels source code moves through — and why each is hard to catch

Git itself is a structural blind spot. The protocol packages and sends changes directly, so no file ever passes through the kind of inspection point that traditional data loss prevention tools were built to watch. A push from a corporate repository to a personal GitHub account travels over standard HTTPS and looks, to file-based monitoring, like nothing happened at all. MITRE's ATT&CK framework documents this as technique T1567.001, Exfiltration to Code Repository, and notes that HTTPS adds a further layer of cover against detection. In a network log, a push to a personal repo can look identical to a routine push to an approved upstream.

Personal cloud storage still carries the highest volume of exfiltrated material. Cyberhaven Labs' 2024 insider risk dataset put personal cloud storage at 22.7% of exfiltration volume, removable drives at 15.6%, AI tools at 13.1%. Without lineage tracking, a file moving to personal cloud storage looks like any other SaaS sync, because to most tools, that's exactly what it is.

Collaboration platforms deserve more attention than they usually get. The 2024 Disney Slack incident involved a compromised workspace used to steal more than 1.1 terabytes of data, including unreleased projects, credentials, and source code. GitGuardian's 2025 research found that 28% of secret-leak incidents that year started entirely outside source code, in tools like Slack, Jira, and Confluence, and that 56.7% of the secrets found only in collaboration tools were rated critical severity.

Hardcoded secrets add a passive surface that's easy to write off. GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits in 2025, a 34% jump over 2024 and the largest single-year increase on record. Thirty-two percent of internal repositories carry at least one hardcoded secret, roughly six times the rate of public repos. AI-assisted commits leak secrets at around 3.2%, notably above the platform-wide baseline, and that gap will only widen as AI coding assistants become standard tooling on every team.

CI/CD pipelines are an active target too. Open source malware campaigns have been built specifically to harvest .git-credentials, AWS secrets, and environment variables off developer machines, using time-delayed payloads and encrypted transmission so the compromise doesn't surface until long after it happened.

Then there's the fragment problem, and it cuts against how most content-inspection tools actually work. Cyberhaven Labs found that more than 80% of the data employees exfiltrate consists of fragments, partial files, screenshots, chat excerpts, rather than whole documents. A fragment of source code can still be functionally complete: a single algorithm or a process recipe doesn't need the rest of the file around it to be worth stealing. Tools built to inspect whole documents miss exactly the piece that matters.

Why static DLP rules cannot follow a behavioral pattern across these channels

Legacy DLP was built for a different world: discrete file transfers, known data types, managed endpoints. It was never built for a developer's actual workday, which spans Git, SaaS platforms, CI/CD pipelines, and half a dozen collaboration tools before lunch.

Static rules and regex look at each event on its own, against a fixed pattern, with no memory of what came before. A sixteen-digit number gets flagged as a credit card no matter the context, and a bulk clone of an entire repository sails through because, as far as the rule is concerned, that's just what Git does. These systems can't reason about sequence. They can't ask whether this particular user has ever done this before, because they don't remember yesterday.

The architecture makes it worse. Most legacy DLP deployments aren't wired into SIEM, user behavior analytics, or identity systems, so the Git clone, the after-hours login, and the personal cloud upload sit in three separate dashboards with nothing connecting them. Forrester's July 2024 report on the state of data security found that 83% of enterprises have deployed endpoint DLP, yet only 13% have fully deployed data security in the cloud. That gap, between where the tools sit and where the data actually moves, is the gap every one of these actors walks straight through.

The operational cost shows up as noise, plain and simple. Seventy-eight percent of organizations struggled with their DLP tooling in 2024, and rule-based systems commonly produce false positive rates that can reach extremely high levels, which means analysts spend their days triaging volume instead of chasing anything real. That mismatch will only deepen as AI coding tools spread through engineering teams and expose new channels that rule-based systems were never designed to monitor. That extended detection gap isn't an abstraction. It's the direct, measurable cost of watching tools in isolation instead of watching a person over time.

What behavioral detection actually looks for across the user timeline

The shift underneath all of this is simple to say and hard to build: baseline the person, not the data type. If a system knows an engineer typically clones repositories during business hours from a managed laptop, and has never once touched the firmware library, a 2 a.m. bulk clone of that library is anomalous on its face, no rule required. Every action gets measured against that person's own history, not some generic threshold set for the whole company.

A handful of signals matter more than the rest. Access scope expansion, where someone starts reading repositories or architecture files that have nothing to do with their actual assignment. Aggregation behavior: bulk cloning, recursive downloads, directory compression, especially stacked with off-hours timing. Destination anomalies, like a first-ever upload to a personal cloud account, a connection to an unfamiliar external repo, removable storage showing up on a machine where it's never been used before. Identity and location signals, a geolocation mismatch or concurrent sessions from two places at once, which matters most for the contractor fraud pattern described earlier. And departure-correlated acceleration, a sharp uptick in exfiltration-shaped behavior in the weeks around a resignation, a layoff notice, or a rough performance review.

Data lineage is what stitches these signals together into something usable. Tracking a file from its origin repository through every copy, sync, rename, and upload destination is what lets a security team trace a fragment sitting in a personal Google Drive folder back to the exact line in the codebase it came from. This is also what closes the Git blind spot from earlier: the event that matters isn't the push itself, it's the full chain running from the initial clone to wherever the data ends up.

Systems built to learn what's normal for a given person, instead of applying one fixed rule to everyone, cut false positive rates well below the 80 to 90% range typical of legacy tools. Analysts see fewer alerts and get more context with each one, not more noise to wade through. The alert itself has to read clearly, too: "this user cloned 47 repositories in the past six hours, uploaded a compressed archive to a personal Dropbox account, and gave notice last week" is something an analyst can act on right away. A black-box risk score with no explanation gives them nothing to work with.

None of this holds up, though, without integration across Git, identity providers, endpoints, collaboration tools, and HR systems. No single source of telemetry ever tells the whole story by itself. Teams that lack this integration routinely find themselves piecing together a timeline after the fact that should have been visible in real time.

What an effective detection program looks like in practice for technology and semiconductor security teams

Start by defining what "source code" actually means inside your own walls, before writing a single detection rule. For a semiconductor firm, that has to include process recipes, mask design files, simulation parameters, and manufacturing IP, because those carry exactly as much risk as application code and usually get protected far less carefully. For a technology firm, it means separating core product code from internal tooling and open source forks. Not every repository carries the same weight if it walks out the door.

Prioritize where the risk actually sits. Employees in notice periods, people recently passed over for a promotion, and anyone with standing access to the crown-jewel repositories deserve closer behavioral attention than the rest of the workforce. Contractor onboarding is a gap worth naming outright: fraudulent contractor access exploits weak identity verification right at the point of entry, so behavioral monitoring has to start on day one, not after some probationary period quietly expires.

Close the Git and collaboration blind spots on purpose. That means visibility into repository-level operations, who cloned what, how much, and when, not just file-level transfers sitting at the network edge. It also means pushing monitoring into Slack, Jira, and Confluence, given how much critical secret exposure now starts there instead of in the codebase itself.

Build for correlation across sources, not alerting inside each tool on its own. The pattern that actually matters spans identity, endpoint, Git, and cloud storage all at once, and a program running these as four separate alert queues will miss the staged sequence every time. Behavioral platforms that connect identity providers, endpoint telemetry, HR systems, and collaboration tools give analysts one stitched timeline instead of four disconnected fragments to reconcile by hand.

Measure the program by detection latency and the quality of the investigations it produces, not by alert volume. Eighty-one days is the number to beat, and the real goal is catching the pattern during staging, before the transfer ever happens. A team spending most of its time triaging instead of investigating is a sign the detection layer is producing noise instead of signal.

The insider risk problem now costs the average organization $19.5 million a year, up from $17.4 million in the prior study period, and that cost concentrates hardest in exactly the cases where detection lagged behind the staging. What's missing, in most of the organizations I've seen, isn't the technology to catch this. It's the will to connect the pieces before the notice period starts, not after.