For decades, cybersecurity relied on shared visibility into common codebases. When a flaw was found in OpenSSL or Log4j, the community could respond: identify, share, patch, and protect.

AI-generated code breaks that model. Instead of re-using an open source component and having to comply with license restrictions, one can use AI to rewrite a near similar version but not use the exact open source version.

I recently attended SINET New York 2025, joining dozens of CISOs and security leaders to discuss how AI is reshaping our threat landscape. One key concern surfaced repeatedly: Are we vibe coding our way to a crisis?

Listen to the Audio Overview

Losing the Commons of Vulnerability Intelligence

At the SINET New York event, Tim Brown, VP Security & CISO at SolarWinds, pointed out that with AI coding, we could lose insights into common third-party libraries.

He’s right. If every team builds bespoke code through AI prompts, including similar to but different than open source components,  there’s no longer a shared foundation. Vulnerabilities become one-offs. If we are not using the same components, we won’t have the ability to share vulnerabilities. And that could lead to a situation where you have a vulnerability in your product that somebody else won’t know they have.

The ripple effect is enormous. Without shared components, there’s no community-driven detection, no coordinated patching, and no visibility into risk exposure across the ecosystem. Every organization could be on its own island of unknown code.

AI Multiplies Vulnerabilities

Even more concerning, AI doesn’t “understand” secure coding the way experienced engineers do. It generates code based on probabilities and its training data. A known vulnerability could easily reappear in AI-generated code, alongside any new issues.

Veracode’s 2025 GenAI Code Security Report found that “across all models and all tasks, only 55% of generation tasks result in secure code.” That means that “in 45% of the tasks the model introduces a known security flaw into the code.”

For those of us at RunSafe, where we focus on eliminating memory safety vulnerabilities, that statistic is especially concerning. Memory-handling errors — buffer overflows, use-after-free bugs, and heap corruptions — are among the most dangerous software vulnerabilities in history, behind incidents like Heartbleed, URGENT/11, and the ongoing Volt Typhoon campaign.

Now, the same memory errors could appear in countless unseen ways. AI is multiplying risk one line of insecure code at a time.

Signature Detection Can’t Keep Up

Nick Kotakis, former SVP and Global Head of Third-Party Risk at Northern Trust Corporation, underscored another emerging problem: signature detection can’t keep up with AI’s ability to obfuscate its code.

Traditional signature-based defenses depend on pattern recognition — identifying threats by their known fingerprints. But AI-generated code mutates endlessly. Each new build can behave differently and conceal new attack vectors.

In this environment, reactive defenses like signature detection or rapid patching simply can’t scale. By the time a signature exists, the exploit may already have evolved.

Tackling the Memory Safety Challenge

So how do we protect against vulnerabilities that no one has seen — and may never report?

At RunSafe, we focus on one of the most persistent and damaging categories of software risk: memory safety vulnerabilities. Our goal is to address two of the core challenges introduced by AI-generated code:

• Lack of standardization, as every AI-written component can be unique
• No available patches, as many vulnerabilities may never be disclosed

By embedding runtime exploit prevention directly into applications and devices, RunSafe prevents the exploitation of memory-based vulnerabilities, including those that are unknown or zero days.

That means even before a patch exists, and even before a vulnerability is discovered, RunSafe Protect keeps code secure whether it’s written by humans, AI, or both.

Building AI Code Safely

AI-generated code is here to stay. It has the potential to speed up development, lower costs, and unlock new capabilities that would have taken teams months or years to build manually.

However, when every product’s codebase is unique, traditional defenses — shared vulnerability intelligence, signature detection, and patch cycles — can’t keep up. The diversity that makes AI powerful also makes it unpredictable.

That’s why building secure AI-driven systems requires a new mindset that assumes vulnerabilities will exist and designs in resilience from the start. Whether it’s runtime protection, secure coding practices, or proactive monitoring, security must evolve alongside AI.

