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.
Since our previous discussion on the EU Cyber Resilience Act (CRA) and Software Bill of Materials (SBOMs), significant updates have clarified and expanded the framework for compliance. The European Parliament approved the CRA on March 12th, marking its importance in enhancing product security across the EU. This follow-up explain these developments, focusing on new guidelines and the evolving expectations for SBOM compliance.
New clarity on SBOMs from Germany: TR-03183
To provide more detailed guidance, Germany’s Federal Office of Information Security (BSI) released the Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Products (Part 2: Software Bill of Materials (SBOM)), version 2.0. This 20-page document sets the groundwork for SBOM requirements under the CRA. Key highlights include:
Mandatory SBOM Compilation: An SBOM is essential for meeting CRA compliance.
Minimum Information Requirements: The SBOM must include the component name, version, dependencies, license (preferably using SPDX or ScanCode identifiers), and a SHA-256 hash.
Version-Specific SBOMs: A separate SBOM must be generated for each software version, with updates made only for error corrections or new information.
Preferred Formats: SBOMs must adhere to CycloneDX (v1.4 or higher) or SPDX (v2.3 or higher).
Process Integration: The SBOM must be generated as part of the build process or an equivalent mechanism.
Other recommendations, such as using CSAF with a VEX profile for distributing vulnerability information, aim to enhance transparency without directly embedding vulnerabilities in the SBOM.
Challenges in SBOM Implementation
While TR-03183 provides critical guidance, several unresolved issues highlight the complexities of SBOM creation and usage:
Identification Gaps: The absence of mandatory CPE or PURL requirements makes vulnerability reporting from SBOMs prone to errors.
Undefined “Scope of Delivery”: The guidelines use this term to define the depth of transitive component enumeration but lack clarity on acceptable thresholds.
SHA-256 Ambiguity: The methodology for computing a SHA-256 hash of source code remains unspecified.
Relationship Details: While all transitive components must be recursively included, relationships among them are not explicitly required. This omission can hinder the effectiveness of SBOMs in vulnerability management.
Preparing for CRA Compliance
The CRA’s adoption signals a critical need for manufacturers and software developers to refine their compliance strategies. With enforcement set for early 2027, organisations should prioritise:
Automating SBOM Generation: Tools like Meterian can streamline SBOM creation, ensuring accurate dependency mapping and compliance with CRA’s format requirements.
Enhancing Vulnerability Management: Despite the lack of mandatory CPE or PURL, integrating these identifiers into internal processes can improve accuracy.
Staying Updated: Monitoring updates to technical guidelines like TR-03183 will be vital as CRA implementation progresses.
Looking ahead
The CRA represents a significant step forward in securing the digital ecosystem. By leveraging clear guidelines and robust tools, organisations can align with compliance requirements while strengthening their cybersecurity posture. The publication of TR-03183 marks progress but also underscores the need for continued refinement as industry feedback shapes the future of SBOM practices.
Navigating the complexities of SBOM creation and CRA compliance doesn’t have to be overwhelming. Meterian provides automated solutions designed to simplify the generation and management of SBOMs, ensuring:
Effortless Compliance: Meterian supports both CycloneDX format, helping you meet the CRA’s technical requirements with ease.
Comprehensive Dependency Mapping: Automatically scans your codebase to identify all components and transitive dependencies, ensuring nothing is missed.
Ongoing Vulnerability Monitoring: Integrates seamlessly with vulnerability databases to keep your SBOMs updated and your products secure.
Time-Saving Automation: Embeds SBOM generation into your build processes, reducing manual effort and increasing efficiency.
With Meterian, you can confidently meet CRA requirements while enhancing your overall security posture. Contact us to learn how we can support your journey toward compliance and beyond.
As healthcare companies face a complex web of EU and US regulations, understanding and adhering to these standards is crucial for maintaining trust and operational continuity. Regulations such as the EU’s Medical Device Regulation (MDR), the Network Information Security (NIS) directive, and upcoming legislation like the Cyber Resilience Act (CRA) and Digital Operational Resilience Act (DORA) demand meticulous compliance and robust cybersecurity measures.
Specifically, MDR requires stringent oversight of software used within medical devices, demanding thorough documentation and regular updates to ensure safety and performance. Meterian simplifies these tasks by automating the detection of vulnerabilities and outdated components in software, facilitating compliance through comprehensive Software Bill of Materials (SBOMs). These SBOMs provide a detailed inventory of all software components, crucial for MDR compliance, and help healthcare organisations maintain the integrity and security of their medical devices. By streamlining these processes, Meterian not only aids in meeting regulatory requirements but also enhances operational efficiency and reduces the risk of non-compliance penalties.
Meterian stands as a pivotal ally for healthcare companies navigating these regulatory landscapes. By offering tools that facilitate compliance with these stringent regulations, Meterian ensures that healthcare providers can focus more on patient care and less on the nuances of cybersecurity compliance.
The conversation around SBOMs and compliance is growing, and Meterian is leading these discussions with healthcare companies, showcasing how automation and detailed compliance reporting can ease the burden on healthcare providers. Whether it’s a startup or a seasoned enterprise, Meterian’s scalable solutions fit diverse budgets and operational scales, making comprehensive cybersecurity accessible to all healthcare entities.
By partnering with Meterian, healthcare companies not only ensure compliance with current regulations but also prepare for future legislative changes. Meterian’s proactive approach helps companies anticipate and adapt to the regulatory landscape, ensuring that they are always one step ahead in their cybersecurity measures.
Are you ready to elevate your healthcare organisation’s compliance and cybersecurity strategy?
Partner with Meterian today to ensure that your technology infrastructure meets the stringent demands of regulations like the NIS Directive and MDR. Don’t wait until a cybersecurity incident occurs – take proactive steps to safeguard your patient data and systems.
Visit our website or contact us to learn how Meterian can help your healthcare organisation stay secure, compliant, and resilient in an ever-evolving digital landscape.
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.
Red alert! All enterprise software maintainers of software using Java libraries need to check if their systems are affected by the newly discovered vulnerabilities “Spring4Shell” since its announcement, between 29th and 30th March, 2022, affecting various Spring components.
Vulnerability Score: 9.5 (CVSS:3.0 / AV: N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H) Platform: Java Components: org.springframework:spring-beans Affected versions: all versions before 5.2.20, all versions before 5.3.18 Fixed in version: 5.2.20, 5.3.18
Please note that this affects also the spring-framework package and the spring-boot package, that both use the offending libraries. New versions of such packages have been made available. You can upgrade spring-framework to version 5.2.20 or 5.3.18, and you can upgradespring-boot to version 2.5.12 or 2.6.6 (note that spring-boot itself includes spring-framework, no other upgrades necessary).
Which systems does these affect?
CVE-2022-22963 affects any project built using a vulnerable version of Spring Cloud, a framework that provides tools for developers to quickly build some of the common patterns in distributed systems. The “functions” part is a subsystem used to implement serverless functions like AWS lambda or Google Cloud Functions: if you are using such subsystem you are potentially affected.
CVE-2022-22965 affects any project built using a vulnerable version of Spring Framework, Spring Boot or the library spring-beans. A successful attack, however, can only be conducted undere these conditions:
JDK 9 or higher is used as the runtime environment
Apache Tomcat is used as the Servlet container
The application is packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
There is a dependency with spring-webmvc or spring-webflux, or an endpoint is used with DataBinder enabled
Please note however that analysis are undergoing and the nature of the vulnerability is quite general: we suggest you keep monitoring this page for further updates.
Why do these threats demand an urgent patch?
Both vulnerabilities allows the attacker to remotely execute code on your system, with the ability to gain complete control of the underlying servers. It’s a simple exploit, as it requires only to send a crafted HTTP header in a request in order to execute code on the remote host. These vulnerabilities are actively exploited in the wild.
How can I check if my system is affected?
If you maintain any software using Java libraries, check if you are using any Spring Cloud Function library. The Meterian BOSS scanner can be used to scan your codebase to identify all dependent software libraries. If it is using the offending package, it will find the affected vulnerable versions and provide more information on how to mitigate this risk.
If you are a developer and you have access to the code, you can simply execute this command from your terminal:
If you see any response lines, check the version: if it’s below 5.3.18 (as in the above example) or, if using 5.2.x, below 5.2.20, you may be affected.
My system has the vulnerable spring cloud function library — how can I mitigate the risk?
There are now patched versions of the affected components that resolve the issues, they are available via the standard Maven repositories. Upgrade the offending packages using the patched versions, as described in this article.
If the library is coming from a transitive dependency (it’s not one of your direct dependencies, but a dependency of them) you can just include an override in your root pom.xml (or where applicable) and retest that it’s not there anymore with the command shown before.
Please be aware that there are multiple packages rooted in "spring-cloud-function": you will need to upgrade all of them, in particular "spring-cloud-function-context" which is also directly affected.
Please be aware that you may need / may be better to upgrade the parent pom of the project using an unaffected version of spring boot / spring framework (see at the start of the article).
What can I do to proactively protect from such vulnerabilities?
We always suggest you regularly scan your software code bases.
To include this as part of your continuous improvement efforts to build resilience into your software development lifecycle, see our documentation on the various integrations we support with GitHub Actions, Azure DevOps Pipelines, and others.
Are Meterian applications affected by the spring vulnerability?
We have verified our applications and none are using the offending packages in a vulnerable configuration. We maintain a continuous monitoring system to ensure our development operations are up to date with the latest known vulnerabilities in software components. Given the nature of this vulnerability we will be running a specific monitoring for the following days, while more details are unfolded in regards to those vulnerabilities.
Recent high profile cyber security incidents have reinforced the importance of cleaning up the open-source software supply chain. From Heartbleed to the Apache Software Foundation’s Log4j vulnerability, these highly publicised incidents have exposed the threats associated with the software supply chain.
Open source security vulnerabilities are nothing new. Heartbleed was a security bug in the OpenSSL cryptography library that affected many systems. Similarly, Log4Shell is a severe vulnerability, however in the case of Log4j the number of affected systems could well run into potentially billions. Many cybersecurity experts have characterised Log4Shell as the single biggest, most critical vulnerability of the last decade.
These incidents have brought into sharp focus the risks and galvanised a range of responses at national and international level. It even prompted the White House to convene an Open Source Software Security Summit in January that was attended by leaders from global technology companies including Google, Meta, Apple, and Cisco. Members of the open source community were also represented at the summit, as well as US government agencies, including the Cybersecurity and Infrastructure Security Agency, the National Security Council and the National Institute of Standards and Technology.
The gathering may have been precipitated by the Log4Shell vulnerability, but the wider context was clear. How do we ensure source code, build, and distribution integrity to achieve effective open source security management?
Open source under the microscope
Technology companies have been using open source for years as it speeds up innovation and time to market. Indeed, most major software developments include open source software – including software used by the national security community.
Open source software brings unique value, but it also has unique security challenges. It is used extensively, however, the responsibility of ongoing security maintenance is carried out by a community of dedicated volunteers. These security incidents have demonstrated that the use of open source is so ubiquitous that no company can blindly continue in the mode of business as usual. Recent research showed that 73% of applications scanned have at least one vulnerability[1]. These can be buried deep in the open source software supply chain that software-driven businesses rely on for basic functionality and security to accelerate their time to market.
The known unknown
The concept of known knowns, known unknowns and unknown unknowns has been widely used as a risk assessment methodology. When it comes to cybersecurity and the voracity of threat actors to exploit vulnerabilities, it is a useful analogy.
Let’s take Apache Log4J as an example. Companies often create products by assembling open source and commercial software components. Almost all software will have some form of ability to journal activity and Log4j is a very common component used for this.
How do you quickly patch what you don’t know you have?
Java logger Log4j 2 – A zero-day vulnerability
Log4J was originally released in 2001, and over the last 20 years it has been used in billions of software developments and applications across the world. For logging incidents within software, Log4j is used by everything from the humble 404 error message, gaming software such as Minecraft, and Cloud providers such as iCloud and Amazon Web Services, as well as for all manner of software and security tools.2 On 9 December 2021, the zero-day vulnerability in the Java logger Log4j 2, known as Log4Shell, sent shockwaves across organisations as security teams scrambled to patch the flaw. If left unfixed, attackers can break into systems, steal passwords and logins, extract data, and infect networks with malicious software causing untold damage, not least to brand reputations.
However, herein lies the problem. How do you quickly patch what you don’t know you have?
Often in the race to innovate, the first thing sacrificed is up-to-date documentation. Without it how does a company know if Log4J is integrated within its application estate, let alone know if it has been previously patched.
Improving safety and trust when speed is of the essence
If we are to increase safety and trust in software, we must improve transparency and visibility across the entire software supply chain. Companies should have the ability to automatically identify open source components in order to monitor and manage security risk from publicly disclosed vulnerabilities. A software bill of materials (SBOM) should be a minimum for any project or development. Without such visibility of all component parts, security teams cannot manage risk and will be unaware, and potentially exposed, to dangers lurking in their software.
Case study – Full Visibility within an Hour
To give an example; one of the largest UK based financial services company with millions of customers across the world discovered it had Log4J embedded within dozens of in-house developed software projects. Having seen the first reports of the vulnerability at the start of the business day, within an hour the security team had identified projects using Log4j and were able to start work on follow up activities. By the end of the day, the entire business had a concise list of projects at risk, some of which were already remediated.
How was this achieved?
The company had automated tooling integrated into their software development environment with comprehensive component security. This enabled them to quickly identify those software projects which depended on the affected log4j component.
This visibility allowed the company to devise remediation plans to mitigate the risks of the vulnerability in Log4J. The company was able to target valuable resources across multiple locations to ensure fixes were applied quickly to critical business applications within just a couple of hours. While they were implementing an action plan based on the organisation’s use of Log4j, some of its competitors without such comprehensive tools were still in the information gathering stage.
Innovating securely
As organisations continue to innovate at pace in order to reduce time to market, the reliance on open source software continues to increase. However, when the security of a widely-used open source component or application is compromised, every company, every country, and every community is impacted.
The White House has taken an important first step in trying to identify the challenges present in the open source software supply chain and encourage the sharing of ideas on ways to mitigate risk and enhance resilience. Organisations can and should take advantage of the many benefits that open source software can deliver, but they must not do it blindly. Ensuring you know the exact make-up of your technology stack including all the component parts is an important first step. Choosing discovery tools that have the widest comprehensive coverage is important, and so too is the flexibility to grade alerts so that only the most pressing threats are highlighted. This avoids ‘alert fatigue’ and enables security teams to focus resource where it matters most, putting organisations in a good position to act fast when vulnerabilities are discovered.
Hackers faced with stronger security defences will continue to turn their attention to the weaker underbelly of the software supply chain. Now is the time for organisations to implement integrated and automated tooling to gain comprehensive risk control of components in their open-source software supply chain. Only by increasing visibility, coverage of known unknowns and transparency can companies stay one step ahead.
1 Meterian research from aggregated and anonymised data of 2044 scanned software applications in 2020.
We are sure many of you have been hearing about SBOMs. Nowadays, software include some components with code written by your own developers, but 80-90% of the code is typically from third-party developers. How can you know who produced what and when it absolutely needs to be replaced? Since Meterian has been managing SBOMs for awhile, we’re happy to share our know-how so you can consider a comprehensive strategy to manage your open source software supply chain.
SBOM is an acronym that means Software Bill Of Materials. The concept originates from the manufacturing industry, where a bill of materials lists dependent components in machinery. A SBOM lists all third-party components present in your application. A good SBOM also lists the licences used by each component and, when possible, the specific copyright attribution. An excellent SBOM can also provide further information, such as possible relationships between those components to better understand any supply chain risk. You may have encountered SBOMs in the past, known as “third party notice” documents created to manage legal requirements, such as the one in the image below.
However, modern SBOMs are “machine-readable”. They follow a strict specification that can be understood by a computer.
What machine-readable formats are used to publish SBOMs?
The most commonly used formats to define a SBOM are:
CycloneDX, a lightweight open-source standard designed for use in application security context and supply chain component analysis. This originated from within the OWASP community.
SPDX, an open source format with origins in the Linux Foundation, slightly more complex, and recently approved as ISO/IEC standard in version 2.2.1 as ISO IEC 5962:2021.
SWID, another ISO/IEC industry standard used by various commercial software publishers.
All these formats support a variety of use cases, but the first two (CycloneDX and SPDX) are the most versatile. Due to SPDX’s complexity, we think CycloneDX has an edge at this time, but only time can tell which of these formats will be the winner. To learn more about these formats you can also read the official NTIA publication, which drills down into the matter.
Why are SBOMs important? And how are they useful?
As a consumer of software, the main reason why you want to have access to the SBOMs of the systems you are using is to manage risks. When a very commonly used software component becomes vulnerable: how do you know what you need to patch and which subsystems are at risk? This is exactly what happened with the recent Log4Shell debacle. The logging library called Log4j, was suddenly exploitable with a very simple and repeatable attack. How do you know where it is? Which one of the systems you are using is suddenly at risk? With a correctly managed archive of SBOMs, getting this information reduces to a very simple lookup task. Without it, it can be a real nuisance —a time consuming information hunt that disrupts everyone’s work flow.
As a producer of software, instead, you want to preserve and maintain an archive of all the SBOMs of the system you produce so that you can create and distribute timely patches to your customers. Having a systematic and comprehensive analysis of your most commonly used software packages would be useful indeed. Some companies were very fast in releasing patches to their customers, while others were extremely slow, mostly because they did not have the information. You probably want to be in the first group of companies 🙂
Governments are also mandating the need for use of SBOMs, realising that software security needs to be regulated. The U.S. Executive Order 14028 that mandates all federal agencies to require SBOMs from their suppliers. This not only impacts the companies that have direct sales to the US government but also their own software suppliers. As so many systems and devices have been connecting to the Internet to send and receive information, consequently our digital world relies on a software supply chain. This “ripple effect” will be significant for many industries.
Very carefully :), because an SBOM contains the full list of the “ingredients” of your system or application. While open-source projects happily share this information to the world, the same does not apply to private companies. In fact, a malicious actor that gets hold of the SBOM of your system can then check if you are using any vulnerable components. There are public vulnerability databases, such as the NVD, which are very popular. Someone can simply browse in there and compose a list of possible attacks, try them, and maybe get lucky. Probably 9 out of 10 vulnerabilities affecting components in your system won’t be exploitable, but having the ability to go through the whole list, certainly makes the task of finding an exploit much easier.
There’s no need to keep SBOMs a complete secret, however, as long as a few simple principles are kept in check:
SBOMs need to be shared securely,
they need to be accessed only by the authorised parties, across organisational boundaries, and
they should not be tampered with.
In summary, it is essential to produce a precise SBOM, and it is just as vital to share it and maintain it securely with the correct (trusted) third parties.
Why bother with SBOMs now?
In summary, it is essential to produce a precise SBOM, and it is just as vital to share it and maintain it securely with the correct (trusted) third parties. In our hyper connected world, comprehensive coverage of components is important for preventative strategies and threat detection in supply chain attacks. Therefore, implementing SBOM management proactively now will be worth something to your organisation when the next critical vulnerability appears and stand your organisation in good stead. All good collections are worth organising. How valuable is your collection of software?
The need for SBOMs is already high. Level up your open source software security and implement this requirement. Check out the SBOM capabilities in Meterian-X platform’s approach to DevSecOps.
The topic of sustainability is unmissable at the moment. As the urgency of the situation grows, it continues to demand attention from various sectors and industries within society. You may wonder where the cyber security industry fits into all of this. Whilst traditionally from very different worlds, they are united through the characteristics of constant innovation and the capacity to bring about real change for the better. Certainly, cyber security has a bigger role to play in the overarching battle for a more sustainable world than one may initially think.
The Industry
As around two thirds of greenhouse gas emissions world wide are associated with burning fossil fuels1, renewable energy is a good place to start. The UK currently has the largest number of offshore wind resources in the world, equating to about 10GW in operation outside of the border2. Infrastructure such as this pushes us one step closer to meeting the UK’s target of reaching net zero emissions by 20502. It’s not just the UK that has set the ball rolling in the fight against greenhouse emissions, our friends across the pond are aiming for no electricity sector carbon emissions by 2035— as outlined by Biden3. So, whilst this growing industry means great things for our hopes of preserving the world we live in, mass investment means it is also shaping up to be a very lucrative market for cyber criminals to direct their efforts towards. Jim Guinn, global managing director for cyber security in energy, chemicals, utilities and mining at Accenture states, “The cybersecurity conversation in the renewable energy engineering and construction business is almost nonexistent today.”3 It is imperative that an industry gaining traction as quickly as this one protects itself with the necessary defense measures against cyber attacks.
How exactly are renewable energy plants made vulnerable to cyber hackers?
As mentioned before, sustainability shares close ties with new innovation. Renewables depend on control systems and distribution networks supported by technology. As many sources of renewable energy, such as wind and solar power are not readily available 24/7 like fossil fuels are— they require storage previsions that are also underpinned by technology4. IoT plays a huge role in the remote monitoring, control and regulation of off-shore wind turbines5. As we know, more than 75% of the code in use that makes these technologies a reality is open source, putting open source components smack bang in the middle of the sustainability conversation. However, older wind farms and their communication systems were never designed with the “security by design” mindset like the IEC 62443 standard6, similar to the GDPR principle7. As stated by Jim Guinn “renewables have lax cybersecurity standards, as they are an industry that may be more focused on building first and leaving cybersecurity as an afterthought”3.
Past attacks
A first example in which renewable energy facilities became victims of cyber attacks was the 2014 DragonFly hack8. The cyber criminal group used Remote Access Trojans (RAT) named Backdoor.Oldrea and Trojan.Karagany to infiltrate energy grid operators, major electricity generation firms, petroleum pipeline operators, and Energy industry industrial control system (ICS) equipment manufacturers located in the United States, Spain, France, Italy, Germany, Turkey, and Poland. The hackers had been present in systems since 2011 before detection. Although reports indicate that the overarching aim of the hack was to gather intelligence, later investigation suggested it also had the capacity to take control of physical systems themselves.
A second example in which renewable energy facilities have fallen victim to cyber attack was the SPower hack of 2019. Unfortunately, the group gained the title of being the first U.S. provider of solar and wind renewable energy to have been the victim of a cyber-attack. A hacker used a vulnerability in a Cisco firewall to interrupt the connection between sPower’s wind and solar power generation installations and the company’s main command center9.
More recently, Colonial Pipeline’s hack10– reported on 7th May 2021 fell victim to a cyber attack, highlighting just how seriously energy supplies can be affected by cyber criminal organisations. As a result of ransomware, one of the U.S’ biggest pipelines was forced to shut down operations11. In the subsequently released statement it was revealed that after a 90M bitcoin payout, Colonial Pipeline said that remediation is ongoing and each system is being worked on in an “incremental approach”12. This attack compromised around 45% of the East Coast’s fuel, including gasoline, diesel, home heating oil, jet fuel, and military supplies. Whilst the energy jeopardised in this case was not renewable, Jonathan White, director of NREL’s cybersecurity program office highlighted that “As the penetration of renewable generation and EV charging stations increases in the future, the consequence of a successful attack is likely to be similar in aggregate to those of a successful attack to a natural gas, coal or nuclear plant today”3. Thus, a cyber attack such as the one launched on Colonial Pipeline gives a worrying insight into the potential damage that could be launched on the renewable energy sector.
Risks for the future
After using the Meterian web scanner to evaluate the security of some major UK energy suppliers, we were able to see that similar issues are being faced. For example, the UK’s biggest supplier of energy, British Gas received a security score of 0 out of a best possible 100. Our report indicates that they currently have components in use that pose a threat to their system, as well as components in use with undeclared licenses.
Again, after scanning https://firstlightfusion.com/, one of the UK’s leading renewable energy suppliers, we found 2 high threat level vulnerabilities and 3 medium threat level vulnerabilities, as well as components in use with undeclared licenses.
As this sector grows in both relevance and monetary value, there is a need for adequate cyber security that is growing in unison. According to industry growth trajectories, the renewable energy sector is set to become a big target of cyber hackers. As shown in this blog, experts have not been afraid to warn that more needs to be done to reinforce the security of renewable plants. The need is made even more important to protect consumers’ faith in new energy sources that play an important role in our fight against climate change.
There is some evidence that the tide is changing to benefit the cybersecurity of the energy sector, both traditional and renewable. On 12th May 2021 Biden issued The Executive Order on Improving the Nation’s Cybersecurity13. A few main points from the bill are:
New and more stringent cyber security standards for government purchased software including multi-factor authentication and endpoint detection and response of software.
Suppliers of technology must provide a SBOM (Software Bill Of Materials) that highlights the source of the software (supplier ID) that can be used to perform a risk assessment. This supplier ID can be used to alert high risk software if it is not verified by the digital signature applied to a SBOM14.
There is to be the enforced sharing of intel surrounding cyber attacks, in the hope that the sharing of information will benefit us all. Jennifer Bisceglie, President and CEO of enterprise resilience company Interos Inc., stated that “we live in a world that people are, and companies are very concerned about their brand and reputation”15 and thus are reluctant to admit to cyber breaches. The new bill is set to remove fear of blame and shame and promote collaborative learning and continuous improvement for a safer and stronger society in the digital world.
An automatic, continuous line of defence protecting the open source components in use in renewable energy control systems is one way that Meterian can support the ongoing battle against carbon emissions. Whilst incremental in their support of rapid innovation, open source components are a pressure point to security systems of which cyber attackers are not afraid to make use of.
Visit our homepage to learn more about how Meterian can secure your businesses’ open source components—keeping cyber hackers out and your intellectual property in.
1 “Energy and climate change”. European Environment Agency, 11 May 2021, https ://www.eea.europa.eu/signals/signals-2017/articles/energy-and-climate-change
2GOV.UK, 6 October 2020, https ://www.gov.uk/government/news/new-plans-to-make-uk-world-leader-in-green-energy
3 Vasquez, Christian. “CYBERSECUIRTY: Biden is eyeing renewable energy. So are hackers”. E&E News, 22 December 2020, https ://www.eenews.net/stories/1063721291
4 Ruhle, Micheal and Trakimavicius, Lukas. “Cyberattacks are the new challenge for renewable energy”. Politico, 18 July 2017, https ://www.politico.eu/article/opinion-cyberattacks-are-the-new-challenge-for-renewable-energy/
5 Taylor-Smith, Kerry. “How IoT can improve the performance of offshore windfarms”. NS Energy, 15 May 2020, https ://www.nsenergybusiness.com/features/iot-wind-power/
6 Freudenberg, Wolf K. “Why windfarms need to step up cyber security”. DNV, https ://www.dnv.com/article/why-windfarms-need-to-step-up-cyber-security-128082.
9 Cimpanu, Catalin. “Cyber-attack hits Utah wind and solar energy provider”. ZDNet, 31 October 2019, https ://www.zdnet.com/article/cyber-attack-hits-utah-wind-and-solar-energy-provider/
10 “Colonial Pipeline confirms it paid $4.4m ransom to hacker gang after attack”. The Guardian, 20 May 2021, https ://www.theguardian.com/technology/2021/may/19/colonial-pipeline-cyber-attack-ransom
11 Galiordi, Natalie. “Colonial Pipeline aims to restore operations by end of the week after cyberattack”. ZDNet, 10 May 2021, https ://www.zdnet.com/article/colonial-pipeline-aims-to-restore-operations-by-end-of-the-week-after-cyberattack/
12 Stevens, Pippa. “Owner of pipeline shuttered by cyber attack aims to restore service by end of the week”. CNBC, 10 May 2021, https ://www.cnbc.com/2021/05/10/colonial-says-parts-of-fuel-pipeline-being-brought-online-aims-to-restore-service-by-end-of-week.html
13The White House, 12 May 2021, https ://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
14 Brooks, Richard. energycentral, 21 May 2021, https ://energycentral.com/c/ec/cybersecurity-executive-order-requires-new-software-security-standards-synopsys
15 Roby, Karen. MSN, “Expert: Biden’s executive order on cyber security is a good start toward protecting organizations”. 26 May 2021, https ://www.msn.com/en-us/money/smallbusiness/expert-bidens-executive-order-on-cybersecurity-is-a-good-start-toward-protecting-organizations/ar-AAKnd7E?ocid=uxbndlbing
