Process Lineage

What is Process Lineage (Security)?

Process lineage is the documented chain of parent-child process relationships on an endpoint, recording which process spawned which, what each executed, what files it accessed, and what network connections it made. It provides the execution-side context that security investigations require: not just that something happened, but which computational sequence produced it.

The term comes from the same conceptual root as data lineage, but the two answer different questions. Data lineage tracks where data went. Process lineage tracks what happened to generate and move it.

How process lineage works

Every process on a modern operating system has a parent. A user double-clicks a file: the shell spawned the file manager, the file manager spawned the document editor, the document editor spawned a macro execution environment. A scheduled task runs a script: the task scheduler spawned a shell interpreter, the shell interpreter spawned a database client, the database client executed a query. Each of these relationships is a parent-child process link.

Process lineage captures the full chain from root to leaf, along with the contextual data that makes each link meaningful for security analysis.

Four data points define a complete process lineage record.

Process identity. The name and path of the executable, the process ID, and the parent process ID. These establish the structural relationship: this process was spawned by that process.

Execution context. The command-line arguments the process was invoked with, the user account that launched it, the working directory, and the timestamp. A python.exe process with no arguments looks different from python.exe exfil_script.py --output /tmp/staging --target dropbox.com. Same executable, completely different risk profile.

File access. Which files the process opened, read, wrote, created, or deleted during its execution. This is where process lineage connects to data movement: a process that reads from a sensitive database output file and writes a compressed copy elsewhere has a file access record that documents that transformation.

Network activity. Which network connections the process established, to which destinations, how many bytes it transferred. Network activity tied to process identity is what allows analysts to say a specific process, not just a device, made a specific connection.

Process lineage vs data lineage

These two concepts are complementary and are often confused. Both are forms of provenance. Both are essential for complete incident investigations. But they track different dimensions.

Data lineage tracks the journey of data itself: where a dataset originated, how it was transformed, which systems received copies, how it propagated downstream. It answers: what happened to this data, across which systems, over what time period?

Process lineage tracks the execution chain that manipulated data: which process read a file, which process compressed it, which process uploaded it. It answers: what computational sequence produced this outcome, and which identity was ultimately responsible?

An investigation that has data lineage but not process lineage knows that data moved from a database to cloud storage. It doesn't know which process performed the extraction, whether that process was a sanctioned tool or a custom script, or what the command-line arguments suggest about intent.

An investigation that has process lineage but not data lineage knows that a compression utility ran and a network upload followed. It doesn't know what data sensitivity was involved or how far that data propagated downstream.

Both together produce the complete picture: what sensitive data moved, through which process chain, attributable to which identity, to which destination.

Why process lineage matters for security investigations

Most modern data loss scenarios involve legitimate tools used in illegitimate ways. The database client is authorised. The compression utility is standard. The cloud storage service is approved. What's not authorised is the specific sequence: a large query at an unusual time, followed by local staging, followed by compression, followed by upload to a personal account rather than a corporate one.

Each step in that sequence generates a process event. The process lineage record ties all of them together into a chain. One query. Then a file write. Then a compression invocation. Then a network transfer to an unexpected destination. Evaluated as a sequence, the intent becomes clear. Evaluated as isolated events, each one looks unremarkable.

That's the core value of process lineage for security: it makes sequences visible, not just individual events. A single alert on an outbound upload is noise. An alert that shows a parent shell spawning a database client, which spawned a file write, which spawned a compression utility, which spawned a cloud storage client, all within four minutes, tied to a user who hasn't previously done this operation: that's a finding.

Process lineage in the evidence record

When a security incident reaches the stage of regulatory notification, legal proceedings, or executive briefing, the evidence must be both complete and attributable. "Data was exfiltrated" is not an evidence statement. "This user's authenticated session spawned this script, which read these files containing this sensitivity class of data, which were compressed and uploaded to this destination transferring this many bytes at this timestamp" is an evidence statement.

Process lineage contributes the execution-side attribution to that record. It answers who ran what, in what sequence, with what arguments, producing what file and network operations. Combined with data classification that identifies what sensitivity the accessed data carried, and data lineage that shows where that data propagated, process lineage completes the chain from identity to outcome.

That completeness is increasingly what regulators under DPDP and GDPR, and auditors under HIPAA and SOC 2, require. Not an approximate account of what probably happened. A traceable, attributable record of what actually did.

How process lineage is captured

Process lineage requires kernel-level telemetry. User-space monitoring cannot observe the parent-child process relationships and system call chains that constitute process lineage, because those relationships exist inside the kernel before any user-space logging decision is made.

On Linux systems, eBPF (extended Berkeley Packet Filter) programs attached to process creation hooks and system call entry/exit points capture the process tree, command-line arguments, file access events, and network operations that build the lineage record. On Windows, ETW (Event Tracing for Windows) kernel providers record the same categories of events through the Windows security subsystem.

The resulting telemetry is only as useful as the time window it covers. Process lineage records assembled after an incident from surviving logs may be incomplete if the attacker cleaned up, if log rotation removed early records, or if the monitoring system wasn't running at the time. Continuous kernel-level telemetry that streams process lineage events off the endpoint in real time is what makes the record tamper-resistant and gap-free.