At RunSafe, we’re focused on one critical piece of that puzzle, protecting software from memory-based exploits before they can be weaponized. As AI continues to redefine how we write code, it’s our responsibility to redefine how we protect it.

Learn more about Protect, RunSafe’s code protection solution built to defend software at runtime against both known and unknown vulnerabilities long after the last patch is available.

The post AI Is Writing the Next Wave of Software Vulnerabilities — Are We “Vibe Coding” Our Way to a Cyber Crisis? appeared first on RunSafe Security.

Security can either be your biggest margin killer or your most powerful profit enabler. From the beginning, our goal at RunSafe has been to put control back into the hands of the defenders. And that means building solutions that meaningfully reduce risk across your product portfolio. As cyber defense champions, we can quantify economic benefits to security solutions that improve your product line profitability.

Listen to the audio overview below: 

The Cost of Reactive Security

Security incidents now average $4.88 million per breach according to IBM’s 2024 Cost of a Data Breach Report, but that figure only scratches the surface. The real damage comes from the operational drag that reactive security creates long before any breach occurs.

Consider an example from a software manufacturer, one of RunSafe’s customers. Implementing RunSafe’s runtime code protection saved the company over $1 million per year, with reduced patching representing the largest cost saving. 

Calculate your potential Total Cost of Ownership here.

Being proactive about security (deploying RunSafe Protect) rather than reactive (relying on patching) saved this company a significant amount of money. And it’s not just money. It’s also about opportunity cost.

The hidden costs of reactive security include:

• R&D Resource Drain: Effort is put into code scanning/review, penetration testing, subsequent remediation, and then coordinated release of patches to customers. These issues spawn lengthy retesting cycles and gobble up R&D resources that would otherwise be able to work on new features and products.
• Market Access Barriers: Companies lose significant contracts when their security posture can’t meet customer requirements. Consider how Zoom was initially excluded from certain DoD environments due to its security posture not meeting baseline requirements.
• Developer Productivity Loss: Engineering teams spend 30-40% of their time on security remediation instead of innovation.

Competitive Disadvantage: Slower release cycles compared to competitors, who ship features faster with built-in security.

Are You Spending to Patch or Investing to Prevent?

The problem with scan-and-patch security is inefficiency and ineffectiveness. For example, in our work on embedded devices, we see on the daily that memory safety vulnerabilities account for 40-70% of identified vulnerabilities in embedded code. 

A study by North Carolina State University shows that for Linux operating system software over a 10-year period, only 2.5% of memory vulnerabilities were identified in vulnerability scanning tools. This shows us that scanning, a widely adopted practice, leaves one vulnerable.

Similarly, multiple studies say companies and users generally aren’t patching on time due to a lack of knowledge, the effort to coordinate change, the process slowing progress, fear of breaking the current setup, and other barriers. At its best, patching is reactive. More often, costs and other barriers mean patching is delayed, if done at all.

Even when vulnerabilities are found, patching faces massive barriers:

• Coordination Costs: Cross-team alignment, testing cycles, and deployment logistics
• Customer Resistance: Nobody wants to patch, especially when it might break existing functionality
• Timing Mismatches: Critical vulnerabilities discovered right before major releases
• Risk Accumulation: Delayed patches create growing attack surfaces

The math is brutal. If you’re patching reactively, you’re not just paying for the patch—you’re paying for the disruption, the delays, the testing cycles, and the opportunity costs of having your best engineers chasing down someone else’s vulnerabilities instead of building your next breakthrough feature.

The Runtime Security Advantage

Here’s where the economics flip completely. Runtime security—integrating code protection directly into your development process—transforms security from a margin killer to a competitive advantage.

RunSafe’s approach demonstrates this transformation. RunSafe Protect eliminates an entire class of vulnerability common in embedded software to defend your software from the very beginning and dramatically reduce your attack surface. Protect safeguards your systems during runtime without compromising performance or requiring post-deployment modifications.

