Why Developers Need Security in Their IDE: Lessons from Today’s Vulnerability Mess

2–4 minutes
HEIDI by Meterian logo with the tagline "Security where you code." The design features blue stylized code brackets forming an 'H' alongside a glowing signal icon above the 'I' in HEIDI.
Stop Coding in the Dark: Bringing Real-Time Security to Agentic AI Development

The software supply chain has become the backbone of business, but with that reliance comes escalating risk. Attackers are moving faster than defenders, targeting not just production environments but the very tools and processes developers rely on every day.

Recent statistics underline the urgency:

  • API vulnerabilities rose 168% in 2025, with 91% of organisations reporting API-related security incidents. Misconfigured APIs now expose 10 billion records annually, making them the fastest-growing attack vector.
  • GitHub repositories remain a high-value target. With 35% of repos public, malicious actors exploit developer missteps to compromise projects upstream.
  • Self-hosted runners used in CI/CD pipelines are another weak link. Research shows 35% of enterprises leave themselves exposed to attacks that allow lateral movement across repositories and organisations.

For AI adoption and secure coding to scale among thousands of developers of all skill levels, the industry needs both tools and guardrails to work together at machine-speed.  Agentic coding (using assistants like Cursor or Windsurf) has increased the risk of “blind trust” in AI-proposed code because LLMs often lack current threat intelligence.  

Shifting Attacker Focus

The Q2 2025 vulnerability data reveals a telling pattern. Exploited software included remote access tools and document editing platforms, as well as low-code/no-code development tools and even frameworks for building AI-powered applications.

What’s striking is that the vulnerabilities weren’t found in AI-generated code itself but in the frameworks supporting it. As development technologies evolve, attackers follow — exploiting weaknesses wherever developers least expect them.

The Developer’s Blind Spot

Despite these trends, many organisations still rely on security checks late in the lifecycle — in CI/CD pipelines or after deployment. This leaves developers coding in the dark, unaware that the open-source components and dependencies they’re pulling in could already be vulnerable.

By the time an issue is flagged, code is often deeply integrated, making remediation costly, disruptive, and in some cases, too late.

This is the gap attackers exploit: the developer’s blind spot inside the IDE.  ‘Blind Trust’ becomes a liability. 

Security Where You Code

Closing that gap means moving security upstream, directly into the developer’s workflow. That’s where HEIDI, Meterian’s new free IDE plugin, comes in.

HEIDI integrates with Visual Studio Code and JetBrains IDEs, providing:

  • Automatic vulnerability scanning of open-source dependencies (direct and transitive).
  • One-click fixes, so developers can remediate issues instantly.
  • Lightweight reports with actionable insights — without leaving the IDE.
  • Privacy by design: no source code ever leaves the machine, only manifest files are scanned.

Built for operational resilience:  now finding a vulnerability at the workbench is a “5-second fix,” preventing downstream disruption or a firm’s existential crisis.

By embedding this capability where code is actually written, HEIDI removes the guesswork and makes secure coding a natural part of the process. It transforms security from a late-stage barrier into an everyday guardrail.

Building Resilience From the Start

The rise of API exploitation, exposed GitHub repos, and vulnerable CI/CD runners clearly shows that attackers no longer wait for production. They strike wherever software is created, stored, or moved.

Organisations that want to stay ahead need to shift left — making vulnerability assessment and remediation part of the developer’s daily environment.

HEIDI makes this shift practical. It empowers developers to ship code that is secure from the start, reducing security debt, lowering patching costs, and protecting the supply chain before vulnerabilities can spread downstream.Stop coding in the dark. Arm your AI companion with the real-time security signals it’s been missing. Download HEIDI for free on the Visual Studio Code or JetBrains Marketplace today

Why Developers Need Security in Their IDE: Lessons from Today’s Vulnerability Mess

The UK Public Sector is Facing a Big Cyber Issue in 2026

5–7 minutes
A graphic illustration featuring iconic London architecture, including Big Ben and other historical buildings, overlaid with geometric patterns and the title 'The National Resilience Problem' in blue font.



The United Kingdom’s public sector is under increasing cyber pressure.

Government departments, healthcare systems, local councils, and public institutions now rely heavily on interconnected digital infrastructure. Much of that infrastructure was built years ago and still depends on ageing systems that are difficult to update, monitor, or secure properly.

