EU Cyber Resilience Act: Key Updates on SBOM Compliance

EU Cyber Resilience Act

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:

  1. Automating SBOM Generation: Tools like Meterian can streamline SBOM creation, ensuring accurate dependency mapping and compliance with CRA’s format requirements.
  2. Enhancing Vulnerability Management: Despite the lack of mandatory CPE or PURL, integrating these identifiers into internal processes can improve accuracy.
  3. 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.

EU Cyber Resilience Act: Key Updates on SBOM Compliance

WHY IS SOFTWARE COMPOSITION ANALYSIS (SCA) IMPORTANT?


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.

Countless examples are available:

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.

Also Tesla decided to release its code to the public to comply with a copyleft license. On another occasion.  Westinghouse Digital Electronics preferred bankruptcy

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.


Looking forward hearing from you.

WHY IS SOFTWARE COMPOSITION ANALYSIS (SCA) IMPORTANT?

Meeting Compliance Challenges in Healthcare: How Cybersecurity Partnerships Can Lead to Success

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. 

Meeting Compliance Challenges in Healthcare: How Cybersecurity Partnerships Can Lead to Success

Understanding the Importance of Software Composition Analysis in the Context of EU’s DORA Regulations

The EU’s Digital Operational Resilience Act (DORA) represents a significant step towards ensuring that the financial sector can withstand and rapidly recover from ICT-related disruptions and threats. Among the wide variety of security testing tools and actions mandated by DORA, Software Composition Analysis (SCA) emerges as a critical component. Let’s explore why SCA is vital in this new regulatory landscape and how solutions like Meterian can be particularly beneficial.

What is Software Composition Analysis?

Software Composition Analysis (SCA) is a cybersecurity process that helps organizations identify and manage open source components within their software inventory. SCA tools scan software projects to detect open source libraries and frameworks, check the versions used, and compare them against databases of known vulnerabilities. Additionally, SCA assesses license compliance risks, ensuring that the open source licenses are compatible with corporate policies on software usage.

The Role of SCA Under DORA

The DORA framework emphasizes the need for a broad and adaptable approach to cybersecurity, recognizing the diverse nature of financial entities and their varying levels of ICT maturity. Here’s why SCA is integral to this approach.

Vulnerability Management
Financial entities utilize a plethora of software solutions, many of which rely on open-source components. SCA provides a systematic approach to detecting vulnerabilities in these components, some of which may be critical and widely exploited in the financial sector. By identifying these vulnerabilities early, financial institutions can patch them before they are exploited.

Compliance and Risk Management
DORA calls for rigorous compliance standards, including in areas like software licensing. SCA tools automatically detect the licenses of every component and alert teams about potential legal and operational risks, thus supporting compliance with DORA requirements.

Enhanced Operational Resilience
By integrating SCA into their cybersecurity practices, financial institutions can improve their operational resilience. Knowing exactly what is in their software reduces the time and resources spent on crisis management in the event of a security breach.

Supporting Advanced Testing Requirements
As entities mature, advanced testing such as Threat-Led Penetration Testing (TLPT) becomes viable. SCA ensures that the foundational elements of software security are addressed, which is critical for conducting more sophisticated, scenario-based tests effectively.

How Meterian Can Help

In the context of DORA, Meterian stands out as a valuable ally for financial institutions aiming to enhance their software security posture. Here’s how Meterian can specifically support compliance and resilience:

  • Continuous Security and Compliance Monitoring: Meterian continuously scans your software projects, providing real-time alerts on new vulnerabilities and compliance issues. This ongoing monitoring ensures that financial entities can respond promptly to emerging threats.

  • Automated Fix Suggestions: Beyond identifying issues, Meterian provides actionable insights and automated fix suggestions. This helps in quickly resolving vulnerabilities and license conflicts, significantly reducing the window of exposure.

  • Ease of Integration: Meterian’s platform can be seamlessly integrated into existing development workflows. This integration ensures that security and compliance checks occur throughout the software development life cycle, aligning with DORA’s emphasis on continuous improvement and adaptation.

  • Customizable Reporting: Meterian offers detailed, customizable reports that can assist financial entities in demonstrating their compliance with DORA regulations to regulators. These reports provide clear evidence of the proactive measures taken to ensure operational resilience.

By leveraging SCA tools like Meterian, financial institutions can not only meet the stringent requirements set forth by DORA but also significantly strengthen their cybersecurity frameworks. This proactive approach to software security is essential in a landscape where digital operations are increasingly integral to financial stability and success.

Understanding the Importance of Software Composition Analysis in the Context of EU’s DORA Regulations

Precise and Timely Vulnerability Notifications with Meterian