The results speak for themselves. RunSafe deployed code protection to dramatically reduce the attack surface by 70% for an industrial automation leader deploying HMI products. The company was able to measurably reduce risk and protect software in very difficult-to-update facilities within critical infrastructure.

Understand the total exposure of your embedded software and quantify your risk reductions with RunSafe Protect. Give your code a scan.

The broader business impact includes:

• Faster Time-to-Market: No more security-driven delays in release cycles
• Predictable Operations: Controlled patch timing instead of emergency responses
• Enhanced Customer Relationships: Fewer disruptions, more reliable products
• Engineering Focus: Teams building features instead of fixing vulnerabilities
• Market Differentiation: Security as a selling point, not a compliance checkbox

Security as a Revenue Driver

Beyond cost savings, the right security approach actually opens new revenue streams. Companies with robust security profiles win contracts that others can’t touch. In RunSafe Security’s 2025 Medical Device Cybersecurity Index, we saw that 83% of healthcare organizations now integrate cybersecurity standards directly into their RFPs and 46% have declined to purchase medical devices due to cybersecurity concerns. A lack of security quickly leads to lost revenue in this competitive market. 

On the other hand, it opens the door to increased product line profitability. 79% of healthcare buyers are willing to pay a premium for devices with advanced runtime protection. Similarly in the automotive industry, RunSafe’s 2025 Connected Car Cyber Safety & Security Survey, 87% of survey participants said a car brand that offers strong cybersecurity and privacy would influence their purchase decision, with 35% willing to pay more.

Customers are saying security is worth the cost. That’s good news for product teams looking to make smart investments.

The Bottom Line

Security doesn’t have to be a necessary evil that drains profitability. When implemented early, systematically, and with business impact in mind, security becomes a competitive advantage that drives margin improvement and sustainable growth.

The companies that figure this out first will have operational advantages their competitors can’t match: faster development cycles, lower operational costs, stronger customer relationships, and access to markets that others can’t reach.

Can you afford to keep subsidizing reactive security approaches that are killing your margins and slowing your growth?

See how runtime security can transform your product line profitability. Calculate your potential ROI with RunSafe Protect or schedule a call with our team to discuss your specific business impact.

The post Is Your Security Helping or Hurting Your Product Line Profitability? appeared first on RunSafe Security.

Recently, Andy joined us for a discussion on defending against software supply chain risks and how Schneider Electric is tackling a hidden crisis in ICS/OT security. What he shared confirmed what many in the industrial security space have suspected but lacked the data to prove. While organizations focus heavily on perimeter security, the most dangerous threats are often already embedded within their systems.

Memory Safety: The Root of Industrial Software Supply Chain Attacks

Memory safety is a topic Andy has been interested in for awhile, but it came time to prove just how significant—or not—the issue really was. Looking at all of the publicly disclosed vulnerabilities Schneider Electric had across project lines, Andy found that “memory safety was easily the largest percentage of recorded security issues that we had.”

94% of these weaknesses come from third-party components. Though that number is eye-opening, it’s not as surprising as you might think. Products today contain a significant amount of third-party or open source code.

Now, it’s important to note that this isn’t just an isolated case. We know that motivated threat actors, like Volt Typhoon and Salt Typhoon, are targeting critical infrastructure. We also know that they are using both known memory-based vulnerabilities and zero days to do so. 

Consider the infamous Urgent 11 vulnerabilities that affected countless industrial control systems. Six of those eleven vulnerabilities were memory-based, and they provided attackers with significant leverage to compromise devices across multiple industries and vendors.

Memory safety vulnerabilities are widespread in software, and they are in your software supply chain too.

The Asymptotic Security Problem

Andy Kling brilliantly articulated what I consider the fundamental challenge in securing industrial systems: “We have to shift left and find out where we can improve in our own processes. But it’s also asymptotic, meaning more and more effort is going to go in to find fewer and fewer of these things.”

