RunSafe Security and Lynx are partners in securing embedded software platforms.

For too long, open source vulnerability management has been treated as a reactive game of whack-a-mole: identify vulnerabilities, patch them, and repeat. This approach often leaves teams overwhelmed and constantly playing catch-up. 

What if we flipped the script? Vulnerabilities aren’t just problems—they’re signals. They reveal weaknesses, highlight opportunities, and guide better decisions. By treating vulnerabilities as feedback rather than failures, you can rethink how embedded systems in industries like aerospace, automotive, industrial automation, and medical devices are designed and secured. 

In this article, we explore five transformative strategies for addressing open source vulnerabilities that go beyond traditional practices, helping you move from firefighting to future-proofing your systems.

1. Redefine Your Relationship with Vulnerabilities

Most teams view vulnerabilities as failures, reacting only when an issue is discovered. But vulnerabilities are more than just bugs—they’re data points. When properly analyzed, they offer insight into design choices, team processes, and system architecture, providing an opportunity for improvement. 

How to Leverage Vulnerabilities as Feedback 

• Refine your software architecture: Use your SBOM (Software Bill of Materials) as a diagnostic tool. Are recurring vulnerabilities tied to a particular library or dependency? Consider switching to better-maintained or less vulnerable alternatives. 
• Understand system dynamics: Track patterns across projects and teams to identify development blind spots. 

Real-World Application:
Imagine an automotive team that regularly identified vulnerabilities in a third-party diagnostic library. By switching to an open-source alternative with a more active community, they reduced vulnerabilities by 40% and enhanced system reliability. 

This proactive approach fosters confidence in your processes, ensuring continuous improvement. 

What is an SBOM (Software Bill of Materials)? SBOMs are a list of all components in a software build, including libraries and dependencies, which helps teams identify and track vulnerabilities systematically. 

Understanding the full scope of an SBOM enables more informed decisions about system modifications and vulnerability management strategies, leading to more secure software architectures.

2. Embed Resilience Instead of Chasing Compliance

Compliance frameworks like DO-326A (aerospace cybersecurity), ISO/SAE 21434 (automotive cybersecurity), and NIST Cybersecurity Framework provide a baseline for secure systems. But achieving compliance shouldn’t be the end goal—it’s the beginning. Resilience is about building systems that remain secure even as threats evolve, ensuring compliance is naturally met as a byproduct. 

How to Build Resilience That Meets Compliance 

• Design with failure scenarios in mind: Use threat modeling to identify potential attack vectors early during development. 
• Automate compliance reporting: Tools like Lynx Vigiles simplify audit preparation, allowing teams to focus more on security instead of documentation. 

Pro Tip:
Treat compliance as a checkpoint, not a destination. Teams that embed cybersecurity into their workflows achieve compliance faster and with fewer reworks. 

Threat modeling: Identifying potential security threats to the system and developing countermeasures to prevent or mitigate these threats.

3. Focus on Vulnerability Paths, Not Just Individual Flaws

Attackers don’t exploit single vulnerabilities in isolation; they look for exploit paths—chains of vulnerabilities that can lead to system failure. Addressing how open source vulnerabilities interact within your system can stop attacks before they start. 

How to Identify and Break Exploit Paths 

• Map dependencies: Visualize how different components interact and assess how vulnerabilities in one might expose others. 
• Prioritize by context: What may be a low-severity issue in an industrial control system could be critical if it enables lateral movement to safety-critical functions. 

Example:
In an industrial automation system, a minor flaw in a third-party networking library allowed attackers to bypass authentication. Fixing this vulnerability preemptively protected safety-critical systems. While the flaw might not have drawn much attention in isolation, its potential impact within a chain of vulnerabilities highlighted its true risk. 

Power Move:
Integrate RunSafe Security’s memory address randomization to protect against memory-based attacks, common in exploit paths. This technique, applied during the software compilation process, randomizes the layout of memory addresses within a program. By making the memory structure unpredictable, it significantly impedes attackers’ ability to craft exploits that rely on known memory locations, thereby neutralizing a substantial portion of memory corruption vulnerabilities. 

