La respuesta "real" depende de dónde pretende realizar sus evaluaciones de CC. Ha habido una reciente agitación en el mundo de las evaluaciones de CC con Estados Unidos y Canadá (y Australia) en un campo, y la mayor parte de Europa en otro campo. (Veo por su uid que puede estar en Francia). Los esquemas específicos pueden tener requisitos específicos. De todos modos, deberás contratar un servicio de evaluación, por lo que es mejor que empieces a rodar la bola.
La razón por la que la ubicación es importante es que el mercado de los EE. UU. / CAN se está moviendo hacia las garantías en EAL2 y en niveles más bajos (y luego se desharán de los niveles de seguridad). En EAL2, las dos únicas cosas en el ámbito de los propósitos de "infraestructura" son el sistema de gestión de la configuración y la cadena segura de entrega / suministro.
Los requisitos para EAL2 son bastante modestos y básicamente dicen que NECESITA tener un sistema CM y que el producto y la documentación deben controlarse dentro del sistema CM. Sin embargo, no se exige ninguna funcionalidad específica más que mostrar que está controlada (ni siquiera es necesario que sea automatizada para EAL2).
Ahora, en Francia, si he traducido correctamente, el esquema de CC (ANSSI: Agencia Nacional de Seguridad de Sistemas de Información) parece continuar por el camino de las certificaciones de aseguramiento de nivel medio a alto (por ejemplo, EAL4 y más). En EAL4, existen importantes requisitos de seguridad en el entorno de desarrollo, las herramientas y el sistema CM.
La clave, sin embargo, es que el CC no es prescriptivo: no le dice qué funciones de seguridad debe tener, solo cuál es el resultado final (por ejemplo, debe proteger la confidencialidad y la integridad del producto). Una de las cosas clave que debe recordar es que cuando el evaluador considera que las medidas del desarrollador no son las adecuadas, se debe proporcionar una justificación clara basada en el potencial de una vulnerabilidad explotable.
Le sugiero que primero observe qué nivel de seguridad está buscando lograr (generalmente una decisión de marketing más que cualquier otra cosa). Utilice esta decisión para determinar qué componentes de aseguramiento se incluirán (según el esquema, por supuesto): esta cuadrícula se encuentra en la página 231 (tabla 24) en el Apéndice E de CC Part 3 . (Para su situación, solo le interesa la clase de aseguramiento ALC (Ciclo de vida)). Luego, busque estos componentes de aseguramiento en el cuerpo del mismo documento. Está buscando los "Elementos de acción del desarrollador" y "Elementos de contenido y presentación", como ALC_CMC.2.1D y ALC_CMC.2.1C. Es útil saber qué buscará un evaluador, por lo que le insto a leer la Metodología de evaluación común (CEM) ) para los mismos componentes de aseguramiento. En función de lo que encuentre, estará en una mejor posición para formular el conjunto correcto de preguntas. Muchas de estas preguntas se dirigirán a su equipo de integración interna, algunas serán preguntas sobre las características del producto. Como ejemplo, en EAL4, necesita tener control de acceso automatizado e integración de compilación (por ejemplo, ALC_CMC.4.4C y ALC_CMC.4.5C) en su sistema CM. Sin embargo, también necesitará un extenso "plan de CM" que describa cómo su entorno de desarrollo utiliza el sistema de CM (ALC_CMC.4.6C). Esto será desarrollado internamente.
Me parecería altamente improbable que encuentre una lista de productos que estén "CC Ready (tm)!". La razón es porque CC está más preocupada por el resultado final que por cómo se llega allí. Por lo tanto, una hoja de cálculo podría ser una forma aceptable de sistema de administración de configuración para EAL2 siempre que haya políticas y procedimientos implementados para garantizar que se cumpla. Esto no volaría en EAL4. Por el contrario, solo porque use el Sistema de gestión de control de fuente (tm) de Bells and Whistles no significa que pasará a EAL2, ya que es posible que no haga un seguimiento de todos los elementos necesarios.