Secure Development Policy

​

Purpose

To ensure that information security is designed and implemented within the development lifecycle for applications and information systems. Neuroscale is committed to the continual improvement of its secure-development practices and of the broader information security management system (ISMS). Improvements are identified and driven through the ISMS management review and the Corrective Action & Continual Improvement Procedure.

​

Scope

All Neuroscale applications and information systems that are business-critical and/or process, store, or transmit Confidential data. Applies to all internal and external engineers and developers of Neuroscale software and infrastructure.

​

Policy

This policy describes the rules for the acquisition and development of software and systems that apply to development within Neuroscale.

​

System change-control procedures

Changes to systems within the development lifecycle are controlled by formal change-control procedures. See the Operations Security Policy and Change Management. Significant code changes must be reviewed and approved via PR by at least one engineer other than the author — typically the Engineering Lead or a designated reviewer in the relevant code-owners list — before being merged into any production branch. See the check-in / PR-review process at Code Review. Branch-protection rules in GitHub enforce this requirement on production branches. Change-control procedures ensure that development, testing, and deployment of changes is not performed by a single individual without approval and oversight.

​

Software version control

All Neuroscale software is version-controlled and synced between contributors. Access to the central repository is restricted based on role. All code is written, tested, and saved in a local repository before being synced to origin. Source of truth is GitHub.

​

Technical review after operating-platform changes

When operating platforms change, business-critical applications are reviewed and tested to ensure no adverse impact on operations or security.

​

Restrictions on changes to software packages

Modifications to third-party application packages are discouraged, limited to necessary changes, and strictly controlled.

​

Secure system engineering principles

Principles for engineering secure systems are established, documented, maintained, and applied to any information-system implementation effort.

​

Secure-by-design principles

• Minimize attack surface area.
• Establish secure defaults.
• Principle of least privilege.
• Defense in depth.
• Fail securely.
• Don’t trust services.
• Separation of duties.
• Avoid security by obscurity.
• Keep security simple.
• Fix security issues correctly.

​

Privacy-by-design principles

• Proactive not reactive; preventative not remedial.
• Privacy as the default setting.
• Privacy embedded into design.
• Full functionality — positive-sum, not zero-sum.
• End-to-end security — full lifecycle protection.
• Visibility and transparency — keep it open.
• Respect for user privacy — keep it user-centric.

Engineering documentation and technical references are maintained in the Engineering standards set, with deeper how-to material on each topic. Software developers adhere to Neuroscale’s coding standards throughout the development cycle, including standards for quality, comments, and security. See Secure coding.

​

Application security requirements

Information-security requirements are identified, specified, and approved during the planning and design phase of any new application, service, or significant feature — and before acquiring third-party application software — rather than retrofitted through testing alone. At a minimum these requirements address: the classification and protection of the data the application handles; authentication, authorization, least-privilege access, and session management; input validation and output encoding; secure logging and the redaction of sensitive data; cryptography for data in transit and at rest per the Cryptography Policy; and the applicable privacy and regulatory obligations for the data and use case. The requirements are recorded with the design or planning artifact and approved by the Engineering Lead — and, for business-critical applications or any application processing Confidential data, by the CISO — before development or acquisition proceeds. Acquisition of third-party application software additionally follows the Acquisition of third-party systems and software section.

​

Secure development environment

Neuroscale establishes and protects environments for system development covering the entire SDLC. The following environments are logically or physically segregated:

• Production
• Test / Staging
• Development

​

Outsourced development

Neuroscale supervises and monitors the activity of any outsourced system development. Outsourced development adheres to all Neuroscale standards and policies.

​

System security testing

Security functionality testing is performed at defined periods during the SDLC. No code is deployed to production without documented, successful test results and evidence of security remediation activities, except for emergency changes per the emergency-change provision in the Operations Security Policy and the Change Management → Emergency change procedure, which require CISO and Engineering Lead approval recorded in the ticket and a post-change retrospective on the timeline set in that policy.