This asymptotic security curve means that traditional approaches yield diminishing returns. You can invest millions in better static analysis, more thorough testing, and improved development practices, yet still miss critical vulnerabilities. This isn’t to say these practices aren’t valuable—they absolutely are—but they’re insufficient on their own.

For example, some reports suggest that static analyzers for C/C++ miss 47%–80% of real vulnerabilities. Think about that: the tools we rely on for security validation are missing a significant scope of potential vulnerabilities.

This challenge is compounded by the staggering scale of industrial software. During our panel, Andy revealed that just one Schneider Electric system contained approximately 20 million lines of code—and that doesn’t even include the operating system underneath. Across their entire product portfolio, they estimate half a billion lines of code. In such vast codebases, vulnerabilities are inevitable.

The traditional approach to this problem—finding bugs and patching them—breaks down in industrial environments for several reasons. First, patches take time to develop, test, and deploy. Second, many asset owners can’t afford downtime for updates or are running critical systems that simply can’t be taken offline. Third, equipment can remain in operation for decades, far beyond standard support lifecycles.

The reality is we can’t rewrite all legacy code, and we can’t patch our way out of this problem.

A Strategic Framework for Embedded Security

To address these challenges, we need a comprehensive approach that considers the entire lifecycle of embedded systems. Andy proposed a framework organized around “time windows” for security interventions:

• Design time: Making architectural decisions that prioritize security from the start
• Implementation time: Using secure coding practices and memory-safe languages where possible
• Compile time: Leveraging compiler tools and flags that enhance security
• Load time: Implementing protections as programs are loaded into memory
• Runtime: Detecting and preventing exploitation attempts in real-time
• Support time: Analyzing field data to identify and address potential security issues

This multi-layered approach acknowledges that no single intervention is sufficient. By considering security at each phase, organizations can build defense-in-depth strategies that significantly raise the cost and difficulty for attackers.

As Andy put it: “You have a strategy here today that allows you to achieve that vision that you have for 10 years from now. And that’s that’s the seat I’m sitting in right now, and that’s why I’m talking with RunSafe, and why I’m working on it on these other approaches.”

Innovation in Memory Protection

While addressing memory safety in the software supply chain is a challenge, we’re not without options. Several innovative approaches can help address memory safety issues without requiring complete code rewrites:

Memory-safe languages like Rust and Go offer significant security improvements, but adoption in embedded systems remains challenging due to legacy constraints, performance requirements, and the sheer volume of existing C/C++ code.

Hardware-based approaches such as ARM’s Memory Tagging Extension (MTE) and Intel’s Control-flow Enforcement Technology (CET) show promise, but implementation across diverse industrial hardware ecosystems will take time.

Load-time Function Randomization (the technology we’ve developed at RunSafe) moves code around in memory every time a program runs, preventing attackers from reliably exploiting memory vulnerabilities even when they exist in the code.

What’s particularly exciting about these newer approaches is that they change the fundamental economics of cyber warfare. Rather than playing an endless game of vulnerability whack-a-mole, these technologies make exploitation prohibitively difficult and expensive for attackers, even when vulnerabilities exist.

Action Plan for Industrial Organizations

So how should industrial organizations approach this challenge? Based on our work with clients across critical infrastructure sectors, here are key recommendations:

1. Conduct a Risk Reduction Analysis to identify your most critical systems and components, focusing particularly on those with memory safety implications. Understand where your key vulnerabilities lie and prioritize protection efforts accordingly.
2. Have frank conversations with vendors about their approach to memory safety and supply chain security. Ask specifically how they’re addressing vulnerabilities in third-party components and what runtime protections they provide.
3. Implement a defense-in-depth strategy that includes both preventative measures (improved coding practices, memory safety) and runtime protections that can mitigate vulnerabilities even when they exist.
4. Make the business case for memory safety investments by focusing on the consequences of compromise. As Andy explained: “You have to understand the likelihood is high, the potential is high. So let’s talk about consequences. And now you have an informed conversation where you can decide how to approach it.”
5. Balance security with operational requirements. The best security solutions for industrial environments are those that provide protection without disrupting operations or requiring massive code rewrites.

