Security
Headlines
HeadlinesLatestCVEs

Headline

Lessons From OSC&R on Protecting the Software Supply Chain

A new report from the Open Software Supply Chain Attack Reference (OSC&R) team provides a framework to reduce how much vulnerable software reaches production.

DARKReading
#xss#vulnerability#linux#intel#auth

Neatsun Ziv, CEO & Co-Founder, Ox Security

November 15, 2024

5 Min Read

Source: Andrey Kryuchkov via Alamy Stock Photo

COMMENTARY

The complexity of today’s software development — a mix of open source and third-party components, as well as internally developed code — has resulted in an abundance of vulnerabilities for attackers to exploit throughout the software supply chain.

We’ve seen the direct effects of software supply chain attacks in incidents like the MOVEit and SolarWinds breaches, revealing that no industry sector, size of company, or stage of software development is immune. According to a survey from Enterprise Strategy Group (ESG), 91% of organizations experienced at least one software supply chain security incident in 2023, and 2024 hasn’t seemed any better.

Security teams are overwhelmed by the task of sorting through, assessing, and prioritizing the mitigation of tens of thousands of alerts to discern those that pose real risk from those that are benign. In 2023, a group of AppSec experts addressed this problem by launching the Open Software Supply Chain Attack Reference (OSC&R), a freely available, MITRE ATT&CK-like framework to help organizations gain a deeper understanding of their software supply chain vulnerabilities.

The OSC&R community’s inaugural report, “OSC&R in the Wild: A New Look at the Most Common Software Supply Chain Exposures,” offers a comprehensive analysis of the severity of vulnerabilities across the software supply kill chain. Based on a nine-month analysis of over 100 million alerts, tens of thousands of code repositories, and 140,000 real-world applications, it examines the risk to software supply chains and probes the alignment between the vulnerabilities found in the wild and the focus of AppSec teams today.

The research offers some eye-opening statistics, including that 95% of organizations have at least one high, critical, or apocalyptic risk in their software supply chain, with the average organization having nine such issues. What’s more, the OSC&R data shows that many of the most common software supply chain vulnerabilities are tied to fundamental security controls, such as authentication, encryption, publicly available information in logs, and the principle of least privilege. Following are some of the most important takeaways from the report.

1. Watch for Run-Time Exposure

One in five applications was found to contain high, critical, or apocalyptic runtime vulnerabilities during the execution phase of an attack. This makes them prime targets for attackers. Because the most significant software vulnerabilities tend to surface in later attack stages, it’s crucial to catch issues early in the software development life cycle.

As such, AppSec and DevOps teams should aim to strengthen application runtime security. This can be accomplished by integrating continuous monitoring and real-time protection mechanisms that focus on the later stages of an attack, when the damage potential is greatest.

2. It’s Worth Fixing Older Vulnerabilities

While newer vulnerabilities may grab headlines, older vulnerabilities remain the most common attack vectors when it comes to supply chain security. Techniques like command injection (15.4% of applications), sensitive data in log files (12.4% of applications), and cross-site scripting (11.4% of applications) — as well as slow-burn vulnerabilities like CVE-2024-3094, which targeted the compression utility XZ Utils in major Linux distributions — still wreak havoc in unpatched systems. Attackers continue to successfully use historical tactics and techniques, showing that “old school” vulnerabilities present significant and persistent risks.

To counter these tactics and techniques and drive down the opportunity for attack, organizations should regularly review and update legacy systems and codebases to patch known vulnerabilities. Further, implementing a robust vulnerability management program that includes continuous scanning for both old and emerging threats will harden software to known risks.

3. Vulnerabilities That Span Multiple Attack Stages Amplify Damage

In the OSC&R report data analysis, 36% of applications were found to be vulnerable to exploits in the initial access attack stage, with many overlapping across multiple stages of attack. Indeed, vulnerabilities in initial access stages often open the door for more severe threats, such as persistence and execution exploits.

The data underscores the need for AppSec and DevOps team to bolster defenses across all stages of the attack life cycle, not just in initial phases. Organizations should adopt multilayered security solutions that can detect and neutralize threats at various stages of the kill chain to prevent attackers from moving laterally within systems and causing widespread cyber and business damage.

Next Steps for AppSec Teams

One of the questions the inaugural OSC&R report sought to answer was whether what AppSec and DevOps teams focus on matched the vulnerabilities found in the wild. The data reveals that this is not yet the case. Progress is being made, but the high volume of vulnerabilities passing through the supply chain into live applications, and the large percentage of organizations that report supply chain security incidents, indicate that greater focus on proactive software security measures is needed.

