What we did, and how it ended.

Six engagements across all three disciplines: from designing and building platforms through security audits to penetration testing. Each one states the starting point, the scope of the work and the outcome.

On anonymity

We publish these only in anonymised form and with the client's consent. No company names, and no detail narrow enough to identify anyone. Technical specifics are described only as far as they need to be, never far enough to help someone repeat an attack. A direct reference can be arranged on request.

01Secure product development

A multi-tenant platform for a supply chain

A logistics company needed to replace an ageing monolith with a platform for orders, warehouses, suppliers and invoicing. The suppliers themselves were to log in, so each of them may see only their own data. That single requirement shaped the whole design.

What we delivered

  • A Go backend over PostgreSQL, data separated by Row Level Security and one consistent tenant model
  • A Next.js front end with React Query
  • Sign-in through Keycloak (OIDC), short-lived access tokens and rotating refresh tokens
  • AWS infrastructure (EKS, RDS, ElastiCache) entirely in Terraform
  • Deployment through GitHub Actions, operational visibility through OpenTelemetry and Grafana
  • Cloudflare in front of the application: WAF, rate limiting, DNS

Approach

Security was part of the design from the start: threat modelling, least privilege, secrets exclusively through AWS Secrets Manager, and automated scanning of dependencies and containers on every change. Before going live the whole thing went through an internal security review and a penetration test.

ResultThe platform runs in production. The separation between suppliers held up under later testing. The engagement continues as a long-term engineering retainer.

02Offensive security

Penetration test of a financial application before a funding round

A fintech with a live application covering accounts, transfers and transaction history wanted an independent adversarial look before a larger funding round. The stack: React, a Node.js and Express API, PostgreSQL, a React Native mobile app and AWS infrastructure.

What we delivered

  • A grey-box penetration test of the web app, the REST API, the Android and iOS apps and selected parts of the infrastructure
  • Manual testing supported by Burp Suite Professional, OWASP ZAP, Frida and Objection on mobile, Nuclei and custom scripts
  • A report with findings ranked by real risk and a proposed fix for each
  • A retest once the fixes were deployed

Approach

The test was authorised in writing beforehand, with an agreed scope, a time window and a contact in case anything in production reacted unexpectedly.

Key findings

  • Missing object level authorisation on transactions: changing an identifier returned somebody else's transactions. This is the class OWASP tracks as Broken Object Level Authorization.
  • Mass assignment on profile updates: the interface accepted a field that let a user raise their own permissions.
  • Refresh tokens were not properly invalidated after a password change or a sign-out.
  • In the mobile app, sensitive data in unencrypted storage and weakly configured certificate pinning.
  • Outdated dependencies with known vulnerabilities, among them the ip package before 1.1.9, whose isPublic function treated private addresses written as 0x7f.1 as public and so opened a path to SSRF (CVE-2023-42282).

ResultEvery critical and high finding was fixed and none was exploitable on retest. The client came away with a report usable in front of investors and their technical due diligence.

03Secure product development

An internal platform and cloud for a manufacturer

A manufacturer with several plants was handling fault reports, spare parts and maintenance jobs with a mix of spreadsheets, email and an older on-premise tool. They wanted one system across all plants.

What we delivered

  • An internal web application in React and NestJS over PostgreSQL
  • AWS infrastructure (EKS, RDS, S3, Cognito) entirely in Terraform
  • GitOps deployment through GitHub Actions and ArgoCD
  • Operational and log visibility through Prometheus, Grafana and Loki
  • Access control through AWS IAM and Kubernetes RBAC, held to least privilege
  • Secrets through AWS Secrets Manager, image and dependency scanning on every change

Approach

Environments were separated from the start, access was set to the minimum and operations were made legible. Before handover the architecture was reviewed and a hardening baseline applied.

ResultThe company got one system instead of scattered spreadsheets and email. The infrastructure will carry further internal tools. The engagement continues as monthly support.

04Offensive security

