Secure Development & Change Management
How code is written, reviewed, and released — securely and with customers kept informed.
At a glance
| Do you follow secure coding practices and conduct code security reviews? | Yes OWASP-aligned practices, reviewed changes, and dependency vulnerability management |
| Do you have a formal change management process with customer notification for major updates? | Yes Version-controlled, pipeline-driven releases with customers notified of major changes and maintenance windows |
Secure coding practices
- OWASP-aligned development — solutions are built with the OWASP Top 10 risks in mind: parameterised data access, output encoding, CSRF protection, secure authentication flows, and framework-level protections provided by ASP.NET Core and the wider .NET platform.
- Secrets management — credentials and connection strings are kept out of source code, using managed stores such as Azure Key Vault and platform-managed identities.
- Supported platforms — solutions are built on current, supported versions of the .NET platform, so security patches from Microsoft remain available throughout the engagement.
- Regular OWASP scanning — security scanning aligned to the OWASP Top 10 is performed on a regular basis across the code base and its dependencies, in addition to the review and monitoring below.
- Dependency management — third-party packages are chosen deliberately (see Third-Party Supplier Management), and known-vulnerability advisories for dependencies are monitored and patched.
- Data protection by design — personal data handling is minimised and protected from the design stage, per UK GDPR Article 25.
Code review
Changes are developed on branches and reviewed before merging to release branches, which are protected so unreviewed code cannot reach a customer release. Review covers correctness and security-relevant concerns — input handling, authorisation checks, and data exposure — with every change attributable in version control history.
Change management
Releases to customer environments follow a controlled path:
- Version control — every change is committed, attributable, and reversible.
- Automated pipelines — builds and deployments run through CI/CD pipelines, not manual copying, so releases are repeatable and logged.
- Environment progression — changes are validated in development and staging environments before production, where the engagement includes them.
- Approval gates — production deployments require explicit approval, recorded in the pipeline.
- Rollback — because environments are pipeline-deployed, the previous known-good version can be redeployed quickly if an issue emerges.
Customer notification
Customers are notified in advance of major updates, breaking changes, and planned maintenance windows affecting their systems, with the scope of the change and any expected downtime. Routine, non-breaking updates are summarised through the engagement's normal reporting rhythm. Emergency security patches may be applied first and communicated immediately afterwards, where waiting would leave a known vulnerability exposed.
Engagement-specific process
The exact review, environment, and notification arrangements for your engagement are documented at kick-off. For details, contact hello@assemblysoft.com.
Start a meaningful conversation with us today.
Assemblysoft are Your Safe Pair of Hands
Azure
Azure DevOps
