Stop RHACS from destroying your CI/CD pipeline and your will to live

RHACS 4.8 dropped in July 2025, and while Scanner V4 is supposed to be better than the old scanner that would crash randomly, it still chokes on those massive Node.js images your developers love to build. Trust me, when the entire team pushes at 5 PM on Friday, you'll find out real quick where the performance limits are.

Your devs are pushing containers to prod right now, and half of them probably contain dependencies with critical CVEs from 2019 that nobody's bothered to patch. RHACS integration will fuck up your pipeline on day one. Plan on spending a month unfucking the policies while developers complain that security is ruining their lives.

Here's how to actually integrate this thing

RHACS hooks into your CI/CD through the roxctl CLI and Kubernetes admission controllers. The sales pitch is simple: scan images during build, check deployment policies before deployment, block the bad stuff. Reality check: plan on weeks of policy tuning unless you enjoy getting paged at 2 AM because someone's legitimate deployment got blocked by an overzealous policy.

The official docs show you the demo setup. In real life, you'll spend weeks tuning policies so they don't break every single deployment. The defaults flag every container that runs as root - which kills half your infrastructure.

What actually works:

• Image scanning with roxctl image scan catches most CVEs before deployment, though it'll miss zero-day vulnerabilities
• Deployment checking with roxctl deployment check validates Kubernetes YAML against security policies
• Admission controller enforcement blocks policy violations at the cluster level, though it adds 100-300ms latency to each deployment
• Registry integrations with Harbor, Quay, AWS ECR, Azure Container Registry, and Google Container Registry usually work without much hassle

What actually breaks:

• Default policies are fucking insane - they'll flag every container running as root, which breaks system containers, init containers, and half your infrastructure. Day one: every deployment fails. Spent 3 days figuring out why our logging sidecars died
• False positives everywhere during setup. I've spent entire sprints tuning policies while devs complain that security is "blocking innovation." One policy flagged our monitoring stack because Prometheus runs as root - obviously it fucking does
• Scanner V4 still dies on bloated Node.js containers during peak hours. You know the ones - 2GB images with every npm package ever created. Had a React app that pulled in like 800+ dependencies or something crazy. Took forever to scan and the devs threatened to push straight to prod
• Network issues between roxctl and Central in corporate networks with undocumented firewall rules and proxy configs nobody knows about. Spent a Tuesday troubleshooting why scans worked from my laptop but died in Jenkins
• Authentication failures with roxctl give you exit code 13 and zero useful info. Usually means your API token expired or has wrong permissions. The troubleshooting guide won't help much - just delete and recreate the damn API token. Happened to me twice last month

The Three Integration Patterns That Actually Work

1. Fail-Fast Image Scanning (Recommended Start)
Scan images early in the build process using roxctl image scan. This catches vulnerabilities before they reach your registry. Start with informational scanning, gradually enable enforcement as your images clean up.

## Basic CI/CD image scanning
roxctl image scan --image myapp:latest --endpoint $RHACS_CENTRAL_ENDPOINT --token $RHACS_API_TOKEN

2. Registry-Triggered Scanning
Configure RHACS to automatically scan images when pushed to your registry. Works well with Harbor, Quay, and cloud registries. Reduces CI/CD pipeline complexity but scanning happens after build.

3. Pre-Deployment Policy Validation
Use roxctl deployment check to validate Kubernetes manifests against security policies before deployment. Catches misconfigurations that image scanning misses.

## Validate deployment manifests
roxctl deployment check --file deployment.yaml --endpoint $RHACS_CENTRAL_ENDPOINT --token $RHACS_API_TOKEN

CI/CD platform integration hell

Jenkins Integration: Works Until It Mysteriously Doesn't
Jenkins has the most mature RHACS integration through the StackRox Container Image Scanner plugin. It mostly works, but I've seen the plugin randomly lose API tokens after Jenkins restarts, and the error messages are useless. The official Jenkins integration docs give you basic examples, but the Red Hat workshop labs have more realistic scenarios.

Happened to us: plugin works fine for weeks, then Jenkins auto-updates and boom - every build dies with "Error code 13." Spent half the day figuring out the restart corrupted some auth bullshit. Turns out the plugin stored tokens in some temp directory that got wiped during the restart.