ICS/OT Security That Gets Ahead of Supply Chain Risk

The security challenges facing industrial control systems and operational technology are significant, but they’re not insurmountable. By addressing memory safety as a root cause rather than just the symptoms, organizations can dramatically improve their security posture against both current and future threats.

As Andy showed, even organizations with massive legacy codebases can make meaningful progress by adopting a strategic, multi-layered approach to security. The key is understanding where your risks lie and implementing protections that work with, rather than against, the realities of industrial environments.

The attackers targeting our critical infrastructure are sophisticated, well-funded, and persistent. But by changing the economics of exploitation through innovations in memory protection, we can ensure that the cost of attacking these systems far exceeds any potential benefit.

That’s a future worth building—one where critical infrastructure is resilient by design, and where attackers seeking to disrupt essential services find themselves facing an insurmountable challenge. Securing embedded systems isn’t just about technology, it’s about protecting the systems that power our world.                                     

The post Securing the ICS/OT Software Supply Chain: What Schneider Electric’s Discovery Means for Industrial Systems appeared first on RunSafe Security.

The Urgency of Space Security

Space assets, from satellites to ground stations, are integral to defense and civilian operations. With the global space economy projected to exceed a trillion dollars by 2030, the risk of cyberattacks becomes a pressing concern. Events like Russia’s cyberattack on Viasat during the Ukraine war demonstrate how adversaries can target satellites to erode confidence and disrupt infrastructure.

However, space infrastructure remains vulnerable due to limited cybersecurity regulations and the logistical challenges inherent in space operations. Protecting these assets from emerging space threats is essential to maintain national security, economic stability, and the continuity of essential services worldwide.

The primary cyber threats to space assets include attacks on ground stations and on-orbit systems. Ground stations are more accessible targets, but satellite attacks can have far-reaching implications, disrupting military and civilian networks. Threat actors exploit weaknesses in both software and hardware, with ransomware and platform-level compromises posing significant risks.

Satellite Command & Control Systems, spacecraft navigation systems, remote sensing and telemetry systems, and more are all examples of critical systems that could be targeted in an attack.

1. Attacks on Ground Stations: Ground stations represent a vulnerable entry point for adversaries. A recent example is Russia’s pre-invasion cyberattack on Viasat, which disrupted Ukrainian communication systems. Breaking satellite-ground communication links can lead to loss of satellite control, interruptions to data transmission, and navigation errors.
2. Orbital Interference: Adversaries have demonstrated the ability to threaten satellites in orbit. Recently, concerns have been raised with Russia’s Luch/Olymp satellites, which exhibit unusual movement patterns that raise the  potential for monitoring or interference with other satellites’ operations and the potential for direct orbital attacks.
3. Compromise of the Supply Chain: The increasingly globalized and commoditized nature of the space supply chain introduces new vulnerabilities. Malicious actors can target the development environments, manufacturing processes, or the software supply chain to infiltrate space systems through compromised hardware or software. Even subtle changes in manufacturing code could compromise the integrity of critical components, with the potential for catastrophic failures.
4. Malware: Attackers can upload malware to satellite terminals, giving them control over devices or disrupting communications.
5. Source Code-Level Attacks: Sophisticated cyber threats like the SolarWinds attack demonstrate the risk of attacks at the source code and platform level, potentially compromising the trust and integrity of space systems.

To counter these threats, the security community must prioritize trusted, secure communication channels and reliable updates for satellite functions. Ensuring trust in AI-driven processes and machine-learning functions is another growing challenge as these technologies become central to satellite operations.

Unique Challenges to Security in Space

Unlike terrestrial systems, space assets face constraints that complicate security implementations. Solutions must avoid adding excess power consumption, weight, or cost to satellites while still providing robust protection.

Additionally, it’s very difficult to update space systems once they are launched. Security needs to be done right from the get-go. Once an asset is in space, it’s a foregone conclusion. Because of this, it’s imperative to consider implementing runtime protection to defend space assets even after they are operating in orbit.