Mapping dependencies and breaking exploit paths: This strategy involves visualizing the interconnections between software components to identify and disrupt sequences of vulnerabilities that could be chained together by an attacker, thereby preventing a single weakness from compromising the entire system.

4. Shift Vulnerability Ownership Across the Organization

Vulnerability management is often confined within security or DevSecOps teams. However, for a system to be secure, everyone—developers, product managers, and leadership—must share responsibility. Security is a business-critical priority, not just a technical concern. 

How to Foster Organizational Ownership 

• Set team-level goals: Include vulnerability remediation and time-to-resolution as part of team OKRs and KPIs. 
• Invest in security training: Equip all team members with the knowledge to identify and mitigate vulnerabilities early. Think of it as the equivalent of educating your team not to plug in random USB sticks found in the wild, except for open source vulnerabilities. 

Pro Tip:
Make vulnerability metrics visible across the organization to encourage collaboration. Teams that understand their impact on overall security are more motivated to act. This shared responsibility leads to a quicker resolution of vulnerabilities, reducing the window of exposure and enhancing overall system security.

5. Use Automation to Do the Heavy Lifting, but Keep Humans in the Loop

Automation is essential for managing the sheer volume of vulnerabilities in modern embedded systems. But tools alone aren’t enough. Strategic oversight ensures that fixes align with business goals, technical feasibility, and long-term resilience. 

How to Combine Automation with Expertise 

• Automate triage: Use tools like Vigiles to filter out non-applicable vulnerabilities, focusing your team on critical issues. 
• Enable smarter decisions: Human judgment is critical for balancing security with operational needs, especially in safety-critical industries. 

Example:
An aerospace company used automated scanning with basic filters and faced over 1,000 vulnerabilities. Enhancing these filters with additional context and capabilities, such as with Vigiles, they saw half automatically marked as non-applicable. This effective triage cut their potential workload in half and allowed them to thoroughly assess high and critical severity vulnerabilities impacting system safety, saving weeks of manual effort and unnecessary remediation. 

Including RunSafe Security’s runtime memory protection during the compilation process drastically lowers the risks associated with common memory vulnerabilities, allowing security teams to focus on more complex threats. 

These approaches not only optimize resource allocation but also enhance the accuracy and relevance of vulnerability management efforts, leading to a more resilient system. 

The Cost of Inaction: Addressing Open Source Vulnerabilities 

Neglecting to adopt proactive strategies for open source vulnerability management comes at a high cost: 

• Missed deadlines: Vulnerabilities discovered late disrupt production schedules. 
• Compliance failures: Inadequate processes expose teams to regulatory penalties. 
• System compromises: Unchecked exploit paths can lead to catastrophic consequences. 

Every delay in addressing vulnerabilities isn’t just a technical risk—it’s a threat to your mission, your reputation, and your bottom line.

Conclusion: Security as a System 

Rethinking open-source vulnerability management is about more than fixing issues—it’s about designing systems that are secure by default. By redefining your relationship with vulnerabilities, embedding resilience, focusing on exploit paths, fostering organizational ownership, and leveraging automation, you can move from firefighting to future-proofing your embedded systems. 

Take the next step today: 

• Don’t wait for open source vulnerabilities to disrupt your operations. Cut through the noise with Lynx Vigiles and focus on the vulnerabilities that matter most. 
• Discover RunSafe Security’s runtime protection to neutralize vulnerabilities before attackers can take root.

The post Rethinking Open Source Vulnerability Management: 5 Strategies to Build Resilience in Embedded Systems appeared first on RunSafe Security.

Ensure Your Open Source Software Usage Won’t Make You the Next Cybersecurity Victim

Software Vulnerabilities Within Your Supply Chain

Finding Potential Software Supply Chain Risks in Code Repositories

RunSafe Can Keep Your Supply Chain Secure

Open source software is widely used across various industries and applications. Some developers estimate that more than 80% of the code in a software delivery is open source code. Open source code is helpful for developers because it can be more efficient to reuse code and reduce the amount of work needed to be done.
In many cases, open source software is more secure than proprietary software. This is because a broader set of contributors are testing and fixing code without limiting budgets that may affect the code quality of proprietary software. With that said, not all open source software is mature let alone secure. As such, it is also imperative to thoroughly understand the open source software used your products can pose security risks, if not tracked and monitored.