At the same time, public sector software increasingly relies on open-source components. These dependencies help teams develop systems faster and reduce costs, but they also introduce software supply chain risk when vulnerabilities are not tracked or patched consistently.

Together, legacy infrastructure and unmanaged open-source dependencies are creating a difficult security environment. Attacks are becoming more disruptive, more expensive, and harder to contain.

Legacy Systems Remain Widespread Across the Public Sector

Legacy technology remains one of the biggest cyber security weaknesses inside UK public infrastructure.

The National Audit Office warned in 2025 that many government systems remain “high risk” due to age, unsupported software, and outdated architecture. 

Infographic about UK public sector legacy IT systems, highlighting 228 identified systems, 28% rated red due to high risk, and 53% lacking fully funded remediation plans.

The UK government’s own Cyber Action Plan similarly acknowledged that some legacy systems cannot be defended effectively using modern security controls.

Many of these systems:

  • Were built decades ago
  • Cannot be patched easily
  • Depend on outdated software stacks
  • Lack compatibility with modern security tooling
  • Require specialist maintenance knowledge

Replacing these systems is difficult. Large public sector upgrades are expensive, operationally risky, and often slowed by procurement complexity.

As a result, vulnerable systems frequently remain active long after safer alternatives are available.

Why Legacy Systems Increase Cyber Risk

Older systems are easier targets for attackers because they often lack basic modern protections.

Many do not support strong identity controls, modern encryption standards, or real-time threat monitoring. Some are no longer supported by vendors, meaning newly discovered vulnerabilities may never receive official patches.

Legacy systems also create wider operational risk because they are rarely isolated. Most are connected to newer applications, databases, cloud environments, or third-party services.

That means a vulnerability in one outdated system can become an entry point into a much larger network.

The National Audit Office has warned that ageing systems increase the likelihood of successful attacks and make incident recovery more difficult once breaches occur.

Download Meterian’s 2026 Predictions EBook. Master the New Rules of Software Sovereignty to understand why traditional AppSec models are breaking down and how leadership teams can prepare. 

Open-Source Software Adds Another Layer of Risk

Open-source software now powers most modern applications.

Public sector organisations use open-source frameworks, libraries, and packages across internal systems, citizen services, cloud applications, and third-party platforms.

The challenge is visibility.

Modern applications often contain hundreds or thousands of software dependencies, including transitive dependencies that developers may not even realise are present.

If organisations do not know which components exist inside their software, they cannot know which vulnerabilities affect them.

Research consistently shows that the majority of modern software contains open-source code. Many applications also contain known vulnerabilities that remain unresolved long after patches become available.

This is becoming a major concern for governments worldwide because vulnerable open-source components can spread risk across multiple systems at scale.

Want to see how vulnerable open-source dependencies can be identified earlier in development? Try HEIDI by Meterian, a free IDE plugin built to help developers find vulnerable packages and move to safer versions while they code.

The Log4j Problem Showed How Fast Risk Can Spread

The Log4j vulnerability remains one of the clearest examples of software supply chain risk.

Even years after the Log4Shell vulnerability was disclosed and patched, vulnerable versions continued appearing inside production systems worldwide.

Reports in 2025 showed that a significant percentage of Log4j downloads still contained vulnerable versions despite years of public awareness.

Infographic titled 'Log4j: A Warning About Software Supply Chain Risk' showing that 13% of global Log4j downloads in 2025 were still vulnerable, with UK rate at 14%. Approximately 300 million Log4j downloads in 2025, 40 million still unsafe. Notes that vulnerable code can remain in production even with existing patches.

The issue was never simply the existence of the vulnerability itself. The larger problem was that many organisations did not know where Log4j existed inside their software stack.

This is the core software supply chain challenge facing public sector organisations today.

A single vulnerable dependency can quietly exist across government systems, suppliers, applications, and service providers without clear visibility.

Cyber Attacks Against Public Services Are Increasing

The cyber threat facing the UK public sector continues to intensify.

The National Cyber Security Centre reported a growing number of nationally significant cyber incidents in its latest annual review. State-backed threat actors, ransomware groups, and financially motivated attackers continue targeting public infrastructure because disruption creates immediate pressure.

Several recent incidents have shown how severe the consequences can become.

Healthcare Systems

