Trust center
How we keep the work secure
Security is part of how we design and deliver, not a step at the end. This is what it means in an engagement.
In short
In client work we aim for least-privilege access, can work in accounts and repositories you own, manage secrets in managed stores and build security checks into delivery. The systems we build get controls matched to their risk, from encryption to audit logging. These are practices, not certifications.
Last updated
01 Access
How do we handle access to your systems?
- Least-privilege access: we aim to take only what a task needs and to remove it when the work ends
- Identity federation and multifactor authentication where appropriate
- Work in cloud accounts and repositories you own, where you want that
- Secrets kept in managed secret stores, not in code or messages
02 Controls
Which controls go into the systems we build?
Controls should reflect data sensitivity, business impact, system exposure, contractual requirements and the law. Depending on the system, they can include:
- Encryption in transit and at rest
- Managed secrets and key rotation
- Network segmentation and private endpoints
- Secure API gateways and rate limiting
- Dependency, container and infrastructure scanning
- Audit logging and security monitoring
- Data classification and retention controls
- Backup protection and recovery testing
- Vulnerability remediation and patch management
03 Delivery
How does security fit the delivery process?
Security runs through the lifecycle: plan, design, develop, test, scan, build, deploy, observe and improve. Dependency scanning, secret detection, infrastructure validation and release approvals should sit at the points where they catch problems early.
Relevant controls can include peer review, version-controlled infrastructure, separated environments and a rollback procedure.
04 Reporting
How do you report a security issue?
If you find a vulnerability in nexstella.com or blog.nexstella.com, the disclosure page explains how to report it.