Security audit and threat modelling for a B2B platform

A SaaS company whose B2B platform had been running for several years was preparing for larger enterprise deals. They needed a formal audit and threat model, not just a penetration test.

What we delivered

  • A review of the application layer, both the web app and the interfaces
  • A review of sign-in, permissions and access to sensitive data
  • A check of the basic cloud configuration
  • Threat modelling workshops over the critical business flows

Approach

A combination of documentation review, interviews with the technical team, static and dynamic analysis, and STRIDE workshops adapted to how much risk the company was willing to carry.

Key findings

  • Several places with insufficient object level authorisation, the same pattern as in the study above.
  • Weaker session and privilege handling in the administrative area.
  • Outdated dependencies with known vulnerabilities, among them the qs library before 6.10.3, where prototype pollution can hang the process (CVE-2022-24999).
  • No single approach to secrets or to rotating access credentials.

ResultThe client received a threat model, a list of risks ranked by business impact and a six to twelve month improvement plan. They implemented the quick wins in house and brought in outside help later for the larger architectural changes. The audit also helped them in conversations with enterprise customers.

05Offensive security

An audit of cloud infrastructure and its security baseline

A manufacturing and logistics company ran several applications and internal tools on AWS. The infrastructure had grown over years without a common rule. They wanted an independent look at its state, its permissions and how ready it was for a possible compliance audit.

What we delivered

  • A review of the AWS account and organisation structure
  • IAM: roles, policies, users and service accounts
  • Network design, meaning VPCs, security groups and what is reachable from the internet
  • Kubernetes configuration and its RBAC
  • Secrets, logging and operational visibility

Approach

A review of the Terraform code and the live configuration, automated scans with Prowler, ScoutSuite, Trivy and kube-bench, manual analysis of the critical points and interviews with the team that runs it.

Key findings

  • Several roles with far more privilege than they needed, particularly around deployment and service accounts.
  • Some resources reachable from the internet without adequate restriction.
  • Inconsistent handling of secrets, some still in environment variables and older configuration.
  • Missing or incomplete logging of security-relevant events.
  • Several medium findings in Kubernetes hardening, for instance workloads running as root and containers with unnecessarily broad capabilities.

ResultWe delivered a ranked report and a concrete hardening plan. The client closed the largest gaps step by step and folded part of the recommendations into their own internal standards. The audit also gave them the argument to take to management for funding the work.

06The full cycle

An asset and maintenance platform, from design to penetration test

A company with operations in several countries was replacing fragmented management of assets, maintenance, service jobs and spare parts. Until then they had used older on-premise software, spreadsheets and a handful of isolated tools. The individual companies in the group had to keep their data separate, so the platform was designed as multi-tenant from the outset.

What we delivered

  • A Go backend with clearly separated domains, a front end in Next.js and TypeScript
  • PostgreSQL with a strict tenant model and Row Level Security
  • Sign-in through OIDC with finely grained permissions
  • Asynchronous work, meaning notifications, synchronisation and reporting, through a message queue
  • AWS (EKS, RDS, S3, IAM, Secrets Manager) entirely in Terraform, deployed the GitOps way
  • Visibility through OpenTelemetry, Prometheus, Grafana and Loki, with Cloudflare as the edge layer

Approach

Threat modelling happened during design rather than at the end. Least privilege applied from the start across IAM, Kubernetes and application roles. Secrets went exclusively through Secrets Manager and not one lived in the repository. Code, dependencies and containers were scanned on every change, reviews ran throughout the build, and a full penetration test of the web app, the interfaces and selected infrastructure preceded launch.

ResultThe platform replaced the previous mix of tools and unified asset and maintenance management across the operations. The separation between the companies in the group held up under a later external look. The engagement continues as a long-term product and platform retainer.

Get in touch

Got something similar on your desk?

Tell us what it involves. We reply within one business day and say whether it is work for us, even when the answer is no.

Get in touch →Back to home