Stop worrying about missing critical vulnerability alerts. As application security experts, we know the constant struggle to stay informed about the latest threats facing your open-source components. That’s why we’re excited to introduce Meterian’s vulnerability notification system, designed to provide timely, accurate, and actionable information so you can take immediate steps to protect your applications.

Unparalleled Insight into Open-Source Risks

Meterian boasts the largest OSINT vulnerability database on the market, meticulously tracking over 335,000 vulnerabilities daily across 20+ diverse sources. We go beyond mere quantity, offering almost 94,000 unique vulnerabilities spanning 16 programming languages, ensuring comprehensive coverage for your development stack. Every day,

Never Miss a Critical Update

Our system proactively identifies new open-source component vulnerabilities and critical updates, delivering comprehensive notifications straight to your inbox. Each notification contains all the essential details to address the issue effectively:

  • Precise component name and ecosystem
  • Affected version range
  • Detailed vulnerability description
  • CVE identifier (if available)
  • Associated CVSS and EPSS scores
  • List of unaffected versions
  • Links for further exploration

What’s a CVE?

A CVE is like the official scoreboard listing of a severe foul or broken piece of equipment (a security flaw) that the entire league (the tech world) agrees must be fixed. Meterian acts as your team’s Defensive Coordinator, constantly watching the game for any new fouls and sending a precise, instant notification only to the players (developers) who are currently using that faulty gear, telling them exactly how to swap it out for a legal one before the referee throws a flag (a breach).

We believe that staying informed about vulnerabilities requires a comprehensive view. That’s why our platform not only delivers daily updates but also offers a valuable 30-day history, for free. This historical perspective allows you to track the evolution of vulnerabilities: whether you’re a seasoned developer or an individual user, understanding the trends over the past month can empower you to make informed decisions and take proactive security measures. Visit our Meterian Vulnerabilities pages to explore this rich history and stay ahead of the curve.

Tailored Alerts for Subscribed Users

We understand that information overload can be counterproductive. That’s why we offer two distinct notification systems for subscribed users:

  • Sentinel that continuously monitors previously scanned projects
  • Allerta that provides alerts based on a user specific preferences

Sentinel Notification System: Continuous Security Monitoring

Our Sentinel Notification System is your ticket to continuous security monitoring. It offers timely alerts to development teams, even without active scans. Once a project is under Meterian’s purview, Sentinel automatically and routinely examines it for new vulnerabilities. This seamless process ensures ongoing security screening, eliminating the need for user intervention. With Sentinel, you can rest assured that your projects remain protected around the clock.

Allerta Notification System: Tailored Security Alerts

The Allerta Notification System is designed with flexibility in mind. It allows users to tailor security alerts based on their preferences. You can define your interests, specifying preferred ecosystems, and scoring thresholds, ensuring that you receive notifications that align with your specific needs. Whether you’re a developer focusing on a particular programming language or a security professional seeking a broader view, Allerta provides precise information tailored to your requirements. With Allerta, you gain the ability to customize your security alerts while staying well-informed about the vulnerabilities that matter most to you.

Empowering Developers and Security Teams

Developers can focus on specific languages, while security personnel maintain a global view. All notifications provide granular details, including the affected component and version, so everyone has the context needed to make informed decisions. Don’t wait for a breach to expose your vulnerabilities. Meterian’s notification system empowers you to take control of your application security.

Sign up for a free trial today and experience the power of proactive application security. See for yourself how Meterian can keep you ahead of the curve and your applications safe. And remember, you can always consult the daily vulnerability report online, completely free: no subscriptions needed.

Take action now and protect your applications from the ever-evolving threat landscape!

Precise and Timely Vulnerability Notifications with Meterian

Improved Security for Swift Developers: Meterian Now Supports SwiftPM!

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.

I want to use Meterian: what should I do?

Meterian is free for open source projects! If you have a GitHub OSS project, you can easily integrate Meterian using the GitHub Action following this step-by-step guide or you can checkout this live example on GitHub. We do have also native integrations with BitBucket and Azure Devops, and also integrations with other CI/CD platforms.

Meterian is here to help!

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.

Improved Security for Swift Developers: Meterian Now Supports SwiftPM!

Cyber resilience is critical for innovation and economic sustainability

The events of the last few years have highlighted the world’s vulnerabilities and shown the importance of building resilience into organisations, supply chains and the global economy. COVID-19 and the war in Ukraine have exposed issues we’d chosen to ignore, thought we’d fixed forever or hadn’t even considered before. Growth is no longer guaranteed. The global economy’s increasing reliance on technology to enable the world to function extends the attack surface and opens up new cyber security threats.

The need for cyber security to protect sustainable growth

Governments are struggling with plans for sustainable economic growth against a background of conflict, continuing supply chain problems, climate change, rising prices and interest rate increases. Typical sustainable development goals include; economic growth measured by GDP; business innovation and infrastructure renewal; creating sustainable cities and communities; and responsible consumption of products.

