In our previous article, David explained why Hexiosec adopted the Software Security Code of Practice and joined the DSIT Ambassador Scheme. This article covers what actually happened when we sat down and worked through the self-assessment.
I completed the assessment in September 2025, using the NCSC’s Assurance Principles and Claims (APC) framework. It covers 14 principles across four themes. Each principle breaks down into specific claims, and each claim requires evidence - not just a yes or no, but a description of what you actually do and why you believe it meets the standard.
What follows is an honest summary of where we landed. We were largely aligned. We also found areas to improve. Both matter.
Theme 1: Secure Design and Development
This theme covers four principles:
- following an established secure development framework (1.1)
- understanding the composition of your software and managing third-party components (1.2)
- having a clear testing process (1.3)
- following secure-by-design and secure-by-default principles (1.4)
This was the area where we had the strongest existing alignment.
Our development framework and processes are documented in Archbee, covering coding standards, review practices, testing strategy, and release procedures. All code sits in GitHub under version control, with a documented branching strategy. Requirements are captured through a formal RFC process - each RFC records the rationale, requirements, design decisions, and security considerations for any significant change.
For third-party component management (Principle 1.2), we use Renovate to automate dependency updates, pulling from trusted repositories. GCP-managed services like GKE and Cloud SQL are updated directly by Google. Where components fall outside automated management - Keycloak, for example - we handle updates manually and document the process. Every pull request, including those generated by Renovate, has to pass unit tests before merging, and daily regression tests run across both development and production environments.
Our testing approach (Principle 1.3) combines automated unit and regression testing with regular manual testing cycles. Unit tests are recorded in Github, regression tests in GCP and manual test results are recorded as stories in Shortcut. Defects are triaged, tracked, and resolved through the standard development workflow.
For secure-by-design (Principle 1.4), security considerations are embedded in our RFC process. MFA is enforced for all system users via Entra SSO. We have an organisational password policy, and ASM enforces strong passwords by default. Input validation is a standard part of development, reinforced through code reviews and automated testing. Sensitive data and credentials are managed through 1Password and Kubernetes secrets.
Example: Designing Organisation Access and Third-Party Visibility
When we introduced organisation management pages, one of the key security considerations raised during the RFC process was how to safely support third-party access.
ASM allows organisations to invite external users (for example, consultants or MSPs) to view scan results. The risk identified was that overly broad permissions could expose sensitive data across the organisation, particularly if access controls were not tightly scoped.
To address this, we designed access control around organisation and scan-group boundaries. Users are assigned roles via user groups, with permissions explicitly scoped to the organisation and, where required, limited further to specific scan groups. This ensures third-party users can only access the data they have been explicitly invited to view, rather than inheriting wider visibility.
We validated this design through code review and testing, ensuring that all queries and API endpoints enforce organisation-level scoping. This approach aligns with our secure-by-design principle of least privilege and ensures access is intentionally granted, not implicitly assumed
Theme 2: Build Environment Security
This theme covers two principles:
- protecting the build environment against unauthorised access (2.1)
- controlling and logging changes (2.2).
Access to our build environment is controlled through role-based access in both GitHub and GCP, with roles defined and managed through a Terraform project. This means permissions are version-controlled and auditable, not configured ad hoc. MFA is enforced on all build environment accounts. Session lengths follow platform defaults, requiring regular re-authentication.
For change control and logging (Principle 2.2), GitHub provides audit logs of user access, repository changes, and pull request activity. Terraform changes are version-controlled, giving us a permanent history of infrastructure configuration changes. All changes require review before they can be merged.
One area we identified for improvement here relates to the breadth of our audit logging. GitHub and Terraform give us good coverage of code and pipeline changes, but we want to ensure we have the same level of coverage for GCP audit logs - formalising their retention and making them part of a single, reviewable audit trail alongside the GitHub and Terraform records.
Theme 3: Secure Deployment and Maintenance
This theme covers five principles:
- secure distribution (3.1)
- vulnerability disclosure (3.2)
- vulnerability management (3.3)
- reporting vulnerabilities to relevant parties (3.4)
- providing timely security updates (3.5).
Because ASM and Transfer are SaaS products, some of the Code’s deployment principles apply differently to us than they would to a vendor distributing installable software. Our customers do not need to download, install, or update anything locally. Products are accessed through Hexiosec-owned domains over TLS. This is a genuine advantage of the SaaS model from a security perspective - we control the deployment pipeline end to end.
Our vulnerability disclosure policy is published at hexiosec.com/disclosure/, and our internal incident management policy covers escalation, prioritisation, and customer communication. We use our own ASM tooling to scan our public-facing infrastructure alongside Renovate for automated dependency advisories. Vulnerability management follows our documented bug process in Archbee - capturing, triaging, and prioritising issues based on severity and impact.
Security updates are prioritised, tested through the standard automated and manual pipeline, and deployed as quickly as possible. Because we manage the deployment, customers receive updates immediately without needing to take any action.
Theme 4: Communication with Customers
This theme covers three principles:
- specifying the level of support and maintenance provided (4.1)
- providing notice of end-of-support (4.2)
- making information available about notable incidents (4.3).
Our SaaS delivery model means several claims in this theme are addressed inherently. Customers do not need to apply updates, manage end-of-support dates for installed components, or follow update documentation - because we handle all of that as part of the managed service.
Where we identified an opportunity for improvement is in how we proactively communicate certain aspects of our security posture and lifecycle management to customers. Our incident management policy covers how and when we notify customers if a significant security issue affects them. But we believe there is scope to go further - making our overall approach to security transparency, update cadence, and support commitments clearer and more accessible without customers needing to ask.
What we are doing next
The two improvement areas we identified are being worked through now. Once complete, we will carry out a final review of our assessment against the Code of Practice and publish the results.
If you are a software vendor thinking about doing this yourself, the next article in this series walks through a practical guide to completing the self-assessment - what to expect, how to approach the APC framework, and how to handle claims you cannot fully evidence yet.
And if you want to start with a different kind of assessment - one that shows you what your organisation looks like from the outside - you can run a free Hexiosec ASM scan and see your full external attack surface in minutes.
Related Posts
