Hi! Vulnerability assessment is continously happening. It is a common estimation that the public sees its results with some two months delay in average. Actually the other assurance measures are invented to have as few facts to be found by AVA, as possible.
AVA_CCA.1 Covert channel analysis (EAL5) I do not cover this topic here, as one can get even EAL4 without it. Hopefully firewall vendors will realise sooner or later, that their products have no protection without doing their homework in this area. (I count myself as one of them.) AVA_MSU.2 Validation of analysis (EAL4, EAL5) AVA_MSU.2.1D The developer shall provide guidance documentation. (See AGD) AVA_MSU.2.2D The developer shall document an analysis of the guidance documentation. (This is the new one. I doubt that any OSS products have it) AVA_MSU.2.1C The guidance documentation shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation. (An often lacking element of docs.) AVA_MSU.2.2C The guidance documentation shall be complete, clear, consistent and reasonable. (It is everyone's long term goal:) AVA_MSU.2.3C The guidance documentation shall list all assumptions about the intended environment. (As stated in AGD, and shall be found in ST.) AVA_MSU.2.4C The guidance documentation shall list all requirements for external security measures (including external procedural, physical and personnel controls). (This is drawn from the list of objectives against te non-it environment from the ST.) AVA_MSU.2.5C The analysis documentation shall demonstrate that the guidance documentation is complete. (hmm..) AVA_SOF.1 Strength of TOE security function evaluation (EAL2-EAL7) AVA_SOF.1.1D The developer shall perform a strength of TOE security function analysis for each mechanism identified in the ST as having a strength of TOE security function claim. (Fortunately it is a well-researched area. One can find research papers analysing the strength of the cryptographic functions widely used. The minimum pasword complexity/key lengths should only be set according to them, which can be made a requirement against the environment and documented in the guidance.) AVA_SOF.1.1C For each mechanism with a strength of TOE security function claim the strength of TOE security function analysis shall show that it meets or exceeds the minimum strength level defined in the PP/ST. (see above) AVA_SOF.1.2C For each mechanism with a specific strength of TOE security function claim the strength of TOE security function analysis shall show that it meets or exceeds the specific strength of function metric defined in the PP/ST. (See above) AVA_VLA.2 Independent vulnerability analysis (EAL4) AVA_VLA.2.1D The developer shall perform a vulnerability analysis. (We all think about ways to overcome the defence of our program. Let's call it vulnerability analysis:) AVA_VLA.2.2D The developer shall provide vulnerability analysis documentation. (Write down what did you thought about.) AVA_VLA.2.1C The vulnerability analysis documentation shall describe the analysis of the TOE deliverables performed to search for ways in which a user can violate the TSP. The vulnerability analysis documentation shall describe the disposition of identified vulnerabilities. (look ad docs, fix if you find something, and document it.) AVA_VLA.2.2C The vulnerability analysis documentation shall show, for all identified vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE. The vulnerability analysis documentation shall justify that the TOE, with the identified vulnerabilities, is resistant to obvious penetration attacks. (This is the type of security advisory that claims that "our system is not vulnerable", or "our system is not intended for that type of use", but in the docs this time.) This time I list an evaluator action element, as this is the main point: AVA_VLA.2.3E The evaluator shall perform an independent vulnerability analysis. (We have plenty of evaluators, they perform it, but often fail to tell it to others:) Nonetheless there are plenty of position papers telling that a strength of open source is opennes to independent vulnerability analysis. And they are true.) -- GNU GPL: csak tiszta forrásból