HACKADEMICS

Cloud Security Posture Analysis with OpenSCAP

Feb 22, 2026 6 min read

Your compliance checklist says you're securing cloud workloads, but OpenSCAP was built for physical servers in 2009. That doesn't mean it's useless for cloud environments—just that you need to understand what it actually checks, what it misses, and why your "100% compliant" scan results might be lying to you.

What OpenSCAP Actually Does

OpenSCAP is the open-source implementation of SCAP (Security Content Automation Protocol), a NIST framework for security automation. It runs standardized security checks against systems and compares them to compliance baselines like CIS Benchmarks, DISA STIGs, and PCI-DSS requirements.

The good: it's programmatic, repeatable, and maps to actual compliance frameworks auditors recognize.

The bad: it was designed for traditional infrastructure—physical servers and long-lived VMs. Cloud-native architectures with ephemeral containers, auto-scaling groups, and API-driven configuration don't fit this model cleanly.

The ugly: most teams run OpenSCAP scans, generate reports nobody reads, and think they're "doing security." You're not. You're doing compliance theater.

Let's fix that by using OpenSCAP for what it's actually good at: validating OS-level security configurations on cloud compute instances.

Why Cloud Teams Need OS-Level Hardening

Cloud providers give you pre-configured base images. Amazon Linux 2, Ubuntu Cloud Images, Azure's marketplace offerings—they're better than rolling your own, but they're still generic. They ship with:

  • SSH configurations that might not match your threat model
  • Filesystem permissions optimized for compatibility, not security
  • Logging configurations that don't meet compliance requirements
  • Network services you don't need but attackers do

OpenSCAP validates that your instances match security baselines after deployment. That matters because:

  1. Your infrastructure-as-code might not implement every CIS control
  2. Config drift happens when someone makes "temporary" changes
  3. Auditors want proof you're following published standards
  4. You need to catch misconfigurations before attackers do

The Setup: Installing OpenSCAP on Cloud Instances

AWS EC2 (Amazon Linux 2)

# Install OpenSCAP scanner and security content
sudo yum install -y openscap-scanner scap-security-guide

# Verify installation
oscap --version

The scap-security-guide package includes pre-built security profiles for common compliance frameworks. List what's available:

oscap info /usr/share/xml/scap/ssg/content/ssg-amzn2-ds.xml

You'll see profiles like:

  • CIS Amazon Linux 2 Benchmark Level 1 (Server)
  • CIS Amazon Linux 2 Benchmark Level 2 (Server)
  • DISA STIG for Amazon Linux 2

Azure VMs (Ubuntu)

# Update and install OpenSCAP
sudo apt update
sudo apt install -y libopenscap8 ssg-base ssg-debderived

# Check available profiles
oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2004-ds.xml

GCP Compute Engine (CentOS/RHEL)

# Install via yum
sudo yum install -y openscap-scanner scap-security-guide

# List profiles
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

Running Your First Scan

Let's scan an EC2 instance against the CIS Level 1 Server profile:

sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --results /tmp/scan-results.xml \
  --report /tmp/scan-report.html \
  /usr/share/xml/scap/ssg/content/ssg-amzn2-ds.xml

This produces two outputs:

  • scan-results.xml: Machine-readable results for automation
  • scan-report.html: Human-readable report with pass/fail details

The scan checks hundreds of controls. Common failures on fresh cloud instances:

File Permissions

  • /etc/shadow not set to 0000 permissions
  • World-readable config files in /etc

SSH Hardening

  • Password authentication enabled (should use keys only)
  • Weak ciphers and MACs allowed
  • PermitRootLogin not disabled

Audit Configuration

  • Auditd not logging privileged command execution
  • No file integrity monitoring configured

Network Services

  • Unnecessary services running (rpcbind, cups)
  • IPv6 enabled when not needed

None of these are "critical vulnerabilities" in the CVE sense. They're configuration weaknesses that expand your attack surface and violate compliance requirements.

Automating Scans with Systems Manager

