Security checklist for CI/CD pipelines with self‑hosted runners and secrets management

By Kevin Marcondes · Published on Oct 11, 2026 · 8 min read

This CI/CD security checklist for self‑hosted runners and secrets management focuses on practical controls: host hardening, isolation, least-privilege access policies, secret handling, supply-chain protections and audit. Use it as a reference to reduce the risk of secret leakage, runner takeover and artifact tampering in self-managed environments.

Common threats in self‑hosted CI/CD: understand the landscape

Self‑hosted runners give you control and performance, but they also expand your attack surface. Typical threats include secret leakage in logs, malicious jobs, compromised dependencies, host takeover and credential theft used for malicious deployments. The first step is to separate build environments from production and adopt strong isolation, least-privilege access and regular secret rotation.

Map who triggers pipelines, what each job can access, where artifacts are sent and which networks are allowed. Define clear boundaries: a runner should not have direct access to production databases or queues without additional controls and audit trails.

Runner host and network hardening: essential checklist

Treat the runner host as a sensitive asset. Apply system hardening, automatic updates and package inventory. Minimize the attack surface: disable unnecessary services, enable a firewall and limit open ports. Separate runners by sensitivity (production, staging) into distinct subnets.

Reduce egress. Allow only necessary destinations: registries, mirrors, dependency providers, CI endpoints and secrets stores. Block inbound Internet access. Prefer outbound NAT, authenticated proxies and internal DNS with allowlists.

For a baseline hardening guide for Linux servers, see: VPS Linux security checklist.

• System up to date and controlled reboots
• Restrictive firewall (deny by default) and firewall logging
• SSH access with keys, MFA on bastion hosts and no remote root login
• Temporary mounts with noexec,nosuid,nodev when possible
• Runner monitoring and alerts (CPU, disk, processes)
• Backups and golden images used only as runner templates

Ephemeral runners, isolation and least privilege

Ephemeral runners reduce malware persistence and data traces. Launch a runner per job or for short-lived batches and destroy it when the job finishes. Avoid reusing work directories. Run jobs as an unprivileged user, with kernel controls (seccomp, AppArmor/SELinux) and cgroups to limit resources.

Where possible, isolate each job in containers or lightweight VMs. Disable privileged docker‑in‑docker; prefer limited sockets or runtimes with strict policies. CI tokens should be scoped minimally and be short-lived.

For architecture and automation at scale, see: Auto-scale Self-Hosted Runners for PHP CI.

• Runner per job or short-lived instances
• Unprivileged user; no sudo available to the job
• Container security policies (seccomp, AppArmor)
• CPU/RAM/IO limits per job
• Tokens with minimal scope and short expiration
• Secure workspace wipe after job completion

Secrets management: policies, flow and leakage controls

Centralize secrets and avoid persistent .env files. Use CI-native secrets, external secret stores or short-lived credentials issued via OIDC to obtain credentials on demand. Apply periodic rotation, versioning and audit trails. In pipelines, mask sensitive variables, forbid echoing secrets and sanitize logs and artifacts.

Restrict secrets by environment and branch. Don’t pass secrets to jobs that don’t need them. Prefer mounting secrets in memory (tmpfs) and remove them after use. Scan repositories and artifacts for accidentally committed secrets.

In Docker builds, avoid ARG/ENV for secrets in Dockerfiles. Inject secrets only at build time with restricted scope and avoid leaking them into image layers.

Supply chain: dependencies, builds and signing

Your base image and dependencies are part of the perimeter. Pin versions, use checksums and block unreviewed updates. Generate an SBOM on every build and store it alongside the artifact. Scan dependencies and images for CVEs before promoting to deploy.

Sign images and artifacts and publish provenance attestations. Maintain private caches, mirrors and registries under strict control. Treat cache outputs as untrusted: validate outputs before use. For a private authenticated registry with a mirror, see: Private Docker Registry with Mirror on VPS.

To speed up builds without weakening controls, see: BuildKit remote cache for CI.

