Security · United States (NIST)

NIST SP 800-190 (Application Container Security)

Attestkeep maps what your cluster's admission control and image scanning recorded in a period to 15 clauses of NIST SP 800-190. 11 are assessed from those records; 4 are marked outside scope, each with the reason.

Create an account How a package is built

What the framework asks

11 clauses a cluster can answer.

Citations and titles as the report prints them. Open a clause to read what it asks, restated close to the instrument's own words.

Application Container Security Guide

NIST SP 800-190

Section 3 risks and section 4 countermeasures for images, registries, orchestrators and containers

Citation	Clause	Report sections
3.1.1 / 4.1.1	Image vulnerabilities Images should be scanned for vulnerabilities on an ongoing basis, and organizations should adopt tools and processes that prevent images with vulnerabilities above a defined threshold from being run.	CoverageAdmission decisionsOutcomesControl statement
3.1.2 / 4.1.2	Image configuration defects Images should be checked for configuration defects, including running as root and other settings that weaken the isolation a container relies on.	Control statementAdmission decisions
3.1.3 / 4.1.3	Embedded malware Images should be monitored for malicious files, using both signature-based detection and the provenance of the image itself.	CoverageSupply chainControl statement
3.1.5 / 4.1.5	Use of untrusted images Organizations should maintain a set of trusted registries and images, and prevent workloads from running images obtained from anywhere else.	Control statementSupply chainAdmission decisions
3.2.2 / 4.2.2	Stale images in registries Organizations should ensure that only current images are deployed, for example by referring to images by immutable identifiers rather than by tags that can be moved to older content.	Control statement
3.2.3 / 4.2.3	Insufficient authentication and authorization restrictions Access to registries should be restricted, and images should be pulled only from registries the organization controls or has vetted.	Control statement
3.3.1 / 4.3.1	Unbounded administrative access Orchestrator administrative access should be least privilege and, where possible, federated to the organization's directory rather than held as separate local accounts.	Evidence chain
3.3.2 / 4.3.2	Unauthorized access Only authorized workloads should be admitted to the cluster, and every admission decision should be attributable.	Control statementAdmission decisionsEvidence chain
3.4.4 / 4.4.4	App vulnerabilities Containers should be monitored for vulnerabilities discovered after they were deployed, and remediated within defined windows.	CoverageControl statementAdmission decisionsIssuesBreak-glass events
4.1.1 (policy-driven enforcement)	Deviations from the control are governed Where a container must run despite failing a check, the deviation should be recorded, justified and time-bounded rather than granted silently.	Triage decisionsEvidence chain
6.4 (operations and maintenance)	The control operates continuously The countermeasures above are only effective while they are running; their availability is itself part of the control.	Availability

4 clauses marked outside scope, and why

Citation	Clause and reason
3.1.4 / 4.1.4	Embedded clear text secrets an admission controller reads an image's metadata and findings, not the contents of its layers; secret scanning of layer content is not performed by this operator and is not claimed here
3.3.4 / 4.3.4	Mixing of workload sensitivity levels namespace segregation and node placement are the cluster operator's own design; this control governs which images may run in a namespace, not how namespaces are separated from one another
3.3.5 / 4.3.5	Orchestrator node trust node attestation and host hardening are outside an admission controller's view; this document speaks to what may run, not to where
3.4.1 / 4.4.1	Vulnerabilities within the runtime software the runtime is part of the host platform; this operator reports on the images it admits and on its own availability, not on the runtime's version

What Attestkeep produces

Evidence from records the cluster already keeps.

Nothing is filled in by hand. Each clause's answer carries a status (met, partial, gap or outside scope), a note with the period's own numbers, and the report sections those numbers come from.

Statements the mapping draws on

Each assessed clause is answered by one or more of these statements about the period's records. The same statement answers the same question under every framework, so two reports for one period cannot disagree.

Admission refuses non-compliant workloads3 clauses
Every decision and administrative action is recorded3 clauses
Every image in the inventory carries a scan record3 clauses
Only images of established provenance may run2 clauses
Images may enter only from named registries2 clauses
Administrative access is federated to a directory1 clause
The control itself was operating throughout the period1 clause
Workloads name images by digest, not by a movable tag1 clause
Accepted risks are named, justified and expire1 clause
A refusal or a critical finding reaches a person1 clause
Remediation windows are declared for each severity1 clause
Images carrying severe findings are refused1 clause
Workload privilege is constrained at admission1 clause

The package

What the report contains.

Every package carries the same sections, whatever the framework. The ones marked are those NIST SP 800-190 answers cite, with the number of clauses citing each.

The scope paragraph, as the report states it.

This document reports what one Kubernetes cluster's admission control and image scanning recorded during the period, mapped onto NIST SP 800-190. The guide covers images, registries, orchestrators, containers and host operating systems; this operator observes the first three at the point a workload is admitted. Runtime behaviour inside a running container, and the hardening of the hosts themselves, are outside what an admission controller can see and are marked as such rather than claimed.

Questions

About NIST SP 800-190 and Attestkeep

Is this a NIST SP 800-190 certification?

No. The package is evidence produced from your cluster's own records. It is not a certification, and no auditor is obliged to accept it. The scope paragraph on this page is the one the report itself carries.

Why are 4 of the clauses outside scope?

They ask about things one cluster's admission and scanning records cannot show. They are listed with the reason rather than left out, so whoever reads the report can see the gap is deliberate.

Which plan includes NIST SP 800-190?

Every plan can report against it. Community and Team include one framework of your choice, Business three, Enterprise every one. Prices are on the pricing page.

How does an auditor check the package?

In a browser at attestkeep.com/verify.html, where nothing is uploaded, or with the short script on the documentation site. Neither needs us. For auditors has the details.

Install it yourself.

Create an account, confirm your e-mail with the code we send, take the free Community key from the Licenses page, and install with Helm.

Create an account