Month: September 2025

Open Source Code in the Insurance Sector: Boom or Cybersecurity Time Bomb?

bbossola, , Leave a comment

Benefits, Risks, and Real-World Attacks Involving Open Source in the Insurance Industry

The insurance sector is undergoing a rapid digital transformation, integrating technologies like artificial intelligence, big data analytics, blockchain, and cloud computing to better serve customers, optimise operations, and reduce fraud. Central to this shift is the growing reliance on open source software (OSS), tools, libraries, and platforms freely available for development, adaptation, and integration. From talking to c-suite members within all of the key sectors, OSS is recognised as beneficial but also seen as the “elephant in the room” as the risks are known but lack of experience in dealing with this layer is allowing threat penetration to be successful

While OSS empowers insurers with flexibility, innovation, and cost efficiency, it also introduces serious cybersecurity risks. This article explores how open source is being used in insurance, outlining  the real-world consequences of cyber threats involving OSS, and assesses the risks of future attacks, especially as threats grow more sophisticated.

Why Insurers Use Open Source Software

Open source components are now integrated into nearly every stage of the software development lifecycle in the insurance industry. Key benefits include:

  • Cost savings: Avoiding high licensing fees of proprietary software.
  • Faster development: Leveraging pre-built libraries and frameworks.
  • Community support: Tapping into vast global expertise and frequent updates.
  • Flexibility: Extending existing open source code to meet business-specific requirements.

Examples include:

  • Apache Kafka and Airflow for real-time data processing.
  • TensorFlow for machine learning in fraud detection.
  • PostgreSQL and MongoDB for scalable data storage.
  • OpenJDK as a base for Java-based enterprise applications.

With open source software, legacy systems have been replaced.  Insurance software providers have gained ready-to-use features and deliver enterprise-grade and SaaS applications 50-60% faster, while avoiding vendor lock-in.  They are seizing the opportunity to be part of a sector-specific open source software community to learn, grow, and contribute, with potential to shape the future direction at a sector level.  Some of these ready-to-use features include policy, claim, and property management, as well as time tracking.  There are also templates available to  offer embedded insurance products seamlessly integrated into customer buying experiences.

The business-led software-driven transformation helps streamline processes, enhance risk assessment, and improve customer service.  We can all appreciate the availability of cloud-based solutions that’s increased the ease of purchasing standalone and embedded insurance products in our daily digital experiences.  Forgot to buy travel insurance when you booked your ski holiday?  Not to worry, because the ski rental agency that’s selling ski lift passes on their mobile web app also lets you buy insurance when you checkout.  Open source software is helping to drive innovation and specialized offers across sectors, benefitting sellers and resellers from greater access to customers wherever they are in their journey.

OSS Cybersecurity Risks of Open Source within the Insurance Sector

Open source code, while powerful, is not immune to vulnerabilities. Many packages are maintained by volunteers, and while updates and patches are released very quickly, it’s difficult for a company to keep the pace, because of lack of  awareness and processes to handle them. A single unpatched library can serve as a gateway to an entire corporate network,  and for insurance companies, this can expose sensitive personal, financial, and medical data.

Key risks include:

  • Direct cyber attacks Because of the lack of vulnerability scanning, simply by leveraging an existing vulnerability in one opensource component used on an internet facing system, a hacker could get access to all internal databases.
  • Supply chain attacks A piece of malicious code included in a widely used software library is then automatically incorporated into thousands of downstream applications that use the library, allowing the attackers to compromise a vast number of targets simultaneously.
  • License mismanagement and IP risks When using a non-business friendly licensed component, there’s a significant risk of being forced to publicly release your own intellectual property, leading to loss of competitive advantage and potential legal action.
  • Shadow IT and undocumented OSS use The unmonitored use of unapproved software, often by developers seeking speed and agility, creates significant security and compliance blind spots, as these tools operate outside of corporate governance and lack security patching or vulnerability tracking

Notable Cyber Attacks Involving Open Source

1. Log4Shell (CVE-2021-44228) – Apache Log4j

