Container Scanner Can't Authenticate to Private Registry

The most infuriating part isn't that authentication breaks - it's that the error messages are complete garbage. "Unauthorized" tells you nothing. "Access denied" could mean anything. And when Trivy just returns empty results with zero explanation? That's a special kind of hell.

I've debugged this shit across ECR (worst token expiration), Harbor (RBAC nightmare), Azure Container Registry (randomly denies access), Google Artifact Registry (service account hell), Docker Hub (works sometimes), and a dozen others. Every single one fails differently, and none of them tell you what actually went wrong.

Each Registry Is Special (And Broken Differently)

Every registry thinks it's special and needs its own authentication method. Docker Hub uses OAuth tokens that sometimes work. AWS ECR tokens expire every 12 hours because fuck your weekend on-call rotation. Harbor implements RBAC that requires a PhD to understand. Google Artifact Registry wants service account JSON keys and will randomly decide you don't have permission.

Trivy works with some registries but not others - no clear pattern. Snyk has its own weird authentication dance. Docker Scout claims to support multiple registries but really only works reliably with Docker Hub.

The Three Ways Authentication Shits The Bed

Token Expiration Is A Fucking Nightmare

AWS ECR tokens expire every 12 hours like clockwork. Harbor tokens can expire in 30 minutes if you're unlucky. Google tokens expire whenever they feel like it. Your pipeline that worked fine yesterday fails today with zero explanation.

Our entire security pipeline went dark for 3 days in November 2024 because ECR tokens expired and nobody noticed. No alerts. No obvious failures. Just empty vulnerability reports that looked fine until someone asked "why don't we have any vulnerabilities this week?" Trivy 0.48.0 was silently failing to authenticate and returning nothing instead of throwing proper errors. ECR get-login-password needs to be run every 12 hours or your shit breaks.

Permissions Are A Goddamn Minefield

Your service account can pull images but scanning needs different permissions. Harbor's RBAC will let you scan project-a/app-image but deny project-b/base-image with the same fucking credentials. Half your scans work, half fail, and the error messages tell you nothing useful.

Registry permission models are all different: AWS ECR uses IAM policies, Azure has role assignments, Google wants service account permissions, Harbor has project-based RBAC, and Docker Hub uses organization management. Each one implements a completely different access control paradigm, so your scanning service needs different permissions for each registry.

Multi-Registry Hell

is where you go to die. Your app pulls base images from Docker Hub, application images from ECR, and utility images from Harbor. Each one needs different credentials, different authentication methods, and different refresh logic. Scanning tools barely support one registry properly, let alone three.

War Stories From The Trenches

ECR Credential Rotation From Hell

Some fintech company thought rotating ECR credentials every 4 hours was a good idea for "security." Works great until your scanning job takes 6 hours to complete and the token dies halfway through. Half the scans fail with "image not found" even though you can see the images right there in the console. Kubernetes 1.28 imagePullSecrets don't help because the scanning pod started with valid creds that expired during execution.

Took 2 weeks to figure out ECR tokens were expiring mid-scan on their Jenkins 2.414.3 pipeline. The fix? Don't rotate credentials during business hours, and make scanning jobs restart if they take longer than token lifetime. Cost them $15k in consultant fees to learn what should have been common sense.

Harbor RBAC Makes No Fucking Sense

Deployed Harbor 2.8.0 with project-based access thinking it would be simple. Dev teams get access to their projects, scanning service gets read access to everything. Wrong. Harbor's RBAC needs explicit project membership for vulnerability database access, even if you have broad read permissions.

Scans work fine, pull images successfully, then report "no vulnerabilities found" because the service account can't access Trivy's vulnerability databases stored in Harbor's internal registry. Took 3 days of debugging to realize successful image pulls != successful vulnerability database access in Harbor's permission model. The HTTP 403s were buried in debug logs that nobody checks.

Air-Gapped Scanning Is Pure Pain

Government contract with air-gapped environment. Harbor mirrors sync images during maintenance windows. Scanning works for images but vulnerability databases are always stale because scanning tools try to update from internet sources they can't reach.

Nobody documented that vulnerability databases need separate credentials from image registries. Scanning succeeds but with 6-month-old vulnerability data, making the whole exercise pointless.

