Secure Development Policy

1. Policy Statement

Skoolfly builds security into its development lifecycle. This policy defines the requirements for designing, coding, testing and deploying the platform securely, reducing the likelihood and impact of vulnerabilities.

2. Purpose

The purpose of this policy is to embed security at every stage of software development and delivery, protect the data Skoolfly processes, and support the secure-development commitments made in the Information Security Policy.

3. Scope

This policy applies to all software, applications and configuration developed, modified or maintained by or on behalf of Skoolfly, including internal tools, integrations and AI-assisted functionality.

4. Secure Development Lifecycle

Security considerations are incorporated in planning, design, development, testing, release and maintenance.

Risks are identified early rather than treated as an afterthought.

Security activities scale to the risk of the change being made.

Developers own the security of the code they deliver.

5. Threat Modeling and Design

Significant features and architectural changes are assessed for threats during design. Considerations include authentication and authorisation, data validation, data exposure, injection risks, rate limiting, secrets, and privacy impact. Higher-risk changes receive documented threat models.

6. Secure Coding Standards

Code treats all external input as untrusted and validates, sanitises or parameterises it.

Authentication and authorisation checks are enforced on the server side, never relying on client-side rules alone.

Output is encoded to prevent injection and cross-site scripting.

Error handling avoids disclosing sensitive information.

Security-sensitive logic follows platform security guidelines and approved patterns.

Privacy and least-privilege principles from the Data Protection and Access Control policies are applied to features and data access.

7. Dependencies and Third-Party Code

Third-party libraries and packages are kept up to date and checked for known vulnerabilities.

Dependencies are added deliberately and with a minimal-footprint approach.

Untrusted or abandoned packages are avoided or replaced.

Licensing and provenance of third-party code are considered.

8. Secrets Management

Credentials, API keys and tokens are stored in an approved secrets mechanism, not in code or configuration repositories.

Secrets are rotated and reviewed periodically and immediately when compromise is suspected.

Access to secrets is limited to those who need it and is logged.

9. Code Review

Changes are reviewed by peers before deployment. Reviews check for logic errors, security issues, data handling risks and consistency with this policy. Security-critical changes receive additional attention.

10. Security Testing

Automated scanning (including static analysis and, where applicable, dynamic analysis) is applied to find common vulnerabilities.

Manual security review is applied to high-risk changes.

Application and dependency vulnerabilities feed into the Vulnerability Management Policy.

Testing considers authentication, authorisation, input handling, data exposure and rate-limiting risks.

11. AI-Assisted Development

Where AI tools assist development, generated code is treated as untrusted by default and undergoes the same review and testing as any other change. AI-assisted code that handles data must comply with this policy and the platform's data handling rules.

12. Change Management and Deployment

Releases follow a defined process with environment separation between development, testing and production.

Changes are tested before production deployment.

Deployments are reversible and monitored for issues after release.

Environment configuration differences are managed to avoid security drift.

13. Roles and Responsibilities

14. Training

Development personnel receive appropriate security training, including secure coding fundamentals, threat awareness and updates to frameworks and security practices.

15. Compliance and Enforcement

Non-compliance may result in findings being blocked from release, corrective action or other measures. Compliance is reviewed through audits and security assessments.

16. Review

This policy is reviewed at least annually, or when development practices, frameworks or threat landscapes change significantly.