SLAs with Software Provider

Scope “…declare the rights and responsibilities between EGI.eu and the Software Provider for a particular component.” Which project/entity is the SLA with? Who are the SLA contacts? – Technical and Managerial contact points – Designated representation on the MCB What does it cover? – Agreed list of components (e.g. GridFTP Server/Client, GSISSH Server/Client, CREAM Server/Client, gLExec, …) and descriptions – ??? How will these components be delivered – meta-package? Multiple agreements may be in place between EGI.eu and the Software Provider at any one time. Duration – Expiry and review dates

EGI.eu Agrees to: Inform the Software Provider of issues reported to EGI.eu relating to the use of the software components in its production environment. – Access to GGUS Include the Software Provider in the triaging of issues reported through the use of their software in the infrastructure coordinated by EGI.eu. – Meeting linking MU (DMSU) and the Software Providers Provide requirements to the Software Provider for new features requested from their component and to indicate which features EGI.eu sees as a priority for its users. – Written (GGUS, document, …) set generated through the MCB Provide the Software Provider with generic acceptability criteria that relate to all the software components being contributed to EGI.eu. – Written specification (e.g. baseline set of RPMS, other issues) Provide the Software Provider with specific acceptability criteria that relate to their software component. – Written performance criteria, etc. Define for the Software Provider the environments that the software components need to be delivered to work in (e.g. SL5). – In writing as part of release requirements. Contact point for issues raised by the software provider – With expected response time – 2 wd?

Software Provider Agrees to General Software Issues Roadmap Acceptance Criteria Security Exceptions

General Define a technical and managerial contact point for a component who are both able to provide definitive useful answers to any issues raised or to respond to any documents circulated within 5 working days. – /phone, – Contact points may be defined per component or the same for all points. – TODO: Issue classification and response time Provide a security contact for each identified software component that will participate in the Software Vulnerability Group (following their processes) and other security related software activity (e.g. SVG Deputy Coordinator, Risk Assessment Team, security training, etc.) – /phone To notify the EGI MU when a release is available and where the relevant binary and source code packages can be obtained from. – Process defined using the software repository provided by EGI.eu

Software Issues Provide an issue tracker that is accessible by the EGI.eu MU – must use GGUS or an issue tracker integrated into the GGUS infrastructure. – To be defined by the software provider – TODO: Agree state mappings between software provider issue tracker and the GGUS state model. To respond to any assigned issues within the following timescales depending on the issue severity: – Critical / Emergency: 1 working day – Other: Move into the release schedule? – gLIte: Immediate (i.e. emergency), High (must be in the next revision release), – Who sets the priority? Need to put the priority within the context of other agreed work – EXPLORE FURTHER – NEEDS TO BE A LOT OF CLARIFICATION PARK THIS: Deliver a new version of an existing released component which just includes a provided patch within 1 working day – What if the provided patch does not work? – What is a reasonable response time (inc. review, build and test time) given the severity of the fix? – Would not bypass stage rollout

Roadmap Provide an updated roadmap to the EGI.eu MU every 3 months showing the major & minor software releases planned for the component(s) during the lifetime of the SLA including the new functionality they will contain and the communities it will benefit (linked back the previously described MCB requirements). To identify which releases will be incompatible with previous releases.

Acceptance Criteria Acceptance criteria defined by MU and approved by MCB – N/A to emergency releases To advise EGI.eu on the effort and time required to implement any changes to the generic or specific acceptance criteria. To provide to EGI.eu documentation of the test plan and the results of running the test plan for each release of a software component. Any software that forms part of the test plan around a release must also be made available. The test plan relating to an upcoming release must be delivered to EGI.eu MU at least 20 working days before the planned release for review. – EGI.eu to give feedback within N days. – Minor releases with new functionality need to provide testplan Days mentioned in the template Actual figures in the SLA

Security Issues (Put into Acceptance Criteria?) To document threat assessments and security reviews in the design process and provide this documentation to EGI.eu. – Limited disclosure. More discussion on how to implement and ramp this up. To document in the design process the tradeoffs that are made between security and performance/usability and passed back to EGI. – Disclosure limits? To co-operate with the investigation of potential vulnerability issues in their software. Responding within at most 1 working day. Part of SVG. – Confidentiality. Link into SVG process. To report any security vulnerabilities in software already released to EGI within 1 working day of it being found by the software provider or if they are informed of it through sources other than EGI. – Disclosure Limits. Report into SVG. All security vulnerabilities will be treated as a ‘critical issue’ (see earlier for response time and process) however disclosure of the issue will be restricted until a patch is available. – By following the SVG process.

Escalation Perceived failures to comply with the provision of this agreement must be reported to the EGI.eu CTO and the >. Failures of this agreement must be reported to the EGI.eu Director & >. Further escalation to the EGI.eu EB. Failure of the software provider to comply with aspects relating to technical issues and the provision of patches in the stated times will, if time critical, remove the obligation for EGI.eu to consult with the software provider and vice versa.

Deleted To ensure only adequately qualified and experienced developers able to write secure, efficient, reliable software are working on the software and that they remain trained in current best practices (e.g. secure coding).