Access and secrets
Real keys, passwords and environment secrets remain outside source control. Access is limited to the work required, and environment credentials are separated.
Security and delivery
Production delivery with clear controls.
Xencra treats security as part of product architecture and delivery, not as a final-stage add-on. Controls are adapted to the system's risk, data, integrations and production responsibility.
Last reviewed 5 August 2026
Core standards
Controls that reduce avoidable risk.
These principles form Xencra's normal delivery framework. The exact control level depends on system criticality and the responsibility agreed for the project.
Environment separation
Development and validation happen in staging. Production code is promoted through version control from main; application files are not edited manually in production.
Change control
Before release, the branch, commit, clean worktree, change scope and source integrity are verified. Each production change must remain traceable.
Testing and release gates
Type checks, builds, content checks and risk-appropriate functional tests run before production. A failed gate stops the release.
Data and input handling
Public input is validated server-side. Attachments are checked by type and size, requests are limited, and sensitive records stay outside the public web root.
Dependencies and external services
Third-party permissions and keys are constrained. External availability is not treated as guaranteed, and critical failure paths are defined according to system needs.
Delivery lifecycle
Security moves with the project from definition to handover.
-
01
Discovery
Business outcome and risk boundaries
Identify users, data, permissions, external dependencies, critical flows and production responsibility.
-
02
Architecture
System boundaries and access plan
Define environments, roles, integrations, secret handling, logging and the need for recovery or backups.
-
03
Implementation
Controlled development in staging
Build features in an isolated environment with validation, permissions, failure paths and operational needs included.
-
04
Release
Versioned deployment and live verification
Promote an approved commit. After the build, verify the server, primary routes, metadata and agreed critical flows.
-
05
Handover
Documentation and clear ownership
Transfer the agreed source, configuration description, access, operating guidance and known operational boundaries.
Applied to Xencra's own system
The public website follows the same controlled path.
Xencra's website source and release process provide a concrete example of these standards in practice.
Separate staging and production
Development uses a staging branch and separate worktree. Production uses main with its own build and runtime.
Secrets outside Git
Environment secrets and email keys stay in restricted server configuration. Only placeholder examples belong in the repository.
Protected project requests
Server-side validation, origin and host checks, honeypot, timing limits, MIME validation, rate limits and random identifiers.
Controlled production deployment
Deployment takes the approved main branch, installs locked dependencies, runs Astro checks and build, validates Nginx and performs a live smoke test.
Responsibility boundaries
Clear standards do not mean unrealistic guarantees.
Security is continuous risk management. Project-specific controls, service levels and responsibility are defined in the agreed scope.
- No internet-connected or software system can be completely risk-free.
- Xencra does not claim ISO, SOC 2, PCI DSS or another certification unless it is separately evidenced for the specific engagement.
- Availability of external services, network operators and blockchains remains under those providers' control.
- Backup, recovery, monitoring and incident-response levels are agreed according to system criticality.
- The client remains responsible for its users, approved access, content and sector-specific legal obligations unless the contract states otherwise.
Project security framework
Define the risks before the system reaches production.
Share the current system, data, integrations, access model and intended production responsibility. Xencra will help define a practical control level.