Secure Development Policy

​

Purpose

To ensure that information security is designed and implemented within the development lifecycle for applications and information systems.

​

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 live in the Engineering tab of this site, with deeper how-to material on each topic listed there. Software developers adhere to Neuroscale’s coding standards throughout the development cycle, including standards for quality, comments, and security. See Secure coding.

​

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.

​

Application vulnerability management

Application code is scanned prior to deployment. Patches addressing application vulnerabilities that materially impact security are deployed within 90 days of discovery. 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. Customer data must not be used for testing without explicit permission of the data owner and the CTO.

​

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 template is on file, reflecting intended purpose, training-data provenance, evaluation metrics, limitations, and human-oversight requirements.
• 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