Capability

Security engineered into the architecture from the first design

We build security into systems as they are designed and written: trust boundaries, identity, data protection, secure delivery and detection. The work is engineering practice, carried out by the same people who design the software and the infrastructure.

Discuss your system

Overview

Security is a property of how a system is built. It shows up in where trust boundaries are drawn, how identity is established and propagated, which component is allowed to reach which data, and what an attacker gains from compromising any single part. Tools and reviews help find defects, but they cannot add a boundary the architecture never had.

We approach cybersecurity as an engineering discipline that runs through the whole lifecycle. Requirements carry data classification and abuse cases. Designs are threat-modelled. Code is written against secure defaults and checked automatically. Infrastructure is defined with least privilege and segmented networks. Production is monitored for the behaviours the threat model predicted, and incident response is planned before it is needed.

Our scope is the security of the systems we design and build, and the engineering that supports an organisation's compliance programme. We design controls and evidence collection to support frameworks such as ISO 27001, SOC 2 and PCI DSS. Formal certification and attestation are carried out by accredited auditors, and independent penetration testing is integrated into the delivery plan as an input to our engineering work.

What we engineer

Technical areas

Secure software development lifecycle

A secure SDLC assigns a security activity to each stage of delivery so that defects are found where they are cheapest to fix. We define security requirements with the functional ones, model threats during design, automate analysis in the pipeline and verify before release. Each activity produces a record that can be shown to a reviewer.

Security requirements and abuse cases
Threat modelling with STRIDE and data-flow diagrams
Secure coding standards and review checklists
SAST, DAST and software composition analysis in CI
Security acceptance criteria in the definition of done
Alignment with OWASP SAMM and NIST SSDF practices

Application and API security

Most breaches of custom software exploit flaws in authorisation, input handling or session management. We design APIs with authentication at the edge and authorisation at the resource, validate every input against a schema and apply rate limits per identity. The OWASP Top 10 and the OWASP API Security Top 10 are used as a minimum checklist, not as the design.

Object-level and function-level authorisation checks
OAuth 2.0 and OpenID Connect with short-lived tokens
Schema validation and output encoding
Rate limiting, quotas and abuse detection
Mutual TLS and request signing for service and partner APIs
Protection against injection, SSRF, CSRF and deserialisation flaws

Identity and access management

Identity is the control plane of a modern system. We design identity and access management for workforce users, customers and workloads: how each is authenticated, how permissions are modelled and how access is reviewed and revoked. Least privilege is enforced by default, with elevation that is temporary, approved and logged.

Single sign-on with OIDC and SAML federation
Multi-factor authentication and passkeys with WebAuthn
RBAC for coarse permissions and ABAC for contextual rules
Workload identity and service accounts without static keys
Just-in-time privileged access with session recording
Joiner, mover and leaver automation with SCIM

Cloud, infrastructure and container security

Cloud breaches are usually caused by misconfiguration: public storage, over-broad roles or exposed management interfaces. We prevent these with organisation-level guardrails, private networking, encryption by default and continuous posture checks. Containers are built from minimal images, run without root and are constrained by admission and network policies.

Network segmentation and private service endpoints
Cloud security posture management and CIS benchmark checks
Encryption at rest and in transit with managed key services
Minimal and distroless base images with image scanning
Pod security standards, seccomp profiles and network policies
Runtime threat detection with Falco

Secrets, dependencies and vulnerability management

Credentials and third-party code are the two assets attackers most often reuse. Secrets are held in a managed store, injected at runtime and rotated automatically, with detection for anything committed to source control. Vulnerabilities are handled as a managed backlog: discovered continuously, prioritised by exploitability and exposure, and remediated against agreed timelines.

HashiCorp Vault and cloud-native secret managers
Dynamic, short-lived database and cloud credentials
Secret scanning in repositories and pipelines
Dependency pinning, SBOMs and automated updates
Risk-based prioritisation using CVSS, EPSS and reachability
Patch service levels and tracked exceptions