GitLab CI Integration: YAML Hell but Actually Reliable
GitLab requires you to write custom YAML configs, but at least you get full control over the process. Red Hat's Trusted Application Pipeline docs are actually decent and the examples work - unlike most vendor documentation that assumes your environment matches their demo setup perfectly.

GitHub Actions Integration: Minimal but Gets the Job Done
GitHub Actions has basic RHACS support through Red Hat's Trusted Application Pipeline, but don't expect much hand-holding. Documentation is thin, so you'll be reading GitHub Actions YAML examples and figuring out the rest. Works fine for simple use cases.

Azure DevOps Integration: DIY Everything
Microsoft and Red Hat clearly didn't prioritize this. You're stuck writing custom scripts and calling roxctl commands manually. It works, but expect to write a lot of PowerShell or bash scripts to make it happen.

Policy tuning without getting fired

RHACS comes with like 375 security policies out of the box. Some make sense, others are completely nuts. The "no root containers" policy will break every sidecar, init container, and piece of infrastructure you actually need to run.

How to tune policies without your team wanting to murder you:

1. Start everything in "inform" mode. Don't break builds on day one unless you enjoy being the most hated person in engineering
2. Look at violation patterns for a few weeks. You'll discover that 80% of violations come from 3-4 policies that make no sense in your environment
3. Enable enforcement for the real stuff first: critical CVEs, privilege escalation, secrets in environment variables
4. Gradually enable more policies based on what won't make developers bypass your entire security setup
5. Use policy scopes to be strict in prod, relaxed in dev

The Policy as Code feature in RHACS 4.8 finally moved from tech preview to GA. You can now manage policies as Kubernetes custom resources and integrate them into GitOps workflows. This is actually useful for teams that want policy management in their existing Git workflows, though you'll need to understand both RHACS policy syntax and your application requirements.

Performance and scaling shit

Scanner V4 is supposed to be better than the old scanner, but it'll still eat your resources if you let it. Give it decent CPU and RAM - depends on your image sizes and how many teams are scanning at once. During peak hours when everyone pushes at once, scanning becomes a bottleneck fast.

Red Hat's sizing guidelines are theoretical bullshit - your mileage will vary based on your weird images and whatever network setup you inherited. Check their performance guide then prepare to tune everything anyway.

Scaling patterns that work:

• Enable delegated scanning on clusters with heavy CI/CD workloads
• Use registry mirrors geographically close to your CI/CD infrastructure
• Cache scanned image layers to avoid redundant scanning
• Schedule compliance scans during off-peak hours

This stuff mostly works once you get it configured right. The hard part is figuring out which integration pattern works with your specific CI/CD setup.

After fighting with RHACS integrations across dozens of organizations, here are the implementation patterns that survive contact with real development teams and production environments.

The Implementation Strategy That Doesn't Get You Fired

Phase 1: Informational Integration (Weeks 1-2)
Start with scanning and policy checking in "inform" mode. Don't break builds yet - just collect data on what would break. This gives you baseline violation data and helps identify the policies that will cause the most pain.

## Jenkins pipeline example - informational phase
stage('Security Scan - Inform Only') {
    steps {
        script {
            try {
                sh '''
                    roxctl image scan --image ${IMAGE_NAME}:${BUILD_NUMBER} \
                    --endpoint ${RHACS_CENTRAL_ENDPOINT} \
                    --token ${RHACS_API_TOKEN} \
                    --output json > scan_results.json
                '''
                archiveArtifacts artifacts: 'scan_results.json'
            } catch (Exception e) {
                echo "Security scan failed but not breaking build: ${e.getMessage()}"
            }
        }
    }
}

Phase 2: Selective Enforcement (Weeks 3-4)
Enable build-breaking for critical issues only: high/critical CVEs, privilege escalation, and obvious misconfigurations. Keep most policies informational while teams adapt.

Phase 3: Full Enforcement (Month 2+)
Gradually enable enforcement for remaining policies based on violation patterns and team feedback. This is where most teams rush and break everything.

roxctl Integration Patterns That Actually Work

Pattern 1: Container-Based Integration (Recommended)
Run roxctl inside a container to ensure consistent behavior across different CI/CD environments. This eliminates "works on my machine" issues with roxctl versions and dependencies.

