NIST SP 800-218 (SSDF v1.1)
Was Admission Control und Image-Scan Ihres Clusters in einem Zeitraum erfasst haben, ordnet Attestkeep 13 Anforderungen zu (Quelle: NIST SP 800-218 v1.1). 11 davon werden aus diesen Einträgen bewertet; 2 sind als außerhalb des Umfangs markiert, jede mit Begründung.
11 Anforderungen aus Clustersicht.
Fundstellen und Titel so, wie der Bericht sie druckt, also auf Englisch. Öffnen Sie eine Anforderung, um zu lesen, was sie verlangt – nah am Wortlaut des Regelwerks wiedergegeben.
Secure Software Development Framework
NIST SP 800-218 v1.1
PO.3 und PO.5, PS.1 bis PS.3, PW.4 sowie RV.1 bis RV.2 – die Praktiken, die über den Build hinaus bis in das reichen, was ausgerollt wird
| Fundstelle | Anforderung | Berichtsabschnitte |
|---|---|---|
| PO.3.2 | Deploy and maintain the toolchainEmpfohlene Sicherheitspraktiken befolgen, um Werkzeuge und Toolchains einzurichten, zu betreiben und zu warten, und sicherstellen, dass sie wie vorgesehen arbeiten. | AvailabilityEvidence chain |
| PO.5.1 | Separate and protect the environments used for softwareFür jede Umgebung Multi-Faktor- und risikobasierte Authentifizierung sowie bedingten Zugriff einsetzen und einschränken, wer sie ändern darf. | Evidence chain |
| PS.1.1 | Protect all forms of code from unauthorized access and tamperingCode nach dem Prinzip der minimalen Rechte ablegen und prüfen, dass das Ausgerollte dem Veröffentlichten entspricht. | Supply chainControl statement |
| PS.2.1 | Provide a mechanism for verifying software release integrityKryptografische Hashes veröffentlichen oder Releases signieren, damit Nutzer prüfen können, dass die Software, die sie betreiben, die veröffentlichte ist. | Supply chainControl statement |
| PS.3.1 | Archive and protect each software releaseDas Release und seine Herkunftsdaten archivieren, damit das Release später identifiziert und seine Herkunft festgestellt werden kann. | Supply chainControl statementEvidence chain |
| PS.3.2 | Collect and maintain provenance data for componentsHerkunftsdaten, einschließlich einer Software Bill of Materials, für die Komponenten bereitstellen, aus denen ein Release zusammengesetzt ist. | Supply chain |
| PW.4.1 | Acquire well-secured components from commercial or open-source sourcesKomponenten aus bekannten und vertrauenswürdigen Quellen wiederverwenden und prüfen, dass jede bezogene Komponente von dort stammt, wo sie es angibt. | Control statementSupply chain |
| PW.4.4 | Verify that acquired components comply with requirementsJede bezogene Komponente vor dem Einsatz gegen die Sicherheitsanforderungen der Organisation prüfen und das über ihre gesamte Lebensdauer fortsetzen. | CoverageAdmission decisionsOutcomes |
| RV.1.1 | Gather information about potential vulnerabilitiesQuellen für Schwachstelleninformationen zur Software und zu den Komponenten, von denen sie abhängt, laufend beobachten. | Coverage |
| RV.1.2 | Confirm and prioritize each vulnerabilityJede gemeldete Schwachstelle prüfen, bestätigen, priorisieren und festhalten, damit die Reaktion angemessen und nachvollziehbar ist. | CoverageAdmission decisionsOutcomesTriage decisionsEvidence chain |
| RV.2.1 | Analyze and plan the remediation of each vulnerabilityJede Schwachstelle analysieren, um die Reaktion festzulegen, und innerhalb eines festgelegten Zeitraums handeln. | Control statementAdmission decisionsIssuesBreak-glass events |
2 Anforderungen außerhalb des Umfangs, und warum
| Fundstelle | Anforderung und Grund |
|---|---|
| PW.1 to PW.3, PW.5 to PW.9 | Design, review, and test the software itself Diese Praktiken regeln, wie Software geschrieben und geprüft wird, bevor sie zum Image wird; dieses Dokument berichtet, was ein Cluster zugelassen hat, und das kommt nach jeder einzelnen davon. |
| RV.3.3 | Review the root cause of vulnerability classes Die Ursachenanalyse ist eine Tätigkeit des Herstellers an Quellcode und Design; die Einträge hier zeigen, welche Befunde wiederkehrten, nicht warum sie entstanden. |
Nachweise aus Einträgen, die der Cluster ohnehin führt.
Nichts wird von Hand ausgefüllt. Jede Antwort zu einer Anforderung trägt einen Status (erfüllt, teilweise, Lücke oder außerhalb des Umfangs), eine Notiz mit den Zahlen des Zeitraums und die Berichtsabschnitte, aus denen diese Zahlen stammen.
Worauf sich das Mapping stützt
Jede bewertete Anforderung wird durch eine oder mehrere dieser Aussagen über die Einträge des Zeitraums beantwortet. Dieselbe Aussage beantwortet dieselbe Frage in jedem Framework; zwei Berichte über denselben Zeitraum können sich daher nicht widersprechen.
- Jede Entscheidung und jede administrative Aktion wird festgehalten4 Anforderungen
- Nur Images mit nachgewiesener Herkunft dürfen laufen4 Anforderungen
- Workloads referenzieren Images per Digest, nicht per verschiebbarem Tag2 Anforderungen
- Jedes Image im Bestand hat einen Scan-Eintrag2 Anforderungen
- Images mit schweren Befunden werden abgelehnt2 Anforderungen
- Administrativer Zugang läuft über ein Verzeichnis1 Anforderung
- Die Kontrolle selbst lief den ganzen Zeitraum1 Anforderung
- Akzeptierte Risiken sind benannt, begründet und laufen ab1 Anforderung
- Eine Ablehnung oder ein kritischer Befund erreicht eine Person1 Anforderung
- Images kommen nur aus benannten Registries1 Anforderung
- Für jeden Schweregrad ist ein Behebungsfenster festgelegt1 Anforderung
- Für die laufenden Images liegt ein SBOM vor1 Anforderung
Was der Bericht enthält.
Jedes Paket enthält dieselben Abschnitte, unabhängig vom Framework. Markiert sind die, auf die sich die Antworten zu NIST SSDF stützen, jeweils mit der Zahl der Anforderungen, die auf sie verweisen.
- Organisation
- Framework mapping
- Cluster
- Control statement5
- Coverage3
- Vulnerability findings
- Outcomes2
- Admission decisions3
- Supply chain5
- Triage decisions1
- Break-glass events1
- Availability1
- Evidence chain4
- Deployment context
- Issues1
- Ledger
- Population
- Runtime events
- Producer statements (VEX)
Geltungsbereich, wörtlich aus dem Bericht (Englisch).
This document reports what one Kubernetes cluster's admission control and image scanning recorded during the period, mapped onto the Secure Software Development Framework. SSDF governs how software is produced; a deployment-time control speaks to the practices that reach past the build — verifying the integrity and provenance of what is released, knowing which third-party components are in service, and finding and answering vulnerabilities in software already deployed. Practices about source code, design review, build toolchains and developer training belong to the producing organisation and are marked outside the scope of this document rather than stretched to fit.
Fragen zu NIST SSDF
Ist das eine Zertifizierung nach NIST SSDF?
Nein. Das Paket ist ein Nachweis aus den clustereigenen Einträgen. Es ist keine Zertifizierung, und kein Auditor muss es anerkennen. Der Absatz zum Geltungsbereich auf dieser Seite ist derselbe, den auch der Bericht enthält.
Warum liegen 2 Anforderungen außerhalb des Umfangs?
Sie fragen nach Dingen, die die Admission- und Scan-Einträge eines einzelnen Clusters nicht zeigen können. Sie werden mit Begründung aufgeführt statt weggelassen, damit jeder Leser des Berichts sieht, dass der Ausschluss bewusst ist.
Welcher Plan enthält NIST SSDF?
Jeder Plan kann danach berichten. Community und Team enthalten 1 Framework Ihrer Wahl, Business 3, Enterprise alle. Die Preise stehen auf der Preisseite.
Wie prüft ein Auditor das Paket?
Im Browser unter attestkeep.com/verify.html, wo nichts hochgeladen wird, oder mit dem kurzen Skript auf der Dokumentationsseite. Beides kommt ohne uns aus. Einzelheiten stehen unter Für Auditoren.
Selbst installieren.
Konto anlegen, die E-Mail mit dem zugesandten Code bestätigen, den kostenlosen Community-Schlüssel auf der Seite Licences holen und mit Helm installieren.
Konto anlegen