La risposta "reale" dipende da dove intendi ottenere le tue valutazioni CC. C'è stato un recente sconvolgimento nel mondo delle valutazioni CC con Stati Uniti e Canada (e Australia) in un campo, e la maggior parte dell'Europa in un altro campo. (Vedo dal tuo uid che potresti essere in Francia.) Schemi specifici potrebbero avere requisiti specifici. Dovrai comunque stipulare un contratto con una struttura di valutazione, quindi potresti anche far girare quella palla.
Il motivo per cui la posizione è importante è che il mercato USA / CAN si sta spostando verso assicurazioni a EAL2 e inferiori (e poi si libereranno del tutto dei livelli di garanzia). In EAL2, le uniche due cose per scopi di "infrastruttura" sono il sistema di gestione della configurazione e la catena di consegna / approvvigionamento sicura.
I requisiti per EAL2 sono piuttosto modesti e in pratica si dice che è necessario disporre di un sistema CM e che il prodotto e la documentazione devono essere controllati all'interno del sistema CM. Tuttavia, non vengono fatte richieste su funzionalità specifiche se non quella di mostrare che è controllato (non è nemmeno necessario automatizzarlo per EAL2).
Ora, in Francia, se ho tradotto correttamente, lo schema CC (ANSSI: Agence Nationale de la Sécurité des Systèmes d'Information) sembra continuare sulla strada delle certificazioni di assicurazione medio-alte (ad es. EAL4 e versioni successive). In EAL4, ci sono importanti requisiti di sicurezza imposti sull'ambiente di sviluppo, sugli strumenti e sul sistema CM.
La chiave, tuttavia, è che il CC non è prescrittivo: non ti dice quali funzioni di sicurezza devi avere, ma solo quale sia il risultato finale (ad esempio, deve proteggere la riservatezza e l'integrità del prodotto). Una delle cose fondamentali da ricordare è che, laddove le misure dello sviluppatore sono ritenute non adeguate dal valutatore, è necessario fornire una giustificazione chiara in base al potenziale di vulnerabilità sfruttabile.
Ti suggerisco di guardare prima a quale livello di assicurazione stai cercando di ottenere (di solito una decisione di marketing più di ogni altra cosa). Utilizzare questa decisione per determinare quali componenti di assicurazione saranno inclusi (a seconda dello schema, ovviamente): questa griglia si trova a pagina 231 (tabella 24) nell'appendice E di CC Parte 3 . (Per la vostra situazione, siete interessati solo alla classe di garanzia ALC (Lifecycle).) Quindi, cercate questi componenti di assicurazione nel corpo dello stesso documento. Stai cercando gli "Elementi azione di sviluppo" e "Elementi di contenuto e presentazione" come ALC_CMC.2.1D e ALC_CMC.2.1C. Aiuta a sapere che cosa cercherà un valutatore, quindi ti invito a leggere la Metodologia di valutazione comune (CEM per gli stessi componenti di sicurezza. Sulla base di ciò che trovi, sarai in una posizione migliore per formulare la giusta serie di domande. Molte di queste domande saranno indirizzate al tuo team di integrazione interna, alcune saranno domande sulle caratteristiche del prodotto. Ad esempio, in EAL4, è necessario avere il controllo automatico degli accessi e integrare l'integrazione (ad esempio ALC_CMC.4.4C e ALC_CMC.4.5C) nel sistema CM. Tuttavia, sarà necessario anche un "piano CM" completo che descriva come il proprio ambiente di sviluppo utilizza il sistema CM (ALC_CMC.4.6C). Questo sarà sviluppato internamente.
Trovo altamente improbabile che trovi un elenco di prodotti che sono "CC Ready (tm)!". Il motivo è perché CC è più preoccupato del risultato finale piuttosto che di come ci si arriva. Pertanto, un foglio di calcolo può essere una forma accettabile di sistema di gestione della configurazione per EAL2 purché esistano politiche e procedure per garantire che vengano applicate. Questo non volerebbe a EAL4. Viceversa, solo perché si utilizza il sistema di gestione del controllo dei codici sorgente di Bell e Whistles (tm) non significa che passerai a EAL2, perché potresti non tenere traccia di tutti gli elementi necessari.