Software Vulnerabilities Within Your Supply Chain

Hackers are able to find any open source software repository used within an application with ease through platforms such as GitHub and GitLab.

As a result, hackers are able to analyze and attack areas of vulnerability. Understanding how to mitigate this risk is critical in order to prevent hackers and maintain the integrity and security of open source software. 

At RunSafe Security, we wanted to understand the levels of maturity of open source software and the potential areas of risk while recommending ways to protect your software assets—all without breaking the bank.

Finding Potential Software Supply Chain Risks in Code Repositories

We set out to analyze several open source code repositories across GitHub and GitLab and understand factors that could identify potential risk in code. Our preliminary research shows that some of the numerous risk factors include the contributors, date/age of the software, and the geographic location from which a contributor works.

Our Initial Hypothesis

Using ParseHub, a web crawling tool, we collected data from over 450 repositories. Our initial hypotheses including the following:

1. Individuals that have contributed code to open source software for many years are much more trustworthy than those who have recently joined. This is due to the fact that they have been with the software for many years and most likely do not intend to create any potential vulnerabilities. Furthermore, these contributors have a track record of delivering code without nefarious intent.
2.  Repo contributors that include their location and company can be observed to be more reliable, specifically if the company is one of which is reputable or well known. As an example, some contributors mentioned that they worked for Red Hat or Microsoft, both reliable and notable companies.
3. If a repository has versions that are consistently released, the repository can be seen to be more secure as constant updates are being made. These updates allow for any issues and vulnerabilities to be solved, reducing the amount of risk in the open source software.
4. Repositories with a high amount of stars can be seen to be more reliable with practically fewer vulnerabilities. This is due to the fact that a multitude of people are following the repository and are interested in it. Thus, the repository is usually more credible.
5. The date of the last commit can also aid in recognizing vulnerabilities. A repository that has been updated recently can be seen to be active in use with contributors continuing to develop itIn contrast, repositories that were last committed years ago are more likely to have vulnerabilities and hackers attack them. This is due to the fact that there are not constant updates being made of the repositories and the code is staying the same, prompting hackers to find and attack areas of vulnerabilities.

Overall Findings

Our data findings suggest software maturity practices and maturity are helpful to understand but likely insufficient to predict where attacks could come from.

• Most repositories with a high number of stars also had a high watch count and fork count. In addition, many of them had multiple versions.
• A large number of the repositories with over a thousand stars had commits dated recently. Comparatively, their repositories with fewer than 1,000 stars typically had their last commit several months if not years ago.
• All of the repositories had fewer than 800 contributors. The number of contributors did not seem to have a large effect on other factors, such as the star count. There were many repositories that had a few contributors, fewer than 5 in some cases, but still had a large star count.

How to Protect Your Software Supply Chain

Overall, our efforts to understand risk within your software supply chain led us to find straightforward ways to protect your software, including:

• Build from a trusted repository and verify you are working from the same version published by the open source repo.
• Add software hardening into your builds when you are using open source software. By using RunSafe technology, for example, you can eliminate the exploitation of an entire class of vulnerabilities – namely memory-based vulnerabilities—so that you are protected even if a vulnerability exists and a fix is not available.
• Update your software versions on a regular basis. Yes, it is expensive to update software because changes may impact other components and may necessitate additional testing and compatibility checks, but the alternative is to chase your tail after an attack. Notably, you can add protections in with RunSafe to help smooth out when these updates need to be applied because you will often be protected from the most devastating and common types of attacks (memory-based ones) on open source software.

RunSafe Can Keep Your Supply Chain Secure

In conclusion, open source software has tremendous benefits operationally and security-wise. However, you need to monitor your entire software supply chain to reduce risk of exploitation. Though there are indicators that will help you avoid some attacks, adding security protections to guard against memory-based exploits should be used so you can streamline your software development processes and your security practices. 

The post Ensure Your Open Source Software Usage Won’t Make You the Next Cybersecurity Victim appeared first on RunSafe Security.

