ComplianceAsCode Builder
Modern containerized build environment for security compliance content
<span @click="$slidev.nav.next" class="px-2 py-1 rounded cursor-pointer" hover="bg-white bg-opacity-10"> Press Space for next slide
layout: default —
What is ComplianceAsCode?
## Overview - Security compliance as code - Defines security policies, benchmarks, and remediations - Machine-readable security content - Supports multiple standards and platforms ## Benefits - Consistent security implementation - Automated checking and remediation - Standardized benchmarks - Reduces manual security work
```yaml benchmark: id: rhel9-baseline title: RHEL 9 Security Baseline description: Security configuration for RHEL 9 version: 1.0.0 rules: - id: ensure_ssh_key_access_only title: Ensure SSH Key Authentication Only description: Disable password authentication for SSH check: | sshd_config_value PasswordAuthentication no fix: set_sshd_config PasswordAuthentication no ```
layout: section —
The Challenge
layout: default —
Building Compliance Content
The Challenges
layout: two-cols —
Security Benchmarking Reality
## Traditional Workflow 1. Set up build environment manually 2. Install dependencies (error-prone) 3. Configure certificates & networking 4. Clone multiple repositories 5. Debug build failures 6. Wait ~30-60 minutes for build 7. Troubleshoot content errors
::right::
## Common Issues - **Environment inconsistencies** "It works on my machine..." - **Dependency conflicts** Missing or incompatible packages - **Certificate problems** Corporate networks & proxies - **Architecture differences** Intel vs ARM platforms - **Onboarding friction** Days spent on environment setup
layout: statement —
Enter CAC-Builder
layout: two-cols —
CAC-Builder Solution
::right::
layout: default —
Architecture
## Components - Base Fedora container - CMake build system - Certificate management - Content repository - Build tools & dependencies - SCAP validation tooling
```mermaid graph TD A[Developer] --> B[CAC-Builder Container] B --> C[ComplianceAsCode Content] C --> D[Build Process] D --> E[XCCDF Files] D --> F[OVAL Content] D --> G[Remediation Scripts] H[GitHub Actions] --> B I[CI/CD Pipeline] --> B ```
layout: two-cols —
Multi-platform Support
## Challenge - ARM64 architecture gaining popularity - Traditional containers build for one architecture - Incompatibility between platforms - Slow emulation on the wrong architecture - Apple M-series Macs need native containers
::right::
## How We Solved It 1. QEMU emulation layer in GitHub Actions 2. Docker buildx for multi-platform builds 3. Manifest lists for platform-specific selection 4. Optimized build flags for ARM64 5. Testing across architectures ```yaml # In GitHub Actions workflow - name: Set up QEMU uses: docker/setup-qemu-action@v2 with: platforms: 'arm64,amd64' - name: Build container uses: docker/build-push-action@v4 with: platforms: linux/amd64,linux/arm64 push: true ```
layout: default —
Key Features
## Build Variants - **Full**: With pre-built content - **Minimal**: On-demand builds - Multi-platform: AMD64 + ARM64
## Certificate Management - Split cert handling for GitHub Actions - Flexible cert assembly - Internal CA support - Automatic validation
## CI/CD Integration - Automated testing - Build artifact collection - Container publishing - Version tagging
layout: default —
Container Usage
# Pull the container
docker pull ghcr.io/mitre/cac-builder:minimal
# Run with mounted output directory
docker run -it --rm -v $(pwd)/output:/output ghcr.io/mitre/cac-builder:minimal
# Build specific product
docker run -it --rm -v $(pwd)/output:/output ghcr.io/mitre/cac-builder:minimal -c "
cd /content
./build_product rhel9
cp /content/build/ssg-rhel9-* /output/
"
# Using the full container with pre-built content
docker run -it --rm -v $(pwd)/output:/output ghcr.io/mitre/cac-builder:full -c "
cp /content/build/ssg-* /output/
echo 'Content copied to output directory'
"
layout: two-cols —
With CAC-Builder
## Simplified Workflow 1. Pull the container ```bash docker pull ghcr.io/mitre/cac-builder:minimal ``` 2. Generate content ```bash docker run -v $(pwd)/output:/output \ ghcr.io/mitre/cac-builder:minimal -c \ "cd /content && ./build_product rhel9 && \ cp /content/build/ssg-rhel9-* /output/" ```
::right::
## Real-world Impact ### Before - Environment setup: 2-4 hours - First build: 30-60 minutes - Onboarding a new dev: 1-2 days - Troubleshooting env issues: 30%+ of time ### After - Environment setup: 2 minutes - First build: 5-10 minutes - Onboarding a new dev: 30 minutes - Troubleshooting env issues: <5% of time
Case Study: MITRE Security Team
"Using CAC-Builder, our team was able to develop and test custom RHEL security benchmarks in a single day, compared to the previous 3-4 day process."layout: center class: text-center —
Certificate Management
layout: two-cols —
Certificate Challenges
## The Problem - GitHub's 64KB secret size limitation - Certificate chains are often larger - Private certs can't be committed to repo - Enterprise environments with custom CAs - Build processes need certificates ```javascript // The Problem: GitHub Secrets Size Limit // 1. CA bundle is often >64KB // 2. Cannot exceed GitHub's limit // 3. Need certificate for builds ```
::right::
## Our Approach 1. **Split**: Divide certificates into parts 2. **Store**: Save parts as separate GitHub secrets 3. **Assemble**: Reconstruct at build time 4. **Validate**: Verify certificate integrity 5. **Use**: Install in container's CA store ```bash # Split certificate into manageable parts ./scripts/split-cert-for-secrets.sh \ --parts 5 ./certs/org/ca-bundle.pem ```
Each part maintains proper PEM certificate format for maximum reliability. Parts are automatically assembled at build time.
layout: default —
Certificate Solution in Detail
## Split & Store ```bash # Split large certificate for GitHub ./scripts/split-cert-for-secrets.sh \ --parts 5 ./certs/org/ca-bundle.pem # Update GitHub secrets via GitHub CLI ./scripts/update-repo-secrets.sh \ --directory ./split-certs \ --repo mitre/cac-builder ``` ## Reassemble at Build Time ```bash # Certificate assembly from parts ./scripts/assemble-certificates.sh --verify ```
## In the GitHub Workflow ```yaml - name: Create certificate file for build env: CA_BUNDLE: $ CA_BUNDLE_PART1: $ CA_BUNDLE_PART2: $ # ...more parts... run: | # Use our dedicated assembly script ./scripts/assemble-certificates.sh --verify # Show the assembled certificate info ls -la certs/org/ ```
layout: default class: text-sm —
Local GitHub Actions Testing
## Challenge - GitHub Actions workflows hard to debug - Certificate handling needs local testing - Wait time for CI feedback too long - Environment inconsistencies ## Our Solution ```bash # Test GitHub Actions locally ./scripts/test-github-actions.sh \ --workflow publish-container.yml \ --arch arm64 \ --fix-socket ```
## Key Features
- **Multiple Architectures**: Test on amd64/arm64 - **Certificate Simulation**: Test with dummy certs - **Docker Socket Handling**: Fixes common Docker issues - **MacOS Compatibility**: Works on M1/M2 Macs - **Detailed Debugging**: Step-by-step output
layout: default —
Workflow Automation
## CI/CD Pipeline - Automatic certificate assembly - Multi-platform builds via QEMU - Artifact collection and retention - Cross-platform container publishing - Automatic image visibility management
## Build Artifact Collection ```yaml - name: Save build artifacts uses: actions/upload-artifact@v3 with: name: cac-test-content path: | output/*.xml output/*.xccdf.xml output/*.ds.xml output/build-info.txt retention-days: 14 ```
The workflow generates detailed build info: - Build timestamp and environment - File listings with sizes and types - Commit information for traceability - Performance metrics
layout: default —
Real-world Developer Workflow
## Compliance Content Development with CAC-Builder
### Development 1. Mount local content directory ```bash docker run -v $(pwd):/local -it \ ghcr.io/mitre/cac-builder:minimal ``` 2. Develop & test with immediate feedback ```bash # Inside container cd /local ./build_product rhel9 ``` 3. Push changes to repository ```bash git commit -am "Add new RHEL9 rule" git push ```
### CI/CD Integration 4. GitHub Actions builds and tests ```yaml - name: Build container uses: docker/build-push-action@v4 with: platforms: linux/amd64,linux/arm64 ``` 5. Artifact collection ```yaml - name: Save build artifacts uses: actions/upload-artifact@v3 ``` 6. Testing & verification ```bash # Download and use the artifacts oscap xccdf eval ./output/ssg-rhel9-ds.xml ```
Integration with existing Security Workflows
- Security scanners consume output XML
- CI/CD pipelines trigger compliance checks
- Delta reporting between container builds
- Content development/testing separated
- Consistent testing environments
- Version-controlled security policies
layout: section —
Future Developments
layout: default —
Roadmap
## Short Term - Windows container support - Test result visualization - Enhanced validation rules - More build automation
## Medium Term - Content browsing UI - Result comparison features - Extended platform coverage - Custom policy templates
## Long Term - Integration with remediation systems - Compliance scoring dashboards - Container hardening profiles - Community content library
layout: center class: text-center —
Questions?
GitHub Repository · Documentation
layout: end —