Trade Secrets Leave a Trail: Software Forensics Follows the Evidence

When software becomes evidence, source code alone rarely tells the whole story. A software trade secret dispute may require reconstructing the history of two systems: how disputed functionality was implemented, how it evolved, and which engineering decisions shaped its design.

Software forensics is a technical investigation of how software works and how it developed. Source code, the instructions programmers write, shows how a particular version is implemented. System design and development records help explain how that implementation took shape. Together, these materials provide the historical record from which an expert can assemble the software’s technical story.

That reconstruction depends on engineering judgment. A relationship between software components may lead the expert to additional files, while an earlier revision may change the understanding of the current design. As the investigation progresses, individual observations begin to form a supported account of the software’s development that attorneys can evaluate and trace to the underlying evidence.

Start With the Claimed Trade Secret

A product demonstration may show that two applications perform similar tasks. It does not explain whether they use the same underlying methods. Systems can produce similar results through different designs, while applications with different interfaces may share relevant implementation details.

The investigation should begin with the specific information identified as the claimed trade secret. A software expert can help counsel clarify its technical boundaries and assess how that information relates to each system. Whether the information qualifies for trade secret protection involves legal requirements beyond technical similarity.

The technical review should address:

• What specific methods, designs, or implementation details are at issue?
• Where and how are they implemented in each system?
• Which similarities and differences are technically meaningful?

The expert examines how each system implements the disputed functionality and reconstructs its development history on its own terms. This gives the comparison a sound engineering basis by establishing an independent understanding of each system before comparing them. It also  distinguishes common software practices from implementation details that warrant closer investigation.

Map How the Software Works

A claimed trade secret may be implemented across several cooperating components. Software architecture, the way a system is organized and its components interact, provides the context needed to understand those relationships.

For example, a feature may depend on:

• A user interface, the screens and controls through which people interact with the application.
• Business logic, the rules the software uses to process information and make decisions.
• Database schemas, which define how stored information is organized and related.
• Application programming interfaces, or APIs, which define how software components exchange requests and data.

A keyword search or feature name may provide a useful starting point. From there, reviewing one source file often leads to another, gradually revealing the relationships that implement the feature. The expert follows those interactions through the application and its supporting components to understand how the observed behavior is produced.

The relationship also works in reverse. A single source file may support several features, so the expert must determine which portions relate to the claimed trade secret and which serve other purposes.

An attorney might reasonably ask why a source code investigation includes database structures, system diagrams, and application workflows. These materials provide a roadmap for the investigation by revealing how components work together and where additional evidence is likely to be found. They can also help explain the engineering decisions that shaped the design.

Understanding those relationships helps distinguish common design approaches from more specific technical similarities between systems. Mapping them is often one of the most technically demanding and intellectually rewarding aspects of a source code review.

Keep the Investigation Focused

Defining the scope of the investigation is itself part of the technical analysis. The expert must develop a sufficiently complete understanding of the relevant functionality while keeping the review focused on the issues presented in the litigation.

A review may begin with a small number of source files identified through demonstrations, documentation, or preliminary analysis. Examining those files may reveal supporting components that warrant further investigation. Conversely, components initially believed to be relevant may prove to have little relationship to the functionality at issue.

As evidence accumulates, the expert continuously reassesses whether additional material is needed to support reliable conclusions. The investigation gradually converges on an understanding of which portions of the software are necessary to explain the claimed trade secret’s implementation. Documenting those judgments helps counsel understand the basis and limits of the review.

Practical insight: The objective is to review the right source code.

Reconstruct the Development Timeline

The current version of a system shows its present implementation. Trade secret disputes may also require an account of what existed at an earlier date and how it changed.

A source code repository stores project files. When managed with a version control system such as Git, it also records revisions. Each commit, a recorded revision, can include changes to files, identifying information about the contributor, a date, and an explanatory message.

Examining these records can help an expert identify:

• The earliest preserved version containing the functionality under review.
• Changes to the implementation and the components involved.
• Contributors identified in the available development records.
• How those changes relate to released versions of the software.

Together, these records can begin to reveal the sequence of engineering decisions behind a feature. Successive revisions may show how developers refined its behavior, changed its structure, or adapted it to work with other components. In that sense, the repository becomes a historical archive. Examining it helps the expert understand how an implementation took shape and which engineering decisions are reflected in the preserved record.

Repository history requires careful interpretation. Files may have been renamed or reorganized, earlier work may have been imported from another system, and multiple revisions may have been combined into one. Dates and contributor information describe the available records and require context before they support broader conclusions about origin or authorship.

The expert therefore compares repository findings with other available materials, such as release records, development documentation, and issue tracking systems that record tasks and defects. This helps distinguish what the preserved history establishes from what remains uncertain.

Practical insight: The earliest preserved record of a feature may not be its true development starting point.

Corroborate the Technical Evidence

Each source of evidence answers different questions. Source code can show how a feature works in a particular version. Historical revisions can show how that implementation changed. Documentation may explain the intended design, while release records can help connect development changes to a distributed product.

These sources also have limitations. Documentation may describe plans that were never implemented. A repository may omit earlier work. A commit message may summarize a change inaccurately. The expert must evaluate whether the records support the same conclusion and investigate discrepancies.

Multiple records do not necessarily provide independent corroboration. For example, a release note that simply repeats a commit message adds little independent support. Confidence depends on the quality and relationship of the evidence, rather than the number of documents that repeat an assertion.

For counsel, corroboration helps identify which findings are well supported, which require further investigation, and where the available materials cannot resolve a technical question.

Interpret Development Metrics Carefully

Software metrics are measurements drawn from development records. They can help characterize activity around a disputed feature, but they require the same scrutiny as other evidence.

Useful measurements may include:

• Commit activity, or the number and timing of recorded revisions.
• Code churn, a measure of how much code was added, changed, or removed during a defined period.
• The development period and contributors reflected in the preserved history.

These measurements can identify questions for further review. If comparable functionality appears to have been developed over very different periods, the expert may investigate the reasons. Differences in project scope, reused software, team experience, or the completeness of the records may explain the apparent gap. The evidence may also warrant investigating whether developers relied on an existing implementation or design.

A shorter recorded development period does not, by itself, establish copying. Nor does a larger commit count establish greater engineering effort. One team may record many small revisions, while another combines extensive work into a single commit. Comparisons must account for how the records were created and whether the work being measured is comparable.

The investigative value of a metric depends on the question it helps answer. The expert should explain what was measured, how it was calculated, and how the result fits the broader development record.

Practical insight: Software metrics are most valuable when they are treated as technical evidence rather than technical conclusions.

Build a Technical Narrative Counsel Can Use

The purpose of the investigation is to assemble an objective explanation of the software and the evidence it contains. That explanation should connect implementation details to the questions counsel needs to evaluate:

• How is the claimed trade secret implemented, and which components are involved?
• What does the preserved record establish about its development and timing?
• Which technical similarities and differences matter to the comparison?
• What alternative explanations and evidentiary gaps remain?

The analysis should identify the versions and materials reviewed, explain the investigative steps, and connect conclusions to specific evidence. Another qualified reviewer should be able to follow the reasoning and, where the materials permit, reproduce the analysis.

The software expert provides technical findings that support the legal analysis. When several explanations remain plausible, the narrative should address them directly. When records are incomplete, the expert should explain how those gaps limit the conclusions.

When presented clearly, this technical narrative enables attorneys, judges, and juries to understand complex software without becoming software engineers. It connects the implementation, its development history, and the available records into an explanation of how the system operates and how it reached that state.

Every software system has a history. The value of a software forensic investigation lies in reconstructing the relevant parts of that history and showing what the evidence supports. For the litigation team, that provides a factual foundation for evaluating the claims, focusing further investigation, and explaining the findings.