The NHS has experienced repeated cyber incidents linked to outdated infrastructure and unpatched vulnerabilities.

These attacks disrupted services, delayed operations, and exposed sensitive patient information. Healthcare systems remain particularly vulnerable because they depend on large interconnected environments that are difficult to modernise quickly.

The British Library Attack

The cyber attack against the British Library became one of the UK’s clearest examples of how legacy technology can worsen the impact of a breach.

The incident caused major operational disruption and lengthy recovery efforts. Later analysis linked the severity of the attack partly to historic underinvestment in cyber resilience and ageing infrastructure.

Local Government Disruption

Local councils across the UK have also faced growing cyber pressure.

Attacks have disrupted housing systems, benefits administration, and citizen services. In some cases, organisations were forced to revert to manual processes while systems recovered.

For public services, cyber incidents quickly become operational problems rather than isolated IT failures.

Why This Is Becoming a National Resilience Issue

The combined effect of legacy systems and open-source vulnerabilities creates broader national risk.

These issues are interconnected.

A vulnerable open-source component inside a legacy environment can affect multiple public services simultaneously. Once attackers gain access, interconnected systems make lateral movement easier and containment harder.

The consequences can include:

  • Service disruption
  • Data breaches
  • High remediation costs
  • Operational downtime
  • Delayed digital transformation
  • Increased exposure to state-sponsored attacks

Public infrastructure now depends heavily on software resilience. When software supply chains become difficult to monitor, national resilience becomes harder to maintain.

What Needs to Change

The UK public sector does not need to stop using open-source software. That would be unrealistic and counterproductive.

The priority is visibility.

Public sector teams need to know which open-source components are inside their software, where vulnerable versions are being used, and which fixes are available. This needs to happen continuously, because new vulnerabilities emerge every day.

Security also needs to move closer to development. If vulnerable dependencies are only discovered late in CI/CD, or after deployment, remediation becomes slower and more expensive.

The strongest approach is to make dependency security part of the normal development workflow. Developers should be able to see vulnerable packages, understand the risk, and move to safer versions before code reaches production.

Conclusion

The UK public sector faces a layered cyber security problem.

Legacy systems create weak points. Unmanaged open-source dependencies add software supply chain risk. Together, they make public services more exposed to attacks that can disrupt operations, expose data, and damage national resilience.

Modernising public infrastructure will take time. But visibility over open-source risk can improve now.

Knowing what is inside public sector software is the first step toward protecting the services people rely on every day.

← Back

Thank you for your response. ✨

The UK Public Sector is Facing a Big Cyber Issue in 2026

The Java Clone Hack That Happened in 20 Minutes — Could It Happen to You?

2–3 minutes
A smartphone displaying icons for a 'Clone App' with error messages and a shield symbol, highlighting cybersecurity themes.

In May 2025, a clone of the secure messaging app Signal — known as TM SGNL by TeleMessage — was compromised in under 20 minutes. The breach wasn’t due to zero-day exploits or state-sponsored threat actors. Instead, it was a plain, preventable Java server misconfiguration that exposed plaintext credentials, archived messages, and encryption keys.

This incident is a stark reminder for security and development teams – modern applications, especially Java-based clone apps, are riddled with hidden vulnerabilities that standard controls often miss.

This is exactly the class of threats Meterian’s continuous monitoring and AI-powered vulnerability intelligence is built to catch early and fix fast.


The TM SGNL Hack: Anatomy of a Misconfiguration

At the heart of the breach was a forgotten and publicly accessible Spring Boot Actuator endpoint. The exposed heap dump included:

  • Admin usernames and passwords in plaintext
  • Encryption keys
  • Archived private messages

TM SGNL had promised end-to-end encryption. Yet archived content was stored insecurely, and passwords were hashed using client-side MD5 — a deprecated and insecure method. The application also ran on an outdated JSP stack, compounding the risk.

The breach showed how vulnerable legacy Java frameworks and poor server hygiene can create systemic risk, even in apps that claim security by design.


Where Continuous Scanning Could Have Helped

This type of vulnerability isn’t exotic. It’s configuration-level, but critically dangerous. Meterian’s platform continuously scans Java applications for:

  • Misconfigured Actuator endpoints
  • Insecure or outdated hashing algorithms (like MD5)
  • Use of legacy Java stacks with unpatched CVEs
  • Exposure of credentials in memory dumps or logs