Why Teams Just Turn Off Scanning

When authentication breaks for the third time this month, the easiest solution is to just disable scanning. "We'll fix it later" becomes "we'll fix it never." DORA metrics don't track time wasted debugging bullshit authentication, but it's easily 4-6 hours per incident.

Half the companies I've worked with have scanning disabled in at least one environment because "it doesn't work reliably." Authentication failures create security blind spots that persist for months because fixing registry auth is harder than explaining why scanning is turned off.

NIST container guidelines require continuous vulnerability scanning, but good luck with compliance when your scanning randomly fails due to expired tokens.

Multi-Cloud Makes Everything Worse

Multi-Cloud Is Authentication Hell Squared

You've got AWS ECR for production, Google Artifact Registry for CI/CD, and Azure Container Registry for development. Each one has different authentication, different token formats, and different ways to fail.

Cross-cloud scanning requires managing three different credential systems, three different refresh mechanisms, and three different sets of permissions. Most scanning tools support one cloud provider well and everything else poorly.

Kubernetes Makes It Worse

imagePullSecrets work fine for pods inside the cluster, but your scanning tools running outside can't access them. So you need separate credentials for the same registries.

Service mesh authentication and mTLS add more layers that break scanning tools in creative ways. Nobody tests this shit together.

The OCI keeps promising standardized authentication, but everyone implements their own proprietary bullshit that breaks compatibility.

Bottom line: registry authentication fails silently, creating security blind spots that nobody notices until an audit. Understanding why it breaks is the first step to fixing it before your compliance team finds out.

Enough complaining about what's broken - here's how to actually fix the authentication disasters we just covered. Registry authentication failures require systematic diagnosis and targeted fixes. Unlike timeout errors that are obvious, authentication failures often masquerade as other problems: images "not found," empty scan results, or cryptic authorization errors that point to nothing useful.

The key is methodical troubleshooting instead of randomly trying fixes until something works.

Diagnosing Registry Authentication Issues

Step 1: Verify Basic Registry Access

Before blaming your scanning tool, confirm that you can actually reach and authenticate with your registry manually. This eliminates network, DNS, and basic authentication issues:

## Test Docker Hub access (should work without authentication for public images)
docker pull hello-world

## Test ECR access with temporary token
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com

## Test Harbor access
docker login your-harbor.company.com -u username

## Test Google Container Registry
echo $GCR_SERVICE_ACCOUNT_KEY | docker login -u _json_key --password-stdin gcr.io

## Verify you can pull a specific image
docker pull your-registry.com/namespace/image:tag

If these basic tests fail, you have network or credential issues, not scanning tool problems. Fix the underlying authentication before proceeding.

Step 2: Test Scanner-Specific Registry Access

Each scanning tool has different authentication mechanisms and registry support. Test your specific scanner's ability to access your registry:

## Trivy registry authentication test
trivy image --username $REGISTRY_USER --password $REGISTRY_PASSWORD your-registry.com/image:tag

## Grype registry authentication test
grype --username $REGISTRY_USER --password $REGISTRY_PASSWORD your-registry.com/image:tag

## Snyk authentication test (uses separate login)
snyk container test your-registry.com/image:tag

Most scanning tools support Docker credential helpers, which can simplify authentication. Additional authentication mechanisms include OCI registry authentication, Kubernetes service account tokens, AWS IAM roles for service accounts, Google Workload Identity, Azure Managed Identity, Harbor Robot Accounts, GitLab Deploy Tokens, GitHub Personal Access Tokens, Docker Hub Access Tokens, and JFrog Access Tokens:

## Use Docker credential helper for AWS ECR
echo '{"credsStore": "ecr-login"}' > ~/.docker/config.json

## Use credential helper for Google Cloud
gcloud auth configure-docker

## Use credential helper for Azure
az acr login --name myregistry

Fixing AWS ECR Authentication Issues

AWS ECR authentication failures are epidemic because ECR tokens expire every 12 hours and most teams don't implement proper token refresh logic.

Fix ECR Token Expiration:

## Get a fresh ECR token (expires in 12 hours)
TOKEN=$(aws ecr get-login-password --region us-east-1)

## Configure Trivy with ECR credentials
export TRIVY_USERNAME=AWS
export TRIVY_PASSWORD=$TOKEN

