SECURE ENGINEERING
Secure software development lifecycle
How MedTalk designs, builds, tests, and releases software securely across the MedTalk AI platform.
Purpose and scope
This policy defines how MedTalk designs, builds, tests, and releases software securely across the MedTalk AI platform. It applies to all engineering staff, contractors, and automated pipelines involved in developing, deploying, or maintaining MedTalk AI, and covers the full lifecycle from design through to production release and ongoing maintenance. It is enforced consistently across MedTalk's engineering organisation and complements MedTalk's Information Security Policy, Vulnerability Management Policy, and Third-Party Security Policy.
Secure development principles
Security by design
Security requirements are considered from the earliest stage of feature design, not retrofitted after implementation. Every new feature or architectural change that touches clinical data, authentication, or data storage undergoes a security design review before development begins.
Threat modelling
MedTalk applies structured threat modelling to significant architectural changes, using a STRIDE-based approach to identify spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege risks. Threat models are reviewed by the CISO or a delegate, with outcomes fed directly into the engineering backlog as tracked security requirements.
Secure coding standards
- OWASP ASVS: application code is developed against the OWASP Application Security Verification Standard, targeting Level 2 controls for components that process clinical or identifying data
- OWASP Top 10: engineering teams are trained on, and code review checklists reference, the current OWASP Top 10 web application security risks
- Language and framework standards: secure coding guidance is maintained for each primary language and framework in use, covering input validation, output encoding, parameterised queries, and safe deserialisation
Dependency and supply chain security
- Software Composition Analysis (SCA): all third-party libraries and packages are scanned automatically on every build to identify known vulnerabilities and licence risks
- Dependency management: dependencies are pinned to specific versions, reviewed before introduction, and updated on a regular cadence rather than left to drift; critical vulnerabilities are remediated under the same 48-hour Critical-severity SLA as application code
- Static Application Security Testing (SAST): source code is scanned automatically on every pull request to identify insecure coding patterns before merge
- Dynamic Application Security Testing (DAST): running application instances in staging are scanned periodically to identify runtime vulnerabilities not visible through static analysis alone
Secrets management
Credentials, API keys, and other secrets are never stored in source code or configuration files committed to version control. Secrets are managed centrally via AWS Secrets Manager and AWS Key Management Service, with access scoped to the specific service or pipeline that requires it. Automated scanning checks every commit for accidentally committed secrets before it reaches a shared branch.
Code review and change control
- Mandatory code review: no code reaches a production branch without independent review and approval by at least one other engineer
- Pull request approval: pull requests require passing automated checks (build, test, SAST, dependency scan) in addition to human review before merge is permitted
- Branch protection: production and release branches are protected, direct pushes are disabled, and merges require the mandatory review and check gates above to pass
CI/CD, infrastructure and container security
- CI/CD pipeline security: build and deployment pipelines run with scoped, short-lived credentials rather than long-lived access keys, with pipeline configuration changes following the same review and approval controls as application code
- Infrastructure as code security: infrastructure is defined and deployed as code, with automated policy checks applied before provisioning to catch misconfigured network exposure, over-permissive access, or unencrypted storage
- Container security: container images are built from minimal, version-pinned base images, scanned for known vulnerabilities before deployment, and run under least-privilege task roles on Amazon ECS Fargate
Release and vulnerability management
| Release type | Approval requirement | Testing requirement |
|---|---|---|
| Standard Release | Engineering Lead and CISO delegate sign-off | Full automated test suite, SAST, dependency scan, staging validation |
| Emergency Release | CISO or Engineering Lead expedited approval, retrospective CAB review within 5 business days | Targeted regression testing for the affected component; full suite run post-deployment |
Vulnerabilities identified in application code, dependencies, or infrastructure follow MedTalk's severity classification and remediation SLA: Critical within 48 hours, High within 14 days, Medium within 60 days, and Low addressed during routine release cycles.
Developer training and continuous improvement
- Developer training: engineering staff complete secure coding training at onboarding and on a recurring basis, covering the OWASP Top 10, secrets handling, and MedTalk's secure development standards
- Security testing: in addition to automated pipeline scanning, MedTalk commissions independent penetration testing on a bi-annual basis
- Continuous improvement: findings from code review, security testing, and incident post-reviews are tracked to closure and fed back into this policy and MedTalk's secure coding standards on an ongoing basis
Contact
Security & Compliance: support@medtalk.co
Legal / compliance: legal@medtalk.co