• Greg Kurtzer, CEO of Ctrl IQ, original CentOS author, and founder and creator of Rocky Linux, a community-driven effort to offer enterprise-grade, production-ready Linux
• Brad LaPorte, former analyst at Gartner, a technology research and consulting company
• Doug Britton, CTO of RunSafe Security, a solution that immunizes software from cyber attacks and disrupts bad actor economics without developer friction

Linux Open Source Software Evolutions Can Leave You Vulnerable

Linux is a prevalent component of nearly every workload: more than 90% of cloud workloads and 70% of web servers run on it. Like all technology solutions, Linux has continued to evolve over time, potentially opening you up to new cyber security threats. Bad actors often have an advantage because they are working against known security measures and the cloud has made it easier to share information on successful entry points. That means it’s vital you stay on top of known and potential vulnerabilities.

LaPorte offered some sobering data when commenting on how the security landscape has changed:

• Malware families alone have grown 40% year over year since 2019 and 500% over the past decade.
• The IBM Exforce Threat Intelligence Index shows exploits are now the main attack vector, bumping phishing from its decade-long run as the #1 entry point.
• Somewhere in the past 30+ years, Linux went from “secure by default” to showing up in the breadcrumbs of more than 90% of software security breaches.

Despite the obvious rise in bad actors exploiting vulnerabilities in Linux operating systems, the increase can’t be chalked up to any brand new techniques—buffer overflows are still the biggest threat. What has changed, according to Kurtzer, is the sheer scope of this popular open source software, which leads to additional entry points and increased risk. Containers compound these vulnerabilities, allowing user spaces to be packed up and moved around independently of the core operating system.

According to Kurtzer, two big container missteps that can reduce security are: not having good provenance that allows you to see where the containers come from, and the byte rot associated with continuous deployment without management, updates, or visibility.

With Linux driving more workloads that run the cloud, it’s important to remember that the same types of attacks work across containers, cloud-based systems, and physical servers. As Kurtzer noted, the cloud often provides a double threat to security, making cyber security attacks more effective and easier to scale while simultaneously making the job of effectively monitoring and managing entry points more difficult.

Addressing Vulnerabilities in Open Source Software

Risk is directly related to how much visibility you have into the depths of your software. The nature of open source software means people not employed by you or your company have the ability to submit code, which in turn means you could be blind to risks contained within it. Put plainly, what you don’t know can hurt you.

Distilling down to the essentials, Britton offered two key questions that can help determine your level of risk:

• Do you have a complete bill of materials for your software, including open source? Being able to see and explain the purpose of every piece of code in all of your software helps you lay the foundation for understanding and mitigating vulnerabilities.
• Do you have visibility into the kind of malicious activity each type of code is vulnerable to? The web app on top of the stack might be the easiest to notice, but the compiled code and aspects of an operating system that exist underneath it constitute latent risks.

These questions get to the heart of why visibility is so vital—because bad actors are always trying to get one level below where your software security efforts are located. That means that attacks are progressively moving farther down the stack while a lot of focus has been on the surface level like antivirus protection, multi-factor identification, and Linux-based solutions for endpoint protection.

LaPorte noted that most industry solutions are almost the inverse of how software security should work. He and Britton both agreed that traditional security methods have huge gaps and the focus should be on hardening the software to prevent changes and stop attacks at the code level.

“Too many times, we’ve seen people think that because they’ve tied off one layer that vulnerabilities elsewhere in the stack just don’t matter,” said Britton. “And what I think that history has shown us that it’s a bit of a naive assumption because bad actors are good at taking your assumptions and turning them on their ear. Being able to provide that hardening for everything that is in memory is essential.”

RunSafe Builds in Software Security from the Bottom Up

RunSafe Security’s patented Alkemist technology helps secure software during the build, leveraging both Moving Target Defense (MTD) and Runtime Application Self-Protection (RASP) techniques to prevent bad actors from weaponizing vulnerabilities. According to both Kurtzer and Britton, MTD models are proving to be incredibly helpful in mitigating buffering overflow attacks by removing predictability. RunSafe Security and CIQ have teamed up to integrate RunSafe’s Alkemist:Code technology within CIQ’s platform.

