We’re already into the second half of 2026, and it’s worth pausing for a second. Not to recap headlines, but to understand what actually changed in terms of security.
Spoiler alert…. A lot.
Because 2025 wasn’t just another year of breaches. The scale was larger, and the impact was more visible.
The attack on Jaguar Land Rover brought that into focus. Production stopped for months. The losses were estimated at £1.9 billion. The disruption moved straight into operations and revenue.
In the education sector, Kido International faced a ransomware incident that exposed personal data linked to thousands of children and staff. The impact here sat around safeguarding and trust.
Retail saw a similar strain. The ShinyHunters group claimed breaches across multiple brands, including Marks & Spencer. Some platforms lost the ability to trade online during the disruption.
Alongside these cases, a large pool of over 16 billion credentials circulated across criminal forums. Those datasets fed ongoing account takeover attempts throughout the year.
None of this felt isolated. The same weaknesses appeared again and again.
Constant Pressure on Infrastructure
Attacks moved closer to systems that support daily life.
The incident in Poland’s energy sector showed how attackers can move across IT and operational environments. That overlap creates a different kind of exposure.
In the UK, water utilities faced continued pressure from ransomware incidents. These systems often rely on older industrial controls with limited visibility.
At the consumer level, compromised IoT devices formed large botnets. Devices that sit in homes became part of wider attack infrastructure without the user being aware.
The surface area kept expanding.
The Supply Chain Problem is Getting Bigger
Across these incidents, the supply chain kept appearing in the background.
Attackers focused on software providers, cloud platforms, and third-party tools. Access at that level opens the door to many organisations at once.
This approach scales efficiently. One weakness can affect a large number of systems downstream.
For most organisations, this sits outside direct control. That makes it harder to track and harder to manage.
What’s Changing in 2026? A lot
The direction for the coming year is already visible.
Attack workflows are becoming faster. Automation plays a larger role. AI is being used to scan systems, prepare phishing content, and identify weak points.
The targets remain consistent. Local government systems, supply chains, and infrastructure continue to attract attention.
These environments often operate with limited resources and older technology. That combination creates exposure that is difficult to close quickly.
The Open Source Reality
Most systems depend on open source components.
That dependency runs deep. Many components sit several layers down, out of sight during routine checks.
Over time, vulnerabilities build up in those layers. Without active monitoring, they remain unnoticed.
Periodic reviews miss changes that happen between audits. New vulnerabilities appear regularly, and attackers move quickly once they are public.
Continuous monitoring becomes part of day-to-day security, rather than an occasional task.
The events of 2025 point to a clear shift in approach.
Security needs to keep pace with how quickly vulnerabilities appear and spread. That requires visibility into dependencies and a way to respond without delay.
The focus moves toward shorter response times and better awareness of what sits inside each system.
Small gaps tend to expand quickly when left unattended.
Closing Thought
The past year showed how cyber incidents now reach into operations, services, and public systems.
The same patterns are already carrying into 2026.
The difference will come from how quickly organisations detect and respond to what is already present in their environment.
What can you do? Start with visibility. Continuous monitoring of your open source components is non-negotiable.
Open source powers most modern software and expands your attack surface. At APIdays London, Meterian CTO Bruno Bossola showed how a crafted JSON request can trigger remote code execution when a vulnerable dependency slips into a service.
The key takeaway was that without visibility and fast remediation, vulnerabilities ride your software supply chain into production.
1) Exploits start upstream, not in production
Meterian’s live demo used a known jackson-databind flaw to execute code via a JSON payload. Incidents like the Apache Struts 2 breaches proved the same point years ago: attackers go where libraries are ubiquitous and exposure is public-facing.
Teams still discover many issues late, inside CI/CD or after release. By then, the vulnerable package is woven into multiple services and rollbacks get expensive.
What to change
Shift security into the IDE so developers see and fix dependency risk as they code.
Add pre-push and CI checks to block known-bad versions before they land on main.
2) You can’t patch what you can’t see
Most applications are a small slice of proprietary code on top of a large stack of third-party packages. New CVEs appear daily across NVD, OSV, and GitHub Advisories. If you don’t know exactly which versions you run—including transitives—you can’t assess blast radius or prioritise patches.
What good visibility looks like
Keep an up-to-date SBOM for every build (e.g., CycloneDX) and ingest vendor SBOMs.
Continuously monitor your dependency graph against live feeds and internal policy.
Prioritise RCEs and internet-exposed paths first, then reduce debt in lower-risk services.
3) Make remediation fast and routine
In the demo, upgrading a vulnerable component inside the IDE removed the exploit path in seconds. That’s the experience to aim for: actionable guidance at the moment of discovery, with one-click upgrades where possible. Speed reduces MTTR, avoids regressions, and prevents risk from spreading across repos.
Operationalise speed
Standardise one-click upgrades and automated PRs for safe versions.
Set patch SLAs by severity and exposure (e.g., 24–72 hours for critical RCEs).
Track MTTR, exception waivers, and policy drift to guide platform investments.
A simple workflow that works
IDE (shift left): real-time vulnerability assessment of manifests and transitive dependencies, with suggested fixes developers can apply immediately.
Pre-push: Git proxy hooks to enforce policy and block known-bad versions.
CI/CD: SCA checks per build, SBOM generation/signing, and fail-the-build on criticals.
Post-build: continuous monitoring of deployed SBOMs against new advisories; targeted rollouts for high-risk upgrades.
Governance: clear patch SLAs, exception process, and regular supply-chain reporting to leadership.
Bottom line
Exploit paths are simple; dependency graphs are not. Treat open source security as a first-class discipline.
Visibility is non-negotiable. If you can’t list it, you can’t fix it.
Shift left so the fastest path becomes the secure path—inside the IDE, at pre-push, and in CI.
Meterian’s APIdays demo made it clear: build visibility, shorten the distance from detection to fix, and your software supply chain becomes measurably safer.
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
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
Following our recent alert about the PHP AVideo exploit (CVE-2025-48732), another high-risk vulnerability has emerged: ADOdb SQL Injection – CVE-2025-54419. This newly discovered open-source vulnerability in the ADOdb database abstraction library affects a wide array of PHP applications. And yes—it puts your customer database at serious risk.
Therefore, businesses must patch now, or risk customer data loss and brand damage.
Why This Vulnerability Matters
SQL Injection remains one of the most exploited classes of software flaws in today’s threat landscape. The ADOdb vulnerability (pre-5.22.9 versions) allows attackers to manipulate query inputs in PHP applications using SQLite3, enabling them to execute arbitrary SQL commands and:
Access sensitive customer data
Delete or modify database records
Compromise connected systems
This flaw exposes an all-too-common weakness in open-source software components. When dependency management fails, it’s your customer data and digital brand trust on the line.
What is ADOdb and Who Uses It?
ADOdb is a widely used open-source database abstraction library that enables PHP developers to write flexible applications that work across:
MySQL
PostgreSQL
Oracle
Microsoft SQL Server
SQLite
DB2
Sybase
Firebird
Access ODBC
Informix
And more…
It acts as the middleware connecting your PHP app to its data. In modern e-commerce, SaaS, and media delivery platforms, ADOdb often underpins customer records, inventory systems, and transaction logs.
Understanding the Vulnerability (Technical Breakdown)
This SQL injection vulnerability exploits three ADOdb methods:
metaColumns()
metaForeignKeys()
metaIndexes()
If these methods receive a malicious table name, SQLite3 fails to properly escape the input—leading to arbitrary SQL execution.
❗ A single malformed input can compromise your entire database.
This isn’t hypothetical. It’s a known weakness. And it’s now indexed across vulnerability databases. Attackers are already probing for this entry point.
Real-World Impact
Think of it this way: a customer attempts to view their order history. But due to a code-level vulnerability, the attacker uses that same request to exfiltrate entire user tables or drop your product catalog. This can result in:
Permanent data loss
Corrupted analytics and reports
System downtime
Compliance fines (e.g. GDPR, PCI-DSS)
Severe brand reputation damage
A recent IBM report noted that data breaches tied to open-source component vulnerabilities cost businesses an average of $4.45 million per incident in 2024.
What You Should Do Now
Here’s your quick vulnerability assessment checklist for ADOdb:
✔️ Does your application use ADOdb prior to version 5.22.9? ✔️ Are you using the metaColumns(), metaForeignKeys(), or metaIndexes() methods? ✔️ Are your PHP apps connecting to a SQLite3 database? ✔️ Have you scanned third-party dependencies for known CVEs?
If you answered “yes” or “not sure” to any of these, your platform is at risk.
Mitigate risk now with a software composition analysis (SCA) tool that identifies vulnerable open-source components and provides auto-remediation.
Meterian’s Take
At Meterian, our daily scans using BOSS and Sentineldetected and flagged this vulnerability as of August 5, 2025. Teams relying on Meterian’s continuous monitoring and automated vulnerability assessment tools received instant alerts and recommendations to patch or isolate affected components.
Learn How to Protect Your Software Supply Chain
Want to explore how continuous vulnerability assessment can protect your platform?
📍 Learn practical steps to secure your software supply chain 📍 Get insights from industry experts on real-world open-source risks 📍 Explore tools for automated remediation and SBOM management
SQL injection may seem like an old-school threat, but vulnerabilities like this one in ADOdb show that even trusted, mature packages are not immune.
Don’t assume your code is safe just because it compiles.🔍 Start your vulnerability assessment today. Use tools that continuously scan and remediate open-source security risks—before attackers breach your systems.
In May 2025, cybersecurity headlines were dominated by Ivanti Endpoint Manager Mobile (EPMM) facing active exploitation through chained remote code execution (RCE) vulnerabilities—CVE‑2025‑4427 and CVE‑2025‑4428.
These flaws enabled unauthenticated attackers to execute malicious code on affected systems, affecting enterprises globally. Ivanti’s vulnerabilities were notably tied to outdated open-source Java components, highlighting the critical importance of managing open-source security dependencies.
In this blog, we explore the Ivanti incidents, understand the role vulnerable Java libraries played, and demonstrate how proactive software composition analysis (SCA), continuous monitoring, and automated remediation through Meterian-X could have prevented or swiftly mitigated these attacks.
Ivanti’s Open Source Vulnerability: Java Libraries at Fault
The Ivanti vulnerabilities were rooted in the software’s reliance on outdated versions of Java libraries, specifically including “hibernate-validator.” These libraries were susceptible to chained exploits:
These vulnerabilities underscore a significant risk: even trusted enterprise products can expose businesses if they incorporate insecure or outdated open-source components.
Understanding the Attack Surface
Ivanti’s attack scenario reveals common industry oversights:
Outdated dependency versions not promptly updated.
Inadequate visibility into the software bill of materials (SBOM).
Insufficient integration of security checks in the continuous integration and continuous delivery (CI/CD) pipeline.
Given the rise in nation-state actors targeting supply chains, companies must ensure software dependencies are continuously scrutinized.
Continuous Monitoring & Detection with Meterian Sentinel
Meterian Sentinel actively monitors dependencies, aggregating real-time vulnerability intelligence from authoritative sources, such as the National Vulnerability Database and GitHub Security Advisories.
Sentinel would have identified Ivanti’s outdated “hibernate-validator” dependency, alerting development and security teams of the urgent update required.
Real-time notifications of critical vulnerabilities.
Actionable, prioritized remediation steps directly within development workflows.
In Ivanti’s case, BOSS would have immediately alerted to the risky dependency version, detailing the vulnerability and auto-generating a recommended fix within the CI/CD process.
Proactive Prevention: CI/CD Integration Workflow with Meterian-X
Integrating Meterian-X into CI/CD pipelines ensures software vulnerabilities are detected and addressed at the earliest stage, automatically:
Ivanti’s vulnerability illustrates a fundamental truth: security must extend beyond internal code to encompass all open-source dependencies. Meterian empowers security leaders, developers, and compliance teams to proactively detect and auto-remediate risks like those affecting Ivanti.
Adopting Meterian’s comprehensive security integration ensures continuous monitoring. It provides a rapid response and reliable protection of your software supply chain. This safeguards your business from the increasing threat of supply-chain-based cyber attacks.
Essential Steps for Leaders Before the Next Supply Chain Attack
Author: Rod Cobain • 4 min read
A Storm Is Brewing
We live in an age of unprecedented digital dependency. From agile startups to global enterprises, modern organizations rely on interconnected software systems, primarily driven by open source software (OSS). While OSS is powerful, flexible, and cost-effective, it increasingly represents a critical cybersecurity risk.
Cyber attackers are aggressively exploiting open source vulnerabilities, targeting the tools and libraries that power global innovation. The question isn’t whether your organization uses open source software—it undoubtedly does. The critical question is: How effectively are you securing it?
This article will explore:
Why open source vulnerabilities attract cyber attacks.
The evolving nature of these threats.
The crucial role of cybersecurity thought leadership.
Strategic actions leaders must take immediately.
Open Source Software: The Expanding Attack Surface
The Prevalence of Open Source
80-90% of modern applications incorporate OSS components.
OSS underpins critical infrastructure including finance, AI, and cloud services.
OSS adoption is accelerating within IoT and edge computing environments.
Why Attackers Target Open Source
A single vulnerability can impact thousands or millions of systems.
Attackers view the software supply chain as an attractive, often poorly defended target.
Many organizations lack visibility into OSS dependencies.
Recent High-Profile Incidents
Log4Shell (Log4j): A critical vulnerability in a widely used Java library triggered global disruption.
Allocate resources to enhance OSS security measures.
Support cross-industry initiatives and SBOM adoption.
Promote a culture where software security is central to business strategy.
The Broader Impact: Securing a Global Commons
Open source software represents a global digital commons. Poor security practices risk widespread systemic failure, not just isolated breaches. Robust thought leadership from security and business executives can act as a force multiplier by:
Without proactive leadership, organizations face continuous cycles of reactive firefighting. With it, we can build resilience and trust in the digital future.
Conclusion: Your Leadership Legacy
The stakes have never been higher:
Attackers are innovating rapidly.
OSS vulnerabilities will continue to surface and be exploited.
Regulatory landscapes and liability expectations are evolving quickly.
Now is the time for bold cybersecurity leadership that transcends organizational silos, engages across industries, and shapes global security practices. As a leader, ask yourself:
Is your organization prepared for the next OSS attack?
Are you shaping the conversation or merely reacting?
What legacy will you leave in securing the software that powers the world?
The future of digital trust depends on your answers.
Today’s Reality Check: Vulnerability Management is Non-Negotiable
With the MITRE CVE system being the backbone of global vulnerability identification, it’s alarming to see discussions about funding cuts that could jeopardize this critical resource. If the industry loses its shared language for describing digital flaws, we’re all in trouble. This could stifle innovation in vulnerability management and mitigation, leaving organizations scrambling for reliable data in the U.S. and globally.
The industry needs to rally. We must collaborate on alternative funding models, invest in open-source initiatives, and forge partnerships that keep vital resources like CVE alive and thriving. Let’s ensure that our defenses remain robust, even in the face of disruption.
Meterian: The Power Database and Invisible Security Platform You Need
While others may falter, Meterian is charging ahead. Our vulnerability database is not just comprehensive; it’s a powerhouse, tracking over 400,000+ vulnerabilities and receiving daily automatic updates from a multitude of sources. We pull data from the National Vulnerability Database, GitHub Security Advisories, and 15 other unique feeds. But we don’t stop there. Our AI-generated insights, combined with meticulous manual curation, deliver a done-for-you service that your security and engineering teams can depend on.
In short, we provide your enterprise with a pair of automated eagle eyes, ensuring you have full visibility into potential software weaknesses in your third-party software supply chain.
Quality and Volume
Our commitment to excellence means you get the best tools to manage vulnerabilities effectively, for your team’s tech stack and workflow. We have a multitude of integrations and our OpenAPI architecture means we can collaborate to create more value together.
Join the Revolution
It’s time to elevate your cybersecurity strategy with the best solution for your team. Ready to take your cybersecurity to the next level? Check out our product page infographic to see how our database stacks up against the competition.
Attacks through open source are growing year on year, so companies cannot rely only on periodic pen testing. The code needs to be scanned on a daily basis during the lifecycle of the application’s development stages, and continue to do so once an application is deployed.
Modern software development in fact heavily relies on open-source components: they accelerate development, reduce costs, and provide access to well-tested, community-maintained code. Understanding the composition of their software products is crucial for companies producing applications, as it helps manage and secure the significant portion of their codebase that originates from open-source projects.
Checking open-source components in software development is crucial for at least three reasons: let’s have a closer look and clarify the problems.
Security Risks
The code of open-source components is always publicly available and it is a natural target for hackers. Each day, more than 50 new vulnerabilities are discovered in open-source components and, if not identified and managed, they can be exploited, leading to security breaches.
the iCloud and Minecraft hack (2021): Log4j vulnerability (CVE-2021-44228)
All these hacks were performed using a vulnerability in an open-source component: nothing was wrong with the code written by the respective developers.
How common are vulnerabilities? See, in this sample, the growth of vulnerabilities in the .NET open-source ecosystem:
Please note that this is a restricted view that matches exclusively only vulnerabilities affecting opensource components specific to the .NET ecosystem. Across all ecosystems, more than 100,000 vulnerabilities affecting open-source components are recorded.
The risks are real. If you want to learn more you can also read our blog here.
License compliance
Open-source components come with various licenses, each with specific requirements and restrictions. Failing to comply with these licenses can lead to legal issues, including copyright infringement claims.
Among all those, let’s not forget TruthSocial, the famous Twitter clone created by the Trump Media & Technology Group, was found to be in breach of an OSS license and had to disclose its source code publicly.
The risks are real. If you want to learn more you can also read our blog here.
Quality and reliability
While open-source software can be of high quality, this varies significantly, and some components might be abandoned or poorly maintained. Using such components can pose risks to the project’s stability and reliability.
Here introducing you Swashbuckle, a popular .NET project that has been abandoned by his creator for a more interesting adventures and now lays unmaintained and without an owner. It was last updated 6 (six) years ago.
Let’s also have a look at Lazy, another popular NodeJS component that was last updated 11 (eleven) years ago. While it’s a small library with a limited attach surface, why would you like to have this in your application? Software does not age like fine wine, unfortunately.
This is an example of two commonly used opensource components that have not been updated in years, a very long time in software development. Those components are basically not maintained anymore: if a problem is found, it won’t be fixed. If a vulnerability is there, nobody will know about it (apart from the occasional hacker, of course)
How Meterian SCA helps solve the challenge
Meterian offers a comprehensive application security platform designed to enhance the security posture, compliance adherence, and overall quality of software projects. This platform provides in-depth analysis and automation capabilities, empowering organisations to effectively manage open-source and third-party libraries throughout their software development lifecycle. Through its robust features, Meterian enables organisations to identify and mitigate vulnerabilities, ensure compliance with relevant regulations and standards, and maintain a high level of software quality.
Meterian is unique compared to its competitors because of various characteristics, let’s explore them
Supports the largest number of ecosystems If you are using a legacy technology like Perl, focus on data science using Jupyter Notebooks, build video games with Unity, or build ultra-fast micro-services with Rust, you deserve the best protection available. Meterian supports a wide range of languages and ecosystems, and if your platform is not there, we will be happy to support it for you.
Easy to to deploy on premises or dedicated cloud In the SaaS industry, the requirement for a dedicated single-tenant instance or an on-premises installation may be driven by specific business needs, such as tight security, data sovereignty, and geo-location considerations. Meterian can easily provide a single-tenant environment, either on-cloud or on-prem, and offers also a range of air-gapped solutions for extreme secure environments.
Comprehensive vulnerability database Meterian’s vulnerability database not only boasts a broader coverage than any of its competitors but is also updated daily through a fully automated system that integrates numerous OSINT sources and Meterian’s specially curated databases, including AI-generated advisories directly from the analysis of open-source repositories. This automated process outpaces manual entry methods, ensuring we maintain a competitive edge through faster and more efficient updates, a key differentiation in our service offering.
Superior customer support Speed, quality of responses, customer obsession, won deals because of this. We have a unique culture where the concept of “support” does not really exist, as all engineers are constantly working with customers. We want to be obsessed with customers, solve their problems quickly and effectively. Every customer support query is directly handled by engineers and is given priority in our backlog. This approach guarantees that our product evolves in response to real-world feedback, while also maintaining the highest level of customer satisfaction.
What next?
Don’t just take our word for it – experience the benefits for yourself. We invite you to schedule a demo to see how our solution can make a difference in your organisation’s security posture. Our team of experts is ready to guide you through the features and show you how it can address your specific security challenges. Take the first step towards a more secure future – reach out today and discover how Meterian can elevate your cybersecurity strategy.
Meterian is proud to announce that it now supports Swift Package Manager (SwiftPM), providing improved security for Swift developers. This new feature allows Swift developers to seamlessly integrate Meterian’s powerful security scanning capabilities into their Swift projects, helping them identify and fix vulnerabilities in their open source dependencies.
SwiftPM is the official package manager for Swift, the popular programming language developed by Apple for building iOS, macOS, watchOS, and tvOS applications. It simplifies the process of managing dependencies in Swift projects and enables developers to easily share their code as packages. With Meterian’s support for SwiftPM, developers can now add an additional layer of security to their Swift projects by automatically scanning their dependencies for known security vulnerabilities.
I am using Cocoapods: why is this important?
While Cocoapods has been the de facto dependency manager for iOS and macOS projects for several years, SwiftPM has emerged as a powerful alternative, offering several advantages over its predecessor.
Firstly, SwiftPM is an official tool provided by Apple, which means that it is well-integrated with the Xcode development environment and has the backing of the Swift community. This ensures that SwiftPM is continuously updated with the latest features and security enhancements, making it a reliable and secure option for managing dependencies in Swift projects.
Secondly, SwiftPM is designed to be lightweight and fast, with a simple command-line interface that is easy to use and understand. This makes it an ideal tool for small to medium-sized projects, where simplicity and ease of use are essential. Cocoapods, on the other hand, can be slow and cumbersome, particularly for large projects with numerous dependencies, where the overhead of managing the Podfile can become overwhelming.
Thirdly, SwiftPM has a modular architecture that allows developers to easily share code between different projects and platforms, making it a more flexible and versatile tool than Cocoapods. This makes it particularly useful for developers working on cross-platform projects, where code sharing is critical.
Finally, SwiftPM is a more modern and future-proof solution than Cocoapods, which relies on Ruby. SwiftPM is written in Swift and does not require any extra tooling, making it a natural choice for iOS and macOS developers
Overall, while Cocoapods has been a valuable tool for many iOS and macOS developers over the years, SwiftPM has emerged as a more modern, lightweight, and flexible alternative, offering several advantages over its predecessor. With Meterian’s support for SwiftPM, developers now have access to a powerful security scanning solution that is well-integrated with the Swift ecosystem and provides critical security enhancements for their Swift projects.
I am switching to SwiftPM. How does Meterian help me?
Meterian’s SCA solution uses advanced scanning techniques to analyze the source code of open source dependencies and identifies any known security vulnerabilities or licensing issues. The results are presented in a comprehensive dashboard, allowing developers to easily understand the security status of their dependencies and take appropriate actions to address any identified issues.
One of the key benefits of using Meterian with SwiftPM is the seamless integration into the Swift development workflow. Developers can simply add Meterian as a build step in their SwiftPM build process, making it easy to incorporate security scanning into their existing development pipeline. This ensures that security is considered as an integral part of the development process, reducing the risk of shipping software with vulnerable dependencies.
Another powerful feature of Meterian is its ability to provide remediation guidance. When vulnerabilities are identified, Meterian provides detailed information on how to fix the issue, including code snippets, links to relevant documentation, and recommendations for alternative libraries or versions. This helps Swift developers quickly address security issues and keep their dependencies up to date.
Meterian’s support for SwiftPM comes at a critical time when security is a top concern for software development teams. As cyber threats continue to evolve and open source vulnerabilities become more prevalent, it is crucial for Swift developers to proactively manage the security of their dependencies. By leveraging Meterian’s advanced scanning capabilities, Swift developers can ensure that their software is built on a solid foundation of secure dependencies, minimizing the risk of security breaches and protecting their users’ data.
Meterian’s support for SwiftPM brings enhanced security to Swift developers, allowing them to easily scan their open source dependencies for known vulnerabilities and proactively manage their software’s security. With its seamless integration into the SwiftPM workflow and comprehensive remediation guidance, Meterian empowers Swift developers to build secure software and protect their users’ data. To learn more about Meterian’s support for SwiftPM and how it can help improve the security of your Swift projects, visit Meterian’s website at www.meterian.io.
Managing the technology stack and known vulnerabilities is becoming a key criteria for cyber insurance pay outs
Open source software has once again made the headlines following warnings to organisations about the release of a new version of OpenSSL. Released on 1st November 2022, the new version patched vulnerabilities in version 3.0 and above of the nearly ubiquitously used cryptographic library for encrypting communications on the Internet.
The OpenSSL Project team took the unusual step of pre-warning organisations five days ahead of the 1st November release date that a critical update was being issued to address the vulnerabilities. This came as a surprise to many as the OpenSSL library rarely has critical vulnerabilities, but due to its popularity and widespread use, organisations were advised to be cautious and to prepare.
Based on the assessment by the OpenSSL team, the vulnerabilities can be exploited and trigger data leakage or remote code execution. It is hard to predict the potential damage and risk of these vulnerabilities, which is why it’s vital for organisations to act swiftly, determine any use of the affected OpenSSL and patch immediately if they are exposed to the vulnerabilities. However, as these vulnerabilities were classified as “high severity” and not critical as initially thought, widespread exploitation is not expected.
Open Source the foundation of modern software
The benefits of open source software are numerous and well known, so let’s be clear open source is not the problem – our ability to learn from the past is.
There have been a couple of big open source incidents in the last year that have sent shock waves through the cyber security world. Firstly, the vulnerability in the widely deployed Log4J component, and now this new vulnerability in OpenSSL. This is only the second such flaw ever found in the open source encryption project. The first was Heartbleed.
The December 2021 zero-day vulnerability in the Java logger Log4J, known as Log4Shell, was characterised by many security experts as the single biggest, most critical vulnerability of the last decade. If left unpatched, attackers can hack into systems, steal passwords and logins, extract data, and infect networks with malicious software causing untold damage, not least to brand reputations.
Unfortunately, a situation that specialty insurer Crum & Forster, owned by Fairfax, know all too well after falling victim to the hacking group known as RansomHouse. Despite widespread news coverage of the Log4shell vulnerability, which was revealed in December 2021, it appears the insurer was still vulnerable.
The breach at Crum & Forster was first discovered on 22nd July 2022. The hacking group were able to exploit an unpatched system, resulting in a total of 1.7 gigabytes of sensitive data being released, including medical information, insurance policies, employee data, and customer lists.
Crum & Forster are by no means an isolated case, there are many examples over the years of companies falling victim to known vulnerabilities.
History repeating itself
The Heartbleed vulnerability, discovered in 2014, impacted hundreds of thousands of web and email servers worldwide. Among the many systems confirmed to be affected were large organisations such as Yahoo, Eventbrite, and even the FBI’s own website. Many of the big companies confirmed to be affected were able to get their ducks in a row and patch before anything severe happened.
Others weren’t so quick off the mark and hackers were able to exploit the vulnerability in several cases. The Canadian Revenue Agency was one of the many victims that suffered a breach as hackers exploited the Heartbleed vulnerability. The breach resulted in the theft of hundreds of social ID numbers in a six-hour period before the Canadian Revenue Agency realised and removed public access to its online services.
In the aftermath of a breach, companies are quick to express that lessons will be learnt. Unfortunately, in a case of history repeating itself, the Canadian Revenue Agency was once again hitting the headlines. In 2017, just 3 years after Heartbleed, the company had to shut down its website for filing federal taxes due to falling victim to the open source Apache Struts2 vulnerability.
Fail to patch, plan to fail
Several years on from when Heartbleed was discovered and a patch issued, there are still servers harbouring the Heartbleed vulnerability. In November 2020, a security researcher at the SANS Internet Storms Centre discovered that over 200,00 machines are still vulnerable to Heartbleed. The news cycle may have moved on but that doesn’t mean unpatched vulnerabilities have disappeared.
Too many headlines are showing that hacks have one thing in common, they are caused by a known vulnerability within an open source component.
A well know example is the Equifax data breach in 2017, which remains one of the largest cybercrimes related to identity theft. The private records of 147.9 million Americans along with 15.2 million British citizens and approximately 19,000 Canadian citizens were compromised in the breach.
A key security patch for open source software Apache Struts was released by the Apache Software Foundation on 7 March 2017 after a security exploit was found. All users of the framework were urged to patch immediately.
For one reason or another, the patching process within Equifax completely broke down, resulting in vulnerable systems being left open to compromise. Subsequent scans conducted by the Equifax IT department to identify any vulnerable systems appears to have failed and, as the saying goes, the rest is history.
The cost of downplaying security
Recent estimates suggest the 2017 Equifax data breach cost the company at least $1.38 billion, with some sources suggesting the final bill could be closer to $2 billion. The root cause of the data breach was the failure to patch a known open-source web application security flaw. The company effectively left the door open for cyber criminals to walk in and wreak havoc.
In the aftermath of the breach Equifax was condemned for its lax security posture, shambolic emergency response and poor leadership, which led to many senior executives being accused of corruption. The Equifax breach investigation highlighted several security lapses that allowed attackers to enter, allegedly secure, systems and exfiltrate terabytes of data.
More than five years on, the Equifax data breach remains a cautionary tale in failing to manage cyber security risk effectively and lacking the tools and processes to implement a robust vulnerability and patch management regime.
Cybercrime has become a highly lucrative operation; it is not going away and is only set to worsen as companies continue to engage digital technology. Many have taken out cyber insurance to insulate themselves from the punishing costs of cyber-attacks and data breaches.
However, companies across the world are likely to face increases in the cost of insurance as the number of claims increase year on year. According to research conducted by FitchRatings, US claims volume has risen 100 percent annually over the past three years.
In part as a result, the cost of cyber insurance has risen steeply in 2022 in both the US and the UK. According to Marsh, the UK cyber insurance market experienced a pricing increase of 102% year-over-year in the first quarter of 2022.
As a result of rising claim costs, the insurance industry is tightening their qualifying requirements and limiting their coverage. Cyber insurers now require organisations to provide information about their security controls if they want coverage. This can include technical, procedural, and human controls.
Keeping track of your open source exposure
Software Bill of Materials (SBoMs) are an emerging approach to keeping track of your software dependencies, both open source and commercial. SBOMs provide the ingredients list to understanding what code exists within the applications that your business relies upon.
Only by understanding what exists inside applications can organisations evaluate their exposure to risk. Used effectively, SBOMs enable companies to evaluate and target remediation efforts. But most importantly, companies won’t be blindsided when the next big open source vulnerability is announced.
Known vulnerabilities are your responsibility
Many cyber insurers have tightened their standards and are no longer paying out for breaches that have resulted from a known vulnerability. This should serve as a sharp wakeup call to boardrooms that deploy technology, with little thought to the security implications. If companies want to ensure they continue to receive all the benefits of their policy, it’s vital that they have a rigorous patch management system. Corporates may have short memories when it comes to known vulnerabilities but, as the evidence shows, cyber criminals do not.
Companies must increase visibility and transparency of the components in their open-source software and applications if they are to stay one step ahead of cyber criminals. Without continuous management of your governance, risk, and compliance of open source your company is walking a tight rope, without a safety net. Those that fail to learn from history are doomed to repeat it.
