How to Secure Jenkins CI/CD Pipelines Against Common Attack Vectors

Disable anonymous access immediately:

Navigate to: Manage Jenkins > Security > Authorization

• Set to: Matrix-based security or Role-Based Strategy (requires Role Strategy plugin)
• Remove the Anonymous row or set all permissions to Deny
• Add authenticated users with minimum required permissions

Minimum permission sets:

# Developers: read access only unless they need more
Anonymous: none
Authenticated users: Job/Read, View/Read
Developers: Job/Read, Job/Build, Job/Cancel, View/Read
CI Admins: All job permissions but NOT Jenkins admin
Jenkins Admin: Full permissions (restrict to 2-3 people)

Enable CSRF protection (should be on by default, verify):

Manage Jenkins > Security > CSRF Protection: Enable

Enforce HTTPS:

# /etc/default/jenkins (Debian/Ubuntu)
# Add --httpsPort and point to your certificate
JENKINS_ARGS="--httpsPort=8443 --httpsCertificate=/etc/ssl/jenkins/jenkins.crt --httpsPrivateKey=/etc/ssl/jenkins/jenkins.key --httpPort=-1"

# Or put Jenkins behind an nginx/Apache reverse proxy that handles TLS

Configure session timeouts:

// Groovy script in Jenkins Script Console (Manage Jenkins > Script Console)
// Set session timeout to 30 minutes
import hudson.model.Hudson
Hudson.instance.securityRealm.sessionTimeoutInSeconds = 1800
Hudson.instance.save()

Integrate with your identity provider (LDAP, SAML, OIDC): Install the relevant plugin and configure under Manage Jenkins > Security > Security Realm. This centralizes authentication so Jenkins credentials are managed with your standard user lifecycle (provisioning, deprovisioning, MFA).

The most common Jenkins security failure: secrets stored as plain text in environment variables in the Jenkinsfile, visible to anyone with repository read access:

// Bad: secret visible in source control and build logs
pipeline {
  environment {
    AWS_SECRET_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYNEWKEYEXAMPLE"
    DB_PASSWORD = "mysuperinsecurepassword"
  }
}

// Good: credential stored in Jenkins Credentials Store, referenced by ID
pipeline {
  stages {
    stage('Deploy') {
      steps {
        withCredentials([
          aws(credentialsId: 'aws-prod-deploy', accessKeyVariable: 'AWS_ACCESS_KEY_ID', secretKeyVariable: 'AWS_SECRET_ACCESS_KEY'),
          string(credentialsId: 'db-password', variable: 'DB_PASSWORD')
        ]) {
          sh 'aws s3 sync ./dist s3://my-bucket'
          sh './deploy.sh'  // DB_PASSWORD available as env var but masked in logs
        }
      }
    }
  }
}

Credential scoping: store credentials at the right level:

• System scope: Available only to Jenkins admin tasks, not pipeline code
• Global scope: Available to all pipelines (use for shared credentials)
• Folder scope: Available only to pipelines in a specific folder (use for team/project isolation)

Never use Global scope for production credentials. Create a folder for production jobs and store production credentials at folder scope: only pipelines in that folder can access them.

Integrate with external secrets managers:

// HashiCorp Vault integration (requires Vault Plugin)
pipeline {
  environment {
    // Vault retrieves the secret at runtime: nothing stored in Jenkins
    VAULT_ADDR = 'https://vault.internal.company.com:8200'
  }
  stages {
    stage('Deploy') {
      steps {
        withVault(configuration: [
          vaultUrl: 'https://vault.internal.company.com:8200',
          vaultCredentialId: 'vault-approle-jenkins'
        ], vaultSecrets: [
          [path: 'secret/prod/webapp', secretValues: [
            [envVar: 'DB_PASSWORD', vaultKey: 'db_password'],
            [envVar: 'API_KEY', vaultKey: 'stripe_key']
          ]]
        ]) {
          sh './deploy.sh'
        }
      }
    }
  }
}

Mask secrets in build logs:

