Continuous integration and continuous deployment pipelines execute every commit, run every test, build every artifact, and log every failure. Over months and years, a CI/CD system accumulates more knowledge about a codebase than any individual developer. It knows which files break most often, which tests are unreliable, which authors introduce the most regressions, and which hours of the day produce the worst code. This data is a surveillance record of engineering behavior. It is unencrypted. It is unregulated. It is accessible to anyone with pipeline admin access. This paper documents what CI/CD systems actually record, who can access that data, and how it could be weaponized against individual developers. It proposes a framework for pipeline data governance that preserves operational value while protecting developer privacy.
What CI/CD systems record about developers. Who can access that data. How it could be weaponized. A framework for pipeline data governance.
1. Introduction
A developer pushes code. The CI/CD pipeline activates. It checks out the repository. It installs dependencies. It runs tests. It builds artifacts. It deploys to staging. It reports success or failure.
This sequence appears to be a technical process. It is not. It is a data collection process.
Every step in the pipeline generates data. Commit metadata. Test results. Build durations. Failure logs. Author identity. Timestamps. Branch names. The pipeline knows who pushed what, when they pushed it, whether it worked, how long it took, and what broke.
Individually, each data point is trivial. Aggregated over months and years, the pipeline holds a behavioral profile of every developer who contributes to the codebase. It knows who writes fragile code. It knows who works late at night. It knows who introduces the most regressions. It knows who never writes tests.
This data is not protected by privacy law. It is not encrypted at rest. It is not subject to access controls beyond the pipeline admin role. It is a surveillance system that the industry has built and normalized without acknowledging what it is.
2. What CI/CD Pipelines Actually Record
2.1 Commit Metadata
Every commit triggers a pipeline run. The pipeline records:
- Author name and email
- Commit timestamp
- Branch name
- Changed files
- Commit message
- Diff size (lines added, lines removed)
This data links individual developers to specific changes. Over time, it builds a map of who works on what, when they work, and how much they change.
flowchart LR
A["Developer pushes code"] --> B["Pipeline triggered"]
B --> C["Record author name + email"]
B --> D["Record commit timestamp"]
B --> E["Record branch name"]
B --> F["Record changed files"]
B --> G["Record diff size"]
C --> H["Behavioral profile"]
D --> H
E --> H
F --> H
G --> H2.2 Test Results
Every test run generates:
- Test name and suite
- Pass/fail status
- Duration
- Error output (if failed)
- Flaky test history (how often this test fails intermittently)
This data identifies which tests are unreliable and which changes broke them. It also identifies which developers trigger the most failures.
2.3 Build Metrics
Every build generates:
- Build duration
- Dependency resolution time
- Artifact size
- Cache hit/miss rates
- Resource consumption (CPU, memory)
This data identifies performance regressions and inefficiencies. It also identifies which developers produce the slowest builds.
2.4 Deployment Records
Every deployment generates:
- Target environment
- Deployment time
- Success/failure status
- Rollback events
- Approver identity (if approval gates exist)
This data links individuals to production changes and production failures.
2.5 Log Output
Every pipeline step generates logs. Logs contain:
- Application output
- Error messages
- Warning messages
- Debug information
- Occasionally, sensitive data leaked through environment variables or debug statements
3. The Behavioral Profile
Aggregated over time, pipeline data constructs a behavioral profile of each developer.
block-beta
columns 2
block:M1["Commit frequency by hour"]
columns 1
M1a["Work schedule"]
M1b["Late night patterns"]
end
block:M2["Failure rate per commit"]
columns 1
M2a["Code quality signal"]
M2b["40% vs 5% failure rate"]
end
block:M3["Test coverage by author"]
columns 1
M3a["Testing discipline"]
M3b["Who writes tests"]
end
block:M4["Revert frequency"]
columns 1
M4a["Rework indicator"]
M4b["Changes rolled back"]
end
block:M5["Build duration by author"]
columns 1
M5a["Efficiency proxy"]
M5b["Slowest branches"]
end
block:M6["Deployment failure rate"]
columns 1
M6a["Production risk"]
M6b["Incident attribution"]
endThis profile is not intentionally constructed. It is a byproduct of automation. But it exists. And it is accessible.
4. Who Can Access This Data
4.1 Pipeline Administrators
Anyone with admin access to the CI/CD system can view all pipeline data for all developers. This includes build logs, test results, and commit metadata. In most organizations, pipeline admin access is granted to senior engineers, DevOps staff, and sometimes team leads.
4.2 Repository Administrators
Anyone with admin access to the repository can view commit metadata and link it to pipeline data. Repository admin access is typically broader than pipeline admin access.
4.3 Third-Party Services
Most CI/CD systems are cloud-hosted (GitHub Actions, GitLab CI, CircleCI, Jenkins with cloud plugins). The pipeline data is stored on infrastructure owned by the CI/CD provider. The provider’s terms of service typically grant broad rights to process and analyze pipeline data for service improvement and, in some cases, for product development.
4.4 Internal Tools
Many organizations build internal dashboards that aggregate pipeline data for engineering metrics: DORA metrics, deployment frequency, lead time for changes, mean time to recovery. These dashboards are rarely access-controlled beyond the engineering organization. A product manager, a VP, or an internal auditor could access granular pipeline data for individual developers.
block-beta
columns 1
block:ADMIN["Pipeline Administrators"]
columns 1
A1["Senior engineers"]
A2["DevOps staff"]
A3["Team leads"]
end
block:REPO["Repository Administrators"]
columns 1
R1["Broader access group"]
R2["Can link commits to pipelines"]
end
block:THIRD["Third-Party Providers"]
columns 1
T1["GitHub Actions, GitLab CI"]
T2["Data stored on provider infra"]
T3["Broad TOS data rights"]
end
block:INTERNAL["Internal Tooling"]
columns 1
I1["DORA dashboards"]
I2["Engineering metrics"]
I3["Accessible to managers + auditors"]
end
ADMIN --> REPO --> THIRD --> INTERNAL5. How This Data Can Be Weaponized
5.1 Performance Reviews
A manager with access to pipeline data can evaluate individual developers on metrics that were never designed for evaluation: commit failure rate, test coverage, build duration. These metrics are proxies for performance, not measures of it. The developer who introduces the most regressions may also be the developer working on the hardest problems. The developer who commits least frequently may be the developer doing the most design work. The pipeline does not know the difference.
5.2 Layoff Selection
During reductions in force, pipeline data can be used to rank developers on quantitative metrics that appear objective but are context-free. “Lowest commit frequency” becomes a criterion. “Highest failure rate” becomes a criterion. The pipeline data provides a veneer of data-driven decision making over decisions that are fundamentally about human judgment.
5.3 Internal Surveillance
Pipeline data reveals when developers are working. A manager who monitors commit timestamps knows who starts early, who works late, and who is inactive during business hours. This data can be used to enforce presence in ways that remote work was supposed to eliminate.
5.4 Forensic Investigation
If an organization investigates a security incident, a code leak, or an insider threat, pipeline data becomes forensic evidence. Every commit, every build, every deployment is timestamped and attributable. The data that was collected for automation becomes evidence in an investigation.
block-beta
columns 2
block:PERF["Performance Reviews"]
columns 1
P1["Failure rate as proxy"]
P2["Commit frequency as proxy"]
P3["Context-free metrics"]
end
block:LAYOFF["Layoff Selection"]
columns 1
L1["Quantitative ranking"]
L2["False objectivity"]
L3["Human judgment replaced"]
end
block:SURV["Internal Surveillance"]
columns 1
S1["Work hour monitoring"]
S2["Presence enforcement"]
S3["Remote work erosion"]
end
block:FORENSIC["Forensic Investigations"]
columns 1
F1["Incident attribution"]
F2["Code leak tracing"]
F3["Insider threat evidence"]
end6. The Regulatory Gap
6.1 GDPR
Pipeline data that contains author names, emails, commit timestamps, and behavioral patterns is personal data under the GDPR. But CI/CD data is rarely included in data subject access requests. It is rarely listed in records of processing activities. It is rarely deleted upon request. The industry has not yet recognized pipeline data as personal data requiring protection.
6.2 The DPDP Act (India)
India’s DPDP Act requires consent for processing personal data and grants individuals the right to access and erase their data. A developer whose pipeline data is stored on a CI/CD platform has the right to know what data is stored and to request its deletion. But CI/CD platforms do not provide mechanisms for individual developers to access or delete their pipeline history.
6.3 The Gap
The regulatory gap exists because pipeline data is seen as operational data, not personal data. It is generated by machines. It is stored in infrastructure tools. It is not in a database that anyone thinks of as a user database. But the data is linked to individuals. It reveals behavior. It persists for years. It is personal data under any reasonable definition.
7. A Framework for Pipeline Data Governance
Organizations should govern pipeline data with the same rigor they apply to other forms of personal data.
7.1 Data Minimization
Pipeline configurations should collect only the data required for operational purposes. Commit metadata must be collected. Test results must be collected. Build logs must be collected. But granular timing data, per-developer metrics dashboards, and historical archives beyond operational necessity should not be collected by default.
7.2 Retention Limits
Pipeline data should have defined retention periods. Build logs for 90 days. Test results for one year. Commit metadata for the life of the repository. Data beyond its retention period should be automatically deleted.
7.3 Access Controls
Pipeline data should be access-controlled. Developers should be able to see their own data. Managers should see aggregate team data, not individual developer data. Individual developer data should require a specific, documented reason for access.
7.4 Disclosure
Organizations should disclose to developers what pipeline data is collected, how long it is retained, and who can access it. This disclosure should be part of onboarding, not buried in an internal wiki.
7.5 Deletion Rights
Developers should be able to request deletion of their pipeline data when they leave an organization. Commit metadata cannot be deleted without breaking repository integrity. But build logs, test results, and other operational data linked to a departing developer can and should be deleted.
block-beta
columns 1
block:MIN["Data Minimization"]
columns 1
MIN1["Collect only what is operational"]
MIN2["No per-developer metrics by default"]
end
block:RET["Retention Limits"]
columns 1
RET1["Build logs: 90 days"]
RET2["Test results: 1 year"]
RET3["Commit metadata: permanent"]
end
block:AC["Access Controls"]
columns 1
AC1["Developers see own data"]
AC2["Managers see aggregates"]
AC3["Individual data needs justification"]
end
block:DISC["Disclosure"]
columns 1
DISC1["Part of onboarding"]
DISC2["What, how long, who can access"]
end
block:DEL["Deletion Rights"]
columns 1
DEL1["Departing developer data"]
DEL2["Logs and results deletable"]
end
MIN --> RET --> AC --> DISC --> DEL8. Conclusion
CI/CD pipelines are surveillance systems that the industry has built and normalized without acknowledging what they are.
They record who does what, when, and with what result. They accumulate this data over years. They make it accessible to administrators, managers, and third-party platforms. They generate behavioral profiles that can be used to evaluate, rank, and potentially discipline developers.
None of this is malicious. CI/CD pipelines exist to automate software delivery. They succeed at this. The data they collect is a byproduct of automation, not a deliberate surveillance architecture.
But the effect is the same. A system that records individual behavior, links it to identity, persists it indefinitely, and makes it accessible to authority figures is a surveillance system. Calling it “DevOps” does not change what it is.
The industry needs to recognize pipeline data as personal data, govern it accordingly, and give developers the same privacy rights that users of software are increasingly granted.
The pipeline is watching. It is time to acknowledge what it sees.
References
- Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.
- European Union. General Data Protection Regulation (GDPR). 2018.
- Government of India. Digital Personal Data Protection Act. 2023.
- TELOSIS Research. Privacy-Preserving Architectures for Modern Infrastructure. TELOSIS-RP-2026-005, 2026.
- TELOSIS Research. Vendor Lock-In: Structural Analysis and Alternatives. TELOSIS-RP-2026-010, 2026.
Citation
TELOSIS Research. (2026). Your CI/CD Pipeline Knows More About Your Codebase Than You Do. TELOSIS-RP-2026-012.