A simplified overview of the main SHIELDS components and actors is shown below.

The heart of SHIELDS is the security vulnerability repository service (SVRS) and its contents, providing the information needed to detect, remove and prevent vulnerabilities in software, independent of the applied development process.

To generalize and create classes of vulnerabilities we need to start from instances, which need to be modelled, stored, and shared. Note that for a new vulnerability instance that may not have a class (i.e. the instance doesn't match any of the existing classes in the repository) it is crucial that developers have access to a model of that vulnerability instance in order to prevent it.

The information in the repository will contain:

• Information about vulnerability classes and instances (represented as models that detail and formalize vulnerability causes).
• Information about activities (countermeasures and remedies) that should be implemented to prevent the vulnerabilities in software development (models that detail how to prevent each of the causes of a vulnerability, linked to remedies such as test vectors, recognition rules for dataflow analysis, etc.).

The actors involved in SHIELDS can be grouped into three classes of stakeholders: providers, those who provide vulnerability information to the repository; subscribers, those who retrieve information from it; and the archive manager, who is responsible for controlling and maintaining the content and services of the SHIELDS SVRS.

Vulnerability modelling tools will help providers analyse and model formalised software vulnerability information, which is largely a manual task requiring human intelligence, by offering notation and syntax checks and repository interaction support. SHIELDS will build on an existing modelling tool provided by LiU using vulnerability cause graphs.

Development tools connect and retrieve information from the SVRS, thereby staying constantly up-to-date with the latest security knowledge and providing developers and quality assurance staff with the latest information at their fingertips. These are both standalone security tools and IDE-extensions building on existing technology and prototypes from several of the partners, and comprise two branches:

• Semi-automated tools to help during requirements specification and design. Manual methods (where tools are not possible) will be suggested from the SVRS based on the specific software under development.
• Automated tools relying on the SVRS for finding vulnerability instances and classes during implementation and testing, and ways to mitigate the problems. The SVRS will provide the possibility of downloading models and automatically generate/execute specific test cases according to the model.

The development tools may also provide information back to the SHIELDS SVRS, informing about the effectiveness and providing real statistics on vulnerability occurrences.

SHIELDS will operate in an open, distributed environment, and will be based on standard compliant federation protocols (e.g. SAML 2.0) and identification services, and allow the use of established available technologies (e.g. the BANDIT authentication and access control system) in order to provide access to a wide users community (e.g. by using the ECLIPSE Higgins framework and technologies).