Sécurité · États-Unis (NIST)

NIST SP 800-218 (SSDF v1.1)

Attestkeep rattache ce que l'admission control et le scan d'images de votre cluster ont enregistré sur une période à 13 exigences (source : NIST SP 800-218 v1.1). 11 sont évaluées sur ces enregistrements ; 2 sont marquées hors périmètre, chacune avec la raison.

Créer un compte Construction d'un paquet

Ce que demande le framework

11 exigences à portée de cluster.

Références et titres tels que le rapport les imprime, c'est-à-dire en anglais. Ouvrez une exigence pour lire ce qu'elle demande, reformulé au plus près du texte de l'instrument.

Secure Software Development Framework

NIST SP 800-218 v1.1

PO.3 et PO.5, PS.1 à PS.3, PW.4, et RV.1 à RV.2 : les pratiques qui vont au-delà du build, jusqu'à ce qui est déployé

Référence	Exigence	Sections du rapport
PO.3.2	Deploy and maintain the toolchain Suivre les pratiques de sécurité recommandées pour déployer, exploiter et maintenir les outils et les toolchains, et s'assurer qu'ils fonctionnent comme prévu.	AvailabilityEvidence chain
PO.5.1	Separate and protect the environments used for software Utiliser une authentification multifacteur fondée sur le risque et un accès conditionnel pour chaque environnement, et restreindre qui peut le modifier.	Evidence chain
PS.1.1	Protect all forms of code from unauthorized access and tampering Stocker le code selon le principe du moindre privilège, et vérifier que ce qui est déployé est bien ce qui a été publié.	Supply chainControl statement
PS.2.1	Provide a mechanism for verifying software release integrity Publier des hashes cryptographiques ou signer les releases, pour que les utilisateurs puissent vérifier que le logiciel qu'ils exécutent est celui qui a été publié.	Supply chainControl statement
PS.3.1	Archive and protect each software release Archiver la release et ses données de provenance, pour pouvoir l'identifier et établir son origine plus tard.	Supply chainControl statementEvidence chain
PS.3.2	Collect and maintain provenance data for components Mettre à disposition les données de provenance, y compris un SBOM, pour les composants à partir desquels une release est assemblée.	Supply chain
PW.4.1	Acquire well-secured components from commercial or open-source sources Réutiliser des composants issus de sources connues et de confiance, et vérifier que chaque composant acquis vient bien d'où il prétend venir.	Control statementSupply chain
PW.4.4	Verify that acquired components comply with requirements Vérifier chaque composant acquis au regard des exigences de sécurité de l'organisation avant son utilisation, et continuer à le faire pendant toute sa durée de vie.	CoverageAdmission decisionsOutcomes
RV.1.1	Gather information about potential vulnerabilities Surveiller en continu les sources d'information sur les vulnérabilités du logiciel et des composants dont il dépend.	Coverage
RV.1.2	Confirm and prioritize each vulnerability Examiner, confirmer, prioriser et enregistrer chaque vulnérabilité signalée, pour que la réponse soit proportionnée et traçable.	CoverageAdmission decisionsOutcomesTriage decisionsEvidence chain
RV.2.1	Analyze and plan the remediation of each vulnerability Analyser chaque vulnérabilité pour déterminer la réponse, et agir dans un délai défini.	Control statementAdmission decisionsIssuesBreak-glass events

2 exigences hors périmètre, et pourquoi

Référence	Exigence et raison
PW.1 to PW.3, PW.5 to PW.9	Design, review, and test the software itself Ces pratiques régissent la façon dont le logiciel est écrit et revu avant de devenir une image ; ce document rend compte de ce qu'un cluster a admis, ce qui se situe en aval de chacune d'elles.
RV.3.3	Review the root cause of vulnerability classes L'analyse des causes profondes est une activité du producteur, sur le code et la conception ; ces enregistrements montrent quelles vulnérabilités sont revenues, pas pourquoi elles ont été écrites.

Ce que produit Attestkeep

Preuves tirées des journaux que tient déjà le cluster.

Rien n'est rempli à la main. La réponse à chaque exigence porte un statut (satisfaite, partielle, écart ou hors périmètre), une note avec les chiffres de la période et les sections du rapport d'où viennent ces chiffres.

Ce sur quoi s'appuie le mapping

Chaque exigence évaluée reçoit sa réponse d'une ou plusieurs de ces affirmations sur les enregistrements de la période. La même affirmation répond à la même question dans tous les frameworks : deux rapports sur une même période ne peuvent pas diverger.

Chaque décision et chaque action d'administration est enregistrée4 exigences
Seules les images de provenance établie peuvent tourner4 exigences
Les workloads désignent les images par digest, pas par un tag mobile2 exigences
Chaque image de l'inventaire a un enregistrement de scan2 exigences
Les images portant des vulnérabilités graves sont refusées2 exigences
L'accès administrateur est fédéré à un annuaire1 exigence
Le contrôle lui-même a fonctionné pendant toute la période1 exigence
Les risques acceptés sont nommés, justifiés et expirent1 exigence
Un refus ou une vulnérabilité critique parvient à une personne1 exigence
Les images n'entrent que depuis des registries désignés1 exigence
Un délai de correction est déclaré pour chaque sévérité1 exigence
Un SBOM est conservé pour les images en service1 exigence

Le paquet

Ce que contient le rapport.

Chaque paquet contient les mêmes sections, quel que soit le framework. Les sections signalées sont celles que citent les réponses pour NIST SSDF, avec le nombre d'exigences qui renvoient à chacune.

Plus sur le paquet

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)

Périmètre

Le paragraphe de périmètre, tel que le rapport l'imprime (en anglais).

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.

Questions

Sur NIST SSDF

Est-ce une certification selon NIST SSDF ?

Non. Le paquet est une preuve produite à partir des enregistrements de votre cluster. Ce n'est pas une certification, et aucun auditeur n'est tenu de l'accepter. Le paragraphe de périmètre de cette page est celui que porte le rapport lui-même.

Pourquoi 2 exigences sont-elles hors périmètre ?

Elles portent sur des choses que les enregistrements d'admission et de scan d'un cluster ne peuvent pas montrer. Elles figurent avec la raison au lieu d'être omises, pour que le lecteur du rapport voie que l'exclusion est voulue.

Quel plan inclut NIST SSDF ?

Tous les plans peuvent produire un rapport selon ce framework. Community et Team incluent un framework au choix, Business trois, Enterprise tous. Les prix sont sur la page des tarifs.

Comment un auditeur vérifie-t-il le paquet ?

Dans un navigateur, sur attestkeep.com/verify.html, où rien n'est envoyé, ou avec le court script du site de documentation. Aucun des deux n'a besoin de nous. La page Pour les auditeurs donne le détail.

Installez-le vous-même.

Créez un compte, confirmez votre e-mail avec le code envoyé, prenez la clé Community gratuite sur la page Licences et installez avec Helm.

Créer un compte