NIST SP 800-218 (SSDF v1.1)
Attestkeep vincula lo que el admission control y el escaneo de images de su cluster registraron en un periodo con 13 requisitos (fuente: NIST SP 800-218 v1.1). De ellos, 11 se evalúan con esos registros; 2 se marcan fuera de alcance, cada uno con el motivo.
11 requisitos a los que responde un cluster.
Referencias y títulos tal como los imprime el informe, es decir, en inglés. Abra un requisito para leer lo que pide, expresado de forma próxima al texto del propio instrumento.
Secure Software Development Framework
NIST SP 800-218 v1.1
PO.3 y PO.5, PS.1 a PS.3, PW.4, y RV.1 a RV.2: las prácticas que van más allá del build, hasta lo que se despliega
| Referencia | Requisito | Secciones del informe |
|---|---|---|
| PO.3.2 | Deploy and maintain the toolchainSeguir las prácticas de seguridad recomendadas para desplegar, operar y mantener las herramientas y toolchains, y asegurarse de que funcionan como se espera. | AvailabilityEvidence chain |
| PO.5.1 | Separate and protect the environments used for softwareUsar autenticación multifactor basada en riesgo y acceso condicional en cada entorno, y restringir quién puede modificarlo. | Evidence chain |
| PS.1.1 | Protect all forms of code from unauthorized access and tamperingGuardar el código según el principio de mínimo privilegio y verificar que lo desplegado es lo que se publicó. | Supply chainControl statement |
| PS.2.1 | Provide a mechanism for verifying software release integrityPublicar hashes criptográficos o firmar los releases, para que los usuarios puedan verificar que el software que ejecutan es el que se publicó. | Supply chainControl statement |
| PS.3.1 | Archive and protect each software releaseArchivar el release y sus datos de procedencia, para poder identificarlo y establecer su origen más adelante. | Supply chainControl statementEvidence chain |
| PS.3.2 | Collect and maintain provenance data for componentsPoner a disposición los datos de procedencia, incluido un SBOM, de los componentes con los que se monta un release. | Supply chain |
| PW.4.1 | Acquire well-secured components from commercial or open-source sourcesReutilizar componentes de fuentes conocidas y de confianza, y comprobar que cada componente adquirido viene de donde dice venir. | Control statementSupply chain |
| PW.4.4 | Verify that acquired components comply with requirementsVerificar cada componente adquirido frente a los requisitos de seguridad de la organización antes de usarlo, y seguir haciéndolo durante toda su vida. | CoverageAdmission decisionsOutcomes |
| RV.1.1 | Gather information about potential vulnerabilitiesVigilar de forma continua las fuentes de información sobre vulnerabilidades del software y de los componentes de los que depende. | Coverage |
| RV.1.2 | Confirm and prioritize each vulnerabilityRevisar, confirmar, priorizar y registrar cada vulnerabilidad notificada, para que la respuesta sea proporcionada y trazable. | CoverageAdmission decisionsOutcomesTriage decisionsEvidence chain |
| RV.2.1 | Analyze and plan the remediation of each vulnerabilityAnalizar cada vulnerabilidad para decidir la respuesta y actuar dentro de un plazo definido. | Control statementAdmission decisionsIssuesBreak-glass events |
2 requisitos fuera de alcance, y por qué
| Referencia | Requisito y motivo |
|---|---|
| PW.1 to PW.3, PW.5 to PW.9 | Design, review, and test the software itself Estas prácticas rigen cómo se escribe y revisa el software antes de convertirse en una image; este documento informa de lo que un cluster admitió, que va después de todas ellas. |
| RV.3.3 | Review the root cause of vulnerability classes El análisis de causa raíz es una actividad del productor sobre el código fuente y el diseño; los registros de aquí muestran qué hallazgos se repitieron, no por qué se escribieron. |
Evidencia a partir de registros que el cluster ya guarda.
Nada se rellena a mano. La respuesta de cada requisito lleva un estado (cumplido, parcial, carencia o fuera de alcance), una nota con las cifras del propio periodo y las secciones del informe de donde salen esas cifras.
En qué se apoya el mapeo
Cada requisito evaluado se responde con una o varias de estas afirmaciones sobre los registros del periodo. La misma afirmación responde a la misma pregunta en todos los frameworks, así que dos informes de un mismo periodo no pueden discrepar.
- Se registra cada decisión y cada acción administrativa4 requisitos
- Solo pueden ejecutarse images de procedencia establecida4 requisitos
- Los workloads nombran las images por digest, no por un tag movible2 requisitos
- Cada image del inventario tiene un registro de escaneo2 requisitos
- Se rechazan las images con hallazgos graves2 requisitos
- El acceso administrativo está federado con un directorio1 requisito
- El propio control estuvo operativo durante todo el periodo1 requisito
- Los riesgos aceptados tienen nombre, justificación y caducidad1 requisito
- Un rechazo o un hallazgo crítico llega a una persona1 requisito
- Las images solo pueden entrar desde registries autorizados1 requisito
- Hay un plazo de corrección declarado para cada severidad1 requisito
- Se guarda un SBOM de las images en servicio1 requisito
Qué contiene el informe.
Todos los paquetes llevan las mismas secciones, sea cual sea el framework. Las marcadas son las que citan las respuestas para NIST SSDF, con el número de requisitos que cita cada una.
- 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)
El párrafo de alcance, tal como lo formula el informe.
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.
Sobre NIST SSDF
¿Es esto una certificación según NIST SSDF?
No. El paquete es evidencia generada a partir de los propios registros de su cluster. No es una certificación, y ningún auditor está obligado a aceptarlo. El párrafo de alcance de esta página es el mismo que lleva el informe.
¿Por qué 2 de los requisitos están fuera de alcance?
Preguntan por cosas que los registros de admission y escaneo de un cluster no pueden mostrar. Se incluyen con el motivo en lugar de omitirse, para que quien lea el informe vea que la exclusión es deliberada.
¿Qué plan incluye NIST SSDF?
Todos los planes pueden generar informes para este framework. Community y Team incluyen 1 framework a elegir; Business, 3; Enterprise, todos. Los precios están en la página de precios.
¿Cómo comprueba un auditor el paquete?
En un navegador, en attestkeep.com/verify.html, donde no se sube nada, o con el breve script del sitio de documentación. Ninguno de los dos nos necesita. La página Para auditores tiene los detalles.
Instálelo usted mismo.
Cree una cuenta, confirme su correo con el código que le enviamos, obtenga la clave Community gratuita en la página Licences e instale con Helm.
Crear una cuenta