From smart cities, to renewable energy, financial infrastructures and driverless transport, cutting-edge technology is at the heart of our drive for sustainable growth. This provides exciting opportunities but has also exposed existing systems’ weaknesses and created new vulnerabilities to malicious actors. Sustainable development goals are all put at risk by the increased threat from cyber attacks.

Organisations have become familiar with safety and security measures which protect their physical environment such as installing early warning sensors, security cameras, fire safety equipment and intruder alarms. There’s a need for a cultural shift for executives, investors, employees and regulators to recognise the increasing importance of cyber security. The war in Ukraine has brought into sharp relief the importance of having both strong physical and cyber defences. Cyber resilience is absolutely necessary for modern civilisation to survive and flourish. 

How big is the cyber threat?

Recent research and headlines point to cyber crime being very big business indeed. One study showed cyber criminals raking in $1.5 trillion every year. To put that in context that’s exactly the same amount proposed for the US Congress’ bipartisan package to help Ukraine and finance federal agencies for the second half of 2022. Another study from Cybersecurity Ventures expects global cybercrime costs to reach $10.5 trillion annually by 2025. This led Steve Morgan, Editor-in-Chief at Cybercrime Magazine to comment, “This represents the greatest transfer of economic wealth in history, risks the incentives for innovation and investment, is exponentially larger than the damage inflicted from natural disasters in a year, and will be more profitable than the global trade of all major illegal drugs combined.”

Innovation is a growing target for cyber criminals

Innovation and invention are seen as good things for businesses and the wider economy. They power economic growth and prosperity around the world but by their very nature they can open the door to cyber criminals. Innovation is all about new technologies, products and ways of working. The cloud gaming sector is a prime example of an industry that has attracted the attentions of hackers, due to its  constant growth, developing new platforms and introducing new products almost daily. As the industry transitions to cloud infrastructures, the market size was estimated at $609.67 million in 2021, and is expected to grow to $7.382 billion by the end of 2028 according to research by Brandessence. Change, as in this case, often comes at dizzying speed. This means that procedures, controls, security and monitoring may lag behind. Ripping up the rule book to innovate can have huge positives but organisations need to watch for the negatives too. Indeed, some of the largest cyber security incidents in 2022 were targeted at the gaming sector, with breaches reported by such behemoths as Rockstar, Roblox and NVIDIA, to name just a few. 

Rapidly expanding sectors and businesses naturally also attract huge investment. This makes them even more attractive for wily cyber criminals as the rewards from attacks can be particularly lucrative. Another pertinent example is the renewable energy sector. This growing industry promises great things for our hopes of preserving the world we live in. Massive investment means it is also shaping up to be a very attractive market for cyber criminals. 

Jim Guinn, global managing director for cyber security in energy, chemicals, utilities and mining at Accenture has noted, “The cybersecurity conversation in the renewable energy engineering and construction business is almost nonexistent today.” It is imperative that such industries underpin their expansion with the appropriate focus on defence against cyber attacks.

Protecting your software stack

The way today’s technology solutions are created using a jigsaw puzzle of multiple pieces including published APIs, integration with proprietary products, cloud applications from different vendors, open source components all combined with in-house developments means that many organisations are unsure about their complete Software Bills of Materials (SBOMs). This means vulnerabilities are literally built into critical systems introducing undocumented threat vectors which can be used by hackers to gain access to proprietary systems and data.

This lack of knowledge about an organisation’s SBOMs means that even when a bug or vulnerability is identified in the open source community and patches created, the business can be completely unaware  of the fact that it needs to take remedial action. There are many examples of this type of oversight resulting in huge costs and disruption for business.

Secure by default – building resilience

In 2023, developers and publishers of software must focus on Secure by Default principles if systems are to avoid the kind of failures due to poor security posture and an over reliance on end-users to act in a secure manner. The user experience is an integral part of the security features of a system, because if security makes software inconvenient to use, end-users will simply find a workaround. If security isn’t second nature then it’s no security at all.  The UK Government has introduced tough new regulations in the Telecommunications (Security) Act which includes the requirement to have a deep understanding of security risks, including those within the supply chain. This builds on the premise that ‘edge’ devices such as radio masts, internet equipment, or wifi routers supplied to customers should be protected from cyber attack. 

NCSC Technical Director Dr Ian Levy made the point: “We increasingly rely on our telecoms networks for our daily lives, our economy and the essential services we all use. These new regulations will ensure that the security and resilience of those networks, and the equipment that underpins them, is appropriate for the future.”

Online risks spill over into the physical world