## GitLab CI example using container approach
rhacs_scan:
  image: registry.redhat.io/advanced-cluster-security/rhacs-roxctl-rhel8:4.8
  stage: security
  script:
    - |
      roxctl image scan \
        --image $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA \
        --endpoint $RHACS_CENTRAL_ENDPOINT \
        --token $RHACS_API_TOKEN \
        --output json \
        --severity CRITICAL,HIGH
    - |
      roxctl deployment check \
        --file k8s/ \
        --endpoint $RHACS_CENTRAL_ENDPOINT \
        --token $RHACS_API_TOKEN
  artifacts:
    reports:
      junit: roxctl-results.xml
    expire_in: 1 week
  only:
    - merge_requests
    - main

Pattern 2: Multi-Stage Scanning Strategy
Scan at multiple points in your pipeline: base images during build, application images after build, and deployment manifests before deployment. This catches different classes of security issues.

## GitHub Actions multi-stage example
name: Security Pipeline
on: [push, pull_request]

jobs:
  base-image-scan:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Scan Base Image
      uses: redhat-actions/rhacs-scan@v1
      with:
        endpoint: ${{ secrets.RHACS_CENTRAL_ENDPOINT }}
        token: ${{ secrets.RHACS_API_TOKEN }}
        image: registry.redhat.io/ubi8/ubi:latest
        
  application-scan:
    needs: base-image-scan
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Build Image
      run: docker build -t myapp:${{ github.sha }} .
    - name: Scan Application Image
      uses: redhat-actions/rhacs-scan@v1
      with:
        endpoint: ${{ secrets.RHACS_CENTRAL_ENDPOINT }}
        token: ${{ secrets.RHACS_API_TOKEN }}
        image: myapp:${{ github.sha }}
        fail-on: CRITICAL
        
  deployment-check:
    needs: application-scan
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Check Deployment Policies
      run: |
        roxctl deployment check \
          --file k8s/deployment.yaml \
          --endpoint ${{ secrets.RHACS_CENTRAL_ENDPOINT }} \
          --token ${{ secrets.RHACS_API_TOKEN }}

Policy Configuration for CI/CD Success

The default RHACS policies will break your CI/CD pipeline on day one. Here's the policy configuration that actually works for development teams:

High-Priority Enforcement Policies (Enable First):

• Critical and High CVEs in application dependencies
• Container running with privilege escalation (allowPrivilegeEscalation: true)
• Containers running as root (with exceptions for legitimate system containers)
• Images without security patches for 90+ days
• Secrets in container environment variables

Medium-Priority Policies (Enable After 2-4 Weeks):

• Medium severity CVEs
• Missing resource limits and requests
• Images pulled without explicit tags (latest tag usage)
• Containers with excessive capabilities

Low-Priority Policies (Enable Last or Never):

• Low severity CVEs (these will break everything)
• Dockerfile best practices violations
• Container image efficiency issues
• Non-security related configuration issues

Handling Scanner V4 Performance in CI/CD

Scanner V4 in RHACS 4.8 is significantly better than previous versions, but it can still bottleneck your CI/CD during peak hours. Here's how to manage performance:

Scanning Optimization Techniques:

## Use selective severity scanning during CI/CD
roxctl image scan \
  --image myapp:latest \
  --severity CRITICAL,HIGH \
  --endpoint $RHACS_CENTRAL_ENDPOINT \
  --token $RHACS_API_TOKEN

## Skip low-priority scans in feature branches
if [[ "$BRANCH" == "main" || "$BRANCH" == "develop" ]]; then
  SCAN_SEVERITY="LOW,MEDIUM,HIGH,CRITICAL"
else
  SCAN_SEVERITY="HIGH,CRITICAL"
fi

Registry Integration Performance:
Enable delegated scanning for registries close to your CI/CD infrastructure. This reduces network latency and improves scan times. The architecture guide explains the distributed scanning approach in detail.

Parallel Scanning Strategy:
For monorepos or multi-service builds, scan images in parallel rather than sequentially:

## GitLab CI parallel scanning example
.scan_template: &scan_template
  image: registry.redhat.io/advanced-cluster-security/rhacs-roxctl-rhel8:4.8
  script:
    - roxctl image scan --image $SERVICE_IMAGE --endpoint $RHACS_CENTRAL_ENDPOINT --token $RHACS_API_TOKEN

scan_service_1:
  <<: *scan_template
  variables:
    SERVICE_IMAGE: "$CI_REGISTRY_IMAGE/service1:$CI_COMMIT_SHA"

