Principle 1.1 Follow an established secure development framework
Reference
 Principles/Claims
Evidence
Claim 1.1.1
The development framework used is documented.
Each technology stack is documented both against the frameworks/codebases in Version Control systems and within intranet articles. Best practices and patterns are documented and processes follow these. Code Reviews/Merge Requests are enforced and these ensure work is checked in detail to ensure these are followed.
Claim 1.1.2
Developers are trained in the use of the framework and tools.
On-boarding training for all new developers ensure they are given dedicated training against the technologies they will work with before they gain access and can contribute.
Claim 1.1.3
Tools are maintained and updated.
IDEs and development tools are updated as licenses allow. All other software is monitored to ensure it is up to date for any vulnerabilities. Developed and managed software GOSS delivers is monitored for CVEs and is updated either for routine security requirements or as part of support and maintenance tasks.
Claim 1.1.4
Items requiring configuration control are identified and version control is used.
Version control is used for web application configuration. Content based configuration is stored within environments and a history is preserved. Server configuration files are backed up routinely.
Claim 1.1.5
Requirements are captured and recorded.
JIRA requirements are captured. Documents provided or created are stored in SharePoint/document stores/Version control as appropriate. Internal support focused project documentation is created and stored within the GOSS intranet.
Claim 1.1.6
Software is designed for user need.
Yes. BA's, Client Success and Developers design and deliver software based on user requirements. QA and UAT assess this before delivery. Regular demonstrations and touch points are scheduled to ensure potential issues are identified early.
Principle 1.2 Understand the composition of the software and assess risks linked to the ingestion and maintenance of third-party components throughout the development lifecycle
Reference
Principles/Claims
Evidence
Claim 1.2.1
All third-party components are identified and documented.
Dependencies within web applications are automatically stored and can be searched, including specific version numbers within orchestration API. Deployed versions are known and searchable. Technical teams manage repositories of third-party components listed/supported. Libraries made available within the platform are publicly documented.
Claim 1.2.2
Integrity of third-party components and updates is verified.
Private repositories are used. NPM, Maven and Nuget repositories are maintained. External hash/integrity checking on new libraries being introduced are undertaken by developers when needed.
Claim 1.2.3
Each third-party component is tested before being first deployed.
Yes, all delivered components must go via QA and UAT. All releases must be tested then staged through non-live to live environments.
Claim 1.2.4
Third-party component updates are tested.
Yes as per claim 1.2.3
Claim 1.2.5
Processes are in place to manage and deploy updates to third-party components.
All teams have processes in place to manage and deploy updates to third-party components. All releases are staged through environments regardless of team or differing technology stacks/specialisations.
Principle 1.3 Have a clear process for testing software and software updates before distribution
Reference
Principles/Claims
Evidence
Claim 1.3.1
A test plan exists that covers all requirements and third-party components.
Unit tests and other automated testing mechanisms are run and prevent releases if failures occur, via CI/CD triggers. Developers test as they build. QA teams write test plans to meet acceptance criteria and to find any critical faults. QA phases must be signed off before releases are signed off and created.
Claim 1.3.2
Execution of the test plan is automated and repeatable wherever possible.
CI/CD product tests are automated and are scheduled to run regularly. Results of automated test runs are analysed. Any failed tests are reported as defects or where required test code is revised to reflect intended updates to the software. Software updates in the Digital Platform follow a documented testing procedure. Releases of the Digital Platform follow a documented testing procedure
Claim 1.3.3
Defects identified during testing are addressed.
Defects are reported, triaged and addressed based on priority or impact. Unresolved defects will often block releases until the issue has been rectified. Confirmation testing will be conducted alongside any appropriately scoped regression testing to ensure the fix has been successful. When internal quality gates have been satisfied, the release can proceed. At times an unresolved defect may be deemed as non-blocking. These will be scheduled for remediation following the release. Lower-risk defects may be deferred, accepted as known limitations, or scheduled for future remediation following assessment of severity, security impact and business risk. All identified defects remain tracked within internal systems until resolved, accepted, or otherwise formally closed.
Principle 1.4 Follow secure by design and secure by default principles throughout the development lifecycle of the software
Reference
Principles/Claims
Evidence
Claim 1.4.1
Techniques to understand how the software might be exploited (threat modelling) have been used in the design of the software.
Secure by design implemented by all teams. Yearly OWASP training/updates are given to concrete this. Penetration testing conducted on systems yearly. Defence in depth implemented to ensure single failure points are mitigated. Common threats are tested where possible/sensible. Systems enforce certain patterns to prevent threats such as enforced encoding to prevent XSS, enforced parameterisation to prevent SQL injection etc
Claim 1.4.2
Multi-factor authentication for privileged users of the software is enforced.
Yes - Authentication system dependent for public facing systems. MFA is enforced for privileged access to development, build, administrative and production systems. Where software integrates with client-managed identity providers, enforcement of MFA for clients' users remains under client's control.
Claim 1.4.3
Default (and persistent) passwords are not used.
Yes - Randomly generated and password rules are enforced. Password rotation schemes are in place.
Claim 1.4.4
Data input to the software is validated.
We use a layered validation strategy: client-side checks for immediate user feedback, backed by rigorous server-side validation to ensure data integrity and security. Data supplied to the software is validated according to business and security requirements. Validation controls include data type validation, length checks, format validation, server-side validation, input sanitisation and parameterised database queries where applicable.
Claim 1.4.5
Credentials and sensitive data are securely stored.
Application credentials, secrets and sensitive data are stored using appropriate cryptographic controls. Network segmentation is in place to minimise attack surface. Network rules and firewalls defend databases and storage locations.