In late 2021, a critical remote code execution vulnerability was discovered in Log4j, a widely used Java logging library.

Impact on insurance: Many insurance firms used Java-based enterprise systems that included Log4j, making them vulnerable.

Exploitation: Threat actors could remotely execute arbitrary code on affected systems. APT groups including Charming Kitten (Iran) and APT41 (China) were linked to active exploitation.

2. SolarWinds Supply Chain Attack

Though not directly OSS-related, this 2020 attack brought attention to third-party code risks, including OSS components.

Relevance to insurers: Many insurers use SolarWinds or similar IT management tools, and the incident led to an industry-wide audit of third-party dependencies.

3. MOVEit Transfer Exploits (2023)

Cl0p ransomware gang exploited zero-day vulnerabilities in MOVEit file transfer software, affecting dozens of insurance, healthcare, and finance companies.

Relation to OSS: MOVEit, while proprietary, included OSS components and APIs, showing how OSS can be an indirect vector.

Victims: Included Genworth Financial, a major life and mortgage insurer.

Known Named Threat Actors Targeting the Sector

  • DarkSide / BlackCat: Ransomware-as-a-Service groups frequently use software vulnerabilities, including in OSS, for initial access.
  • FIN11 / Cl0p: A ransomware group known for targeting insurance and financial companies.
  • APT38 (North Korea): Known for financial theft operations, including targeting SWIFT and related financial systems.
  • Lazarus Group: Has targeted healthcare and insurance sectors, possibly for both espionage and financial gain.

Future Threat Landscape: What’s Ahead?

The future risk to insurers from open source-based attacks is growing due to:

  • AI-driven vulnerability discovery tools used by threat actors.
  • Complex OSS supply chains making traceability and patching harder.
  • Open source CI/CD toolchains being exploited (e.g., Jenkins, GitLab CI).

Emerging Concerns:

  • Malicious open source packages: Attackers upload poisoned libraries to repositories like npm or PyPI. Example: “ctx” and “phpass” malicious packages.
  • Dependency confusion attacks: Exploiting package naming inconsistencies in private/public repositories.
  • Insider threats: Poor OSS governance can lead to accidental introduction of vulnerable or backdoored code.

Mitigation Strategies for Insurers

  1. Adopt SBOMs (Software Bill of Materials) Maintain a comprehensive inventory of all open source components in use.
  2. Automated Vulnerability Scanning Use tools like Meterian, WhiteSource, or Dependabot to detect issues early.
  3. Continuous Monitoring & Patching Establish DevSecOps pipelines to enforce regular OSS updates.
  4. Zero Trust Architectures Prevent lateral movement even if a component is compromised.
  5. Training & Awareness Developers should be trained on secure OSS usage and license compliance.

Conclusion

The open source revolution has undeniably propelled innovation in the insurance industry. But this double-edged sword demands a proactive cybersecurity posture. From high-profile exploits like Log4Shell to the growing sophistication of supply chain attacks, it’s clear that OSS security is no longer optional, it’s critical.

Insurers must recognize open source as both an opportunity and a threat. Only through comprehensive risk management, visibility, and cultural change can they unlock its benefits while shielding themselves from cyber catastrophe.

If you’re in insurance, now’s the time to put OSS security on the boardroom agenda.

Get in touch here to see how we can help!

Open Source Code in the Insurance Sector: Boom or Cybersecurity Time Bomb?

Jaguar Land Rover Cyberattack: A Wake-Up Call for Supply Chain Resilience

viviandufour, , , , Leave a comment
3–4 minutes

The automotive giant’s recent cyber breach shows why continuous vulnerability assessment and open-source security are no longer optional.

Earlier this month, Jaguar Land Rover (JLR), the UK’s largest carmaker, was forced to shut down global IT systems after a cyberattack disrupted production across its factories. Plants in Solihull, Halewood, Wolverhampton, and Slovakia were halted. Operations in China, India, and Brazil also felt the ripple effect.