Now, cyber hardening technologies offered by Alkemist:Code are available to Rocky Linux users with no extra effort. The virtually unbreakable code won’t slow down development or runtime speeds and offers new ways to leverage containers for security. By adding RunSafe’s Alkemist: Code into a build, Rocky Linux users effectively bake in the most advanced cybersecurity protection tools that will move with that container wherever it goes.

In addition, access to the mighty but easy-to-use Alkemist: Code means that Rocky Linux users can take advantage of protections while maintaining accessibility for those who don’t have decades of expertise in open source software security, making it a truly turnkey solution that mitigates vulnerabilities from the bottom up.

As the Linux landscape evolves, software security is getting harder. Learn from expert panelists how you can identify software security vulnerabilities and implement security protections, in this webinar.

FAQ:

How has the security landscape changed?

• Malware families alone have grown 40% year over year since 2019 and 500% over the past decade.
• The IBM Exforce Threat Intelligence Index shows exploits are now the main attack vector, bumping phishing from its decade-long run as the #1 entry point.
• Somewhere in the past 30+ years, Linux went from “secure by default” to showing up in the breadcrumbs of more than 90% of software security breaches.

How do you determine your level of risk?

• Do you have a complete bill of materials for your software, including open source? Being able to see and explain the purpose of every piece of code in all of your software helps you lay the foundation for understanding and mitigating vulnerabilities.
• Do you have visibility into the kind of malicious activity each type of code is vulnerable to? The web app on top of the stack might be the easiest to notice, but the compiled code and aspects of an operating system that exist underneath it constitute latent risks.

How can you easily prevent software vulnerabilities?

Now, cyber hardening technologies offered by Alkemist:Code are available to Rocky Linux users with no extra effort. The virtually unbreakable code won’t slow down development or runtime speeds and offers new ways to leverage containers for security. By adding RunSafe’s Alkemist: Code into a build, Rocky Linux users effectively bake in the most advanced cybersecurity protection tools that will move with that container wherever it goes.

The post Prioritizing Software Security in the Changing Linux Landscape appeared first on RunSafe Security.

• Jonathan B Fishbeck, Founder and CEO of EstateSpace, LLC, a Managed Security Services Provider (MSSP) that helps people reduce risk, retain property assets, and protect wealth succession.
• Christine Ray, the Chief Information Security Officer at Unqork, a private company specializing in computer software.
• Aaron Smith, Co-founder of Savi, a financial technology solution that works with partners and individuals looking to manage their student loan debt.

Our Current Security Monitoring Tools Are Not Working

It’s clear from the recent attacks on big business that cybercriminals are escalating their attacks and exposing our weaknesses. From malware to ransomware, malicious actors are finding their way through our defenses.

SolarWinds Network Data Breach

This information technology firm experienced a massive cybersecurity attack that spread to its clients in 2020, affecting the U.S. Department of Homeland Security and the Treasury Department. In a nutshell, the bad actors added malicious code to SolarWinds’ software system, Orion, which is used by about 33,000 of their customers. When they sent out software updates, they included the exploited code and created a backdoor to their customer’s IT systems, where the bad actors installed more malware that allowed them to spy on the companies and agencies.

Colonial Pipeline Co. Security Breach

In 2021, the DarkSide, a ransomware gang, managed to shut down the pipeline and disrupt the fuel supply to the U.S. Southeast. The attack occurred using a legacy Virtual Private Network (VPN) system that had only single-factor authentication. The company ended up paying the gang almost $5 million to regain access, some of which hasn’t been recovered.

JBS Paid to Resolve a Cyber Attack

This was followed by a ransomware attack on the nation’s food supply. The cyber criminals, REvil, breached JBS’s computer networks and encrypted their files, shutting down meat plants in the U.S., Australia, and Canada for about a day. The company, the number one beef supplier in the world, paid the intruders $11 million.

Of course, those are just a few of the thousands of cyber attacks that occur annually. Even more disheartening is that 80% of IT security leaders believe their organization lacks sufficient protection against these types of attacks.