## Or use ECR credential helper (recommended)
docker-credential-ecr-login configure-docker

For CI/CD pipelines, implement automated token refresh:

## GitHub Actions ECR authentication
- name: Configure AWS ECR credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: ${{ secrets.AWS_ROLE }}
    aws-region: us-east-1

- name: Login to ECR
  uses: aws-actions/amazon-ecr-login@v2

- name: Scan with fresh ECR credentials
  run: trivy image $ECR_REGISTRY/my-app:$GITHUB_SHA

Fix ECR Cross-Account Access Issues:

ECR cross-account scanning requires proper IAM policies on both the source account (where images are stored) and target account (where scanning occurs):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountScanning",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::SCANNING-ACCOUNT:root"
      },
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:DescribeRepositories",
        "ecr:ListImages",
        "ecr:DescribeImages",
        "ecr:BatchCheckLayerAvailability"
      ]
    }
  ]
}

Apply this policy to your ECR repository to allow cross-account scanning access.

Fixing Harbor Registry Authentication

Harbor authentication failures usually stem from RBAC complexity and project-based permission models that scanning tools don't understand.

Fix Harbor RBAC Issues:

## Create a dedicated scanning service account
## Via Harbor UI: Administration > Users > +USER
## Username: security-scanner
## Email: scanner@company.com
## Password: generate-strong-password

## Grant system-level scanning permissions
## Via Harbor UI: Administration > Users > security-scanner > Edit
## Check: "System Admin" or create custom role with scanning permissions

For project-specific access, create a scanning robot account with cross-project permissions:

## Via Harbor UI: Projects > Your-Project > Robot Accounts > +ROBOT ACCOUNT
## Name: scanning-robot
## Permissions: Pull, Push (for caching scan results)
## Expiration: Never (or set appropriate lifecycle)

Test Harbor authentication:

## Test with harbor robot account
docker login harbor.company.com -u 'robot$scanning-robot' -p 'robot-token-here'

## Test Trivy with Harbor
trivy image --username 'robot$scanning-robot' --password 'robot-token' harbor.company.com/project/image:tag

Fix Harbor SSL/TLS Issues:

Self-signed certificates or custom CA chains break scanner authentication:

## Add Harbor's CA certificate to system trust store
sudo cp harbor-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

## Or configure Trivy to skip TLS verification (NOT recommended for production)
trivy image --insecure harbor.company.com/project/image:tag

## Configure custom CA for Docker daemon
sudo mkdir -p /etc/docker/certs.d/harbor.company.com
sudo cp harbor-ca.crt /etc/docker/certs.d/harbor.company.com/

Fixing Air-Gapped Registry Access

Air-gapped environments create unique authentication challenges because scanning tools can't reach external vulnerability databases while accessing internal registries.

Setup Air-Gapped Registry Mirror:

## Configure Harbor as a registry proxy for air-gapped scanning
## Harbor UI: Administration > Registries > +REGISTRY
## Provider: Docker Registry
## Name: docker-hub-proxy
## Endpoint URL: https://index.docker.io
## Access ID: your-dockerhub-username
## Access Secret: your-dockerhub-token

## Create proxy project
## Projects > +PROJECT
## Project Name: dockerhub-proxy
## Check: "As Proxy Cache"
## Registry: docker-hub-proxy

Configure scanning tools for air-gapped operation:

## Trivy air-gapped configuration
export TRIVY_OFFLINE_SCAN=true
export TRIVY_INSECURE=true  # if using self-signed certs

## Pre-download vulnerability database for offline scanning
trivy image --download-db-only --db-repository harbor.internal.com/security/trivy-db

## Scan using local database
trivy image --offline-scan harbor.internal.com/project/image:tag

Fixing Multi-Registry Authentication

Modern applications span multiple registries, requiring complex authentication coordination.

Configure Multi-Registry Authentication:

## Docker config supporting multiple registries
cat > ~/.docker/config.json << EOF
{
  "auths": {
    "harbor.company.com": {
      "auth": "$(echo -n 'robot$scanner:token' | base64)"
    },
    "123456789012.dkr.ecr.us-east-1.amazonaws.com": {
      "auth": "$(echo -n 'AWS:ecr-token' | base64)"
    },
    "gcr.io": {
      "auth": "$(echo -n '_json_key:json-key-content' | base64)"
    }
  },
  "credHelpers": {
    "123456789012.dkr.ecr.us-east-1.amazonaws.com": "ecr-login",
    "gcr.io": "gcloud"
  }
}
EOF

