CI/CD and Developer-Environment Detection Opportunities
Detect abuse in source, build, package, secret, and deployment systems by following identities and artifacts across trust boundaries rather than treating pipeline success as legitimacy.
A pipeline is an authority graph, not a sequence of scripts
Continuous integration and delivery systems accept source changes, create execution identities, obtain secrets, build artifacts, publish packages, and alter environments. Each step transfers authority across a boundary.
Map people, applications, workflow definitions, runners, repositories, package registries, cloud roles, artifacts, and destinations as related entities. A successful job only says the automation completed according to its current configuration.
Detection begins with unexpected changes in those relationships: a new trigger, runner, reusable workflow, secret consumer, publisher, artifact, approval path, or deployment target.
Source events need review and branch context
Commits, pull requests, approvals, branch changes, workflow edits, and token creation describe different decisions. A merged change may have passed policy while containing malicious logic; an unmerged workflow change may still execute in some trigger models.
Preserve author, committer, approver, actor, application, branch, repository, organization, and protection outcome as separate roles. Shared or bot identities require provenance back to the initiating workflow or user.
Useful hypotheses include protection bypass, self-approval, unusual workflow-file modification, changed external action reference, and new secret access near a release. Each needs repository norms and policy state at event time.
Runner evidence explains where privileged code executed
A runner executes pipeline jobs. Hosted, self-hosted, ephemeral, and persistent runners have different trust and telemetry. A job can inherit credentials, network reach, caches, artifacts, and filesystem state from its environment.
Track runner identity, image, pool, network, job, repository, workflow version, credential grants, and cleanup. Unexpected runner registration or use can redirect trusted workflow authority onto attacker-controlled infrastructure.
Differentiate control-plane records from process or network evidence on the runner. A job declaration does not prove every command executed, while endpoint evidence may lack the authorization context that explains why it ran.
Artifact lineage connects build evidence to deployment
Follow immutable digests from inputs through build outputs, registry publication, signing or attestation, promotion, and deployment. Mutable tags are useful names but weak identity. A trusted pipeline deploying an unlinked artifact is a meaningful mismatch.
Use artifact provenance to evaluate builder, source, subject, and policy. Provenance does not replace behavior monitoring; it states how an artifact was produced under a defined trust model.
Detect rebuild drift, publisher changes, unapproved registries, digest substitution, and deployments without the expected lineage. Explain whether the mismatch is observed and whether malicious cause is only assessed.
Correlated evidence must preserve system boundaries
Source control, CI platform, secret manager, artifact registry, identity provider, cloud control plane, and runtime each use different clocks and identifiers. Build a versioned entity map and retain original IDs before correlation.
Monitor audit configuration, webhook or API completeness, runner coverage, artifact records, pagination, latency, and schema changes. A quiet pipeline can mean no releases or a broken export.
An investigation-ready result reconstructs the authorization chain, changed configuration, artifact lineage, destination, and known alternatives. It states which stages were directly observed and which links were inferred, allowing an analyst to judge the software-delivery story without mistaking automation for trust.
Developer environments extend this path. Local credentials, editor extensions, package tooling, and command-line sessions can initiate trusted changes while sitting outside the hosted pipeline’s logs. Include their available identity and endpoint evidence when the question concerns origin, but state clearly when only the server-side acceptance of a change is observable.
Frequently asked questions
Why are CI/CD detections difficult to design?
The environment is highly automated, identities are short-lived or delegated, legitimate jobs perform powerful actions, and evidence is split across source control, runners, artifact systems, cloud APIs, and deployment targets.
