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 did not make a mistake. They installed a signed update from a trusted vendor, following normal procedures. That was enough.
The SolarWinds attack was a turning point in 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, not for banks in Kigali, Nairobi, or Dar es Salaam.
That assumption is wrong, and it is becoming more dangerous every quarter.
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 like 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, VISA/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 handful of integrators serve dozens of banks across the region. A single compromised integrator could provide attackers with access to multiple financial institutions simultaneously. This is not hypothetical. It is the logical structure of the market.
Concentration amplifies risk. In mature markets, a large bank might use vendors from a pool of hundreds. In East Africa, many banks use the same five or six core banking vendors and the same three or four local integrators. This concentration means a supply chain attack does not need to be sophisticated to have outsized impact. Compromising one integrator with privileged access to multiple banks is more efficient than attacking each bank individually.
How supply chain attacks work against banks
Supply chain attacks exploit the trust relationship between a bank and its vendors. The attack typically follows one of several patterns:
Compromised software updates
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, 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.
We have seen integrators in East Africa with a single shared service account that has domain admin privileges across multiple client banks. One compromised password at the integrator, and every client is exposed.
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 nobody tests the integrator’s custom code with the same 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 their software, the compromised dependency gets included and ultimately deployed in your banking environment.
Real-world supply chain attacks: lessons for African banks
These are not theoretical scenarios. Supply chain attacks have hit financial services repeatedly.
SolarWinds (2020): The most well-known supply chain attack. Attackers compromised the build system for SolarWinds Orion, a network monitoring tool used by over 30,000 organisations. The malicious update (SUNBURST) was distributed through the normal update channel 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 and their clients. Over 1,500 organisations were hit in a single attack through their IT management vendor. Several of the affected MSPs served financial institutions.
3CX (2023): A legitimate desktop communications application used by over 600,000 organisations was compromised through its own supply chain. A trojanised library from a financial trading software vendor was incorporated into the 3CX build, which then distributed malware to end users. This was a supply chain attack that cascaded through two vendors before reaching victims.
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 millions of servers worldwide, including banking infrastructure.
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. Hundreds of organisations were compromised not because they were directly attacked, but because they used a common vendor tool.
The pattern is consistent. In every major supply chain attack, the victims had no visibility into the vendor’s internal security practices, no way to verify the integrity of what the vendor delivered, and no monitoring of what vendor-supplied software was doing inside their environment. The attackers exploited these blind spots deliberately.
The East African supply chain threat surface
Applying these lessons to the East African banking context, several specific risk areas stand out:
Core banking system vendors
Your core banking system is the most privileged software in your environment. It processes every transaction, holds every customer record, and connects to every downstream system. 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. Ask yourself: do you know what security controls your core banking vendor applies to their own software development lifecycle? Have you ever asked?
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 to cross-border payment schemes. These are high-value targets. A compromised payment switch could allow attackers to manipulate transaction routing, intercept card data, or disrupt payment processing across multiple institutions.
In East Africa, several payment switches serve the majority of 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 demonstrated exactly 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
You cannot protect what you do not understand. Build a comprehensive 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
Do not assume that your vendor’s security is adequate. Verify 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? Do they conduct code reviews? Do they use static and dynamic analysis tools? How do they manage dependencies?
- Evaluate build pipeline security: does the vendor protect their build and deployment pipeline? Do they sign releases? Can they demonstrate 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 they manage their 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: every vendor connection must use MFA. No exceptions
- Use dedicated accounts: each vendor employee who accesses your systems should have a named account, not a shared service account. This provides accountability and makes monitoring meaningful
- Segment vendor access: vendors should only reach 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 through an independent channel (not the same channel 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 deployment to 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 to production
- Include vendor software in penetration testing: vendor-supplied platforms should be tested with the same rigour as internally developed applications. This 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 SIEM 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. Your antivirus may not flag it because the malware is embedded in signed software. This is why behavioural monitoring and anomaly detection matter more than signature-based tools when defending 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 go through a support ticket queue
- Alternative operations: for critical vendors, understand how you would operate if you had to completely disconnect from that vendor for an extended period. Can you run core banking without vendor support? For how long?
For guidance on building an incident response capability, see our ransomware defense 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 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
BNR cybersecurity regulation explicitly requires supervised institutions to manage third-party risk. Supply chain risk is a subset of this obligation. During examinations, BNR will look for evidence that you are assessing vendor security, including vendor systems in your testing programme, and maintaining contractual rights to audit.
Beyond BNR, the Central Bank of Kenya, Bank of Tanzania, and other East African regulators are moving in the same direction. Managing supply chain risk is not just good security practice. It is becoming a regulatory expectation across the region.
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 simultaneously. 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, implement monitoring
- 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
We are an OSCP-certified penetration testing firm based in Kigali. We test vendor-supplied banking platforms, assess third-party integrations, and help institutions across East Africa understand and reduce their supply chain risk. We know the common vendor platforms and integrators in the region, and we know where the 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.