scan_service_2:
  <<: *scan_template
  variables:
    SERVICE_IMAGE: "$CI_REGISTRY_IMAGE/service2:$CI_COMMIT_SHA"

scan_service_3:
  <<: *scan_template
  variables:
    SERVICE_IMAGE: "$CI_REGISTRY_IMAGE/service3:$CI_COMMIT_SHA"

Advanced Integration Patterns

Pattern 3: Policy-as-Code Integration
With RHACS 4.8's Policy as Code GA feature, you can manage security policies alongside application code. The GitOps integration guide covers the complete workflow:

## Custom policy for CI/CD enforcement
apiVersion: platform.stackrox.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: ci-cd-enforcement-policy
spec:
  description: "Policies specifically for CI/CD enforcement"
  categories: ["Security Best Practices"]
  policyVersion: "1.1"
  policySections:
  - policyGroups:
    - fieldName: "Image Component"
      values:
      - value: "severity >= HIGH"
    - fieldName: "Container Configuration"
      values:
      - value: "privileged = false"
      - value: "allowPrivilegeEscalation = false"

Pattern 4: Break-Glass Mechanism
Implement emergency deployment capabilities that bypass security policies when needed:

## Emergency deployment flag
if [[ "$EMERGENCY_DEPLOY" == "true" ]]; then
  echo "Emergency deployment detected - skipping security checks"
  roxctl deployment check --file k8s/ --endpoint $RHACS_CENTRAL_ENDPOINT --token $RHACS_API_TOKEN || true
else
  roxctl deployment check --file k8s/ --endpoint $RHACS_CENTRAL_ENDPOINT --token $RHACS_API_TOKEN
fi

Troubleshooting Common CI/CD Integration Issues

Issue 1: roxctl Authentication Failures
Most common problem - API tokens expire or have wrong permissions.

## Test roxctl connectivity - do this first, trust me
roxctl central whoami --endpoint $RHACS_CENTRAL_ENDPOINT --token $RHACS_API_TOKEN
if [[ $? -ne 0 ]]; then
  echo "Auth is fucked - check token and endpoint"
  exit 1
fi

Pro tip: if you get UNAUTHENTICATED: invalid credentials it usually means the token expired or someone rotated it without telling you. If you get PERMISSION_DENIED your token exists but lacks the right roles. Spent way too long debugging this once only to find out our security team rotated all API tokens during "maintenance" without updating the damn wiki.

Issue 2: Network Connectivity Issues
CI/CD agents often can't reach RHACS Central due to firewall rules.

## Network connectivity test
curl -k -f $RHACS_CENTRAL_ENDPOINT/v1/ping
if [[ $? -ne 0 ]]; then
  echo "Cannot reach RHACS Central at $RHACS_CENTRAL_ENDPOINT"
  exit 1
fi

Issue 3: Scanner Overload During Peak Hours
Multiple teams triggering scans simultaneously can overwhelm Scanner components. Had this clusterfuck where everyone pushed at 4 PM on Tuesday and scanning died for everyone. Scanner pods were showing OOMKilled and the entire engineering team was blocked. Took way too long to figure out what happened and restart the scanner pods - ended up bumping memory limits way up.

## Implement retry logic with backoff
RETRY_COUNT=0
MAX_RETRIES=3
until roxctl image scan --image $IMAGE_NAME --endpoint $RHACS_CENTRAL_ENDPOINT --token $RHACS_API_TOKEN; do
  RETRY_COUNT=$((RETRY_COUNT+1))
  if [[ $RETRY_COUNT -gt $MAX_RETRIES ]]; then
    echo "Max retries exceeded for image scan"
    exit 1
  fi
  echo "Scan failed, retrying in $((RETRY_COUNT * 30)) seconds..."
  sleep $((RETRY_COUNT * 30))
done

CI/CD Performance Monitoring

Monitor your RHACS CI/CD integration performance to identify bottlenecks:

Key Metrics to Track:

• Average scan time by image size and complexity
• Policy violation trends over time
• CI/CD pipeline failure rates due to security issues
• Scanner V4 resource utilization during peak hours

Alerting Strategy:
Set up alerts for scan failures, excessive scan times, or policy violation spikes that might indicate a security issue or misconfiguration.

These implementation patterns have been battle-tested in production environments. The final piece is understanding the most common questions and gotchas teams encounter during RHACS CI/CD integration.