Plaintext: Another Call for Moving to Memory-Safe Languages

Welcome to Dark Reading in Plaintext, brought to your inbox this week by Adaptive Shield . In this issue of Plaintext, we delve in to a new CISA report looking at the state of memory-unsafe code in open source projects. We also look at how a security veteran makes the move outside the industry. If you enjoy Plaintext, please share with friends and colleagues !

State of Memory Safety Vulnerabilities in Open Source Projects. CISA , FBI, the Australian Cyber Security Centre, and the Canadian Centre for Cyber Security released a report summarizing the results of their investigation into the use of memory-unsafe code in open source software . Fifty-two percent of the 172 major open source projects that the research authors looked at contained code written in a memory-unsafe language, such as C and C++. More than half (55%) of the total lines of code in all the projects combined were written in a memory-unsafe language, with the larger projects being the worst culprits. Also worth noting: projects written in memory-safe languages may still be exposed to memory vulnerabilities through unsafe dependencies.

Memory-unsafe programming languages allow programmers to have more direct control over memory-related functions in code, which can often lead to very common application security issues like buffer overflows and use-after-free errors. In contrast, memory-safe languages, like C#, Go, Java, Python, Rust, and Swift, handle memory management for the developer, reducing the opportunity to make these types of code errors .

Projects may be written in memory unsafe languages for a number of reasons, including the fact that a lot of existing components and codebase is already written in that language. "It would be difficult to change many of these projects to memory safe languages because it would require resources and efforts from the maintainers, to refactor/rewrite to memory safe languages," notes Chris Hughes, chief security advisor at Endor Labs and a CISA Cyber Innovation Fellow. The project maintainers may not know memory-safe languages, or the time/resources to rewrite the code. Remember, many of these projects depend on unpaid or under-compensated volunteers.

“To reduce risks, organizations need to thoroughly understand their OSS consumption as part of a broader software asset inventory.” —Chris Hughes, Endor Labs.

The joint 22-page report recommends software makers create roadmaps for transitioning to memory-safe roadmaps, including plans for addressing memory safety in external dependencies. This is the not the first time the government has urged using memory safe languages. A February 2024 technical report from the White House urged industry stakeholders to go back to the building blocks and start over with using memory safe code in all software. The US National Security Agency (NSA) urged software makers and all organizations developing software to consider adopting memory-safe languages back in 2022.

Dark Reading in Plaintext is brought to you by Adaptive Shield

Managing SaaS Security: What’s Your Maturity Level?

Read the new SaaS Security Survey Report: 2025 CISO Plans & Priorities ?to find out how your security team compares to other enterprise organizations.

Mike Rothman and the Candy Business. We normally don't track people's comings and goings in this industry, but Mike Rothman 's post over at Securosis talking about how he was leaving security to take on strategy and technology in a completely different industry caught our eye. It's classic Rothman —carefully reasoned, instructive, and funny. He steps through the POPE evaluation (People, Opportunity, Potential, and Exit) to describe his new role, and it is a good reminder to use this framework to think about opportunities that come our way. Also, all knowledge and experience can be adapted and applied to new situations, and this bit from his post really drove that point home for us: "I also leverage my experience in the security business...In the candy business you need to be prepared for a product recall. So we did a tabletop exercise working through a simulated recall scenario. The key to the exercise was having a strong playbook and making sure everyone knew their job. The recall simulation seemed so familiar, but different at the same time." Mike will still be at Black Hat for the Cloud Security Hands-On (for both AWS and Azure ) and we look forward to seeing him there.

What We Are Reading

• [Adaptive Shield ] The Ultimate SaaS Security Checklist, 2025 Edition
• WiCyS weighs in on the Diverse Cybersecurity Workforce Act.
• Trust librarians to write an excellent post-mortem of the attack on the British Library.
• Challenges of multifactor authentication in the cloud data world.
• And a cautionary tale about what can happen if organizations forget to report a breach .

What We Heard On-Air

Tune in to our on-demand webinar?“Assessing Software Supply Chain Risk .”

“Authentication and authorization in the world of API is critical.” —Jonathan Care.

From Our Library

Check out some of the latest reports from our?Dark Reading Library .

• [Adaptive Shield ] The Total Economic Impact of Adaptive Shield’s SSPM Solution
• Dark Reading Research: State of Enterprise Cloud Security
• Tech Insight: Threat Hunting's Evolution: From On-Premises to Cloud
• Dark Reading Research: How Enterprises Secure their Applications
• Tech Insight: Effective Asset Management is Critical to Enterprise Cybersecurity

On That Note

The hours drag but the week flies. How many times have you looked at the calendar and asked yourself how was it possible that the week is already over? How many of you are startled that the first six months of 2024 are already in our rearview mirror? For the busy security professional with not enough time to keep up with the news, have you looked at Dark Reading 's CISO Corner? It is a weekly digest of what we consider as the week's most important headlines. From 5G, China, and NYSE , we got you covered.

Dark Reading in Plaintext is brought to you by Adaptive Shield