By aggregating insights from over 15 trusted vulnerability feeds, including the National Vulnerability Database and GitHub Advisories, Meterian flags risks with both high fidelity and low noise.


BOSS & Sentinel: Detect, Alert, Remediate

Meterian’s Sentinel engine would have flagged the publicly exposed /heapdump endpoint immediately as a misconfiguration with known exploit patterns. Combined with BOSS, our automated alerting system, security engineers would receive:

  • A prioritized, actionable report
  • A breakdown of the exposed endpoint’s risk level
  • Suggested auto-remediation steps (e.g., disable public access, require auth tokens)

These insights are delivered directly into existing CI/CD pipelines or DevSecOps dashboards, accelerating mitigation.


Why Java Clone Apps Are Especially Vulnerable

Clone apps often inherit:

  • Outdated codebases
  • Legacy dependencies
  • Minimal refactoring

In many cases, these applications rebrand functionality but retain insecure implementations. TM SGNL reused insecure design patterns while branding itself as a secure communications tool. This mismatch is where attackers thrive.

Meterian’s dependency graph analysis would have:

  • Mapped all third-party Java libraries in use
  • Flagged outdated dependencies
  • Identified insecure hashing libraries

What This Means for Security Leaders

Security isn’t just about patching CVEs. It’s about maintaining visibility and control across all components — including infrastructure, third-party libraries, and code hygiene.

Meterian helps CISOs, developers, and risk managers:

  • Maintain an up-to-date SBOM (using CycloneDX)
  • Integrate continuous monitoring into CI/CD
  • Detect vulnerabilities before they become breaches
  • Proactively secure clone apps before release


Prevention Is Achievable

The TM SGNL breach should not have happened. With continuous scanning, real-time intelligence, and automation-first remediation, it could have been prevented.

Meterian empowers software teams to spot and fix vulnerabilities like these — not weeks after deployment, but during development.

In 2025, security isn’t just a feature. It’s a process. And with Meterian, that process is invisible, continuous, and resilient by design.

The Java Clone Hack That Happened in 20 Minutes — Could It Happen to You?

Rethinking Open Source Security

Essential Steps for Leaders Before the Next Supply Chain Attack

Author: Rod Cobain • 4 min read

An illustration representing strategic leadership, featuring a businessman pointing and discussing strategy, alongside chess pieces, a light bulb symbolizing ideas, and a graph indicating growth.

A Storm Is Brewing

We live in an age of unprecedented digital dependency. From agile startups to global enterprises, modern organizations rely on interconnected software systems, primarily driven by open source software (OSS). While OSS is powerful, flexible, and cost-effective, it increasingly represents a critical cybersecurity risk.

Cyber attackers are aggressively exploiting open source vulnerabilities, targeting the tools and libraries that power global innovation. The question isn’t whether your organization uses open source software—it undoubtedly does. The critical question is: How effectively are you securing it?

This article will explore:

  • Why open source vulnerabilities attract cyber attacks.
  • The evolving nature of these threats.
  • The crucial role of cybersecurity thought leadership.
  • Strategic actions leaders must take immediately.

Open Source Software: The Expanding Attack Surface

The Prevalence of Open Source

  • 80-90% of modern applications incorporate OSS components.
  • OSS underpins critical infrastructure including finance, AI, and cloud services.
  • OSS adoption is accelerating within IoT and edge computing environments.

Why Attackers Target Open Source

  • A single vulnerability can impact thousands or millions of systems.
  • Attackers view the software supply chain as an attractive, often poorly defended target.
  • Many organizations lack visibility into OSS dependencies.

Recent High-Profile Incidents

  • Log4Shell (Log4j): A critical vulnerability in a widely used Java library triggered global disruption.
  • SolarWinds: Attackers infiltrated software updates, compromising numerous downstream systems.
  • MOVEit: Exploitation of a vulnerability in file-transfer software resulted in extensive data breaches.

These events signify a broader trend: cyber attacks exploiting OSS vulnerabilities are increasing in frequency and impact.


The Need for Thought Leadership

Challenging False Security Assumptions

Executives often mistakenly assume:

  • OSS security is someone else’s responsibility.
  • Commercial vendors adequately secure dependencies.
  • Development teams alone can manage open source risks effectively.

