RAMPART — Evaluation Engine

RAMPART is the evaluation engine that runs on every push to a connected repository. It executes 9 compliance gates in sequence, produces a gate result for each, and emits findings for any failures. Every evaluation is cryptographically signed by CHRONICLE and anchored to the Rekor transparency log.

The 9 Gates

These gates are the authoritative list derived from the RAMPART gate registry. Gate IDs match the PostgreSQL GateName enum.

Source: NIST SP 800-53 Rev 5 (opens in a new tab)

Gate Decisions

Each gate returns one of four decisions:

Gate Detail

IMAGE_DIGEST — Image digest pinning

Checks that every container image reference in the repository is pinned to a SHA-256 digest rather than a mutable tag (such as :latest). Mutable tags allow the image to change between build and deployment without detection.

Fail condition: Any FROM statement or image: reference uses a tag without a digest.

NIST mapping: CM-7 (configuration management — least functionality), SI-7 (software integrity).

VULNERABILITY — Vulnerability scan

Runs Grype against the repository to detect known CVEs in dependencies. FAIL for CRITICAL severity CVEs with available fixes. WARN for CRITICAL CVEs without available fixes.

Threshold: CRITICAL CVEs with a fixed version available cause FAIL. All others are surfaced as findings.

NIST mapping: SI-2 (flaw remediation), RA-5 (vulnerability monitoring and scanning).

SBOM_ATTESTATION — SBOM attestation

Verifies that a CycloneDX Software Bill of Materials is attached to the deployment as a Cosign attestation. Without an SBOM, supply chain risk cannot be assessed.

Fail condition: No SBOM attestation is attached or the attached SBOM has zero components.

NIST mapping: SA-10 (developer configuration management), SR-4 (provenance).

STIG_BASELINE — STIG baseline

Checks OpenSCAP XCCDF results against the applicable DISA STIG baseline for the operating system or container image. Required for DoD IL programs and recommended for FedRAMP High.

NIST mapping: CM-6 (configuration settings), CM-7 (least functionality).

BRANCH_POLICY — Branch policy

Verifies that the repository enforces branch protection: required reviewers, no direct pushes to main/production branches, and a CODEOWNERS file for accountability.

NIST mapping: CM-3 (configuration change control), CM-5 (access restrictions for change).

CHANGE_CONTROL — Change control (CAB)

For production deployments, verifies that a Change Request exists and has been approved by the Change Advisory Board before the change proceeds. Integrates with the CCB engine.

NIST mapping: CM-3 (configuration change control), CM-11 (user-installed software).

SECRETS_SCAN — Secrets scan

Scans the repository for credentials, API keys, tokens, and other secrets committed to source control. Uses Gitleaks for pattern detection and Trufflehog for verified secret detection.

Fail condition: Verified secrets in source. WARN for high-confidence patterns that cannot be confirmed.

NIST mapping: IA-5 (authenticator management), SC-28 (protection of information at rest).

IAC_COMPLIANCE — IaC compliance

Runs Checkov and Trivy against all Infrastructure-as-Code files (Terraform, CloudFormation, Kubernetes manifests, Dockerfiles, Helm charts) to detect misconfigurations.

Tools: Checkov (154+ checks mapped to NIST controls), Trivy (filesystem + configuration mode).

NIST mapping: CM-6 (configuration settings), SC-7 (boundary protection).

SLSA_PROVENANCE — SLSA provenance

Verifies that a SLSA provenance attestation is present and signed. SLSA (Supply chain Levels for Software Artifacts) Level 1 minimum required; Level 2+ recommended for FedRAMP High and DoD programs.

NIST mapping: SA-10 (developer configuration management), SR-3 (supply chain controls and plans).

Source: Sigstore / Cosign (opens in a new tab), Rekor (opens in a new tab)

Evaluation Workflow

Push event received
      │
      ▼
Normalize event (extract commit SHA, branch, repo metadata)
      │
      ▼
Run 9 gates in sequence
  Gate 1: IMAGE_DIGEST
  Gate 2: VULNERABILITY
  ...
  Gate 9: SLSA_PROVENANCE
      │
      ▼
Aggregate gate results
      │
      ▼
Create findings for all FAIL / BLOCK / WARN results
      │
      ▼
Update compliance posture score
      │
      ▼
Sign evaluation with CHRONICLE (Cosign + Rekor)
      │
      ▼
Emit NATS events → AXIOM (control mapping) + PHAROS (monitoring)

Connecting a Repository

See the GitHub Integration guide for step-by-step connection instructions.

RAMPART evaluates on:

• Push events to any branch
• Pull request open/synchronize events
• Manual evaluation trigger from the dashboard

Finding severity matrix

When a gate returns FAIL or BLOCK, RAMPART creates a finding with a severity level based on the specific violation:

Gate-to-framework mapping

Each gate maps to one or more compliance frameworks. This table shows which gates are required for each program type:

Interpreting Results

All gates PASS: Evaluation is green. No new findings.

Any gate WARN: A gate could not run. Review the evidence requirement for that gate. WARN is not a pass.

Any gate FAIL: Findings created. Review severity and NIST control mapping.

Any gate BLOCK: Deployment is blocked. The finding must be remediated or accepted with an approved waiver before deployment can proceed.

What to do with findings

CRITICAL or HIGH findings: These require action before the next evaluation can produce a green result. Options:

1. Remediate: Use the ARE to autonomously generate and verify a fix, or fix manually and push
2. Accept risk: Submit an accepted risk attestation through the PHAROS waiver portal — requires ISSM or CISO approval
3. Defer: Schedule a POA&M milestone for a future remediation date — accepted for non-BLOCK findings

WARN findings: Investigate why the gate could not run. Common causes:

• SBOM_ATTESTATION warns because no SBOM is attached to the build — add Cosign SBOM attestation to your CI pipeline
• SLSA_PROVENANCE warns because no provenance attestation exists — add SLSA provenance generation to your build
• STIG_BASELINE warns because no OpenSCAP report is attached — STIG scan results must be submitted separately

BLOCK findings: No deployment is permitted until the finding is resolved. BLOCK findings cannot be deferred — they must be remediated or accepted through formal waiver. Waivers for BLOCK findings require AO or delegate approval.

RAMPART and the compliance posture score

The posture score (0–100%) is computed from:

1. Control implementation status (IMPLEMENTED vs NOT_IMPLEMENTED vs PARTIALLY_IMPLEMENTED)
2. Open finding count and severity
3. POA&M milestone adherence

RAMPART findings affect the posture score immediately when a finding is created. Remediating a finding restores the score in the next evaluation that passes the relevant gate. The score does not auto-restore on finding acceptance — accepted risk is documented but the finding remains in the posture calculation at reduced weight.

Cryptographic signing

Every RAMPART evaluation is signed by CHRONICLE using Cosign:

1. Evaluation results are serialized as a JSON payload
2. The payload hash is signed with the platform's Cosign key
3. The signature and payload are anchored to the Rekor public transparency log
4. The Rekor log entry UUID is stored with the evaluation record

This means every evaluation has a tamper-evident audit trail. If the evaluation record is modified, the Rekor entry remains — providing independent verification of what was found and when.

Source: Sigstore / Cosign (opens in a new tab), Rekor transparency log (opens in a new tab)

Related pages

• ARE Engine — Autonomous remediation for RAMPART findings
• CHRONICLE Engine — Cryptographic signing and Rekor anchoring
• GitHub Integration — How to connect repositories to RAMPART
• CMMC Guide — CMMC practice domains mapped to RAMPART gates