In addition, organizations need to do a better job of looking systemically at both their software development processes and the attack lifecycle to identify the places most likely to be at risk. But historical data alone is not the answer. Organizations must implement the tools and processes that give them holistic visibility of their supply chain — from the build stage all the way through runtime, and including the development and testing environments, which are occasionally overlooked.

Further, it’s clear that focusing on one or two stages of software development or one stage of the attack lifecycle isn’t enough. Businesses must adopt a multilayered, full-lifecycle AppSec strategy — accompanied by tools that can unify all stages — to reduce the probability of attack.

Development and security teams now have a reference they can use to map their programs to known attack vectors and tactics. OSC&R, in effect, sets the foundation for operating a streamlined software security program that reduces the number of vulnerabilities that reach production, enhancing the resiliency of the organization as a whole and easing the fears of breach due to software flaws.

About the Author

CEO & Co-Founder, Ox Security

Neatsun Ziv is the CEO and Co-Founder of Ox Security, the end-to-end software Active ASPM Platform. Prior to that, he was the VP of Cyber Security at Check Point, where he oversaw all cyber initiatives. His team was one of the first to respond to SolarWinds, NotPetya, and other major attacks, working closely with Interpol, Local CERT, and other enforcement agencies. Neatsun is a passionate and seasoned entrepreneur with vast cybersecurity experience. He served in the IDF Cyber Intelligence Unit and is a frequent speaker at global forums, including RSA and CPX, among others. Neatsun holds a B.Sc. from Israel’s Open University (honors) and an MBA from the Technion (Magna Cum Laude).

Related news

Leveraging Wazuh for Zero Trust security

Zero Trust security changes how organizations handle security by doing away with implicit trust while continuously analyzing and validating access requests. Contrary to perimeter-based security, users within an environment are not automatically trusted upon gaining access. Zero Trust security encourages continuous monitoring of every device and user, which ensures sustained protection after

Understanding Red Hat’s response to the XZ security incident

March 29, 2024 is a day that will hardly be forgotten by the open source community: Andres Freund disclosed his findings about the compromise in the xz compression library, which would enable an attacker to silently gain access to a targeted affected system. How did that coordination work under the hood? In this article we will give a behind the scenes glimpse into what this looked like at Red Hat.DiscoveryOn Wednesday, March 27, Andres contacted the Debian security team via their contact email ([email protected]) and let them know about the oddities he found in a SSH slowdown when using a n

There are plenty of ways to improve cybersecurity that don’t involve making workers return to a physical office

An April 2023 study from Kent State University found that remote workers are more likely to be vigilant of security threats and take actions to ward them off than their in-office counterparts.

Backdoor Discovered in XZ Utils: Patch Your Systems Now (CVE-2024-3094)

By Waqas Critical Backdoor Alert! Patch XZ Utils Now (CVE-2024-3094) & Secure Your Linux System. Learn how a hidden backdoor… This is a post from HackRead.com Read the original post: Backdoor Discovered in XZ Utils: Patch Your Systems Now (CVE-2024-3094)

Gentoo Linux Security Advisory 202403-04

Gentoo Linux Security Advisory 202403-4 - A backdoor has been discovered in XZ utils that could lead to remote compromise of systems. Versions less than 5.6.0 are affected.

Debian Security Advisory 5649-1

Debian Linux Security Advisory 5649-1 - Andres Freund discovered that the upstream source tarballs for xz-utils, the XZ-format compression utilities, are compromised and inject malicious code, at build time, into the resulting liblzma5 library.

Urgent security alert for Fedora Linux 40 and Fedora Rawhide users

Updated March 30, 2024: We have determined that Fedora Linux 40 beta does contain two affected versions of xz libraries - xz-libs-5.6.0-1.fc40.x86_64.rpm and xz-libs-5.6.0-2.fc40.x86_64.rpm. At this time, Fedora 40 Linux does not appear to be affected by the actual malware exploit, but we encourage all Fedora 40 Linux beta users to revert to 5.4.x versions.Editor's note: This post has been updated to more clearly articulate the affected versions of Fedora Linux and add additional mitigation methods.Yesterday, Red Hat Information Risk and Security and Red Hat Product Security learned that the l

DARKReading: Latest News

Non-Human Identities Gain Momentum, Requires Both Management, Security