So, what’s gone wrong?

Current scanning and patching technology miss 50% of vulnerabilities, and we inherit these vulnerabilities from third-party software code and open-source software. “The current application performance monitoring doesn’t see the data signals indicating instability, unreliability, or vulnerability in your infrastructure,” says Saunders. In addition to significant financial damage, these types of attacks threaten a company’s reputation, commerce, and society at large.

The Panelists Reveal Why Security Is Important to Their Company

All guests stressed the importance of security in their business model. Ray noted that customer interaction means that they’re collecting information and learning about their clients daily. Ensuring this interaction is private, confidential, and secure is their number one priority at Unqork.

According to Ray, everybody’s bringing code to the party, which is why it’s so important to have a multi-layered approach with good details, good tracking, and continuous searching. She doesn’t worry about the latest vulnerabilities like SolarWind, because RunSafe gives them their own builds so they know that no one can tamper with the code.

Smith sells software to channel partners that helps their constituents manage student loan debt. Some of these partners include large financial institutions and employers that demand top security in their partners. Borrowers must know their information is safe and that their software is not putting their partners’ security at risk. He also noted that while they use security management tools like intrusion detection, penetration testing, and encryption, older institutions sometimes ask for antiquated security tools that don’t make much sense. In these instances, it’s about getting partners up-to-date on the latest technology.

Fishbeck’s clients at EstateSpace have significant means and assets that they want to know are safe and invulnerable. The company focuses on protecting everyone in its network, including providers and customers. He was quick to point out that it’s no longer just about U.S. compliance—but global compliance. With the use of RunSafe’s technology, he’s no longer worried when someone gets through the wall, because when they get to where they’re going, they’ll either head down a black hole or can’t see anything.

All the professionals report building customer trust by earning compliance certification such as Cloud Security Alliance, performing penetration testing, audits, and external validation—steps that let their partners and clients know they’re doing everything possible to protect them and their information. And all of them use RunSafe.

RunSafe’s Answer to Security Monitoring for SAAS Providers

RunSafe provides a three-way approach to security monitoring by immunizing software and monitoring its health:

1. Alkemist Code: Cyberhardens software code that you can incorporate into your build process.
2. Alkemist Repo: Pre-hardened versions of open-source software.
3. Alkemist Flare: A continuous monitoring service looking for software crashes that may indicate vulnerabilities in your software. It’s designed to capture software crashes and analyze to determine if it’s a potential bug, vulnerability, or cyber attack and then allows you to route that through your SIEM to your security operations or your development team.

According to Saunders, monitoring software crashes indicate instability, whether application weaknesses or potentially compromised data, and are sources of leaked information. Software crashes may also indicate software bugs.

They also indicate unreliability and a problem with third-party software or a bug in the open-source library or a component you’re using to drive software across your platforms. Finally, they may indicate vulnerability, such as an attacker probing for an attack vector or an exploit in process.

In today’s world, it’s all about using the latest technology to ensure security. To delve deeper into the panel discussion and learn more about providing secure software to your customers, click here.

The post How to Address Threats with Security Monitoring appeared first on RunSafe Security.

Managing cybersecurity vulnerabilities for organizations of any size is no small task. For organizations that produce their own code, they’re a step ahead with access to the code itself. But what about organizations that use third-party code or open source code?

In today’s world, this example represents most organizations. Myriad tools exist to help identify and remediate vulnerabilities, especially for open source code, but is that enough? While these tools are excellent, they still rely on the original developers and maintainers to “fix the bug,” and security bugs are as prevalent as ever.

According to recent research, open source vulnerabilities rose by almost 50% in 2019 over the previous year. Also, even though 85% of open source security vulnerabilities have a patch available, more than 50% of systems running that code don’t get updated, ultimately leaving them open to attack.

If we break down the vulnerabilities and look at the types that are the most prevalent and the most dangerous, memory corruption emerges as a significant threat. RunSafe research found that common code scanning tools uncovered memory corruption about a third (34%) of the time. However, our research also indicated that only 12% of the memory bugs were acted upon by developers. When acted upon, the mean time to resolution was 98 days. Some went several years. Moreover, of all these bugs, 59% of the vulnerabilities had known exploit scripts available. In short, memory bugs get missed, they don’t get fixed quickly, and they’re often easily exploitable.