Thousands of employees and suppliers were sent home. Dealers and garages had to switch to manual operations during one of the busiest sales periods of the year: the September license plate registration window.

While no customer data breach has been confirmed, the attack reflects how deeply cybersecurity failures in the supply chain can damage both business operations and national economies. JLR contributes nearly 4% of the UK’s exports.

How the Jaguar Land Rover Attack Happened

The hacking coalition calling itself “Scattered Lapsus$ Hunters” claimed responsibility, posting internal screenshots as proof. Analysts link the group to earlier social engineering campaigns carried out by collectives like Scattered Spider, Lapsus$, and ShinyHunters.

This was not a sophisticated zero-day exploit. It was an attack on trust and resilience. By exploiting weaknesses in IT systems and operational processes, attackers triggered a shutdown that cascaded across JLR’s entire global network.

For an industry where every production hour counts, this was a direct hit to the supply chain.

Why Supply Chain Vulnerabilities Are a Critical Business Risk

The JLR case illustrates the stark reality:

  • Operational Technology (OT) systems are connected to IT systems. A breach in one disrupts the other.
  • Third-party risk is first-party risk. If suppliers or partners are compromised, your own resilience is at stake.
  • Downtime is as damaging as data loss. Even without stolen records, JLR faces millions in lost productivity and missed sales.
  • Open-source software is everywhere. Modern automotive systems depend on open-source libraries and components. Without continuous monitoring, hidden risks can remain undetected until it’s too late.

Where Vulnerability Assessment Makes the Difference

This incident is a powerful reminder of the need for continuous vulnerability assessment and software supply chain security. Key protective measures include:

  • Automated vulnerability scanning across all code, dependencies, and applications
  • SBOM (Software Bill of Materials) to ensure visibility into every open-source component used in critical systems
  • Continuous monitoring for newly disclosed CVEs that could disrupt supply chains
  • DevSecOps integration to ensure remediation is part of the development and deployment pipeline
  • Incident readiness through real-time alerts and automated remediation guidance

How Meterian Helps Build Resilience

Meterian’s platform is built to detect, monitor, and remediate open-source vulnerabilities before they cause widespread damage.

  • BOSS (Business Open Source Sentinel): Provides real-time alerts for newly disclosed vulnerabilities across your software supply chain.
  • Sentinel: Automates vulnerability assessment and integrates into your CI/CD workflows to block unsafe code before it reaches production.
  • SBOM generation and ingestion: Gives you complete visibility into the components your business depends on, simplifying compliance and response.
  • AI-powered continuous monitoring: Ensures you are always ahead of emerging threats—whether in PHP, Java, .NET, or any other stack critical to your business.

Had such systems been in place across JLR and its suppliers, the blast radius of this attack could have been contained, with faster detection and remediation.

Why Open-Source Security Matters

The JLR breach demonstrates a truth we see across industries: open-source security is business security.

When 80–90% of modern applications depend on open-source components, every unpatched library becomes a potential entry point. The cost of ignoring these risks isn’t theoretical. It’s operational paralysis, financial loss, and reputational damage.

Don’t Wait for the Next Breach

The JLR cyber attack is not an isolated incident. It is part of a wider trend of supply chain attacks targeting global industries. The question is not whether open-source vulnerabilities exist in your systems—they do. 

The question is: are you continuously monitoring and remediating them?

Now is the time to take control of your software supply chain.

👉 Learn how to strengthen resilience in our upcoming webinar:
“What’s Open Source Security Got to Do with Resilience of the Supply Chain?”
 📅 September 18, 2025 • 14:00 BST • 15:00 CET • 09:00 ET • 18:30 IST

Register here

Jaguar Land Rover Cyberattack: A Wake-Up Call for Supply Chain Resilience

Major supply chain attack on the NPM ecosystem

viviandufour, Leave a comment

by Bruno Bossola, initially published on LinkedIn on September 9, 2025. Republished here following second larger attack on November 24, 2025.