Scanning individual instances doesn't scale. Use AWS Systems Manager to scan your entire fleet:

{
  "schemaVersion": "2.2",
  "description": "Run OpenSCAP compliance scan",
  "parameters": {
    "Profile": {
      "type": "String",
      "description": "SCAP profile to evaluate",
      "default": "xccdf_org.ssgproject.content_profile_cis_server_l1"
    },
    "OutputBucket": {
      "type": "String",
      "description": "S3 bucket for results"
    }
  },
  "mainSteps": [
    {
      "action": "aws:runShellScript",
      "name": "runOpenSCAP",
      "inputs": {
        "runCommand": [
          "#!/bin/bash",
          "yum install -y openscap-scanner scap-security-guide aws-cli",
          "oscap xccdf eval --profile {{ Profile }} --results /tmp/results.xml --report /tmp/report.html /usr/share/xml/scap/ssg/content/ssg-amzn2-ds.xml",
          "INSTANCE_ID=$(ec2-metadata --instance-id | cut -d ' ' -f 2)",
          "TIMESTAMP=$(date +%Y%m%d-%H%M%S)",
          "aws s3 cp /tmp/report.html s3://{{ OutputBucket }}/openscap/-.html",
          "aws s3 cp /tmp/results.xml s3://{{ OutputBucket }}/openscap/-.xml"
        ]
      }
    }
  ]
}

Run across tagged instances:

aws ssm send-command \
  --document-name "OpenSCAP-Scan" \
  --targets "Key=tag:Environment,Values=production" \
  --parameters "Profile=xccdf_org.ssgproject.content_profile_cis_server_l1,OutputBucket=my-compliance-bucket"

Results get stored in S3. Parse the XML with a Lambda function to track compliance trends and alert on regressions.

Understanding What OpenSCAP Misses

Here's where cloud reality diverges from what OpenSCAP checks.

Cloud-Native Services

OpenSCAP doesn't evaluate:

  • S3 bucket policies (use AWS Config rules)
  • IAM role configurations (use IAM Access Analyzer)
  • Security group rules (use VPC flow logs + custom checks)
  • CloudTrail logging status (use AWS Config)
  • KMS key rotation policies (use custom Lambda checks)

These are critical security controls, but they live outside the OS. You need cloud-native tools to assess them.

Container Security

Running OpenSCAP against container hosts checks the host OS, not the containers themselves. For container security:

# Scan a Docker image (limited CVE checking)
sudo oscap-docker image-cve ubuntu:20.04 --report /tmp/container-report.html

# For runtime security, use tools designed for containers
# - Falco for runtime threat detection
# - kube-bench for Kubernetes CIS benchmarks
# - Trivy or Grype for image vulnerability scanning

Ephemeral Infrastructure

Auto-scaling groups launch and terminate instances constantly. By the time you scan an instance and generate a report, it might be gone. Solutions:

  1. Bake compliance into AMIs: Scan during image build, not runtime
  2. Continuous compliance: Scan on boot with cloud-init, fail deployment if critical controls fail
  3. Drift detection: Scan periodically and alert on changes from baseline

Baking Hardening into AMIs with Packer

Rather than remediating running instances, build hardened base images:

# packer-hardened-ami.pkr.hcl
source "amazon-ebs" "hardened" {
  ami_name      = "hardened-amazon-linux-2-{{timestamp}}"
  instance_type = "t3.micro"
  region        = "us-east-1"
  source_ami_filter {
    filters = {
      name                = "amzn2-ami-hvm-*-x86_64-gp2"
      root-device-type    = "ebs"
      virtualization-type = "hvm"
    }
    most_recent = true
    owners      = ["amazon"]
  }
  ssh_username = "ec2-user"
}

