Secure Development Statement
Secure by Design, from Code to Fleet
Security isn’t something we add at the end. It’s built in from the very start. See how Xirgo designs, codes, tests and releases firmware and cloud services, with threat modeling, automated security testing, signed updates and supply chain controls at every stage.
Xirgo Secure Development Statement
Oct 1, 2026
Purpose and scope
Xirgo builds security and quality into every stage of how we design, develop, test and release software. This statement summarises the controls in our internal Secure Development Lifecycle Policy.
The policy applies to:
- Device firmware and embedded software, including bootloaders and over-the-air (OTA) update packages
- Our cloud services, APIs and integrations
- All development, test and production environments
- Everyone who contributes code, including employees, contractors and third parties
- AI-assisted development tools and the code they produce
Our secure development lifecycle
Every change passes the same security and quality gates before it moves to the next stage. This applies whatever delivery method a team uses. In agile teams, the gates are met inside each sprint.
- Requirements — security and privacy requirements are written into acceptance criteria. A privacy impact assessment runs where personal data is involved.
- Design — architecture review and structured threat modelling. Identified risks are mitigated or formally accepted.
- Implementation — secure coding standards, secrets management and dependency review.
- Testing — functional and security testing. High and critical findings are fixed or formally risk-accepted.
- Review — independent peer review of every change. Authors never approve their own code.
- Deployment — automated pipeline only, with a documented rollback plan.
- Operations — continuous monitoring, vulnerability scanning, patching and incident readiness.
All changes are traceable to an approved work item. Software that fails testing, scanning or review is not released.
Secure design
We address security at design time, because design decisions are the hardest to change later. Our designs follow these principles:
| Principle | What it means |
|---|---|
| Least privilege | Components and users get only the access they need |
| Defence in depth | Several independent controls; no single point of reliance |
| Secure by default | Default settings are secure; weaker settings need an explicit opt-in |
| Fail secure | Systems fail to a safe state and do not expose sensitive data |
| Simplicity | Designs stay as simple as possible; added complexity is risk-assessed |
Threat modelling is mandatory for new products, major architecture changes, new external interfaces and new flows of personal data. We collect and keep only the data a stated purpose needs. Development, test and production environments are kept separate, and production data is not used in testing unless it is anonymised. Hardened configuration baselines are held as code and applied automatically.
Secure coding
Our developers follow OWASP Secure Coding Practices and recognised language-specific guidance.
- Dependencies — only approved frameworks and libraries are used. Each is checked for known vulnerabilities before adoption and kept current.
- Secrets — credentials and keys are never stored in source code. They are held in managed secret stores. Any exposed secret is treated as compromised and rotated at once.
- Data protection — sensitive data is encrypted in transit (TLS 1.2 minimum, TLS 1.3 preferred) and at rest (AES-256 or equivalent). We use only approved cryptographic algorithms and never custom cryptography. Sensitive data is kept out of logs, error messages and URLs.
- Input handling — all external input is validated, and output is encoded for its context to prevent injection attacks.
- AI-assisted development — a human developer reviews all AI-generated code before it is merged. That code passes the same scanning and peer review as any other code. AI tools are never used to generate credentials or keys, and confidential or personal data is not sent to external AI services without approval.
Security testing
Our build pipeline enforces security testing automatically, so a change that fails cannot be merged or released.
| Test | When it runs |
|---|---|
| Static analysis (SAST) | Every code change |
| Dependency and composition analysis (SCA) | Every project with external dependencies |
| Secret scanning | Every code change; findings block the merge |
| Dynamic testing (DAST) | Internet-facing services, before major releases and at least quarterly |
| Independent penetration testing | Internet-facing services, at least annually, by a qualified third party |
We also run unit, integration, end-to-end and security-focused tests in the pipeline. Vulnerabilities are prioritised by CVSS severity, with defined fix timescales for each severity level.
Build and release integrity
Only our controlled build pipeline produces release software. Nothing built on a developer's own machine is released.
- Firmware images and OTA update packages are cryptographically signed. Signing keys are held in protected key stores, not by individual developers.
- Devices and installers verify signatures before installation and reject unsigned or unverifiable software.
- Each release has recorded build provenance, including a Software Bill of Materials (SBOM).
- Published release versions cannot be overwritten.
Vulnerability and incident management
All vulnerabilities go into one register with an owner and a target fix date, however they were found. Sources include our own scanning, penetration tests and reports from outside Xirgo.
- Device and firmware fixes follow the patch targets in the Product Security Support & End-of-Life Statement for each market.
- A vulnerability that is actively exploited is handled as a security incident and escalated at once.
- Every security incident is investigated, fixed and closed with lessons learned. Serious incidents get a root cause analysis.
Report a vulnerability: email security@xirgo.com. Our Coordinated Vulnerability Disclosure Policy explains what to include and how we respond. Our contact details are also published at xirgo.com/.well-known/security.txt.
Supply chain and third parties
Code we do not write ourselves meets the same standard as code we do.
- Third-party contributions pass the same review and security scanning as internal code.
- Open-source components are assessed for licence, maintenance status and security before adoption.
- Development suppliers are assessed for security and commit by contract to equivalent secure development standards.
- We maintain an SBOM for production software, so we can quickly trace a newly disclosed vulnerability to the affected products.
People, governance and improvement
Our senior product software leadership owns the policy, and compliance is mandatory for everyone in scope.
- Developers, reviewers and platform engineers complete secure development training when they join and every year after, covering the OWASP Top 10 and secure coding.
- Any exception to the policy is risk-assessed, approved and reviewed regularly.
- We track security performance monthly and review the policy at least once a year.
- Lessons from incidents, security findings and audits feed back into our standards.
The policy is designed to align with ISO/IEC 27001:2022, ISO 9001:2015 and the SOC 2 Trust Services Criteria.