Protecting Source Code and Intellectual Property

Pattern matching finds card numbers reliably and a proprietary algorithm not at all. For organisations whose value is in designs, code or research, this is the central difficulty.

Why content inspection fails here

A source file, a CAD drawing, a research dataset or a strategy document has no distinguishing pattern. It looks like text or binary content, and a rule that matched it would match everything of the same type.

The generic approaches — "detect code" — flag every developer's normal work, produce enormous noise, and get disabled.

What works instead

Fingerprinting. Register the actual documents or repositories you care about with the DLP system, which then matches derivatives of those specific files. Precise, because it is matching your content rather than a category.

Limitation: it matches known content. A file created after registration, or heavily modified, may not match. Fingerprint sets need refreshing.

Location-based policy. Instead of asking what the file contains, ask where it came from. Anything leaving the design repository, the research share or the code host is treated as sensitive regardless of content. Much simpler and frequently sufficient.

Repository-level controls. For code, the platform itself is the better control point than any DLP product:

Push protection to prevent code reaching personal repositories. Restrictions on making a repository public. Alerting on fork or clone volume. Enforced review before external sharing. Audit of who cloned what and when.

Most code loss happens through the code platform. Instrumenting there is more effective than inspecting network traffic that is encrypted anyway.

Access reduction. The most effective control and the least popular. Most developers do not need access to every repository. Most engineers do not need the full design archive. Narrowing access reduces the population who could take anything, which no detection rule achieves.

The departing engineer

The specific case that generates most real incidents.

Someone leaving frequently believes they are entitled to take work they personally created. That belief is sincere, widely held, and usually wrong as a matter of contract — and the gap between belief and contract is where most cases arise.

The practical controls:

Clone and download volume in the notice period, watched against baseline.

Repository access reviewed at resignation, narrowed to what the handover requires.

An explicit conversation at exit about what belongs to the organisation. This prevents more incidents than any technical control, because a substantial share of these people would not have taken anything had someone told them clearly.

Personal repository pushes, which the code platform can block outright.

Research and design data

Similar logic, different systems.

Large files, specialist formats and a small population who legitimately handle them. That last point is an advantage: with a small user base, per-user baselines are meaningful and anomalies are interpretable.

Watch the export functions of the specialist systems rather than the network. A CAD system's own export log is more informative than any packet inspection.

The realistic position

You cannot prevent a determined engineer with legitimate access from taking code. They can retype it, photograph it, or reconstruct it from memory well enough to matter.

What you can do is make casual and opportunistic taking visible, raise the effort for deliberate taking, establish a record that supports action afterwards, and — most effectively — reduce how many people have access to anything worth taking.

Programmes framed as prevention here will disappoint. Programmes framed as deterrence, visibility and access reduction achieve most of what is achievable.