Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

SVG:Deployment Expert Group

From EGIWiki
Jump to navigation Jump to search
Main page Software Security Checklist Issue Handling Advisories Notes On Risk Advisory Template More

Deployment Expert Group


The Deployment Expert Group are people who volunteer to help the EGI SVG deal with vulnerabilities where they have appropriate expertise.

The aim is to keep the high standard of handling software vulnerabilities which we have established over more than a decade in the ever increasingly inhomogeneous infrastructure.

This is updated after discussion at the SVG meeting on 26th February 2020, further edited after discussion at SVG meeting on 15th July 2020. We will try and keep the role and responsibilities of the DEG as simple and straightforward as possible, we see the following as the main tasks:--

Look out for and report vulnerabilities in software you use

It is important that DEG members are alert to software vulnerabilities announced by the providers of software they deploy, and report via report-vulnerability@egi.eu any they consider serious and relevant to EGI. In addition, vulnerabilities DEG members discover themselves should also be reported via report-vulnerability@egi.eu. Members may of course also report them to the software provider, if able to do so without exposing the vulnerability publicly. Alternatively, SVG will be happy to handle that for you.

Respond when asked if an issue is 'In Scope'

Sometimes when a vulnerability is reported, SVG-RAT members are not aware of whether the software is used. Please respond to this question when you know the answer, particularly if you use the software. If there is no response confirming an issue is in scope, it typically implies we will not look further into it. If there was agreement that the issue should indeed be out of scope, it will be labeled as such. If there was no conclusion (e.g. due to lack of response), that outcome will be recorded instead. Scope depends on participation.

Volunteer for the iRAT if you have expertise

If an issue is considered to be 'In Scope', we will ask for volunteers to join the issue-specific RAT, or iRAT. This is probably the most important function of the DEG. Investigating the impact of vulnerabilities depends on getting appropriate members of the iRAT to look at the issue and its potential effects, according to how the corresponding software is deployed.

Also Note

Anyone can report a vulnerability, they do not have to be a member of SVG or the DEG.

It is in the interest of those who select and deploy services to join the DEG, and respond when asked if software is in scope, to ensure that if software is deployed it is treated as in scope. This will reduce the risk to their services from vulnerabilities.


Anyone deploying services should consider good practice when selecting and configuring software. SVG has produced a simple software security checklist to try and avoid some of the common problems we have found in the past: SVG:Software_Security_Checklist in EGI Wiki.