​

Application vulnerability management

Application code is scanned prior to deployment. Application-vulnerability remediation follows the tiered SLAs in the Operations Security Policy — Critical 7 days; High 30 days; Medium 60 days; Low 90 days — measured from confirmation of the vulnerability. Where the Operations Security SLA and any historical reference in this section conflict, the Operations Security tiered SLA controls. Static analysis (SAST) and dependency scanning run on every PR via GitHub Advanced Security and Snyk.

​

System acceptance testing

Acceptance-testing programs and criteria are established for new systems, upgrades, and new versions. Prior to deploying code, a Release Checklist must be completed including all test plans showing completion of associated tests and remediation of issues. See Release checklist.

​

Protection of test data

Test data is selected carefully, protected, and controlled. Confidential customer data is protected per all contracts and commitments. Confidential customer data must not be used or stored in non-production environments per the Data Management Policy → Confidential data, which sets the flat prohibition and the narrow time-bounded CTO + CISO exception path. Where this policy and the Data Management Policy appear to differ, the Data Management Policy controls.

​

Acquisition of third-party systems and software

Acquisition of third-party systems and software is done per the Third-Party Management Policy.

​

Open source, dependencies, and SBOM

Use of open-source software, license review, dependency hygiene, SBOM generation, and outbound contributions are governed by the Open Source & SBOM Policy.

​

AI / generative-AI in development

Use of AI-assisted coding tools, handling of AI-generated code, and the responsible-development obligations for AI features are governed by the AI Acceptable Use Policy.

​

ML system acceptance and release gates

Any production release of a Neuroscale-trained or Neuroscale-deployed AI/ML model — including model retraining, prompt-template changes, or feature-flag rollout that materially changes model behavior — is subject to the standard Release Checklist plus the following ML-specific gates before promotion to production:

• Model card — a current model card per the Model Card schema is on file, reflecting intended purpose, training-data provenance, evaluation metrics, limitations, and human-oversight requirements. For a feature tiered high-risk (Annex III(4) employment AI), the model card additionally carries the deployer instructions-for-use content required by EU AI Act Art. 13 — provider identity and contact details; the system’s characteristics, capabilities, and limitations of performance; the computational and hardware resources required and the system’s expected lifetime; the human-oversight measures; the logging mechanisms and how to interpret the logs; and any predetermined changes to the system and its performance fixed at the time of the initial conformity assessment. This content is prepared and confirmed by the General Counsel before any placement on the EU market, per the high-risk provider obligations in the AI Acceptable Use Policy → Regulatory compliance, and is recorded in the AI Model Registry.
• Eval thresholds met — accuracy, robustness, and (for high-risk recruiting-AI features) sub-population performance meet the documented threshold; the eval result is attached to the release ticket. See AI Evaluation.
• Bias / disparate-impact check — for AEDT / employment-AI features, the four-fifths-rule and selection-rate metrics are within tolerance per the bias-audit program; deviations are flagged for CISO review prior to release.
• Logging & monitoring — input/output logging, drift indicators, and override-rate tracking are wired and verified.
• Approver — the CISO (or designate) signs off on first production release of any high-risk feature; subsequent material changes require the same sign-off. Sign-off is recorded in the release ticket.

These gates are documented in the release ticket and filed alongside the standard Release Checklist evidence for SOC 2 / ISO 27001 audits.

​

Developer training

Software developers are provided secure-development training appropriate to their role at least annually. Training addresses common web-application attacks and vulnerabilities including:

• Authorization-bypass attacks.
• Insecure session IDs.
• Injection attacks.
• Cross-site scripting (XSS).
• Cross-site request forgery (CSRF).
• Use of vulnerable libraries.

Training is delivered through Vanta.

​

Exceptions

Requests for exceptions must be submitted to the CISO for approval.

​

Violations & enforcement

Report violations to the CISO. Violations may result in suspension of system and network privileges and disciplinary action up to and including termination.

​

Version history