Monitoring, audit logging and incident response

Prevention fails eventually, so the system must record what happened and alert when it matters. We design audit logs that capture who did what to which resource, ship them to tamper-resistant storage and build detections from the threat model. Incident response is prepared in advance with roles, runbooks, communication paths and exercises.

Structured audit logs with actor, action, resource and outcome
Centralised log pipelines into a SIEM
Immutable log storage with retention policies
Detection rules mapped to MITRE ATT&CK techniques
Incident runbooks, severity levels and on-call escalation
Tabletop exercises and post-incident reviews

Security by Architecture

Security cannot be bolted onto an application after development. A system that was designed with one flat network, one database user and one implicit notion of an authenticated caller will keep those properties however many scanners and firewalls are placed around it. The remediations that matter at that point are structural, and structural change late in a project is expensive and usually deferred.

Four design decisions determine most of a system's security posture. Trust boundaries define where data crosses from one level of trust to another and therefore where validation and authentication must occur. Identity defines how every user and workload proves who it is, and how that proof travels through the call chain. Data classification defines which data needs encryption, masking, restricted access or residency controls. Blast radius defines what an attacker can reach after compromising a single component.

Getting these right early makes later controls simple and local. A service that only holds a narrowly scoped credential cannot leak a database it was never able to read. A tenant identifier enforced at the data layer cannot be bypassed by a missing check in one handler. We treat these as architectural requirements with the same standing as availability and latency.

Trust boundaries: authenticate and validate at every crossing, including internal ones
Identity: one verifiable identity per user and per workload, propagated end to end
Data classification: controls follow the sensitivity of the data, wherever it is copied
Blast radius: segment networks, accounts, credentials and tenants so that a single failure stays contained

Architecture

Security architecture: defence in depth

Identity
Every request is authenticated and authorised
- SSO and MFA
- Role-based access
- Service identities
- Session policy
Edge
- WAF
- DDoS protection
- TLS termination
- Rate limiting
Application
- Input validation
- Authorisation checks
- Secure SDLC
- Dependency scanning
Data
- Encryption at rest
- Encryption in transit
- Key management
- Data classification
Infrastructure
- Network segmentation
- Hardened images
- Secrets management
- Patch management
Detection & Response
Assume a control will fail and plan for it
- Central audit logs
- Alerting rules
- Incident runbooks
- Forensic retention

Controls are layered so that the failure of one does not expose the system. Identity is the outermost control and detection is the last, because prevention alone is never complete.

Threat modelling as a design activity

Threat modelling answers four questions about a design: what is being built, what can go wrong, what will be done about it, and whether that was enough. It works from a data-flow diagram that shows processes, data stores, external actors and the trust boundaries between them. Each element is examined for spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.

The output is a ranked list of threats with a decision for each: mitigate, accept, transfer or eliminate by changing the design. Mitigations become backlog items and test cases, and the threats that remain inform what production monitoring should detect. A threat model is revisited when the architecture changes, for example when a new integration, data store or externally reachable interface is added.

The practice is most valuable when engineers do it themselves during design, with security specialists facilitating. A one-hour session on a new feature routinely changes an authorisation model or removes an unnecessary data flow, at a point where the change costs a diagram edit.

Zero trust in practical terms

Zero trust replaces the assumption that anything inside the network is safe with the requirement that every request is authenticated, authorised and encrypted, wherever it originates. Network location stops being a credential. Access decisions are made per request from the identity of the caller, the state of the device or workload, and the sensitivity of the resource.

In an application architecture this means mutual TLS between services with workload identities issued by a framework such as SPIFFE, authorisation policies evaluated at each service, and user context propagated in signed tokens instead of being trusted from an upstream header. For workforce access it means an identity-aware proxy in front of internal tools in place of a flat VPN. Adoption is incremental: start with the most sensitive data paths, establish strong identity, then tighten policy as visibility improves.