build {
  sources = ["source.amazon-ebs.hardened"]

  provisioner "shell" {
    inline = [
      "sudo yum update -y",
      "sudo yum install -y openscap-scanner scap-security-guide"
    ]
  }

  # Apply hardening via shell script
  provisioner "shell" {
    script = "scripts/harden-os.sh"
  }

  # Validate with OpenSCAP scan
  provisioner "shell" {
    inline = [
      "sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_server_l1 --results /tmp/validation.xml /usr/share/xml/scap/ssg/content/ssg-amzn2-ds.xml || true",
      "FAILURES=$(sudo xmllint --xpath 'count(//rule-result[@result=\"fail\" and @severity=\"high\"])' /tmp/validation.xml)",
      "if [ \"$FAILURES\" -gt 0 ]; then echo \"Build failed: $FAILURES high-severity failures\"; exit 1; fi"
    ]
  }
}

The build fails if critical controls don't pass. This prevents deploying non-compliant images.

Remediation: Proceed with Caution

OpenSCAP can automatically remediate failures:

sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --remediate \
  /usr/share/xml/scap/ssg/content/ssg-amzn2-ds.xml

Don't run this on production systems without testing. I've seen automated remediation:

  • Disable SSH entirely because both password and key auth were enabled
  • Set permissions so restrictive that applications couldn't read config files
  • Enable SELinux enforcing mode on systems where apps weren't labeled

Test in dev, review the remediation bash scripts OpenSCAP generates, and apply selectively.

Integrating into CI/CD Pipelines

Scan AMIs as part of your build pipeline:

# GitHub Actions example
name: AMI Security Scan
on:
  push:
    paths:
      - 'packer/**'

jobs:
  scan-ami:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Build AMI
        run: packer build packer/hardened-ami.pkr.hcl
        env:
          AWS_ACCESS_KEY_ID: }
          AWS_SECRET_ACCESS_KEY: }
      
      - name: Launch test instance
        run: |
          AMI_ID=$(aws ec2 describe-images --owners self --filters "Name=name,Values=hardened-*" --query 'Images[0].ImageId' --output text)
          INSTANCE_ID=$(aws ec2 run-instances --image-id $AMI_ID --instance-type t3.micro --query 'Instances[0].InstanceId' --output text)
          echo "INSTANCE_ID=$INSTANCE_ID" >> $GITHUB_ENV
          
      - name: Wait for instance
        run: aws ec2 wait instance-running --instance-ids }
        
      - name: Run OpenSCAP scan via SSM
        run: |
          aws ssm send-command \
            --instance-ids } \
            --document-name "OpenSCAP-Scan" \
            --parameters "OutputBucket=compliance-artifacts"
            
      - name: Parse results and fail on critical issues
        run: python scripts/validate-scap-results.py --fail-on-high

This gates deployments on compliance checks. Non-compliant AMIs don't make it to production.

The Tools OpenSCAP Doesn't Replace

Be clear about what you still need:

Cloud Configuration Assessment: Use cloud-native tools like Prowler (AWS), Azure Security Center, or Google Cloud Security Command Center.

Container Security: Use Trivy, Grype, or Anchore for image scanning; Falco or Sysdig for runtime security.

Network Security: VPC Flow Logs, CloudWatch metrics, and SIEM correlation for traffic analysis.

Application Security: SAST/DAST tools for code vulnerabilities, not OS configuration.

Supply Chain Security: Tools like in-toto or SLSA frameworks for build pipeline integrity.

OpenSCAP validates OS-level security. That's important, but it's one layer in a defense-in-depth strategy.

The Bottom Line

OpenSCAP is useful for what it was designed for: validating OS configurations against published security baselines. That matters in cloud environments because:

  1. Base images aren't hardened by default
  2. Compliance frameworks still reference OS-level controls
  3. You need programmatic validation at scale

But it doesn't assess cloud services, container security, or application vulnerabilities. Use it as part of a broader security program, not as your only compliance tool.

Bake hardening into your base images, validate with OpenSCAP during builds, and scan periodically for drift. Parse results programmatically and fail deployments on critical issues.

And remember: passing a compliance scan doesn't mean you're secure. It means you met a baseline. The attackers looking for your SSH keys in GitHub or your public S3 buckets won't care about your CIS benchmark score.

azure docker kubernetes python typescript