ClearBank broke a 250-year tradition by becoming the first new clearing bank in the UK in centuries. That spirit of innovation made them an early design partner for Phoenix Security, shaping advanced strategies for Application Security Posture Management (ASPM) and remediation. Their commitment to modern cybersecurity practices stands out, especially given the landscape of shifting regulations and the constant need to tackle root causes behind vulnerabilities. Neil Reed, Principal AppSec Engineer at ClearBank, offers a glimpse into the mindset and methods that drive their approach.
====
The path to fewer critical risk ClearBank way
As a Principal Security Engineer, I have learned that there is never enough time or resources to address every vulnerability. This is where context and domain knowledge become crucial.
Numerous tools exist that can identify vulnerabilities in your codebase and outdated dependencies (Software Composition Analysis [SCA], Static Application Security Testing [SAST], etc.). Similarly, third-party scanning software can alert you to misconfigurations in your cloud infrastructure or non-compliance with best practices. Before you know it, you can find yourself overwhelmed by a sea of vulnerabilities, with a team unsure of which “Critical” issue is the top priority to address next. It’s all too easy to lose hope in this sea.
The problem lies in the fact that these tools lack context. They do not understand which codebases are your crown jewels. Is that code running on secure cloud infrastructure? What about the Web Application Firewall (WAF)? Does it offer any protection? And is there DDoS protection to help mitigate attacks?
No one wants to be the person who cries wolf over a vulnerability that never materialises. However, it is essential to have the ability to raise concerns when justified. With the knowledge and context of countermeasures, what initially appeared as a critical issue can be downgraded accordingly.
I strongly believe in defense in depth: if one control fails, there should be another to detect, stop, and reduce the potential blast radius. For over a year, I have worked with Phoenix to map ClearBank’s systems, allowing for more informed business decisions regarding potential vulnerabilities.
As with most companies, mapping ownership and business importance is key. I am fortunate that ClearBank has a centrally managed list of repositories and team owners. Within this list are other useful metadata, such as the Domain and Subdomain of the service, along with a tier. The lower the tier, the higher the importance to the business. Using this information, I created a list of applications within Phoenix that group repositories.
To keep the cogs that make up the application close together, I used the Subdomain combined with the Domain to name the application. For example, a Domain of Payments and a Subdomain of Faster Payments would be called “Faster Payments – [Payments].” The reason for combining Domain and Subdomain is that Subdomains are not globally unique.
Within each application, Phoenix allows components to have unique overriding criticality score weighting. This is where I have assigned the tiering from the source of truth of repository ownership. Each element is a repository with its score and a tag linking it to the owning team. I use rules to assign ownership based on the team meta tag called “pteam”. This allows easy management and reassignment of ownership of repositories.
At this stage, I know which repositories (components) belong to which team, which elements make up an application (Subdomain and Domain), and their overall risk. The criticality setting based on tiering allows the original code scanning tool value to be weighted appropriately based on the importance of the service as deemed by the business.
At this stage, you could have a false sense of security that you know everything about your services. However, what about the cloud components where the service is deployed to? What if they are not secure?
Fortunately, Phoenix allows you to specify the environment and the service to which the application is deployed. As it’s the application and not the component, you must remember that code may perform one key function for a service, e.g., API, and other code performing the data lookups. If one of those components was compromised, what would be the effect on the service?
As with the components, applications can be assigned criticality weightings, allowing adjustment to the imported cloud findings. Each environment and service has its own score, considering what the purpose of the environment is. For example, your Dev Environment will not contain PII data, but Production will. Therefore, you should concentrate your efforts on securing production first.
At ClearBank, we use Infrastructure as Code [IaC] to deploy our infrastructure and meta tags to create the pipeline. Lookups are performed to create rules based on this data and assign cloud assets to services. The service names are combined for ease of pairing: Subdomain and Domain. Using the example from earlier, the “Faster Payments – [Payments]” application is deployed to the Production “Faster Payments – [Payments]” cloud service.
Now, we are starting to get to a system that knows the business importance of the code and the service it runs on. However, more can be done to help understand the countermeasures and score the vulnerabilities appropriately.
Again, Phoenix has thought of this and allows external, DMZ, or internal context settings. This applies to Cloud and Software; a default context can be set. In security, it pays to be paranoid until you are sure something is true; therefore, I have everything set to the worst-case external scenario by default. I class anything directly exposed to the Internet as external; if it’s behind a WAF or other service but consumes data from a user, it’s DMZ; then private, only verified with no direct Internet ingress, are internal. The assignment is achieved by adding tags to the cloud assets and rules within the context engine.
This information and configuration are fantastic at helping assign the appropriate scoring to the service. There will always be domain knowledge that someone holds in their head or is undocumented. This is where other specific rules become very useful. The exception engine allows for this.
A prime example is that unit tests will exist within code repositories but are not run on Production. They, therefore, shouldn’t be given the same importance as a Production vulnerability. To tackle this, I have created a Test project rule that looks at the location of the finding for keywords that relate to test projects, such as “xUnit,” “smoke,” and “Test.” If a match is found, the finding is risk-recast to a lower score. It is still there for overall knowledge and reporting but allows the more significant issues to be tackled first.
Other elements we used for Scaling Security – Exceptions, Smarter Remediation, and Cutting Container Noise
Security is never just about finding vulnerabilities—it’s about fixing them where they matter most. Leveraging Phoenix Security transforms how we approach prioritization and remediation at ClearBank.
The ability to write security exceptions and rescore vulnerabilities at scale has been a game-changer. Not every alert deserves the same attention, and without a way to fine-tune risk, teams can get overwhelmed by the workload. The exception engine in Phoenix Security allows us to craft rules that adjust severity dynamically, ensuring that real threats stay at the forefront. In contrast, the less critical ones don’t clog up the workflow. Test artifacts? They don’t get the exact weighting as Production issues. Vulnerabilities buried in deprecated code that never reaches Production? They don’t get in the way of fixing actual risks.
But security isn’t just about managing exceptions—it’s about fixing problems at scale. That’s why we’ve been running targeted remediation campaigns, ensuring engineers focus their time on vulnerabilities that truly affect the business. Instead of a never-ending list of issues, we can create structured, achievable remediation sprints aligned with how teams work, not against them.
One of the biggest wins? Tackling the sheer volume of container vulnerabilities. Initially, we were flooded with container-related security findings from Azure. Managing that number was impractical, and we were clearly dealing with excessive noise. Using Phoenix Security’s container throttling capabilities, we stripped away the unnecessary imports, refining our dataset to focus on relevant containers. The result? A streamlined, high-fidelity view, a 91% reduction in noise. Suddenly, security findings became actionable, not overwhelming.
This transformation is not merely about streamlining processes; it’s about enhancing security’s effectiveness. We’ve crafted a workflow that scales efficiently without causing delays by removing distractions and providing teams with clear guidance. It’s a security approach that collaborates seamlessly with engineering, rather than hindering it.
Conclusion
Using these combined techniques allows for the overall number of vulnerabilities to increase but the number of Criticals to be driven down to more manageable amounts.
In times when security resources are never enough, and the engineering team needs to focus on producing code rather than chasing every vulnerability, we rely on a partner like Phoenix Security to help us scale our resources and provide clarity over who needs to do what where.
Note from Phoenix Security
We are absolutely grateful and static to work with amazing partners like ClearBank and the ability to move the industry forward in a more risk based and controlled threat centric approach.
Francesco CEO & Co-Founder Phoenix Security
Get on top of your code and container vulnerabilities with Phoenix Security Actionable ASPM powered by AI-based Reachability Analysis
Organizations often face an overwhelming volume of security alerts, including false positives and duplicate vulnerabilities, which can distract from real threats. Traditional tools may overwhelm engineers with lengthy, misaligned lists that fail to reflect business objectives or the risk tolerance of product owners.
Phoenix Security offers a transformative solution through its Actionable Application Security Posture Management (ASPM), powered by AI-based Contextual Quantitative analysis. This innovative approach correlates runtime data with code analysis to deliver a single, prioritized list of vulnerabilities. This list is tailored to the specific needs of engineering teams and aligns with executive goals, reducing noise and focusing efforts on the most critical issues.
Why do people talk about Phoenix?
• Automated Triage: Phoenix streamlines the triage process using a customizable 4D risk formula, ensuring critical vulnerabilities are addressed promptly by the right teams.
• Contextual Deduplication with reachability analysis: Utilizing canary token-based traceability for network reachability and static and dynamic runtime reachability, Phoenix accurately deduplicates and tracks vulnerabilities within application code and deployment environments, allowing teams to concentrate on genuine threats.
• Actionable Threat Intelligence: Phoenix provides real-time insights into vulnerabilities’ exploitability, combining runtime threat intelligence with application security data for precise risk mitigation.
By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.