Kubernetes Image Pull Secrets for Scanning:

## Create registry authentication secrets
apiVersion: v1
kind: Secret
metadata:
  name: multi-registry-auth
  namespace: security-scanning
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: base64-encoded-docker-config

---
## Security scanning pod with registry access
apiVersion: v1
kind: Pod
metadata:
  name: security-scanner
  namespace: security-scanning
spec:
  imagePullSecrets:
  - name: multi-registry-auth
  containers:
  - name: trivy-scanner
    image: aquasec/trivy:latest
    volumeMounts:
    - name: registry-config
      mountPath: /root/.docker/config.json
      subPath: config.json
  volumes:
  - name: registry-config
    secret:
      secretName: multi-registry-auth
      items:
      - key: .dockerconfigjson
        path: config.json

Implementing Robust Authentication Monitoring

Authentication failures often go undetected because they fail silently. Implement monitoring to catch authentication issues before they break your security posture:

## Prometheus metrics for registry authentication (configure your metrics endpoint)
## Example: curl -s ${PROMETHEUS_URL}/metrics | grep registry_auth_failures_total

## CloudWatch metrics for ECR authentication
aws logs create-log-group --log-group-name /security/scanning/auth-failures

## Custom monitoring script
#!/bin/bash
for registry in harbor.company.com 123456789012.dkr.ecr.us-east-1.amazonaws.com; do
  if ! docker login $registry; then
    echo "ALERT: Registry authentication failed for $registry" | tee -a /var/log/registry-auth.log
    # Send alert to monitoring system
  fi
done

Registry authentication is solvable but requires systematic approach. Start with basic connectivity testing, then work through scanner-specific authentication mechanisms. Implement robust monitoring and automated credential refresh to prevent future failures.

The key is treating registry authentication as infrastructure that requires active maintenance, not configuration you set once and forget. Token rotation, permission changes, and infrastructure updates will break authentication - plan for it and build resilient systems that recover automatically.

Now that you've fixed the immediate authentication disasters, let's talk about preventing them from happening again. Constantly firefighting registry auth issues is a waste of time and creates security gaps.

Registry authentication failures are preventable with proper architecture and operational practices. Rather than reactively fixing authentication issues, implement systems that prevent them from occurring and recover automatically when they do.

Authentication Architecture for Container Scanning

Centralized Credential Management eliminates the authentication sprawl that creates most registry access failures. Instead of hardcoding credentials in CI/CD pipelines, scanning tools, and deployment scripts, implement a centralized authentication service that provides temporary, scoped credentials on demand.

## HashiCorp Vault registry authentication
vault write database/config/registry-auth \
  plugin_name=vault-plugin-database-registry \
  connection_url=\"harbor.company.com\" \
  allowed_roles=\"scanning-service\"

## Generate temporary registry credentials
vault read -format=json database/creds/scanning-service | jq -r '.data.password'

AWS IAM roles for service accounts (IRSA) provides native integration for ECR authentication without embedding credentials:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: security-scanner
  namespace: security-scanning
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/SecurityScannerRole

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: trivy-scanner
spec:
  template:
    spec:
      serviceAccountName: security-scanner
      containers:
      - name: trivy
        image: aquasec/trivy:latest
        env:
        - name: AWS_REGION
          value: us-east-1

Multi-Registry Authentication Orchestration handles the complexity of scanning images across multiple registries with different authentication mechanisms. Implement an authentication broker that abstracts registry-specific authentication details from scanning tools.

## Registry authentication broker pseudocode
class RegistryAuthBroker:
    def get_credentials(self, registry_url, image_name):
        if 'ecr' in registry_url:
            return self._get_ecr_credentials(registry_url)
        elif 'harbor' in registry_url:
            return self._get_harbor_credentials(registry_url, image_name)
        elif 'gcr.io' in registry_url:
            return self._get_gcr_credentials()
        
    def _get_ecr_credentials(self, registry_url):
        # AWS ECR token refresh logic
        token = boto3.client('ecr').get_authorization_token()
        return {'username': 'AWS', 'password': token}

