The protection of our development environment and the software services that we provide is crucial to meeting the requirements of our business, and of our customers. Ensuring that security is integral to our development process helps us to minimise the possibility of introducing vulnerabilities into our development systems and software, reducing the risk of data breaches or service unavailability. Management are committed to the security of our application services, and have developed and approved this secure development policy in line with the requirements of the ISO 27001 standard for information security, and our organisation’s business requirements. This document sets out the approved secure development policy so that it can be clearly communicated to all employees, contractors, and third-parties who have responsibilities for developing, managing, and maintaining our software and development environment.
This policy shall apply to the development and administration of all software applications that fall within the scope of our organisation’s ISMS.
All employees, contractors, and third-parties who have responsibility for the design, development, administration, and monitoring of our development environment and software applications shall adhere to this Secure Development Policy. These include, but are not limited to, the following roles:
For the purposes of this document, employees, contractors, and third-parties who carry out these roles shall be collectively referred to as “developers”.
This Secure Development Policy shall be communicated to all employees and agency staff as part of the relevant department training programme, and periodically following any changes to the policy. All contractors and third-parties providing development services or involved in development projects which interact with our services shall be provided with a copy of this policy as part of the process for contracting services. Contractors and third-parties shall be re-issued with updated versions of this policy periodically, and following any changes.
Where a developer performs an activity or activities in breach of this Secure Development Policy, they shall be subject to the disciplinary process documented in the HR Manual, or the applicable service contract.
Management is committed to the continual improvement of our Secure Development Policy, and shall review this document on an annual basis, or whenever an independent review of our organisation’s ISMS reveals a non-conformance or opportunity for improvement. The Management Review shall determine if this policy continues to meet the requirements of our organisation.
Management also endeavours to plan our business operations so that our applications are not misused, either intentionally or unintentionally. This is done by identifying and assigning separate duties and responsibilities to guard against misuses such as fraud, or malicious insider activities, etc. Where a developer identifies potential conflicts or misuse due to improper planning and assignment of duties, developers should raise their concern immediately with their line manager, or the ISMS Manager.
Our organisation recognises the importance of maintaining robust security measures to protect our applications and services against potential vulnerabilities and threats. While malicious attackers constantly seek to exploit weaknesses in software and web-based systems, we are committed to implementing proactive measures to mitigate these risks.
To achieve this goal, developers are encouraged to stay informed about secure coding practices and emerging threats. While adherence to specific training programs such as the OWASP Top 10 standard is beneficial, we understand that different developers may have varying schedules and learning preferences.
Key Points:
No matter which software development methodology is used, our organisation requires that information security considerations and secure coding practices are embedded into the software development lifecycle (SDLC). This section provides guidance for how security is considered at each stage of the SDLC. The policies documented should not be considered exhaustive, and developers may identify additional methods for implementing controls.
The below diagram illustrates how security considerations are typically included throughout the SDLC:
Security Considerations in SDLC Diagram
When determining the functionality of the proposed new service or service update, security considerations must be included as part of the business requirements. The following policies shall apply:
When developing the software service, feature, or application, developers shall ensure security requirements are included in the design stage. By leveraging secure engineering principles, developers will reduce the risk of our services and applications being compromised by malicious attackers. This section documents secure engineering principles that developers should include in the design stage of development. Developers should ensure that they are appropriately trained to understand and implement these principles. Secure engineering principles include, but are not be limited to:
| Principle | Description |
| Data validation | Data validation may include input validation and output encoding. Whitelisting of characters and translation of characters to safe or approved forms provides protection against attacks such as XSS, XFS, SQL injection, buffer overflow, etc. |
| Data minimisation | Data collected, processed, and/or generated by the service, feature, or application shall always be limited to what is absolutely necessary to accomplish the intended purpose. For example, where application logs are generated to identify events about capacity, it may be unnecessary to automatically include user names and their device information in the log data. |
| Authentication | Appropriate authentication mechanisms shall always be used unless the resources or webpages are intended for public access. Requirements for password management are set out in our Information Systems Security Policy, and shall be implemented for all services and users.
Where users of a service, feature, or application will be required to configure their own authentication policies as part of a shared responsibility model, appropriate controls and tools shall be developed and provided so that authoritative users can securely control and manage user accounts. |
| Authorisation | Authorisation controls shall be used to ensure only authorised services and users have access to application resources, accounts, data, and code. Authorisation should be re-validated periodically to ensure access privileges have not changed.
Where users of a service, feature, or application will be required to perform their own access management as part of a shared responsibility model, appropriate controls and tools shall be developed and provided so that users can set and monitor their required levels of access, and ensure access privileges are correct. |
| Secure by default | Default settings for services, features, or applications shall always prioritise user or organisational security so that data is automatically protected. This means that users shall be required to take little or no action to ensure the security of their data, and any automatic sharing of data shall be limited to only what is necessary. For example, a user profile may contain personal contact details, education information, and leave status data. Where only the sharing of contact details is necessary for the proper operation of the application, developers shall not:
The user should have to opt-in, or enable, any additional sharing features, as required. Users should not have to opt-out of, or disable, the sharing of data. |
| Session management | Session management controls help to prevent user impersonation and compromise of session IDs. Session management controls may include:
|
| Fail secure | Where control mechanisms such as authentication, access control, encryption, and system exceptions may fail, they should not fail in an insecure way. For example, where authentication fails due to an exception, the authentication request should be denied. |
| Cryptographic techniques | Encryption and cryptographic keys used to protect data shall meet the requirements for cryptographic control as documented in our Information Systems Security Policy, or where not specifically documented in our policy, they shall comply with the FIPS 140-2 or equivalent standard (https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)
Where users of a service, feature, or application will be required to implement their own cryptographic controls as part of a shared responsibility model, legal, or regulatory requirement, appropriate controls and tools for managing encryption shall be developed and provided to users, where possible. This may include the ability to apply data masking techniques to different types of data, or data storage locations, as appropriate. |
| Error handling | Errors shall be handled securely. Where errors occur, information about the error, and sensitive information such as account and system details, shall not be disclosed in inappropriate ways, such as being displayed back to the user, or included in logs. |
| Logging | Logging should contain the relevant event data such as validation failures, system exceptions, unexpected changes to data, copying and export of sensitive information, etc. Log data should also be protected from unauthorised access in line with our Information Systems Security Policy. |
| File management | Parameter and validation checks should be set for the management of files to prevent upload of unauthorised or unexpected files, etc. |
| Threat modelling | Assists with analysing application components, and identifying and categorising possible threats and requirements for mitigation. This shall also assist in determining security and privacy testing for the service or application so as to proactively secure data and prevent risks from occurring. |
| Data lifecycle protection | Mechanisms for the protection of data shall be implemented with consideration for the full lifecycle of the data to ensure it is appropriately protected from the point of collection to destruction. |
When carrying out development activities, developers shall not only ensure that the security requirements identified from the design stage are implemented in the development stage, but that necessary security controls are applied to protect the development process and the development environment. Secure development requirements include, but are not limited to:
To ensure that the identified security controls are implemented correctly, and to reduce the likelihood of security vulnerabilities going undetected, developers shall plan and carry out security testing in the testing stage. Security testing requirements include, but are not limited to:
When deploying new or modified software services, features, or applications, developers shall ensure that security requirements are built into the deployment stage of the process to protect our information systems and code. Security requirements for deployment include, but are not limited to:
Where it is necessary to outsource development activities to a contractor or third-party provider, our organisation requires that the software, features, and applications developed adhere to our requirements for quality and security. As documented in the communications section of this policy, contractors and third-parties involved in development activities shall be issued with a copy of this document as part of the process for contracting services.
All third-parties involved in development activities shall be managed in line with our Supplier Due Diligence Policy which sets out our requirements for auditing, data agreements, information security controls, technology supply chain, and intellectual property.