Increasingly, online services are impacting people in the real world.  A high profile example is the fall out from the 2017 Equifax data breach, which it is estimated to have 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. This left the cyber doorway open for criminals to enter and cause havoc. Over 140 million U.S. consumers’ data was affected, putting them at risk of future financial instability—being unable to rent housing, being denied a loan, having to pay higher interest rates on credit cards or mortgages, and greater difficulty in getting a job, not to mention the distress and anxiety identity theft causes.

A more recent example, described as the biggest hack in history that affected telco Optus, led to one in three Australians at risk of identity theft or fraud. As a result, 10,000 victims have had their personal details published online and millions of people are scrambling to change their online driving licenses.  T-Mobile data breach that affected 37 million accounts was detected in January 2023 but the weakness in the API had been exploited since November 2022.

Automating Development & Security Operations (DevSecOps)

As software development accelerates and the attacks of malicious actors continue to increase in speed and intensity, organisations must ensure their security operations are equipped to respond equally fast. Preventative strategies can be built into the development workflow to ensure that DevSecOps processes are efficient and maintain the appropriate vigilance without wasting human resources.  Such processes become operationally effective if for every critical patch released, the security and development teams are ready with normal business practice to identify the threat, confirm its presence in their application software estate and remediate as quickly as possible as part of business as usual.  Without DevSecOps, such operations can take days to weeks, but forward thinking teams will have worked this out so such incidents take minutes to hours, thus preventing unauthorised access or infiltration of malware via an open source vulnerability.

With some 64% of companies impacted in 2021 by supply chain attacks, mostly due to increased reliance on open source software components, organisations must be scrupulous about checking that underlying dependencies are safe from vulnerabilities. A further study showed such attacks were up 300% compared to the preceding year.  Businesses that prepare thoroughly against such risks will be well rewarded.  Not only are they underpinning their own operations, ensuring that their business can continue to grow and innovate without hindrance from malicious attacks, they protect their reputation by providing reliable products and services to their customers. In turn, customers know that they can trust their supplier, building loyalty in the business that transcends a purely transactional relationship. 

Ensuring that technology works as it should has long been a given. Now it is an expectation that tech works securely, protecting personally identifiable information, while still providing a great user experience, so that people can get on with their lives, knowing that their trusted suppliers are looking after their data securely. It is a challenge for the entire technology industry, but one on which our very way of life depends.

Visit www.meterian.io to learn how Meterian can help secure your businesses’ open source components to reduce the threats of cyber attacks.

Cyber resilience is critical for innovation and economic sustainability

Want Cyber Insurance? Better get patching!

Image from https://unsplash.com/photos/bq31L0jQAjU

Want Cyber Insurance? Better get patching!

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.  

Cyber Insurance: prove it or risk losing it

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.

Want Cyber Insurance? Better get patching!

URGENT AND CRITICAL: REMOTE CODE EXECUTION IN VARIOUS SPRING COMPONENTS NEEDS IMMEDIATE ATTENTION

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.

CVE-2022-22963

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.cloud:spring-cloud-function-core, org.springframework.cloud:spring-cloud-function-context
Affected versions: 3.1.6, 3.2.2 and older unsupported versions
Fixed in version: 3.1.7, 3.2.3

CVE-2022-22965

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 upgrade spring-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:

CVE-2022-22963:

$ mvn dependency:tree | grep spring-cloud-function | grep compile
[INFO] +- org.springframework.cloud:spring-cloud-function-core:jar:3.1.2:compile

If you see any response lines, check the version: if it’s below 3.1.7 (as in the above example) or, if using 3.2.x, below 3.2.3, you may be affected.

CVE-2022-22965:

$ mvn dependency:tree | grep spring-beans | grep compile
[INFO] +- org.springframework:spring-beans:jar:5.3.11:compile

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.

CVE-2022-22963:

    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-function-core</artifactId>
        <version>3.1.7</version>
    </dependency>

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.

CVE-2022-22965:

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>5.3.18</version>
    </dependency>

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 do a scan from the command line using the Meterian CLI scanner
  • 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 ActionsAzure 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.   

Related references

CVE-2022-22963

CVE-2022-22965

URGENT AND CRITICAL: REMOTE CODE EXECUTION IN VARIOUS SPRING COMPONENTS NEEDS IMMEDIATE ATTENTION

Visibility is vital if we are to improve safety and trust in open source

Image shows an observation deck, but the panorama is veiled behind white light or mist showing blank skies.  Do we know or see what we are building in our digital world?

Photo by Kate Trysh on Unsplash

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.

2 “What is Log4j? A cybersecurity expert explains the latest internet vulnerability”, The Conversation, Dec 21, 2022, https://theconversation.com/what-is-log4j-a-cybersecurity-expert-explains-the-latest-internet-vulnerability-how-bad-it-is-and-whats-at-stake-173896

Visibility is vital if we are to improve safety and trust in open source