Secure Software Development Lifecycle

1. Security by Design

Security considerations begin at the earliest stages of development. Every new feature, integration, or add-on is reviewed with security in mind before implementation begins.

This includes:

• Identifying potential security risks early

• Designing features with least privilege and defence-in-depth principles

• Ensuring new functionality aligns with our overall security architecture

By addressing security at the design stage, we reduce risk, limit technical debt, and prevent vulnerabilities from being introduced later in the lifecycle.

2. Security-Trained Development Team

Our team receive ongoing cybersecurity training to ensure security awareness is maintained across the organisation.

Our team:

• Stays current with evolving threat landscapes

• Understands secure coding principles and common attack vectors

• Applies security best practices as part of everyday development

Security is a shared responsibility, not an afterthought.

3. Secure Coding Standards

We follow defined coding standards to ensure code quality, maintainability, and security consistency across all projects.

Our standards:

• Promote clean, readable, and testable code

• Align with secure coding guidelines from OWASP

• Reduce common issues such as injection flaws, insecure deserialization, and improper error handling

Consistent standards make code easier to review, audit, and secure.

4. DevOps, CI/CD, and Secure Source Control

Our development process is built on a full DevOps continuous integration and continuous delivery (CI/CD) pipeline, designed to support security, traceability, and reliability at every stage.

All source code is:

• Stored in centralised Git-based repositories

• Fully version-controlled with complete change history

• Protected through structured branching and review workflows

This approach ensures that every change is attributable, reviewable, and recoverable.

We use structured branching strategies to:

• Isolate development, testing, and release code

• Prevent unauthorized or unreviewed changes from reaching production

• Support parallel development while maintaining stability

Branch protections and review processes ensure that code is reviewed and validated before being merged.

Our CI/CD pipelines automatically integrate security checks as part of the build and release process, including:

• Static code analysis

• Coding standards validation

• Dependency and vulnerability scanning

• Build-time security enforcement

Full version history allows us to:

• Track changes across releases

• Quickly identify when and where security-relevant changes were introduced

• Roll back or remediate issues efficiently if needed

This level of traceability supports both operational resilience and security assurance.

5. Automated Code Quality and Static Analysis

We use automated tooling to continuously analyse source code throughout development.

This includes:

• Linters to enforce coding standards and catch issues early

• Static Application Security Testing (SAST) integrated into our central security systems

• Identification of insecure patterns, logic flaws, and potential vulnerabilities before deployment

Automation ensures security checks are consistent, repeatable, and scalable.

6. Dependency and Third-Party Component Management

All third-party libraries and dependencies are continuously assessed for known vulnerabilities.

Our approach includes:

• Automated dependency scanning aligned with OWASP Dependency-Check

• Monitoring for Common Vulnerabilities and Exposures (CVEs)

• Evaluating risks introduced by external components before release

This helps prevent supply-chain attacks and reduces exposure from outdated or vulnerable dependencies.

7. Testing and Validation

We apply multiple layers of testing to validate both functionality and security.

This includes:

• Unit testing where applicable

• Quality assurance (QA) testing for expected behaviour

• Security scanning during the build process, including code standards and static analysis

Testing ensures issues are detected early and resolved before reaching production.

8. Malware and Integrity Verification

To protect against malicious code and tampering:

• Cryptographic hashes of external DLLs and executables are generated

• Hashes are submitted to external malware and virus intelligence databases

• Components are verified to ensure integrity and authenticity

This reduces the risk of introducing compromised binaries into our products.

9. Threat Simulation and Security Testing

We proactively simulate potential security threats to evaluate system resilience.

This includes:

• Attempting to identify unauthorized access paths

• Testing application behaviour under abnormal or malicious conditions

• Validating security controls against real-world attack scenarios

This allows us to identify weaknesses before attackers do.

10. Controlled Release and Approval Process (Cloud Products)

For cloud-based solutions, releases follow a structured approval process.

Before deployment:

• All team members and relevant stakeholders review the release

• Development, security, and infrastructure readiness are validated

• Security checks must pass before approval is granted

This ensures deployments are intentional, secure, and fully reviewed.

11. Code Signing and Release Integrity

All DLLs and executables delivered to customer environments are digitally signed using code signing certificates. This provides assurance that released components are authentic and have not been modified since they were built and approved.

What code signing provides:

• Tamper evidence: if a signed binary is altered, the signature validation fails.

• Authenticity: customers and administrators can verify the software originates from your organization.

• Release integrity: signed artifacts support controlled, traceable releases and reduce the risk of unauthorized binaries being distributed.

How it fits into our SDLC:

• Signing occurs as part of the release pipeline, after builds pass security checks and approvals.

• Signed artifacts become the only approved deployable outputs for customer delivery.

12. Code Obfuscation and Intellectual Property Protection

Where appropriate, we apply code obfuscation to released components to make reverse engineering significantly more difficult. Obfuscation changes the structure and readability of compiled code while preserving runtime behaviour, increasing the effort required to analyse internals.

Why obfuscation can be helpful:

• Raises the cost of attack: makes it harder to understand program logic, locate sensitive routines, or develop reliable exploits.

• Protects intellectual property: reduces the risk of proprietary algorithms or implementation details being copied.

• Limits useful detail in the event of compromise: slows down analysis if an attacker obtains binaries.

How it fits into our SDLC:

• Obfuscation is applied during build/release hardening, prior to code signing.

• The resulting binaries are then signed and verified as approved release artifacts.

13. Continuous Security Monitoring and Vulnerability Management

Security does not stop at release. We continuously monitor applications and dependencies in production.

Our controls include:

• Ongoing vulnerability scanning and alerting

• Monitoring against CVEs using industry databases such as NIST

• Use of automated analysis tools (e.g., code and dependency  tools) to detect emerging risks

This enables rapid response to new vulnerabilities and evolving threats.