In December 2020, the security industry learned that SolarWinds, a trusted IT management vendor, had been distributing malware to its customers through routine software updates for months. Attackers had compromised the vendor's build pipeline and injected a backdoor into a legitimate product used by thousands of organisations, including US government agencies and Fortune 500 companies. The victims made no mistake: they installed a signed update from a trusted vendor, following normal procedures, and that was enough.
The SolarWinds attack changed how the industry thinks about supply chain risk, but for most African financial institutions the lessons have not translated into action. The assumption persists that supply chain attacks are a problem for large Western enterprises rather than for banks in Kigali, Nairobi or Dar es Salaam. That assumption is wrong, and the structure of the regional vendor market shows why.
Why supply chain attacks matter more in East Africa
East African banks depend on a concentrated ecosystem of software vendors and integrators. A typical institution relies on external providers for:
- Core banking systems: Temenos, Finacle, Flexcube or regional platforms from vendors such as Craft Silicon and BPC Banking Technologies
- Mobile money integrations: connectors to M-Pesa, MTN MoMo, Airtel Money and other mobile money platforms
- Payment gateway providers: switches connecting to national payment infrastructure, the Visa and Mastercard networks, and regional payment schemes
- Internet and mobile banking platforms: customer-facing applications frequently developed and maintained by third-party vendors
- System integrators: local firms that customise, deploy and maintain these platforms in production
The vendor pool is small: a limited number of integrators serve many of the region's banks, so a single compromised integrator could give attackers access to several financial institutions at once. That risk follows directly from how the market is structured.
Concentration amplifies risk. In mature markets, a large bank might choose its vendors from a pool of hundreds. In East Africa, many banks rely on the same small number of core banking vendors and local integrators, so a supply chain attack does not need to be sophisticated to have an outsized impact. Compromising one integrator with privileged access to several banks is more efficient than attacking each bank individually.
How supply chain attacks work against banks
Supply chain attacks exploit the trust between a bank and its vendors. They typically follow one of four patterns.
Compromised software updates
This is the SolarWinds model. Attackers gain access to a vendor's development environment or build pipeline and inject malicious code into a legitimate software update. When the bank installs the update (which passes integrity checks because it is signed with the vendor's real credentials), the malicious code executes inside the bank's trusted environment.
This is particularly dangerous with core banking system updates, which often run with elevated privileges and have broad access to transaction data, customer records and payment processing functions.
Compromised vendor access channels
Many vendors maintain persistent remote access to the banking environments they support: VPN tunnels, remote desktop connections and dedicated support accounts with administrative privileges. Attackers who compromise the vendor's own network can use these pre-established access channels to move directly into the bank's environment without triggering the perimeter security controls that would catch an external attacker.
Consider an integrator that operates a single shared service account with domain admin privileges across multiple client banks, a pattern our lead tester has encountered in earlier banking-sector engagements. A single compromised password at the integrator then exposes every client.
Compromised development and customisation
Local integrators often customise core banking platforms, develop middleware and build integrations between systems. If the integrator's development environment is compromised, attackers can insert backdoors or vulnerabilities during the customisation phase. These modifications ship to the bank as part of a legitimate project delivery, and the integrator's custom code is rarely tested with the rigour applied to the core vendor's product.
Dependency and library compromise
Modern banking applications rely on open-source libraries and third-party components. Attackers can compromise a widely used library (as seen in the 2024 XZ Utils backdoor attempt) or publish malicious packages with names similar to legitimate ones. When a vendor builds or updates its software, the compromised dependency is included and ends up deployed in your banking environment.
Real-world supply chain attacks: lessons for African banks
Supply chain attacks have hit financial services repeatedly.
SolarWinds (2020): The best-known supply chain attack. Attackers compromised the build system for SolarWinds Orion, a network monitoring tool with roughly 33,000 active customers at the time. The malicious update (SUNBURST) was distributed through the normal update channel to fewer than 18,000 of them, per SolarWinds' SEC disclosure, and remained undetected for months. Multiple US financial institutions were affected.
Kaseya VSA (2021): The REvil ransomware group exploited a vulnerability in Kaseya's VSA remote management tool to push ransomware to managed service providers (MSPs) and their clients. Close to 1,500 downstream organisations were hit in a single attack through their IT management vendor, by Kaseya's own account. Several of the affected MSPs served financial institutions.
3CX (2023): A legitimate desktop communications application from a vendor that reports over 600,000 customer companies was compromised through its own supply chain. Per Mandiant's incident analysis, a trojanised installer from a financial trading software vendor compromised 3CX first, and the 3CX build then distributed malware to end users. This was a supply chain attack that cascaded through two vendors before reaching victims.
MOVEit Transfer (2023): The Cl0p ransomware group exploited a zero-day in MOVEit, a managed file transfer tool used by banks, insurers and government agencies for sensitive data exchange. More than 2,600 organisations were compromised through that one shared vendor tool, per Emsisoft's tracking, rather than through attacks on their own systems.
XZ Utils (2024): A near miss. An attacker spent two years building trust as an open-source contributor before inserting a sophisticated backdoor into XZ Utils, a compression library embedded in nearly every Linux distribution. The backdoor targeted SSH authentication, and if it had not been discovered by accident, it would have given the attacker remote access to a vast share of the world's Linux servers, including banking infrastructure.
The same blind spots recur. In each of these attacks, the victims could not see the vendor's internal security practices or verify the integrity of what the vendor delivered, and they had no monitoring of what vendor-supplied software was doing inside their environment. The attackers exploited those gaps deliberately.
The East African supply chain threat surface
In East African banking, four risk areas stand out.
Core banking system vendors
Your core banking system is the most privileged software in your environment. It processes every transaction and holds every customer record, and every downstream system connects to it. The vendor that builds and maintains this software has, by necessity, deep knowledge of your environment and often retains administrative access for support purposes.
If that vendor's development environment, source code repository or build pipeline is compromised, the attacker gains a direct path into the heart of your banking operations. Find out what security controls your core banking vendor applies to its own software development lifecycle (SDLC); if you have never asked, start there.
Mobile money platform integrators
Mobile money integration is critical for East African banks. The middleware connecting your banking systems to mobile money platforms handles real-time financial transactions and often stores or transmits customer credentials and transaction data. The integrators who build and maintain these connections frequently have access to both the bank's core systems and the mobile money platform APIs.
A compromised mobile money integrator can intercept transactions, redirect funds or exfiltrate customer data from the integration layer, a position that sits between two trusted systems and is rarely monitored with the same intensity as either.
Payment gateway and switch providers
Payment switches connect banks to national payment infrastructure, card networks and, increasingly, cross-border payment schemes. That makes them high-value targets: a compromised payment switch could let attackers manipulate transaction routing, intercept card data or disrupt payment processing across several institutions.
In East Africa, several payment switches serve most of the banks in a given country. The systemic risk is real: a supply chain attack on a shared payment switch could affect the entire national payment infrastructure.
Local IT service providers
Many East African banks outsource some IT functions to local managed service providers. These MSPs often have broad access to client networks for remote support, patch management and infrastructure monitoring. The Kaseya attack showed what happens when an MSP's tools are compromised: every client connected through those tools becomes a target.
Building supply chain resilience: a practical framework
Defending against supply chain attacks requires a different mindset from traditional perimeter security. You cannot patch your way out of a compromised vendor. You need layered controls that assume vendor compromise is possible and limit the damage when it occurs.
1. Know your supply chain
Start with a complete inventory of every software vendor, integrator and service provider that touches your banking environment.
For each vendor, document:
- What systems and data can the vendor access?
- What is the vendor's level of network access (VPN, direct connection, cloud-based)?
- Does the vendor have persistent or on-demand access?
- What credentials does the vendor use, and who manages them?
- What software does the vendor supply, and how are updates delivered?
- Does the vendor use sub-contractors or sub-processors?
Classify vendors by the damage a compromise of that vendor could cause to your institution. This determines the level of scrutiny each vendor receives.
For a full methodology on vendor classification and assessment, see our guide on third-party vendor security assessment.
2. Verify vendor security posture
Verify your vendors' security rather than assuming it. For critical vendors (core banking, payments, mobile money):
- Request evidence of security testing: ask for penetration test reports, SOC 2 Type II reports or ISO 27001 certificates. If the vendor cannot produce any of these, that tells you something important.
- Assess the vendor's SDLC: how does the vendor build software? Does it conduct code reviews? Does it use static and dynamic analysis tools? How does it manage dependencies?
- Evaluate build pipeline security: does the vendor protect its build and deployment pipeline? Does it sign releases? Can it demonstrate a chain of custody from source code to the binary you install?
- Review the vendor's own supply chain: your vendor has vendors too. A security-mature vendor should be able to explain how it manages its own third-party risk.
3. Control vendor access ruthlessly
Vendor access to your environment should be treated with more suspicion than employee access, not less.
- Eliminate persistent access: vendors should not have always-on VPN tunnels or standing administrative credentials. Implement just-in-time access that requires approval and is time-limited.
- Enforce multi-factor authentication (MFA): every vendor connection must use MFA, without exception.
- Use dedicated accounts: each vendor employee who accesses your systems should have a named account, not a shared service account. Named accounts give you accountability and make monitoring meaningful.
- Segment vendor access: vendors should reach only the specific systems they need. A core banking vendor has no business accessing your email servers or domain controllers.
- Monitor everything: log and alert on all vendor access. Establish baselines so you can detect anomalous activity. A vendor support engineer connecting at 3am from an unusual location should trigger an alert.
- Record sessions: for privileged access, use session recording so you have a complete audit trail of what vendors do inside your environment.
4. Validate software integrity
When a vendor delivers software or an update, verify it before deployment:
- Independent hash verification: confirm that the software you received matches the vendor's published checksums, obtained through an independent channel (not the one that delivered the software).
- Code review for custom deliverables: any custom code, integration or configuration delivered by a local integrator should be reviewed by your own team or an independent security assessor before it goes into production.
- Test in isolation first: deploy vendor updates in a staging environment and monitor for unexpected behaviour (network connections, file system changes, process creation) before pushing them to production.
- Include vendor software in penetration testing: vendor-supplied platforms should be tested with the same rigour as internally developed applications, because that is where many of the critical vulnerabilities live. Our penetration testing programme specifically covers vendor-supplied banking platforms.
5. Monitor vendor-supplied systems in production
Once vendor software is running in your environment, monitor it continuously:
- Network monitoring: baseline the network behaviour of vendor-supplied systems. Core banking platforms, payment switches and integration middleware should have predictable communication patterns. Alert on connections to unexpected destinations.
- Process and file integrity monitoring: monitor for unexpected processes, configuration changes or file modifications on systems running vendor software.
- Log analysis: feed logs from vendor-supplied platforms into your security information and event management (SIEM) platform and build detection rules for anomalous behaviour.
- DNS monitoring: supply chain implants often use DNS for command and control. Monitor DNS queries from vendor-supplied systems for unusual patterns.
Detection is harder with supply chain attacks. Malicious activity from a compromised vendor arrives through trusted channels. Your firewall will not block it, because the vendor connection is allowed, and your antivirus may not flag it, because the malware is embedded in signed software. That is why behavioural monitoring and anomaly detection matter more than signature-based tools against supply chain compromise.
6. Prepare for vendor compromise incidents
Include vendor compromise scenarios in your incident response planning:
- Vendor isolation procedure: document exactly how to sever all connections to a specific vendor within minutes, including VPN tunnels, API connections, remote access tools and network-level access.
- Forensic readiness: know which systems interact with each critical vendor so you can scope an investigation quickly.
- Communication plan: establish a direct communication channel with each critical vendor's security team. During an incident, you need to reach the right people immediately, not through a support ticket queue.
- Alternative operations: for critical vendors, understand how you would operate if you had to disconnect from that vendor completely for an extended period. Can you run core banking without vendor support, and for how long?
For guidance on building an incident response capability, see our ransomware defence guide, which covers detection, containment and recovery processes that apply equally to supply chain incidents.
Supply chain risk management checklist
Use this checklist to assess your institution's supply chain security posture:
Inventory and governance
- Complete inventory of all technology vendors with access to banking systems or data
- Vendor classification by criticality and risk level
- Board-level reporting on supply chain risk
- Designated owner for the vendor risk management programme
Vendor assessment
- Security assessments completed for all critical and high-risk vendors
- Evidence of vendor security certifications or audit reports on file
- Vendor SDLC and build pipeline security evaluated for software suppliers
- Vendor sub-processor and fourth-party risk assessed
Access controls
- No persistent vendor access to production systems
- MFA enforced on all vendor connections
- Named accounts for all vendor personnel (no shared accounts)
- Vendor access limited to specific systems through network segmentation
- Vendor session monitoring and recording in place
Software integrity
- Software delivery integrity verification process documented and followed
- Custom code from integrators reviewed before production deployment
- Vendor updates tested in staging before production deployment
- Vendor-supplied platforms included in penetration testing scope
Monitoring and detection
- Network behaviour baselines established for vendor-supplied systems
- Vendor access activity monitored and alerted on anomalies
- Vendor-supplied system logs integrated into SIEM
- DNS monitoring active for systems running vendor software
Incident preparedness
- Vendor isolation procedures documented and tested
- Direct contact with security teams at critical vendors
- Vendor compromise scenario included in incident response tabletop exercises
- Business continuity plans account for loss of critical vendor access
The regulatory dimension
The cybersecurity regulation of the National Bank of Rwanda (BNR) explicitly requires supervised institutions to manage third-party risk, and supply chain risk falls within that obligation. During examinations, BNR will look for evidence that you assess vendor security, include vendor systems in your testing programme and keep contractual rights to audit.
Beyond BNR, the Central Bank of Kenya, the Bank of Tanzania and other East African regulators are moving in the same direction, and managing supply chain risk is becoming a regulatory expectation across the region as well as good security practice.
Institutions that can demonstrate a mature supply chain risk management programme will have an easier time during regulatory examinations and a stronger position if an incident occurs.
Start with what matters most
You do not need to solve every supply chain risk at once. Start with the vendors that matter most:
- Identify your three to five most critical vendors: the ones whose compromise would cause the most damage to your institution
- Assess their security posture: request certifications, review access and evaluate how updates are delivered
- Lock down their access: eliminate persistent connections, enforce MFA and put monitoring in place
- Include their platforms in your next penetration test: find the vulnerabilities before an attacker does
- Build the vendor compromise scenario into your incident response plan: know how you would isolate and investigate
Each step reduces your exposure. Perfect supply chain security does not exist, but the gap between doing nothing and doing the basics is where most of the risk lives.
How we can help
IMIZI Cyber is a Kigali-based firm providing manual penetration testing for banks, fintechs, telecoms, government and healthcare institutions across Africa. Our testing is led by an OSCP- and PNPT-credentialled practitioner and grounded in recognised methodology and evidence-led reporting a board and a regulator can both act on. We test vendor-supplied banking platforms, assess third-party integrations and help institutions understand and reduce their supply chain risk. We scope that testing around the vendor platforms and integration patterns common in the region, because that is where inherited vulnerabilities tend to hide.
For penetration testing of vendor-supplied systems, see our penetration testing service page. For broader vendor risk assessment, see our security assessments service page. Contact us to evaluate the supply chain risk in your banking environment.