Implications for a World Migrating to the Cloud

As the move to the cloud continues, open source infrastructure moves along with it. With that move comes a shift to a shared security model, where both the cloud provider and the customer share in ensuring a secure system. Cloud providers have some of the best security professionals in the world protecting their infrastructure, but the burden falls on their customers to ensure that the code they migrate is equally secure. With open source code, there’s historically been limited options beyond scanning and patching. Luckily that’s changing, and modern code hardening techniques are proving to be both an extra option and an enhancement to open source security overall.

RunSafe Security has developed Alkemist, a novel solution that introduces protections against memory corruption directly in the software itself. Instead of scanning and patching, Alkemist immunizes software from attack altogether. Attack surfaces physically reduce by a third without slowing down deployment or operations.

Alkemist introduces randomization in how programs are loaded into memory. When an Alkemist hardened image launches, every time a process kicks off, its functions load into random memory locations, depriving the attacker of the consistency they need to launch a successful memory-based attack. No need for any configuration or monitoring; the code proactively and intrinsically protects itself.

Alkemist Protected Images Expand on Oracle Cloud Marketplace

RunSafe has built Alkemist protections into common open source IT infrastructure solutions, such Apache, Nginx, Redis and Memcached among others, and published Oracle Cloud Infrastructure (OCI) optimized images on Oracle Cloud Marketplace. OCI customers can now take advantage of these turnkey options to harden the IT Infrastructure that they run in the cloud.

Scanning and patching is with us for a long time to come and it always has its rightful place in security operations best practices. But, this practice is inherently reactive. With adversaries growing increasingly sophisticated and quicker to act on weaponizing vulnerabilities, businesses need proactive solutions that they can deploy simply and easily. By swapping out your current instance of Apache, for example, to an Alkemist hardened version in OCI, you’ve instantly shrunk your attack surface by a third. Not only does this change provide better cybersecurity and resiliency, it allows scarce security resources to focus on a narrower set of vulnerabilities. In turn, resources can reallocate to more meaningful and business impacting projects. It’s a true win for all parties involved.

Want to Know More?

RunSafe and Oracle are hosting a Webinar on October 6, along with Open Source Security Experts from SANS Research Institute. During this session, the team unpacks the realities behind Open Source Security and how RunSafe is providing a newer effective way to protect your cloud-based IT infrastructure.

Secure your Open Source IT Infrastructure with RunSafe Hardened Images on Oracle Cloud Infrastructure by registering for this event.

The post Combating the Rise in Open Source Vulnerabilities with RunSafe Security on Oracle Cloud Infrastructure appeared first on RunSafe Security.

The debate surrounding open source code is sure to continue for years to come, and we’ve previously detailed both the high-level pros and cons to utilizing it. But one thing for sure is that the usage of open source is nearly unavoidable today and it’s becoming an integral part of any software development effort. With this in mind, another critical element to consider is the variety of security stacks that exist and are based on open source code. The most common of these stacks is often referred to as “LAMP,” but there are countless others as well as tools that don’t fall into a specific stack. Although each offers its own handful of benefits, they also have their own vulnerabilities, given they’re all built on insecure code.

According to recent research, open source vulnerabilities rose by almost 50% in 2019 over the previous year. Additionally, even though 85% of open source security vulnerabilities have a patch available, more than 50% of open source vulnerabilities don’t receive it for one reason or another, ultimately leaving them open to attack. We are so used to deploying tech stacks and relying on network protections, but if bad actors are assumed to get in, the security is exposed. So what are some of these specific vulnerabilities that exist within the LAMP stack?

The “LAMP” security stack was one of the first of its kind and remains the most commonly used stack. Consisting of Linux as the operating system, Apache as the webserver, MySQL as the database, and PHP as the programming language, LAMP is a classic layered architecture that can host a variety of popular web applications, such as WordPress, Wikipedia, and Drupal, and also offers a great amount of flexibility, such as deployment across multiple operating systems. A LAMP stack also provides users a considerable amount of customization and the ability to scale. However, each of its four components is still open to potential vulnerabilities. According to cvedetails.com and its categorization of vulnerabilities, a large percentage fall into the three categories of memory corruption, overflow, and code execution. The following tables break down the data into the total number of LAMP vulnerabilities, as well as those that fall specifically within three categories, over the last two decades and also the previous five years:

Based on the data, it becomes extremely apparent that Linux vulnerabilities are much higher than the rest of their stack counterparts. This can be directly attributed to the sheer amount of software that is deployed via Linux systems. One of the primary vulnerabilities found throughout the stack is common vulnerability and exposure (CVE) 2015-0235, otherwise known as “GHOST.” It was named after the system functions where the vulnerable code was found and the vulnerability itself is a buffer overflow that was a bug in the GNU C Library (GLIBC). This vulnerability exists on nearly every Linux system and is also loaded into almost every application, placing them all at risk. But GHOST isn’t the only CVE that has recently plagued the components of LAMP. The table below has further description of some other notable vulnerabilities:

But not all open source tools rely on a commonly used security stack. Components such as SSH, PostgreSQL, NGINX, and Redis are also quite common throughout the open source community, offering various benefits, as well as associated vulnerabilities. SSH focuses on encrypting data to ensure that attackers are unable to access user credentials and passwords, while also preventing the spoofing of DNS and IP addresses. Meanwhile, PostgreSQL, formerly known as Postgres, is most known for being the first database management system that utilizes a multi-version concurrency control (MVCC) feature, even prior to Oracle, while needing only very minimal maintenance and low cost associated with its use. Helping to power popular websites like Pinterest, WordPress.com, and Netflix, NGINX focuses primarily on web serving, reverse proxying, and media streaming by offering high performance yet simple configuration. Additionally, Redis is used mainly as a “database, cache, and message broker.” It’s known for its speed and support of almost all code languages and is becoming more and more popular by the day. However, these four open source tools are imperfect and all susceptible to attacks, specifically the following CVEs:

In addition to the LAMP stack and these four individual components, it’s also important to note the presence and popularity of the MEAN and ELK security stacks. The first was coined “MEAN,” in 2013 by Valeri Karpov. It refers directly to its composition of MongoDB, Express.js, AngularJS, and Node.js and offers the benefit of being entirely written in JavaScript, easily deployable, and cost-effective. Additionally, the MEAN stack is the perfect candidate for cloud hosting and developing cloud-native applications and has been adopted by large enterprises, including PayPal, Netflix, and Uber, to assist with tasks like expense tracking, location finding, and news aggregation. The other security stack was previously known as “ELK,” but is now mostly referred to as the Elastic Stack. Drawing its name from the Elasticsearch, Logstash, and Kibana components, the recent addition of Beats completed the group to where it is today. Growing exponentially in popularity in open source circles, Elastic Stack is now used by organizations like Box, Walmart, and Pfizer. This is because it offers numerous benefits in the log analytics space that were previously left unfulfilled by other stacks, whether it’s the analysis of these logs, scraping and visualizing data, or even allowing for a full-text search option. Again, although both MEAN and ELK are quite common, they offer their own set of issues and are susceptible to vulnerabilities like those detailed above.

The numerous vulnerabilities across some of the most popular open source security stacks may lead most non-technical users, and even some developers or security teams, to perceive that open source code is inherently insecure. That said, open source security isn’t all doom and gloom. These vulnerabilities only signal to users that there are indeed cyber risks involved, similar to every aspect of technology, but there are other tools and processes specifically designed to mitigate these risks. Frequently installing updates, prioritizing secure coding, and using automated tools to detect and remove potential flaws as quickly as possible in the development process are just a few ways to mitigate the risks associated with open source usage. Regardless of the specific tool used to harden software against the vulnerabilities that exist within open source security stacks, organizations that utilize LAMP and the other security stacks should keep up-to-date on the risks involved to keep development and innovation running smoothly, securely, and without error.

Article originally published on DevPro Journal.

The post Security Stack Vulnerabilities: Blame it on Insecure Open Source Code appeared first on RunSafe Security.