Engineering for compliance frameworks

Frameworks such as ISO 27001, SOC 2 and PCI DSS describe control objectives: access is restricted, changes are authorised, data is protected, events are logged, incidents are handled. Most of these map directly to engineering mechanisms. Infrastructure as code with mandatory review evidences change control. Centralised identity with access reviews evidences access management. Immutable audit logs evidence monitoring.

We design systems so that this evidence is a by-product of normal operation, collected automatically from pipelines, cloud APIs and identity providers. That reduces the cost of an audit and, more usefully, means the controls are operating continuously instead of being assembled before an assessment. The systems are designed to support these frameworks; the assessment and any certification are the role of an accredited third party.

How we engineer it

Our approach

Security work is sequenced by risk: understand what needs protecting, fix the structure, automate the checks, then prepare for failure.

01
Identify assets and classify data
We inventory systems, data stores and data flows, and classify data by sensitivity and regulatory obligation. This defines what the controls are protecting and how strong they need to be.
02
Model threats and define the security architecture
We draw trust boundaries, model threats against the design and decide the identity, network segmentation, encryption and tenancy model. The output is a set of security requirements traceable to specific threats.
03
Build controls into code and infrastructure
Authentication, authorisation, input validation, secrets handling and audit logging are implemented as shared, tested components. Cloud guardrails and least-privilege roles are written as infrastructure code.
04
Automate verification in the pipeline
Static analysis, dependency and container scanning, secret detection and policy checks run on every change, with agreed thresholds for blocking. Security test cases derived from the threat model run alongside functional tests.
05
Validate independently
Penetration testing by an independent party is scheduled against a stable build, with scope informed by the threat model. Findings enter the same backlog as other defects, with severity-based remediation timelines and retesting.
06
Detect, respond and improve
Audit logs and security telemetry feed detections and dashboards, and incident runbooks are exercised. Each incident or near miss leads to a blameless review and a concrete change to design, code or process.

Trade-offs

Decisions that shape the design

The questions we work through with your team before committing to an architecture.

RBAC, ABAC or relationship-based access control?: Use RBAC when permissions follow job functions and the number of roles stays manageable. Add ABAC when decisions depend on context such as tenant, region, data classification or time, which would otherwise cause role explosion. Use a relationship-based model in the style of Google Zanzibar, with tools such as OpenFGA or SpiceDB, when access derives from object relationships like ownership, sharing and nested groups. Many systems combine RBAC for coarse entitlements with a finer model for resource-level checks.
Build authentication ourselves or use an identity provider?: Use an established identity provider or a mature open source server such as Keycloak in almost every case. Credential storage, multi-factor flows, federation, account recovery and session management are easy to get subtly wrong and offer no differentiation. Build custom only the parts specific to your domain, typically the authorisation model, and keep them behind standard OIDC tokens.
Should authorisation be enforced at the API gateway or inside each service?: Both, for different things. The gateway is the right place for authentication, token validation, rate limiting and coarse scope checks, because they are uniform across services. Resource-level decisions, such as whether this user may read this record, need domain data and belong in the service or in a policy engine it calls. Relying on the gateway alone fails the moment a service is reached by another path.
Service mesh mutual TLS, or network policy alone?: Network policy restricts which pods can talk but does not authenticate the caller or encrypt traffic. A mesh such as Istio or Linkerd adds workload identity, mutual TLS and per-service authorisation, at the cost of extra components to operate and some latency. Choose the mesh when you handle regulated data, run multi-tenant clusters or need zero-trust guarantees between services; network policy is adequate for a small, single-team cluster.
How should tenant data be isolated: shared schema, schema per tenant or database per tenant?: A shared schema with a tenant identifier enforced by row-level security is the most efficient and suits many small tenants, provided enforcement sits in the database and not only in application code. Schema or database per tenant gives stronger isolation, per-tenant encryption keys and simpler data residency, with higher operational cost. Regulated or large enterprise tenants often justify a dedicated tier while the long tail stays pooled.
Cloud-managed keys, customer-managed keys or a dedicated HSM?: Provider-managed encryption is sufficient for most data and has no operational burden. Customer-managed keys in a cloud KMS add control over rotation, access policy and revocation, and are commonly expected for regulated data. A dedicated HSM is warranted when a standard mandates single-tenant, validated hardware or when keys sign high-value transactions; it brings availability and operational responsibilities that must be planned for.