In reality:

  • OSS projects are often maintained by small volunteer teams.
  • Security debt accumulates rapidly.
  • Strategic oversight cannot be replaced by tools alone.

The Critical Role of Cybersecurity Thought Leadership

1. Driving Organizational Awareness

  • Treat software risk as a business risk.
  • Discuss OSS vulnerabilities regularly at board meetings.
  • Implement continuous monitoring and risk management strategies.

2. Building Industry Collaboration

  • Foster industry-wide partnerships to strengthen OSS security.
  • Support and participate in initiatives such as the Open Source Security Foundation (OpenSSF).

3. Influencing Public Policy

  • Advocate for clear software liability frameworks.
  • Promote mandatory Software Bill of Materials (SBOM) use for transparency and traceability.

4. Leading by Example

  • Adopt secure open source practices internally.
  • Showcase effective practices to peers and partners.
  • Contribute actively to open source communities.

Proactive Leadership Actions: Steps You Should Take Now

For CISOs, CEOs, and Security Officers:

  • Deploy comprehensive Software Composition Analysis (SCA) solutions.
  • Maintain a complete, continuously updated inventory of OSS components.
  • Embed security earlier into the development lifecycle (shift-left approach).
  • Accelerate patching of OSS vulnerabilities through automated remediation.
  • Engage with and support OSS communities financially and operationally.

For Executives and Board Members:

  • Request regular software supply chain risk assessments.
  • Allocate resources to enhance OSS security measures.
  • Support cross-industry initiatives and SBOM adoption.
  • Promote a culture where software security is central to business strategy.

The Broader Impact: Securing a Global Commons

Open source software represents a global digital commons. Poor security practices risk widespread systemic failure, not just isolated breaches. Robust thought leadership from security and business executives can act as a force multiplier by:

  • Driving critical awareness and urgency.
  • Shaping industry standards and best practices.
  • Influencing proactive, collaborative security cultures.

Without proactive leadership, organizations face continuous cycles of reactive firefighting. With it, we can build resilience and trust in the digital future.


Conclusion: Your Leadership Legacy

The stakes have never been higher:

  • Attackers are innovating rapidly.
  • OSS vulnerabilities will continue to surface and be exploited.
  • Regulatory landscapes and liability expectations are evolving quickly.

Now is the time for bold cybersecurity leadership that transcends organizational silos, engages across industries, and shapes global security practices. As a leader, ask yourself:

  • Is your organization prepared for the next OSS attack?
  • Are you shaping the conversation or merely reacting?
  • What legacy will you leave in securing the software that powers the world?

The future of digital trust depends on your answers.

Rethinking Open Source Security

Open Source, Hidden Risk

Part 1: What Business Leaders Must Learn from Recent Cyber Vulnerabilities

Author: Rod Cobain • 4 min read

Three business professionals reading a newspaper titled 'SOURCE: Hidden Risks Susceptible to Cyber Atokspern Attacks' in a modern office setting, discussing hidden risks susceptible to cyber attacks.
AI-generated image of business professionals

Open source software powers your business, it’s a fact whether you know it or not. From core infrastructure to everyday applications, open source code is embedded deep within the tools we trust. It’s a quiet enabler of innovation, agility, and scale.

But recent high-profile vulnerabilities, from Log4Shell to the XZ Utils backdoor, have exposed a hard truth; what’s free and open can also be fragile and risky. For business leaders, these incidents aren’t just technical hiccups. They’re a boardroom-level ticking time bomb. It’s time we stop treating open source security as an engineering detail and start addressing it as a strategic priority.

Many assume that popular open source projects are secure because they’re widely used. But visibility isn’t the same as scrutiny. The Log4Shell vulnerability sat undetected in a core Java logging library for nearly a decade until Dec 2021.  When discovered, it impacted millions of computers, everything from cloud platforms to consumer apps.  As a business leader, if your business relies on open source (and it does), you must invest in ongoing due diligence, not blind trust. Recent supply chain issues should prompt critical questions such as, “What’s in my software supply chain?” and “How’s it monitored?”.

Your Risk is Reflected by Your Dependencies