RunSafe’s Advantage in Space Cybersecurity

RunSafe Security’s technology offers an innovative solution by providing software hardening for satellite systems without additional hardware requirements. This approach maintains operational efficiency, making it highly suitable for space applications. By focusing on software resilience, RunSafe extends the operational life of satellites, a critical advantage when assets in orbit lifespan should be extended to boost the return-on-investment.

RunSafe’s solutions bring unique operational benefits to space systems:

• Hardware-Free Security: RunSafe’s software-based approach enables satellite resilience without additional hardware, making it a cost-effective option that aligns with the operational constraints of space.
• Support of Open Source Software: RunSafe protects open source software deployed as docker images or containers that allow for the swapping and repurposing of satellite software, minimizing the risk of cyber incidents while enhancing mission flexibility. This adaptability is crucial in a landscape where customized solutions tied to hardware often incur prohibitive costs and lack ability to repurpose to meet new missions.

These capabilities make RunSafe an ideal partner for entities focused on extending the lifespan and robustness of space assets without compromising weight, power, or cost.

Public-Private Collaboration in Space Security

As government and commercial entities increasingly share responsibility for space infrastructure, a closer public-private partnership is necessary to ensure cohesive cybersecurity measures. The Space ISAC, a bridge between industry and government, plays a vital role in this collaboration. The Space ISAC helps coordinate responses to threats like orbital anomalies or cyberattacks through threat intelligence sharing and real-time monitoring.

However, collaboration must extend beyond monitoring. Industry standards, developed through cooperation between agencies and private companies, are critical to building a secure framework for space operations. Trusted information-sharing platforms like the Space ISAC’s Watch Center exemplify the proactive approach needed to protect our space infrastructure.

Moving Toward Effective Regulations and Standards

Current space policy directives encourage, but do not mandate, cybersecurity for space assets. This gap in enforceable regulations leaves many companies needing clear guidance, risking vulnerabilities that adversaries could exploit. Evolving best practices offer a flexible path forward, enabling companies to adopt measures tailored to their specific needs without the rigidity of static regulations.

Meanwhile, organizations like IEEE are working toward defining baseline standards for space cybersecurity, ensuring that space infrastructure can withstand the evolving cyber landscape.

As space becomes recognized as a critical infrastructure domain, protecting it from cyber threats is imperative. RunSafe’s innovative approach, focusing on adaptable, hardware-free security, offers a path forward that addresses the unique constraints of space operations. However, effective protection requires more than technology; it demands collaboration across public and private sectors, unified standards, and a proactive stance on cybersecurity.

Through partnerships with organizations like the Space ISAC and forward-looking policies, we can ensure that space assets remain secure, resilient, and capable of supporting global stability in the decades to come. In the race to secure space, now is the time to act.

For those in the industry, cybersecurity, or policy-making, the time to prioritize space security is now. Join us in advancing solutions that protect our orbital assets and ensure a safer, more resilient future in space.

The post Securing Space as the Next Frontier of Critical Infrastructure appeared first on RunSafe Security.

As we move forward into 2025, this focus is extremely promising for the future. We see change all around us and uncertainty in every arena. However, forward momentum is what we need to build more resilient products that can stand the test of time. 

Looking ahead, here are five predictions on how product security will evolve in 2025.

View the five predictions as an infographic here.

1. 200 More Companies Will Pledge Their Commitment to Secure by Design

As of December 2024, 256 companies have already signed CISA’s Secure by Design pledge, including companies like Cisco, IBM, Google, and Microsoft. RunSafe Security has also signed the pledge, which includes seven goals for software manufacturers to work toward to improve the security of their products. 