Production readiness

What makes it production-ready

How it is secured

Every request is authenticated, authorisation is enforced at the resource, and credentials are short-lived and scoped to one purpose. Data is encrypted in transit and at rest, administrative access is just-in-time and recorded, and default-deny applies to network paths and permissions.

How it scales

Security controls are designed to scale with the system: token validation is stateless, policy decisions are cached with short lifetimes, and rate limiting is distributed. Shared libraries and platform-level guardrails mean that adding a service does not require re-implementing its security.

How it is monitored

Audit logs record actor, action, resource, outcome and origin for every security-relevant event and are stored where the systems that generate them cannot alter them. Detections derived from the threat model alert on anomalous authentication, privilege changes, data access patterns and policy violations.

How it is deployed

Changes pass automated security checks and policy gates before release, artefacts are signed and verified at admission, and infrastructure permissions change only through reviewed code. Emergency patches use the same pipeline on an expedited path, so that speed does not remove verification.

How it integrates

Systems federate with corporate identity providers over OIDC and SAML, forward logs to the organisation's SIEM and expose evidence to governance and compliance tooling. Third-party and partner integrations are authenticated individually, scoped narrowly and monitored as untrusted inputs.

Technologies

Chosen to fit the workload and your existing estate.

OAuth 2.0 and OpenID Connect
Keycloak
HashiCorp Vault
AWS KMS
Open Policy Agent
OWASP ZAP
Semgrep
Trivy
Falco
Istio
SPIFFE and SPIRE
Cloudflare WAF
Wazuh
Elastic Security

From zero to production

The engineering lifecycle

01
Idea
02
Discovery
03
System architecture
04
UX / product design
05
Application engineering
06
AI / data layer
07
Cloud infrastructure
08
Security
09
QA & performance
10
Deployment
11
Observability
12
Continuous evolution

FAQ

Common questions

Is Starone a certification body or an audit firm?

No. We are an engineering company. We design and build systems with the controls and evidence that frameworks such as ISO 27001, SOC 2 and PCI DSS expect, and we work alongside the accredited auditors and assessors an organisation appoints. Certification and attestation decisions belong to those bodies.

Do you carry out penetration testing?

We integrate penetration testing into delivery: defining scope from the threat model, preparing environments, triaging findings and engineering the fixes. For independence, the test itself is best performed by a specialist firm separate from the team that built the system, and we coordinate with the tester an organisation selects.

When should security be involved in a project?

At the architecture stage. The decisions with the largest effect on security, including trust boundaries, identity, tenancy and data placement, are made then and are costly to reverse. Involvement later is still worthwhile, but the options narrow to compensating controls.

Can you improve the security of a system that is already in production?

Yes. We start with an architecture and threat review to find the structural risks, then sequence remediation by exploitability and impact. Typical early work is credential and secret hygiene, authorisation gaps, network exposure and missing audit logging, followed by deeper changes to identity and segmentation.

How do you secure AI features and LLM integrations?

By treating model input and output as untrusted. We constrain what tools and data a model can reach, enforce authorisation outside the model, filter and validate outputs before they trigger actions, and log interactions for review. Prompt injection is handled as an architectural risk to be contained, since it cannot be reliably filtered away.

Related capabilities

Solutions that use it

Reference architectures

Have a system that needs to work in production?

Tell us what you are building. An engineer will read it and reply within two working days.

Start a project