Automated Credential Lifecycle Management

Token Refresh Automation prevents the ECR 12-hour expiration problem that breaks most scanning pipelines. Implement proactive token refresh that updates credentials before they expire, not after scanning fails.

## ECR credential refresh service
#!/bin/bash
REFRESH_INTERVAL=10800  # 3 hours (before 12-hour expiration)

while true; do
    # Get fresh ECR token
    NEW_TOKEN=$(aws ecr get-login-password --region us-east-1)
    
    # Update scanning service credentials
    kubectl create secret docker-registry ecr-credentials \
        --docker-server=123456789012.dkr.ecr.us-east-1.amazonaws.com \
        --docker-username=AWS \
        --docker-password=$NEW_TOKEN \
        --dry-run=client -o yaml | kubectl apply -f -
    
    # Restart scanning pods to pick up new credentials
    kubectl rollout restart deployment/security-scanner -n security-scanning
    
    sleep $REFRESH_INTERVAL
done

Certificate Rotation Handling prevents SSL/TLS authentication failures when certificates expire or change. Implement automated certificate management that updates scanning tools when registry certificates change.

## Cert-manager for automated certificate management
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: harbor-tls
  namespace: security-scanning
spec:
  secretName: harbor-tls-secret
  issuer:
    name: company-ca-issuer
  dnsNames:
  - harbor.company.com
  usages:
  - digital signature
  - key encipherment
  - client auth

Registry Access Monitoring and Alerting

Proactive Authentication Monitoring detects credential expiration, permission changes, and registry connectivity issues before they break scanning. Monitor authentication success rates, token expiration times, and registry response times.

## Prometheus monitoring for registry authentication
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: registry-auth-monitor
spec:
  selector:
    matchLabels:
      app: security-scanner
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

---
## Alert on authentication failures
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: registry-auth-alerts
spec:
  groups:
  - name: registry.authentication
    rules:
    - alert: RegistryAuthFailureRate
      expr: rate(registry_auth_failures_total[5m]) > 0.1
      for: 2m
      labels:
        severity: critical
      annotations:
        summary: \"High registry authentication failure rate\"
        description: \"Registry authentication failing at {{ $value }} failures per second\"
        
    - alert: ECRTokenExpiration
      expr: ecr_token_expiry_timestamp - time() < 3600
      for: 0m
      labels:
        severity: warning
      annotations:
        summary: \"ECR token expiring within 1 hour\"
        description: \"ECR token for {{ $labels.registry }} expires at {{ $value }}\"

Authentication Health Checks continuously validate registry access to catch permission changes, network issues, and service outages before they affect scanning:

## Registry health check script
#!/bin/bash
REGISTRIES=(
    \"harbor.company.com\"
    \"123456789012.dkr.ecr.us-east-1.amazonaws.com\"
    \"gcr.io/company-project\"
)

for registry in \"${REGISTRIES[@]}\"; do
    if timeout 30 docker login $registry; then
        echo \"✅ $registry authentication successful\"
        # Test actual image pull
        if timeout 60 docker pull $registry/test-image:health-check; then
            echo \"✅ $registry image pull successful\"
        else
            echo \"❌ $registry image pull failed\"
            # Send alert
        fi
    else
        echo \"❌ $registry authentication failed\"
        # Send alert
    fi
done

Air-Gapped Environment Best Practices

Offline Registry Mirroring eliminates external dependencies that break air-gapped scanning. Implement systematic registry mirroring that keeps vulnerability databases and scanning tools current without internet access.

## Harbor replication policy for vulnerability databases
apiVersion: goharbor.io/v1beta1
kind: ReplicationPolicy
metadata:
  name: vuln-db-mirror
spec:
  src_registry:
    url: ghcr.io
    auth_type: basic
    username: github-token
    password: github-pat-token
  dest_registry:
    url: harbor.internal.company.com
    auth_type: basic
    username: admin
    password: harbor-password
  policy:
    filters:
    - type: name
      value: \"aquasecurity/trivy-db:**\"
    - type: name  
      value: \"anchore/grype:**\"
  trigger:
    type: scheduled
    schedule_param:
      type: daily
      weekday: 1-7
      offtime: 23400

