This theme ensures that the software remains secure throughout its lifetime. The use of appropriate mechanisms and processes for managing and deploying updates to software reduces the likelihood of errors and vulnerabilities persisting in the software.
Principle 3.1 Distribute software securely to customers
Reference
Principles/Claims
Evidence
Claim 3.1.1
The integrity of software (including updates) can be verified in the customer environment.
Yes, the service is delivered as a centrally hosted SaaS platform. Customers do not install or maintain software components locally. Software releases are deployed directly into vendor-managed cloud infrastructure using controlled CI/CD processes. Integrity controls are implemented within the deployment pipeline rather than the customer environment.
Claim 3.1.2
Software (including updates) is distributed over trusted channels.
Yes, all software is deployed securely via Automation teams and are internal services.
Principle 3.2 Implement and publish an effective vulnerability disclosure process
Reference
Principles/Claims
Evidence
Claim 3.2.1
A vulnerability disclosure policy and process is published.
Yes a vulnerability disclosure policy and process is published on out GOSS website: https://www.gossinteractive.com/article/18168/Vulnerability-disclosure
Claim 3.2.2
The vulnerability disclosure process describes how to confidentially report vulnerabilities.
The vulnerability disclosure process describes how to confidentially report vulnerabilities on the GOSS website
Principle 3.3 Have processes and documentation in place for proactively detecting, prioritising and managing vulnerabilities in software components
Reference
Principles/Claims
Evidence
Claim 3.3.1
Knowledge of public vulnerabilities is kept up to date.
Yes, CVEs and KEVs are actively monitored by team leads. Security concerns or issues are raised and actioned by relevant teams as they are detected.
Claim 3.3.2
A vulnerability management plan exists that assesses and prioritises responses to vulnerabilities.
Vulnerabilities are managed through documented security and incident management processes. Vulnerabilities identified through scanning, penetration testing, client reports or public advisories are risk assessed, prioritised according to severity and business impact, assigned to responsible teams and tracked through to remediation within the GOSS system.
Principle 3.4 Report vulnerabilities to relevant parties where appropriate
Reference
Principles/Claims
Evidence
Claim 3.4.1
Internal security teams are informed
As part of incident reporting, vulnerability is logged and assigned to the appropriate security, technical and management personnel for assessment, remediation and tracking. Notifications and actions are recorded within the organisation's ticketing and incident management systems.
Claim 3.4.2
Affected customers are informed
Where a vulnerability is assessed as having the potential to affect clients or clients' data, communications are coordinated through the Incident Management process. Impacted clients are notified in accordance with contractual, regulatory and legal requirements, including details of the vulnerability, potential impact and remediation activities where appropriate.
Principle 3.5 Provide timely security updates, patches and notifications to customers
Reference
Principles/Claims
Evidence
Claim 3.5.1
Security updates are distributed as soon as is practicable.
Yes, where practical and where security vulnerabilities have been detected then teams prioritise security focused updates over other tasks.
claim 3.5.2
Security updates are tested and secure by default.
Yes. Security updates go through the same testing, approval and deployment processes as other software releases. Updates are deployed using established secure release procedures to maintain secure default configurations.