• Pin versions and verify download integrity
• Generate SBOMs and store them with the artifact
• Sign images/artifacts and validate signatures on deploy
• Block egress to unapproved repositories
• Scan for CVEs and fail high-risk builds

Protecting artifacts, logs and deployment channels

Set retention and access policies for artifacts. Store them in repositories with immutable trails and versioning. Separate roles: the person who merges code should not be able to alter signed artifacts. During deployment, validate signatures and attestations before promoting between stages.

Reduce log sensitivity: mask variables and remove excessive stack traces in sensitive jobs. Clean temporary directories at the end of jobs. Use dedicated service accounts for CD with least privilege and time-limited windows.

For internal services exposed to pipelines, use mutual TLS between services. Practical guide: mTLS with Docker Compose (internal PKI).

• Minimal retention with WORM where applicable
• Signature verification as a promotion gate
• Separate service accounts per environment
• Log masking and end-to-end traceability
• Manual approvals for high-risk changes

Continuous audit, testing and incident response

Record who triggered the pipeline, commit hash, runner ID, tool versions, artifact digests and policy decisions. Centralize logs with correlation across stages. Periodically test secret recovery and key rotation.

Prepare runbooks for: secret disclosure, runner compromise, malicious dependency and signature failure. Keep a controlled break‑glass path with short expiration and strong audit. Review permissions and the secret inventory quarterly.

• Collect and retain tamper-evident audit logs
• Tests for secret rotation and credential revocation
• Runbooks with owners and internal SLAs
• Periodic IAM reviews and repository scans

Concise checklist to apply today

Use this list as a starting point. Adapt to your context and risk profile. Prioritize items with the highest impact and lowest effort, and iterate in short cycles with metrics that track exposure reduction and prevented incidents.

• Ephemeral runners, no sudo, with kernel policies
• Hardened host, restrictive firewall and minimal egress
• Centralized, masked and rotated secrets
• OIDC for short-lived credentials when possible
• Pin versions, generate SBOM and sign artifacts
• CVE scans that fail high-risk builds
• Versioned artifact storage and signature checks on deploy
• Service accounts with least privilege per environment
• Masked logs and end-to-end traceability
• Runbooks, drills and periodic permission reviews

Frequently asked questions

What changes in security when using self‑hosted runners?

You must protect the runner host and network as well. This requires system hardening, per‑job isolation, egress control, secret rotation and full auditing. Without those controls, a runner can leak secrets, be hijacked for malicious deployments or expose your internal infrastructure.

Do ephemeral runners really reduce risk?

Yes. Destroying the runner after each job removes malware persistence, reduces leakage from reused workspaces and enforces a known template configuration. Combined with unprivileged users and short-lived tokens, they shrink the attack window and lower the impact of compromises.

How to avoid leaking secrets in pipeline logs?

Enable variable masking, ban commands that print sensitive values and review scripts to avoid echoing secrets. Inject secrets only where needed, mount them in memory when possible and run automatic scans on repositories and artifacts to detect accidental exposures.

Can OIDC replace .env files in CI/CD?

In many cases, yes. OIDC issues short-lived credentials on demand, avoiding static keys in .env files. With properly defined IAM policies, OIDC reduces leak risk and simplifies rotation. Some legacy systems may need gradual integration or a parallel vault during migration.

How often should secrets be rotated?

It depends on risk and the system. As a rule, rotate sensitive secrets on short windows and always after incidents or team changes. Automate rotation when possible and keep version records for safe rollback. Use short-lived credentials to reduce the need for long-lived keys.

Where should CI-generated artifacts be stored securely?

Use artifact repositories with versioning and access controls. Prefer storage with immutability (WORM) and link each artifact to its commit hash and SBOM. Require signature validation before promoting artifacts between environments, and maintain adequate audit trails and retention.

See also

• Pre-deploy checklist and quick rollback plan for PHP applications in production
• Guide: Centralize logs with Fluentd and Elasticsearch for PHP apps on a VPS
• Guide: Organizing PostgreSQL Migrations and Rollbacks for Small Teams
• VPS Linux security checklist before putting services into production: hardening, SSH, backups and monitoring