When Vendors Write Their Own STIGs: Independence, Velocity, and the Container Security Reckoning

*STIGViewer.com | January 2026*

—-

Picture this: You're an AO three months into a container modernization effort. Your team deployed Kubernetes workloads last quarter. The architecture is elegant. The DevSecOps pipeline hums. And then someone asks the question nobody wanted to hear: "Where's the STIG?"

You check DISA's library. There's a Container Platform SRG. Kubernetes has a STIG. Docker Enterprise has one too. But your container images? The actual base images running inside those pods? Nothing. Not a single official STIG exists for generic container images.

So you do what any reasonable security leader does. You look for guidance. And you find Chainguard offering a "STIG Readiness Guide" for their hardened images.

Then a former DISA CIO publishes an article calling it "marketing masquerading as compliance,” (see https://www.linkedin.com/pulse/self-published-stigs-breakthrough-theyre-breakdown-sienkiewicz-%E9%87%91%E5%87%B1%E6%97%8B-oa7he/?trackingId=kUJ481OUTnSNFn942vVaIQ%3D%3D).

Now you've got a problem.

The Independence Argument

Henry Sienkiewicz spent years as DISA's CIO and Authorizing Official. The organization that creates, validates, and enforces the real STIGs. When he says self-published STIGs sever the "chain of trust" underpinning federal accreditation, he's speaking from institutional experience.

His argument isn't complicated. A vendor can't grade their own exam. Conflict of interest is structural. The CMMC program exists precisely because self-attestation failed. Organizations overstated compliance for years. Adversaries walked through gaps. The DoD learned this lesson the hard way.

Boeing 737 MAX proved the principle extends beyond cybersecurity. Congress found the FAA "trusted but did not appropriately verify." The regulator deferred to the manufacturer. People died.

So when Sienkiewicz calls vendor-published security guidance "the digital equivalent of grading your own exam," he's channeling institutional wisdom earned through failure. Independence matters. IV&V isn't bureaucratic ritual. It's how assurance actually works.

He's right about all of that.

Where he goes wrong is assuming Chainguard claims otherwise.

What Actually Happened

Read Chainguard's DISA STIG Commitment page. They don't claim DISA approval. They explicitly state their guidance aligns with the General Purpose Operating System SRG. They call it a "STIG Readiness Guide," not an official STIG. They use "commercially reasonable efforts" language. The transparency is unusual by vendor standards.

VMware does the exact same thing. Their STIG Program documentation acknowledges that customer demand often exists "well before the STIG development process completes." They publish STIG Readiness Guides as interim measures, clearly labeled as lacking DISA's technical validation, requirement fulfillment review, and Risk Management Executive signature.

Nobody accuses VMware of undermining federal cybersecurity.

The difference isn't the practice. It's the framing. Sienkiewicz treats Chainguard's readiness guide as if it were masquerading as an official STIG. But read the actual documentation. They're filling a gap that DISA hasn't addressed. The gap is the problem. Not the filling.

The Velocity Problem Nobody Wants to Discuss

Here's what doesn't appear in Sienkiewicz's critique: DISA's STIG development cycle takes 12 months minimum. Often longer.

VMware vSphere 8.0 released in October 2022. The STIG dropped October 2023. Twelve months. That's for a hypervisor with a stable release cadence and established vendor relationship.

Containers don't work that way. Kubernetes workloads are ephemeral by design. Images rebuild nightly. Vulnerabilities emerge continuously. The threat landscape doesn't pause while the validation process catches up.

Sienkiewicz acknowledges this tension. He agrees that "modern containerized environments need a more agile STIG process." But his conclusion inverts the logic. He argues complexity makes independent validation more essential. True. And also irrelevant to what organizations should do while waiting for that validation to exist.

The practical choice isn't between official STIGs and self-published guides. It's between self-published guidance and nothing.

FedRAMP CM-6(a) recognizes this explicitly. The hierarchy: DoD STIGs first, then CIS Level 2 benchmarks when STIGs are unavailable, then custom baselines as fallback. The regulatory framework already accommodates interim guidance. Sienkiewicz treats that accommodation as weakness. It's actually pragmatism.

The Inherited Controls Reality

Sienkiewicz criticizes Chainguard's approach without acknowledging its doctrinal basis. The DoD's own Container Hardening Process Guide, Appendix C, establishes that containers can inherit security controls from their host environment.

Auditing happens at the kernel level. Isolation comes from namespaces and cgroups. ASLR, firewalls, filesystem encryption, time synchronization: all configured on the host, inherited by the container. The DoD wrote this guidance. Chainguard follows it. Calling that approach dangerous while ignoring its origin isn't principled objection. It's selective reading.

The images focus on what remains after inherited controls: application-level security configuration and vulnerability remediation. That's precisely what the DoD guidance recommends.

The Zero CVE Question