// Jenkins automatically masks credentials from withCredentials blocks
// For any secret not from withCredentials, mask manually:
wrap([$class: 'MaskPasswordsBuildWrapper', varPasswordPairs: [[password: env.MY_SECRET, var: 'MY_SECRET']]]) {
  sh 'echo using $MY_SECRET'
  // Output: "using ****"
}

The pipeline code injection risk: If a developer can modify a Jenkinsfile in a branch and that branch automatically triggers a build, the developer can execute arbitrary code in the Jenkins build environment: potentially accessing secrets, modifying artifacts, or pivoting to deployment environments.

Protected branches and pull request validation:

// Only run privileged stages when building from protected branches
pipeline {
  stages {
    stage('Test') {
      steps {
        sh 'npm test'
      }
    }
    stage('Deploy to Production') {
      when {
        // Only run on main branch: not feature branches or PRs
        branch 'main'
        // Or check that this is not a PR build
        not { changeRequest() }
      }
      steps {
        withCredentials([...]) {
          sh './deploy-prod.sh'
        }
      }
    }
  }
}

Shared Libraries for privileged operations: Move sensitive operations into a Jenkins Shared Library in a separate, access-controlled repository. The Jenkinsfile calls the library function: it cannot see the library's implementation or modify it (unless they have write access to the library repo):

// vars/deployToProd.groovy in the shared-library repo (controlled access)
def call(String serviceName, String version) {
  withCredentials([
    aws(credentialsId: 'aws-prod-deploy', ...)
  ]) {
    sh "./deploy.sh ${serviceName} ${version}"
  }
}

// Jenkinsfile in application repo (developer-accessible)
@Library('jenkins-shared-library') _
pipeline {
  stages {
    stage('Deploy') {
      when { branch 'main' }
      steps {
        deployToProd('webapp', env.BUILD_NUMBER)
      }
    }
  }
}

Groovy sandbox restrictions:

• Keep the Groovy sandbox enabled for all Pipelines
• Require explicit Script Approval review before any code runs outside the sandbox
• Audit the approved scripts list in Manage Jenkins > In-process Script Approval regularly
• Treat any request to approve a new script as a security review event

Never run agents as root:

# Create a dedicated, unprivileged Jenkins agent user
useradd -m -d /var/lib/jenkins-agent -s /bin/bash jenkins-agent

# The agent runs as this user: no sudo, no docker socket access unless explicitly needed
# If Docker access is required, add to the docker group (not run as root)
usermod -aG docker jenkins-agent

Restrict agent workspace access:

# Agent workspace should be isolated from the host filesystem
# Use tmpfs workspaces that are cleared after each build
# Or use ephemeral Kubernetes agents (recommended for cloud deployments)

Kubernetes ephemeral agents (best practice for isolation):

// Jenkinsfile using Kubernetes pod agents
pipeline {
  agent {
    kubernetes {
      yaml """
apiVersion: v1
kind: Pod
spec:
  securityContext:
    runAsUser: 1000
    runAsNonRoot: true
  containers:
  - name: build
    image: node:20-alpine
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: false  # Build needs write access
      capabilities:
        drop: [ALL]
    resources:
      limits:
        memory: 2Gi
        cpu: '1'
"""
    }
  }
  stages {
    stage('Build') {
      steps {
        container('build') {
          sh 'npm ci && npm run build'
        }
      }
    }
  }
}

Ephemeral Kubernetes agents spin up for each build and terminate immediately after: there is no persistent agent state that one build can contaminate or inspect from a previous build.

Audit the attack surface regularly:

# Check which plugins have known vulnerabilities
# Jenkins Security Advisories: https://www.jenkins.io/security/advisories/

# Plugin version audit via Jenkins CLI
java -jar jenkins-cli.jar -s http://localhost:8080 list-plugins | grep -v '(latest)'

# Use the OWASP Dependency-Track or Trivy to scan the Jenkins WAR and plugins
trivy fs /var/lib/jenkins/plugins/