Automated Offline Database Updates keep vulnerability databases current in air-gapped environments through systematic synchronization processes:

## Offline vulnerability database update process
#!/bin/bash
ONLINE_ENV=\"secure-bastion.company.com\"
AIRGAP_ENV=\"harbor.internal.company.com\"

## Stage 1: Download on internet-connected system
ssh $ONLINE_ENV << 'EOF'
  # Download latest vulnerability databases
  docker pull ghcr.io/aquasecurity/trivy-db:2
  docker pull anchore/grype:latest
  
  # Save as transferable archives
  docker save ghcr.io/aquasecurity/trivy-db:2 | gzip > trivy-db-$(date +%Y%m%d).tar.gz
  docker save anchore/grype:latest | gzip > grype-$(date +%Y%m%d).tar.gz
EOF

## Stage 2: Transfer to air-gapped environment
scp $ONLINE_ENV:/tmp/*-$(date +%Y%m%d).tar.gz /transfer/

## Stage 3: Load in air-gapped environment  
ssh $AIRGAP_ENV << 'EOF'
  # Load vulnerability databases
  docker load < trivy-db-$(date +%Y%m%d).tar.gz
  docker load < grype-$(date +%Y%m%d).tar.gz
  
  # Tag for internal registry
  docker tag ghcr.io/aquasecurity/trivy-db:2 harbor.internal.company.com/security/trivy-db:latest
  docker tag anchore/grype:latest harbor.internal.company.com/security/grype:latest
  
  # Push to internal registry
  docker push harbor.internal.company.com/security/trivy-db:latest
  docker push harbor.internal.company.com/security/grype:latest
EOF

Enterprise-Scale Authentication Management

Registry Authentication as Code treats authentication configuration as infrastructure, version-controlled and deployable through CI/CD pipelines. This prevents configuration drift and enables consistent authentication across environments.

## Terraform configuration for registry authentication
resource \"kubernetes_secret\" \"registry_auth\" {
  for_each = var.registries

  metadata {
    name      = \"${each.key}-registry-auth\"
    namespace = \"security-scanning\"
  }

  type = \"kubernetes.io/dockerconfigjson\"

  data = {
    \".dockerconfigjson\" = jsonencode({
      auths = {
        each.value.url = {
          username = each.value.username
          password = each.value.password
          auth     = base64encode(\"${each.value.username}:${each.value.password}\")
        }
      }
    })
  }
}

## Variables for different environments
variable \"registries\" {
  type = map(object({
    url      = string
    username = string
    password = string
  }))
  
  default = {
    production = {
      url      = \"harbor.prod.company.com\"
      username = \"robot$prod-scanner\"
      password = var.harbor_prod_token
    }
    staging = {
      url      = \"harbor.staging.company.com\" 
      username = \"robot$staging-scanner\"
      password = var.harbor_staging_token
    }
  }
}

Authentication Audit and Compliance ensures registry access meets security and compliance requirements through automated auditing and reporting:

## Registry authentication audit script
#!/bin/bash
AUDIT_LOG=\"/var/log/registry-auth-audit.log\"

echo \"=== Registry Authentication Audit $(date) ===\" >> $AUDIT_LOG

## Check credential strength
for secret in $(kubectl get secrets -n security-scanning -o name | grep registry); do
    echo \"Auditing $secret\" >> $AUDIT_LOG
    
    # Extract and decode credentials
    kubectl get $secret -o jsonpath='{.data.\\.dockerconfigjson}' | base64 -d | jq -r '.auths | to_entries[] | .key + \" \" + .value.username'
    
    # Check for weak passwords, expired tokens, etc.
done

## Check for over-privileged access
echo \"Checking registry permissions...\" >> $AUDIT_LOG
## Implementation depends on registry type

The long-term solution to registry authentication failures is treating authentication as critical infrastructure that requires active management, monitoring, and automation. Implement centralized credential management, automated token refresh, proactive monitoring, and systematic air-gapped synchronization.

Most importantly, design authentication systems to fail safely and recover automatically. When credentials expire or registries become unavailable, scanning should degrade gracefully with clear error messages and automated recovery procedures, not fail silently with empty results.