Contact us
Secure Your Code. Strengthen Your Software

43,000+

Lines of first-party code reviewed

21

Findings raised and prioritised

0

Critical or high-severity issues in the application code

Overview

The client is a customer relationship management platform built in-house for a multi-brand retail group in the UAE. It holds customer personal data — names, contact details, visit and spend history — across several brands and locations, and adds task workflows, analytics and an AI-assisted communication feature on top. Because it processes personal data, it falls under the UAE Personal Data Protection Law and, where EU data subjects are involved, the GDPR.

Testvox carried out a white-box security assessment of the codebase: a Static Application Security Test of the first-party code across backend, frontend and database scripts, and a Software Composition Analysis of every third-party component in both ecosystems. Both were consolidated into a single prioritised register mapped to the OWASP Top 10, with every finding carrying a severity, a business impact statement and specific remediation guidance.

Challenges Faced by Client

  • Personal data under a regulatory obligation This is not an internal tool where a security gap is an inconvenience. The platform holds customer PII, so the security of processing is a legal duty, and the quality of the audit trail directly affects the ability to assess a breach within the notification window.
  • A deliberately layered access model that had to be proven, not assumed Access is scoped by brand, by location and by granular permission, with delegated administrators who hold some admin rights but must not be able to escalate to all of them. A model like that is only as good as its weakest route, and it cannot be verified by reading the design document.
  • Scanner output that overstates and understates at the same time Automated tooling flagged dozens of potential issues in the application code and a large block of critical and high advisories in the dependency tree. Taken at face value, that reads as an alarming security posture. Taken correctly, most of it was not reachable — and the genuinely urgent item was not the one with the loudest label.
  • No dependency auditing in the build pipeline The advisories affecting the project had been published for some time, but nothing in the pipeline was watching for them, so the team had no way of knowing which of their components had become vulnerable.
  • An AI integration in the trust boundary A feature that sends customer context to an external model service introduces a data-minimisation question that a conventional code review checklist does not ask.

Testvox Solution

  1. Automated Analysis Followed by Manual Triage of Every Result

    2. Every automated result was reviewed by hand rather than passed through to the report. The largest block of flagged items concerned dynamically constructed database queries; each one was traced to its source and confirmed to use safe parameter binding with server-side allow-lists, and therefore reported as not exploitable. The same discipline applied to the dependency findings: a long list of critical and high advisories in the frontend tree resolved, on inspection, to build and test tooling that is never shipped to users. Reporting those at face value would have been easier and far less useful.

  2. Reachability-Based Severity, Not Scanner Severity

    3. Rather than inheriting whatever rating an advisory database assigned, each dependency finding was rated by what it actually meant for this application: is the vulnerable function reachable, does this code path exist in production, what compensating controls are already in place. Some advisories were downgraded because the affected APIs are never called. One was rated higher than its surface description suggested, because it sat in an authentication-critical library with no upstream fix available. The result is a severity ranking the client's team can act on in order.

  3. Manual Review of the Security-Critical Paths

    4. Authentication, session handling, authorisation on every API route, object-level access, delegated administration, the AI integration, data exports, configuration and CI were reviewed by hand. This is where the access model was either confirmed or broken — and confirming it is a result in its own right, since it is the control that keeps one brand's customer data away from another's staff.

  4. Findings Framed in Business and Compliance Terms

    5. Each finding carries its technical impact, but also what it means commercially and for the regulators: which personal data is exposed, which OWASP category and verification standard it maps to, and which obligation under the applicable data protection law it touches. A development team gets a fix; a decision-maker gets a reason to prioritise it.

  5. A Roadmap Sorted by When to Act, Not Just How Bad It Is

    6. The findings were consolidated into a single remediation table split into three tiers: items to resolve before the next production release, items for the following development cycle, and items for routine maintenance. Every entry names a target version or a specific code change, so the roadmap is a work queue rather than a reading exercise.

Result

The Application Code Came Back Clean

No critical or high-severity vulnerabilities were found in the first-party code. Database queries were safely parameterised throughout, the brand and location access model was enforced server-side on every route, delegated administrators could not escalate their own privileges, and no secrets were committed to the repository. For a platform holding customer PII, that is the finding that matters most — and because the review was white-box and manual, it is evidence rather than an assumption.

Every Top-Severity Issue Came From Outside the Application

The highest-rated findings were all third-party: components in the build and test tooling, and an authentication library with no available upstream fix. The production bundle shipped to users contained no known vulnerable packages at all. That inversion is the useful headline — the team's own code was in better shape than its supply chain, which is the opposite of what the raw scanner totals implied and points remediation effort at dependency management rather than at a code rewrite.

A Build Pipeline Gap That Explained the Rest

The pipeline ran tests, type checks and linting, but no dependency audit, which is precisely why these advisories had gone unnoticed. The report recommended adding dependency auditing and automated update tooling to CI — a one-time change that stops the same backlog accumulating again, and arguably the single highest-value recommendation in the whole engagement.

An Honest Separation of Urgent From Noisy

Of 21 findings, a small number were urgent, a handful were worth a sprint, and the rest were routine maintenance or informational. A report that labelled all 21 as problems would have been technically defensible and practically useless. The client got a ranked queue and a documented list of controls worth preserving through future development.

Conclusion

Most security reports are read once and filed. This one was built to be worked through: every automated result triaged by a human, every dependency finding rated by whether it was actually reachable in this application, every issue tied to a business consequence and a specific fix, and the whole set sorted into what to do before the next release and what can wait. The outcome told the client something genuinely useful — their engineering practice was sound, and their exposure lived in the components they had inherited rather than the code they had written. That is a cheaper problem to solve, but only once someone has looked closely enough to tell the difference.

Related Resources