3–5 minutes
An illustration depicting various JavaScript code packages on a conveyor belt, with some showing green coding structures and others displaying red, corrupted code. Visible elements include digital threats such as skull icons and serpentine shapes representing malware, symbolizing a cybersecurity attack on software supply chains.

A number popular JavaScript code packages were compromised to spread malware, posing a significant threat to software supply chains. The malicious code, often obfuscated, was hidden within seemingly legitimate packages on the Node Package Manager (NPM) registry and executed during the installation process. This type of supply chain attack can lead to the theft of credentials, sensitive data, and even cryptocurrency.

How was the attack performed?

The attack on the debug and chalk packages was a sophisticated supply chain compromise that began with a phishing attack targeting the maintainer’s account. Attackers used a deceptive email, impersonating NPM support, to compromise the maintainer’s credentials. With access to the account, they published new versions of a number of popular JavaScript packages, including debug and chalk, with malicious, obfuscated code. This malware was a cryptocurrency stealer designed to run on a compromised machine, intercepting browser activity and targeting Web3 wallets. The malicious code would hook into network requests and use a fuzzy-matching algorithm to replace a user’s wallet address with an attacker-controlled one during a transaction, silently redirecting funds without the user’s knowledge.

What are the packages affected?

This is the current list at ~0830GMT on 09 September 2025:

How do I know if I am affected?

If you are using Meterian and have Sentinel enabled, you’ve been notified. Please make sure to remove the offending package or move to a non-affected version, and then quarantine the affected systems.

If you are using Meterian, you will also notice that your builds are failing. This is normal, as now Meterian detects a vulnerable package and brings down the security score: the moment such score goes below your threshold, then the Meterian analysis will report a failure

In general, developers should audit their codebases for affected packages, monitor network logs for suspicious activity, and stay vigilant against compromised open-source libraries. This incident underscores the critical need for robust security practices in the software development lifecycle.

If you are a developer and you want to check if you’re affected, you can use a simple grep command in your project folder, where the packages are installed:

grep -r "_0x112fa8"

A Phishing campaign is actively ongoing targeting NPM maintainers!

This is an example of an email received by maintainers from the fake npmjs.help domain, which was created for the sole purpose of performing this attack. If you are an NPM maintainer, please be aware and disregard these emails!

Also, the website is now marked as malicious everywhere and is being taken down as we speak. Well done OSS community!

Article content

But I checked and I did not see any malicious code on GitHub!

The difference you’re seeing is due to how npm packages are published.

When a developer publishes a package, they’re not necessarily publishing the exact code from their GitHub repository. Instead, they run a command, npm publish, which creates a compressed file (a tarball) of the project’s files and sends that to the npm registry.

A maintainer can manually modify the files within this tarball before publishing, or their build process could include a step that modifies or adds code, such as minifying or obfuscating it. Because this process happens locally and the resulting tarball is sent directly to npm, these changes might never be committed to the public GitHub repository. This is why the code you see on the npmjs.com website can be different from the code in the associated GitHub

I am running a backend service: am I affected?

The code first confirms it’s running in a web browser by checking for the window object. Once it verifies the environment, it hijacks common methods for network requests and cryptocurrency transactions, specifically window.fetch, XMLHttpRequest, and window.ethereum.request. It also targets other wallet provider APIs.

This means the malware is designed to steal from end users who have a crypto wallet connected to their browser. While developers aren’t the primary target, they can also become victims if they visit an infected site and have an active wallet.

While the malicious code is designed to be activated in a browser, it is still a significant security risk to your backend service. Even though the malicious payload itself may not execute on the server, the compromised packages introduce a backdoor into your dependency chain. The best practice is to immediately update or remove the vulnerable packages to eliminate the risk of a future, more targeted attack on your server.

What’s next?

We will keep updating this article following the evolution of this incident. If you did not do it yet, please consider adding some defence in your pipeline: Meterian users using Sentinel were alerted overnight of the issue.

Best of luck, stay safe!

Update: Read the follow on attack in our blog post from Nov 24, 2025 about Shai-Hulud 2.0 worm.

Major supply chain attack on the NPM ecosystem