Sienkiewicz dismisses Chainguard's "zero CVE" claim as "operationally meaningless without independent validation." He's right that any system develops vulnerabilities over time. The meaningful metric is remediation velocity.

But here's what backs the marketing claim: Chainguard rebuilds images nightly. New Wolfi packages appear within four hours of upstream release. Their remediation SLAs run 7 days for critical vulnerabilities, 14 days for everything else.

Compare that to FedRAMP's 30/90/180 day windows. Compare it to Iron Bank, where even hardened images carry significant CVE loads according to independent analyses.

The "zero CVE" claim isn't security theater. It's the output of a fundamentally different architecture: minimal images, aggressive patching, automated rebuilds. You can argue whether that architecture meets federal requirements. You can't argue it's just marketing.

The Precedent Problem

Sienkiewicz's strongest argument is about fragmentation. If Chainguard can self-publish a STIG, others will follow. The market floods with "proprietary STIGs" and "self-certified gold images." Cross-domain audits become impossible. Risk fragments across pseudo-compliance.

This concern deserves engagement. The STIG system's value lies partly in standardization. A single authoritative baseline enables consistent posture assessment across the enterprise. Fragmentation is real danger.

But the answer isn't condemning interim guidance. It's accelerating official processes. The Software Engineering Institute at Carnegie Mellon has documented agile IV&V approaches. FedRAMP 20x aims to cut approval times from months to weeks through automated validation.

The regulatory apparatus is evolving. The question is whether it evolves fast enough to make interim guidance unnecessary.

What This Means for You

If you're evaluating container security for federal workloads, here's the practical guidance:

Don't treat vendor guidance as equivalent to DISA validation. Sienkiewicz is right that independence matters. Factor the difference into your risk calculus. Document the distinction in your authorization package.

Don't dismiss vendor guidance as worthless. When no official STIG exists, documented interim baselines beat improvisation. Track them against your POA&M. Plan transition when official guidance arrives.

Verify transparency. Chainguard explicitly states their guidance lacks DISA approval. VMware does too. If a vendor claims official weight, that's the red flag. The problem isn't self-publishing. It's misrepresentation.

Pressure DISA to accelerate. Container technology is a decade old. The Container Platform SRG dropped in 2020. Where are the container image STIGs? The real failure isn't vendors filling gaps. It's gaps existing.

Build toward continuous monitoring. The future isn't periodic third-party assessment versus vendor self-certification. It's automated, continuous compliance validation. FedRAMP 20x moves that direction. Traditional annual 3PAO re-assessment may be phased out. Build toward that model now.

The Deeper Battle

Sienkiewicz warns that weakening the STIG process weakens national cyber readiness.

He's not wrong. But the process is already weakened. Not by vendors filling gaps. By institutional inertia leaving gaps unfilled. The STIG system was designed for persistent systems with multi-year lifecycles. Containers live for seconds. The architecture of assurance hasn't adapted to the architecture of deployment.

Self-published STIGs aren't the disease. They're a symptom. The disease is a validation apparatus that can't keep pace with the technology it's meant to secure.

Sienkiewicz served with distinction at DISA. His concerns about independence reflect genuine institutional wisdom. But wisdom that doesn't account for changed circumstances becomes orthodoxy.

And orthodoxy in cybersecurity is a vulnerability.

The answer isn't condemning vendors for providing interim guidance. It's building systems that make interim guidance unnecessary.

Until then, gaps exist. Someone will fill them.

The question is whether you'll use that guidance wisely. Or ignore it while waiting for validation that may never come.

—-

Sources

Chainguard DISA STIG Commitment. Chainguard (2025). https://www.chainguard.dev/legal/disa-stig-commitment
Chainguard Zero CVE Approach. Chainguard (2025). https://edu.chainguard.dev/chainguard/chainguard-images/about/zerocve/
DISA STIG Vendor Process. DISA (2025). https://www.cyber.mil/stigs/vendor-process/
DoD Container Hardening Guide. DoD (2024). https://dl.dod.cyber.mil/wp-content/uploads/devsecops/pdf/FinalDevSecOpsEnterpriseContainerHardeningGuide1.2.pdf
FAA Certification of 737 MAX. DOT OIG (2021). https://www.oig.dot.gov/sites/default/files/FAA%20Certification%20of%20737%20MAX%20Boeing%20II%20Final%20Report%5E2-23-2021.pdf
FedRAMP 20x Overview. ProjectHosts (2025). https://projecthosts.com/resources/insight/fedramp-20x-keep-calm-and-authorize-on/
Incorporating Agile Principles into IV&V. SEI/CMU (2024). https://www.sei.cmu.edu/blog/incorporating-agile-principles-into-independent-verification-and-validation/
The CMMC Framework. The Assurance Foundation (2025). https://www.taf.org/the-cybersecurity-maturity-model-certification-cmmc-framework/
VMware STIG Program Overview. VMware (2025). https://www.vmware.com/docs/vmw-stig-program-overview