Secure by Design will certainly shape the future of product security and development for decades to come. We’re already seeing the effects with notable signees detailing their progress toward the pledge goals. Overall, Secure by Design will continue to encourage software manufacturers to focus on areas like software supply chain security and memory safety to reduce the risks to and attack surface of embedded devices. As we at RunSafe emphasize, we want to reshape the economics of security to favor defenders. Secure by Design helps to make this possible by focusing on security from the earliest stages of design and development, and we believe hundreds more companies will take up the challenge in the year ahead.

2. Asset Owners Will Begin to Demand Secure by Design

Product security is on the minds of manufacturers, but what about the buyers of software who deploy these products within their organizations and across critical infrastructure? 

As we look ahead to next year, software buyers will begin to get curious about their software supply chain and the steps their vendors are taking to reduce risk within their products. As part of this, asset owners should ask suppliers to provide Software Bill of Materials (SBOMs) to gain insight into potential exposures and vulnerabilities within software across asset owner infrastructure.
One example of an area for asset owners to focus on is CISA’s Roadmap to Memory Safety, which urges software manufacturers to publish a memory safety roadmap by January 1, 2026. Asset owners can use the memory safety roadmap as a starting point to talk with suppliers and discuss how they will approach eliminating this class of vulnerabilities.

3. Product Liability Will Come Into Focus

While Secure by Design and other CISA guidance is voluntary, as more organizations adopt these principles, there is a strong possibility that approaches to  product liability and cyber insurance within the software industry will begin to shift. Though it would be surprising to see a new executive order on critical infrastructure and product liability issued in 2025, we are seeing an immediate response to the EU Cyber Resilience Act.  Perhaps the market will seek to  increase cybersecurity warranties, guarantees, and insurance.

As software manufacturers take on more of the security burden, the way liability is distributed between suppliers and their customers in the event of a security incident will change. Device manufacturers will need to consider what the liability shift means for their business and adopt a new financial perspective to address downside liability.

4. Software Manufacturers Will Prioritize Immediate Solutions for Memory Safety

A key aspect of Secure by Design guidance issued by CISA is memory safety, and it plays a critical role in the overall security of embedded devices. Yet for many, memory safety is not as achievable by simply rewriting products..

Going into 2025, we expect an alternative  to memory safe languages to enter more prominently into the product security discussion. Although Secure by Design guides device manufacturers to rewrite all of their C and C++ software into a memory safe language like Rust, doing so would take decades and require a significant expenditure of resources and human power to accomplish. For companies who produce dozens or hundreds or even thousands of embedded software products  deployed across critical infrastructure (often with 10-30 year lifespans), it is neither feasible nor practical for them to simply rewrite all their products in memory safe languages. Not doing so, however, leaves the door open for attack in the near term.

For this reason, it’s important that software manufacturers insert memory protections, such as load-time function randomization,  intoexisting devices today rather than wait the time it would take to rewrite code. Commercial solutions, like RunSafe’s Protect solution, already exist to provide immediate protection and prevent the exploitation of devastating memory safety vulnerabilities.

5. Companies Will Become More Transparent in Sharing SBOMs

High-profile software supply chain attacks like SolarWinds and Log4j spurred the need for organizations to have visibility into their software components. SBOMs emerged as a tool for managing and mitigating software supply chain risks.

For companies that are committed to Secure by Design and product security best practices, we believe there is great value in publicly sharing SBOMs or sharing SBOMs between asset owners and suppliers. Doing so signals honesty and transparency in software development practices and makes it easier to understand where potential vulnerabilities lie.

Advancing the Resilience of Software in the Year Ahead

2025 is shaping up to be a big year for product security and the implementation of Secure by Design. We can be certain that nation-states, adversaries, and APTs will continue to target the software supply chain. I remain optimistic that software manufactures, software buyers, and the cybersecurity industry on the whole can work together to advance the resilience of software deployed in embedded devices to safeguard critical infrastructure and our world.
Learn more about best practices for safeguarding code. Download our guide to get the knowledge and tools you need to address memory safety challenges and protect your code today and into the future.

The post RunSafe Security’s 2025 Product Security Predictions appeared first on RunSafe Security.