Secure development policy

1. Purpose

This policy defines how security is built into the software HLD Group develops, across the full development lifecycle. Building security in — rather than testing it in at the end — reduces vulnerabilities, cost, and risk to customers.

2. Scope

This policy applies to all software developed by HLD Group, for internal use and for customers, and to the personnel, pipelines, and dependencies involved in building it.

3. Secure development principles

• Security requirements are defined alongside functional requirements
• Threat modelling is performed for significant features and architectural changes
• Secure coding standards are followed and enforced at review
• Security is verified continuously through automated and manual testing
• Least privilege, secure defaults, and defence in depth are applied by design

4. Secure design and threat modelling

Significant features are threat-modelled to identify risks and design mitigations before implementation. Security-relevant design decisions are documented, and sensitive designs are reviewed by the security function.

5. Secure coding and code review

• Coding standards address common vulnerability classes, including the OWASP Top 10
• All code is peer-reviewed before merge, with security-sensitive changes receiving additional scrutiny
• Secrets are never committed; automated secret scanning enforces this
• Dependencies are vetted, kept current, and monitored via software composition analysis

6. Security testing in the pipeline

• Static application security testing (SAST) on every change
• Dynamic application security testing (DAST) for running applications
• Software composition analysis and container image scanning
• Security tests as release gates, with failures blocking promotion

7. Supply chain and build integrity

• Build pipelines are secured, with least-privilege credentials held by the pipeline, not individuals
• Artefact integrity is protected, and provenance is recorded where practicable
• Third-party and open-source components are inventoried in a software bill of materials

8. Environment separation and deployment

Development, staging, and production are separated, and changes reach production only through the Change Management Policy. Production data is not used in lower environments unless masked or synthesised.

9. Framework alignment

• NIST SP 800-218 (Secure Software Development Framework)
• OWASP SAMM, OWASP ASVS, and the OWASP Top 10
• ISO/IEC 27001:2022 Annex A controls 8.25 to 8.31 (secure development lifecycle)
• SLSA supply chain integrity levels; SOC 2 Trust Services Criteria CC8.1

10. Roles, exceptions, and review

Engineering owns secure development under the CISO. Exceptions require documented CISO approval with compensating controls and an expiry date. This policy is reviewed at least annually.