A single compromised component can ripple across countless systems.  Looking at the event-streamincident, a small JavaScript library was hijacked and weaponised to steal cryptocurrency.   As a business leader, demanding visibility into your organisation’s dependency map is a must, ignorance is no excuse, and cyber insurance providers are not covering such risks. Are you relying on unknown or unmaintained components in your software development production? If the answer is “yes or not sure”, you need to have your code assets scanned, and either automatically remediated or managed with a mitigation plan.  As a result of the widespread consequences these open source vulnerabilities can have, since the Log4Shell incident, insurance providers require customers to prove they’ve patched or risk losing their insurance cover benefits

Underfunded Projects Power Billion-Pound Businesses

The most alarming aspect of many open source vulnerabilities isn’t the flaw itself, but the lack of maintenance. The XZ backdoor came about partly because the project had only one active maintainer, such is the nature of open source community driven software.  Therefore consumers and enterprises using the open source library inherit the responsibility for the quality and security of the instance used in its own coding projects. Adopting a pro-active 24/7 solution that incorporates continuous monitoring, automated remediation, and AI-powered vulnerability detection, is essential for identifying and addressing issues swiftly.

Leadership takeaway: Small investment vs Large payout or loss of credibility is clear. 

Speed of Response Is a Competitive Advantage

Putting in place a pro-active approach when vulnerabilities emerge–detect, prioritise, and patch quickly– can prevent disruption and protect your reputation. Marks & Spencer, Co-op and others are still striving to regain normality in the weeks to come.  These unfortunate incidents of “world class companies” highlight how security response has become a key measure of business agility.  Are your teams empowered with the tools and authority to act swiftly when open source risks emerge?

The Future of Open Source Security

Open source is here to stay.  Its growth is undeniable and remains a cornerstone of technological innovation for good. But security can’t just be an engineering checkbox. It must be part of your organisation’s culture, led from the top. Encourage a mindset of proactive security and open collaboration. The best organisations view open source software not just as free software, but as shared infrastructure worth protecting.

Conclusion

Cyber vulnerabilities in open source is not  a reason to fear the model.  Instead, they’re a call to engage more responsibly with it. As leaders, we must stop viewing open source security as someone else’s problem. The reality is: if your business runs on open source, its security must be your priority. Your role may not be a technical one, but asking the right questions and knowing your options from the beginning will help you take a preventive stance to ensure you don’t end up as tomorrow’s headline.

Open Source, Hidden Risk

Defend Against Disruption: Safeguard Vulnerability Management Amid MITRE Funding Risks

Today’s Reality Check: Vulnerability Management is Non-Negotiable

With the MITRE CVE system being the backbone of global vulnerability identification, it’s alarming to see discussions about funding cuts that could jeopardize this critical resource. If the industry loses its shared language for describing digital flaws, we’re all in trouble. This could stifle innovation in vulnerability management and mitigation, leaving organizations scrambling for reliable data in the U.S. and globally.

The industry needs to rally. We must collaborate on alternative funding models, invest in open-source initiatives, and forge partnerships that keep vital resources like CVE alive and thriving. Let’s ensure that our defenses remain robust, even in the face of disruption.

Meterian: The Power Database and Invisible Security Platform You Need

While others may falter, Meterian is charging ahead. Our vulnerability database is not just comprehensive; it’s a powerhouse, tracking over 400,000+ vulnerabilities and receiving daily automatic updates from a multitude of sources. We pull data from the National Vulnerability Database, GitHub Security Advisories, and 15 other unique feeds. But we don’t stop there. Our AI-generated insights, combined with meticulous manual curation, deliver a done-for-you service that your security and engineering teams can depend on.

In short, we provide your enterprise with a pair of automated eagle eyes, ensuring you have full visibility into potential software weaknesses in your third-party software supply chain.

Quality and Volume

Our commitment to excellence means you get the best tools to manage vulnerabilities effectively, for your team’s tech stack and workflow.  We have a multitude of integrations and our OpenAPI architecture means we can collaborate to create more value together.

Join the Revolution

It’s time to elevate your cybersecurity strategy with the best solution for your team. Ready to take your cybersecurity to the next level?  Check out our product page infographic to see how our database stacks up against the competition.

Defend Against Disruption: Safeguard Vulnerability Management Amid MITRE Funding Risks

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?

Big News for Flutter Fans: Meterian Now Supports Dart!

Great news for all you mobile developers out there! Meterian, a leading Software Composition Analysis (SCA) platform, has just rolled out support for Dart, the programming language that’s become super popular for building Flutter apps. If you’re crafting mobile apps with Flutter, this update is specially tailored for you. Let’s dive into what this means and why it’s a game changer for Flutter developers.

