Secure Development Lifecycle (SDL)
- Last Updated: 8 Mar 2026
- Next Review: 1 Jul 2026
This page describes the security practices embedded across our software development lifecycle. These practices apply to all engineers working on Enprivacy 3.0 and are enforced through a combination of tooling, process gates, and training.
Security Training
Section titled “Security Training”- All engineers complete security awareness training on joining and annually thereafter.
- Engineers working on sensitive subsystems (auth, cryptography, data handling) complete additional OWASP training.
- Training completion is tracked and reported to leadership.
Threat Modelling
Section titled “Threat Modelling”We conduct threat modelling for:
- New features that introduce a significant attack surface (network-exposed endpoints, new authentication flows, data processing changes).
- Changes to the deployment architecture.
- Third-party integrations.
Threat models are documented and reviewed by at least one member of the security team before the feature ships.
Secure Coding Standards
Section titled “Secure Coding Standards”We maintain internal secure coding guidelines that cover:
- Input validation and output encoding
- Authentication and session management
- Authorisation and access control
- Cryptography (approved algorithms, key lengths, and libraries)
- Error handling and logging (avoiding sensitive data in logs)
- Dependency usage (see Supply Chain Security)
Guidelines are reviewed annually and updated when new vulnerability classes emerge.
Code Review
Section titled “Code Review”- All code changes require at least 1 peer review(s) or Claude review before merging.
- Security-relevant changes (auth, crypto, privilege escalation paths, external input handling) require review by a qualified security reviewer.
- Our code review checklist includes security-specific checks.
- Automated tooling (SAST, secret scanning, dependency audit) runs on every pull request and must pass before merge.
Static and Dynamic Analysis
Section titled “Static and Dynamic Analysis”| Tool type | Tooling used | Trigger |
|---|---|---|
| SAST | CodeQL | Every PR |
| Secret scanning | GitHub Secret Scanning | Every commit |
| Dependency audit | Dependabot | Daily + every PR |
| DAST | OWASP ZAP | Pre-release |
| Container scanning | Trivy | Every build |
Critical findings block merge or release until resolved or formally accepted with a documented rationale.
Vulnerability Management
Section titled “Vulnerability Management”Internal Discovery
Section titled “Internal Discovery”Vulnerabilities identified through our own tooling or reviews are tracked in our internal issue tracker and security backlog with the following SLAs:
| Severity | Triage SLA | Remediation SLA |
|---|---|---|
| Critical | 24 hours | 7 days |
| High | 3 business days | 30 days |
| Medium | 5 business days | 90 days |
| Low | 10 business days | Next release cycle |
External Reports
Section titled “External Reports”We operate a responsible disclosure programme. See our Vulnerability Disclosure Policy for how to report and what to expect.
Secrets Management
Section titled “Secrets Management”- Secrets (API keys, credentials, certificates) are never stored in source code or configuration files committed to version control.
- Development secrets are managed via local development tooling (such as mise.local.toml and .env files excluded by .gitignore).
- Production secrets are managed via appropriate cloud service provider secret and key management systems for any production workloads.
- Secret rotation schedules are defined and enforced for all long-lived credentials.
Change Management and Release Gates
Section titled “Change Management and Release Gates”Before a release is published:
- All open critical and high vulnerabilities are resolved or formally accepted.
- SAST, dependency audit, and container scan results are reviewed.
- Penetration test findings (if a test cycle coincides) are addressed.
- Changelog and security advisory (if applicable) are drafted.
- Release artifacts are signed.
Penetration Testing
Section titled “Penetration Testing”We commission external penetration tests of Enprivacy 3.0 annually, and additionally following significant architectural changes. Reports are available to customers under NDA on request.
Security Incident Response
Section titled “Security Incident Response”Our internal incident response process covers vulnerabilities in Enprivacy 3.0. In the event of a confirmed vulnerability affecting customers:
- We notify affected customers via email within 3 days of confirmation.
- We publish a CVE (where applicable) and a security advisory at CVE Database.
- We provide patched release artefacts and clear upgrade guidance.
Compliance Mapping
Section titled “Compliance Mapping”| Framework / standard | Status | Notes |
|---|---|---|
| OWASP Top 10 | Addressed in coding standards | See secure coding guidelines |
| NIST SSDF | Aligned | — |
| SOC 2 Type II | Aligned but not certified | Enprivacy plans to undertake this certification in due course |
| ISO 27001 | Aligned but not certified | Enprivacy plans to undertake this certification in due course |