Co-written with Viktor Kartashov.
The NIST SP 800–190 standard provides structured guidelines to secure containerized applications , covering everything from image provenance to runtime controls. As container use explodes in fast-paced DevOps environments, aligning with these requirements becomes both essential and challenging.
But SP 800–190 here is just a use case . The bigger idea is to bring continuous, signed, policy-as-code validation into your CI/CD pipelines, regardless of the security framework.
Most teams still treat compliance as a final-stage activity — delayed, brittle, and divorced from development. But what if every image, every PR, every tag was continuously validated against security policies?
The Challenge: Consistent Compliance in a Rapid SDLC
The challenge is that while SP 800–190 tells you what to secure — it provides clear guidance and categories like Image Countermeasures, the real hurdle is how to translate those high-level guidelines into concrete, actionable checks, how to enforce them consistently, and how to prove that you did. This is precisely where our continuous SDLC governance and compliance tooling comes in, transforming compliance from a manual burden into an automated, verifiable process.
Instead of relying on brittle, one-off scripts or late-stage post-deployment scans, Scribe’s approach brings structured, enforceable security controls directly into the heart of your Software Development Lifecycle (SDLC). We do this seamlessly using GitHub Actions, Valint, and Sigstore, enabling you to:
- Define your security policies as code, making them manageable.
- Automate checks directly within your development workflows.
- Cryptographically sign and securely store all security evidence.
- Achieve full traceability and auditability for every artifact, from Pull Request to production.
The Core of Our Solution: Policy as Code with Valint
At the core of Scribe’s powerful solution lies a declarative initiative file. This beautifully maps abstract SP 800–190 guidelines and controls (like those in “Image Countermeasures”) to concrete, executable rules. This is where your security policies truly become code, enforced by Valint. For a deeper dive into how policy engines like Valint bring order to your compliance efforts, we encourage you to read our previous post, “From Chaos to Clarity: Navigating Policy Engine for Compliance”.
Example: Here’s how specific image countermeasures are defined within your Valint initiative:
controls:
– name: “4.1 IMAGE COUNTERMEASURES”
rules:
– uses: sarif/trivy/blocklist-cve@v2/rules
name: “4.1.1 High-Profile Vulnerabilities”
– uses: images/verify-labels@v2/rules
name: “4.1.3 Required Image Labels”
– uses: images/allowed-base-image@v2/rules
name: “4.1.5 Approved Base Images”
The flexibility here is immense: while our demo uses sp-800-190.yaml, Valint allows you to easily replace it, customize it, or add your own initiatives, whether it’s based on CIS benchmarks, internal organizational guidelines, or completely bespoke policies.
For more detailed information on defining and using specific initiatives, please refer to our documentation. You can also explore our high-level guide on enforcing SDLC initiatives here.
A Developer’s Story: Real-Time Compliance in Pull Requests
So, what does this look like for developers? The moment a Pull Request is opened, the CI pipeline automatically springs into action, orchestrating a series of vital security checks.
First, the Build Phase commences, where the image is built and crucial metadata is collected directly from the Dockerfile. Following this, an SBOM Generation step creates a detailed CycloneDX SBOM, meticulously tracing packages and base image layers for full transparency. Next, a Vulnerability Scan is performed to produce a comprehensive SARIF-formatted report. Finally, Policy Evaluation takes center stage as Valint rigorously checks all the accumulated evidence against your predefined SP 800–190 initiative.
If any violations are uncovered — perhaps a CVE with a severity exceeding 8.5 — your pipeline is configured to either block the PR outright or issue a prominent warning. The best part? A concise summary of the findings is attached directly to the GitHub PR view, providing developers with immediate, actionable feedback. This empowers them to address security concerns proactively, right where they work.
Scribe UI: Clear Policy Violations View
Example: GitHub PR Check Summary: Immediate Developer Feedback
– name: Collect evidence & evaluate policy
uses: scribe-security/action-verify@master
with:
target: my_company/my-image:v1.0.0
bom: true # Generate SBOM for target
input: trivy:trivy-report.json # Generate evidence for trivy report
base-image: Dockerfile # Generate Base Image evidence
initiative: sp-800-190@v2 # Evaluate Initiative
input-format: attest
format: attest
Artifacts like SBOMs, scan results, and the policy output can, of course, be optionally retained as pipeline artifacts for even deeper inspection or compliance archiving.
The Release Gate: Verifiable Compliance Through Signed Evidence
After a Pull Request successfully merges, the journey continues to the release pipeline, where the image undergoes a final, critical validation against the same SP 800–190 rules. This isn’t just a re-run; it’s the gate for deployment. At this crucial stage, the ScribeHub platform focuses on creating verifiable proof of compliance, ensuring that every release is not just secure but demonstrably trustworthy through comprehensive, signed evidence.
Whether a pass or a failure , ScribeHub maintains full transparency and traceability. Crucially, all evidence — including the detailed policy result — is uploaded to a secure store and cryptographically signed (e.g., via Sigstore, x.509, or KMS). This ensures that every outcome is immutable and verifiable, providing a complete record for audit and trust, no matter what the evaluation shows.
These signed SARIF policy results, SBOMs, and scan outputs become invaluable assets for:
- Robust Audit Trails: Providing undeniable proof of compliance.
- Reliable Release Attestation: Confirming the security posture of your deployed artifacts.
- Seamless Kubernetes Admission Control Integrations: Enabling automated gates before images run in your clusters.
Within the ScribeHub UI, any violations are clearly marked, and each piece of signed evidence is meticulously traceable, directly linked to the initiative result that produced it. This offers unparalleled clarity and confidence in your supply chain security.
Aggregated Vulnerabilities from SBOM and Scan
Scribe UI: Traceable and Signed Evidence
See Our Solution in Action: The Demo Pipeline
You’ve read how our continuous compliance tooling brings SP 800–190 to life. Now, see it for yourself! We’ve created a hands-on demo repository that showcases exactly how Valint and Sigstore work together in both PR and release workflows.
Explore the Demo Code Here: scribe-public/demo-pipeline
This repository contains two essential GitHub Actions workflows, sp800-190-policy-pr.yml and sp800-190-policy-release.yml, which visually demonstrate the immediate feedback for developers and the cryptographically signed evidence for release, as described throughout this post.
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