Why Dart and Flutter are a big Deal

Developed by Google, Dart is all about building smooth and stunning mobile and web applications, and it’s the powerhouse behind Flutter—Google’s UI toolkit for crafting beautiful, natively compiled applications from a single codebase. Flutter’s ability to deliver apps that feel great on both Android and iOS has made it a hot favorite. With Dart now getting the spotlight it deserves, security and efficiency in app development are set to reach new heights.

Meterian embraces Dart

With Dart on its radar, Meterian is making sure that your development toolkit is not just powerful but also secure. This inclusion means Meterian can now safeguard your Flutter projects right from the get-go, catching potential security slip-ups before they become real headaches.

Meterian’s leap to include Dart is more than just an update—it’s setting a new standard for mobile app security. By embracing the needs of the Flutter community, Meterian is not only beefing up the security of apps but is also paving the way for projects that scale smoothly and stay robust under pressure.

What’s in it for Flutter developers?

We believe Flutter will eventually get a dominant position in the mobile development scene, so it’s essential to have tools that ensure that your applications are rock-solid safe. Meterian’s support for Dart brings you a suite of benefits:

  • Boosted Security: Spot vulnerabilities early in the development cycle with Meterian’s SCA tools, keeping your apps safe from security threats.
  • Stay on the Right Side of Compliance: Keep up with the latest security standards easily, ensuring your app complies with legal and regulatory requirements.
  • Seamless Development Flow: Meterian fits right into your existing workflows, helping you patch up security issues without slowing you down.
  • Scale with Confidence: As your app grows, Meterian grows with it, making sure that even the most complex projects stay manageable and secure.

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!

With Dart in Meterian’s toolkit, it’s an exciting time to be building apps with Flutter. This move shows Meterian’s commitment to supporting the latest and greatest in app development, making it easier for you to build apps that aren’t just awesome but are also secure and compliant. To learn more about Meterian’s support for Dart/Flutter and how it can help improve the security of your projects, visit Meterian’s website at www.meterian.io.

Big News for Flutter Fans: Meterian Now Supports Dart!

Ensuring Data Integrity and Security in Healthcare: The Crucial Role of Application Security

In the digital age, healthcare companies are guardians of vast amounts of sensitive user data, ranging from personal health records to financial information. With this responsibility comes the challenge of ensuring data integrity and security against the growing threats of cyberattacks and data breaches. Meterian, a leader in application security, is at the forefront of providing solutions that safeguard this critical data.

Healthcare providers harnessing open-source software face unique security risks that require vigilant management and protection strategies. Meterian’s innovative tools actively scan and identify vulnerabilities within applications, ensuring that all components are up to date and secure against potential threats. By leveraging Meterian’s capabilities, healthcare companies can not only protect their patient data but also enhance their overall cybersecurity posture.

Protecting patient records.

In collaboration with Emis Group, a well-established brand in healthcare technology, Meterian has demonstrated its value in real-world applications. Emis has utilised Meterian’s solutions to bolster their applications’ defences, thereby protecting millions of patient records. While our partnership with Emis illustrates Meterian’s capability to handle the complex cybersecurity needs of large enterprises, it’s important to recognise that our solutions are equally effective and accessible for SMEs and startups. Meterian understands the unique challenges faced by smaller organisations, including tighter budgets and limited resources, as our platform is designed to be flexible and scalable.

For healthcare organisations, the fear of missing out on the highest level of security should be a significant concern. Meterian provides an essential layer of security that automates and streamlines the detection and management of vulnerabilities—tasks that would otherwise consume valuable development resources. As legislation evolves and compliance becomes even more stringent, Meterian’s tools help healthcare companies stay ahead, ensuring they meet all regulatory requirements while securing user data against emerging threats.

A successful case study.

To see first – hand how Meterian is enhancing cybersecurity in the healthcare industry, we invite you to explore our success story with Emis Group. This case study provides a detailed look at how Emis leveraged Meterian’s cutting-edge solutions to fortify their application security, ensuring compliance with stringent regulations and protecting sensitive patient data. 

Visit Meterian today!

Ensuring Data Integrity and Security in Healthcare: The Crucial Role of Application Security