Bring your own vulnerable driver (BYOVD) is having a moment in endpoint security. Some of the buzz is earned. Some of it is overblown. This series unpacks both and shows the evidence for each. This piece traces how the technique scaled into an industry.

Ransomware actors successfully disabled security tools in about 48% of intrusions in 2024. That figure comes from security researchers, drawn from incident-response engagements across the year. Attackers attempted to blind the defender in most of those cases. They almost always succeeded. Turning off the sensor was once a flourish. It is now a default move.

That 48% is the broad rate for disabling security tools by any method. BYOVD is the kernel-level technique this series tracks, one fast-growing method inside that number, and public threat research treats it as the part of the tamper problem accelerating fastest. Treat the 48% as the ceiling and the BYOVD slice as the piece that scaled into a market.

The Claim: This Became a Supply Chain

EDR killing industrialized over the last several years. SentinelOne®'s latest Annual Threat Report, "Defending Against the Industrialization of the Modern Cyber Breach," names that shift directly, with mature automation accelerating intrusions and tradecraft moving from one-off effort to maintained capability. A killer was once a binary an intruder wrote and discarded. Today it is a serviced capability, built, versioned, and bundled into ransomware-as-a-service for affiliates who never touch a debugger. The defender once faced a hobbyist. Now the defender faces a development pipeline.

A pipeline behaves differently from a one-off binary. It ships versions, fixes bugs, and reuses code across releases. The defender reads that cadence like a vendor roadmap, and every release leaves the same observable footprint when it runs. The reuse is visible in the architecture. Public threat reporting describes one current framework spinning eight-plus variants off a single shared design. That also means a detection tuned to one variant often catches its siblings. Code reuse cuts both ways, and the defender holds one of the edges.

The Proof: A Four-Year Timeline

Start at the floor. Public threat research documented an early Process Explorer-driver killer in 2023, used to disable EDR ahead of Medusa Locker and LockBit. The same year, SentinelLABS tracked an actor called "Spyboy" selling the Terminator killer. The price ran from $300 for a single AV bypass to $3,000 for the all-in-one EDR killer, and the tool abused Zemana drivers. These were early-window artifacts. They were standalone, sold, and disposable.

That timeline has a SentinelLABS anchor that reframes the whole story. SentinelLABS attributed the AvNeutralizer killer, also known as AuKill, to the FIN7 cybercrime group. FIN7 sold it on Russian-language forums at prices running from $4,000 to $15,000. The tool abused a Time Travel Debugging driver and the Process Explorer driver to disable defenses. This is the moment a killer stopped being a one-off and became a product with a price list.

The adoption pattern proves the product framing. SentinelLABS tracked AvNeutralizer spreading into Black Basta, AvosLocker, MedusaLocker, BlackCat, Trigona, and LockBit operations. One group built it, and six competing crews ran it. A single tool crossing that many rivals is the signature of a supplier, and the new feature was distribution.

Then the model changed inside ransomware-as-a-service. In August 2024, public reporting disclosed EDRKillShifter, abusing the RentDrv2 and ThreatFireMonitor drivers and first seen in a RansomHub attack. Researchers assessed with moderate confidence that the tool served multiple attackers, not RansomHub alone. The SentinelOne RansomHub anthology records the affiliate logic behind that spread, a customized EDR-killer tool made available to higher-level affiliates. One crew's tool became many crews' tool, and the new feature was tiered access.

The driver roster widened fast across 2025. In early 2025, public threat research documented a malicious driver that carried stolen, revoked certificates and imitated a legitimate EDR driver to silence defenses inside Medusa intrusions. By August 2025, GuidePoint tracked Akira affiliates in SonicWall VPN intrusions chaining a ThrottleStop driver, rwdrv.sys, with a malicious helper, hlpdrv.sys, to disable the built-in Windows antivirus. Different crews, different drivers, the same kernel-level objective. SentinelOne's latest Annual Threat Report records the same pattern from the other side of the kill, naming crews that script the built-in Windows antivirus into silence and kernel-mode drivers derived from POORTRY used to terminate EDR processes and delete security files.

The CVE-anchored cases arrived next. In December 2025, security researchers documented DeadLock ransomware abusing the Baidu antivirus driver BdApiUtil, tracked as CVE-2024-51324, to terminate EDR and the built-in Windows antivirus. In February 2026, public reporting documented Reynolds ransomware embedding the vulnerable NSecsoft driver NSecKrnl, tracked as CVE-2025-68947, which terminated more than 30 security processes. Those CVE records do not name the ransomware, and the actor mapping comes from threat intel. The same NSecKrnl driver shows up across unrelated crews, tied to Reynolds and to Warlock. A driver is shared infrastructure, so pivoting on the driver hash groups campaigns by supplier, not by gang.

By 2025 the sharing went structural. Threat-intel reporting found one EDR killer used across several competing ransomware families, distributed as distinct per-attack packed builds, and Singapore's national cyber agency corroborated the same multi-group pattern in an August 2025 advisory, independent of any single vendor. Public threat research also catalogued a forming marketplace of named killers priced from hundreds to thousands of dollars. Rivals were now buying from a common counter.

The 2026 picture is operator-run kits with large affiliate cuts. Public threat reporting documented the Gentlemen RaaS shipping its in-house EDR killer framework, running eight-plus BYOVD variants and targeting over 400 processes across 48 security products through DeviceIoControl calls. The operator reportedly hands affiliates around a 90% revenue share, a 10% operator cut against a 20% industry standard, and bundles third-party killers like HexKiller and ThrottleBlood. By April 2026, researchers saw Qilin and Warlock at the same game, Qilin chaining the rwdrv.sys and hlpdrv.sys pair while Warlock ran NSecKrnl. Public threat research now reads EDR killers as a standard, repeatable phase of the attack playbook. SentinelOne's latest Annual Threat Report measured how far the response window has collapsed, with one chained sequence reaching SYSTEM in roughly 30 milliseconds and a separate intrusion moving from initial download to a persistent service in 49 seconds.

The Turn: Acceleration Over Origination

Here is the correction the timeline forces. Commercial sale of EDR killers predates the 2024 window. SentinelLABS had Terminator on the market in 2023 and dated FIN7's AvNeutralizer sales earlier still. ExtraHop tracked a dark-web market for these tools across 2024 and 2025. Older still, the open-source EDRSandblast project weaponized a vulnerable driver against more than 1,000 security drivers back in 2022. The raw capability was for sale before the surge.

So the real story is acceleration and consolidation. The non-obvious shift is that rival ransomware crews stopped competing on this layer and started sharing it instead. Several groups feeding from one killer is a market choosing a common supplier. The cost of building beats the cost of buying.

The economics pulled the skill floor down. Reynolds ransomware bundled a vulnerable driver as a recruiting selling point aimed at less-skilled operators, and a capability that once required a kernel developer now requires a subscription. The driver is the part most likely to fail in unskilled hands, so researchers documented a practice they call driver decoupling. Affiliates install the vulnerable driver and confirm it loads before running the killer. That is the kind of guardrail a supplier adds to keep low-skill customers successful, packaging doing the work the operator used to do by hand.

What Makes Consolidation Possible

Markets need shared infrastructure, and this one has it. The shared killer that reporting tracked was one tool reissued as distinct packed builds for each attack, with the packer as the common chokepoint several rivals fed through. Singapore's advisory described the same customized-build distribution model, a single supplier serving many buyers.

The driver supply explains why it scales. Public reference lists now track thousands of vulnerable signed drivers, most reachable without admin rights. The live LOLDrivers catalogue alone records hundreds of unique drivers, a large share still missing from the default driver blocklist. That inventory reads as a parts catalog for the kit builder, a dual-use commodity supply where weak driver access controls hand unprivileged users a way in.

The price ladder runs from the low hundreds for Terminator to five figures for FIN7's AvNeutralizer, both tracked by SentinelLABS, while EDRKillShifter spread through tiered affiliate access rather than a flat price. The skill floor drops in step. EDRSandblast showed the open-source baseline back in 2022, already capable against more than 1,000 security drivers, and a buyer in 2026 does not need that depth. The operator maintains the tool and the affiliate just runs it, so each layer of packaging removes a reason an attacker would have failed. A working tool spreads fast once the price of entry drops to a download.

The Payoff: A Top-Tier Threat Getting Cheaper

Put the pieces together and the threat ranking is clear. Disabling defense is attempted in most ransomware intrusions and succeeds in roughly half. The tooling that does it is now maintained, shared across rivals, and sold with affiliate economics that reward volume. Each force lowers cost and widens reach at once. This is a structural threat, and it is getting cheaper to run.

Defenders set the response, and the response is not despair. Public threat research shows BYOVD remains the dominant kill method, and that dominance means the kill chain stays observable. The killer still has to act in a fixed sequence. It installs a driver, registers a kernel service, and issues the calls that terminate the sensor. Those steps leave telemetry behind them.

The defender should still hold the technique apart from its cousins. BYOVD is one entry in a tamper taxonomy. A driverless class is smaller but growing, and it skips the driver-install step entirely. EDR-Freeze suspends the sensor through a Windows error-reporting race, staying fully in user mode. EDRSilencer uses Windows filtering rules to block the sensor's telemetry from leaving the host. Those two break the driver-load observable, so a detection built only around driver loads will miss them.

Prevention narrows the window without closing it, which is exactly why behavioral observables carry weight. The sequence is concrete enough to map to event IDs. Picus Security described the early steps of the BYOVD chain as logged events. A service created with sc.exe surfaces as a Sysmon process-create record (Event ID 1) and a System service-install event (Event ID 7045). The driver load surfaces as a Sysmon driver-load record (Event ID 6). The killer then issues its DeviceIoControl call, followed by callback removal and security-process termination. Each arrow in that chain is a place to correlate and alert.

The behavior inside that chain is even more specific. Public threat research documented a kill loop where a masquerading kernel service enumerates running processes on a repeating, fixed-interval cycle. It passes the process IDs through an IOCTL so the driver calls the kernel termination routine directly, bypassing the protected-process protections that guard the sensor. The repeating rekill cadence is itself a signal, because a normal service does not poll the process list and terminate from kernel mode on a loop.

Callback removal deserves its own hunt, separate from the kill. SOC Prime documented Qilin loading rwdrv.sys for raw memory read and write, then loading hlpdrv.sys to remove the EDR's registered kernel callbacks across more than 300 products. Stripping callbacks blinds the sensor without terminating its process. The process still runs and still reports healthy. The defender who only watches for a killed process misses this entirely.

The masquerade is its own tell. Frameworks ship variants that each impersonate a legitimate product to blend into a normal driver inventory, and one documented driver carried stolen, revoked certificates to imitate a real EDR driver. The defender's answer is to treat the signer and the first-seen status as data. Splunk detection content keys on any driver load whose signature status is not Valid. Alert on a driver whose hash, signer, or version has never appeared on the host before.

The witnesses also outlast the endpoint. Once the sensor is silenced, network, identity, and cloud telemetry are what remain, and independent analysis found EDR-killer execution preceding ransomware across multiple gangs, a window enough to intervene before encryption. Singapore's national cyber agency framed EDR-killer activity as huntable through driver-load monitoring, termination patterns, and telemetry cessation. An agent's health drop, a lost heartbeat, or a gap in a constant feed all read as tamper, so alert on the absence of expected signal. A high-fidelity variant is System Event ID 7031, the service-crash log Windows writes when a kill abruptly terminates a security service. It is rare in a healthy environment, which makes it a strong candidate for a tight, low-false-positive alert.

The mental shift for the practitioner is this. Stop modeling the EDR killer as an exotic, once-a-year event and start modeling it as supply. A supplied capability has a pipeline, a release cadence, and paying customers, and every one of those is a place to detect, disrupt, and raise cost. SentinelOne builds for that fight. SentinelLABS co-discovered the POORTRY and STONESTOP signed-driver toolkit and drove the security advisory ADV220005 that followed. SentinelOne then shipped Local Upgrade Authorization on by default for new customers to blunt the tamper bypass. The purpose behind that work is to give the advantage to those who secure our future. The industry built a market for killing your sensor. The defender's job is to make that market expensive.

Why This Is The Work SentinelOne Exists To Do

Read the timeline and the conclusion is plain. You do not out-hustle a development pipeline with manual triage. You answer it with a pipeline of your own. SentinelOne built the Singularity™ Platform on Autonomous Security Intelligence (ASI) for this exact asymmetry, so the response runs at the speed the supply chain ships. Purple AI® is the reasoning interface for that platform, and its Agentic Investigation capability launches the moment a threat crosses the line, detecting, investigating, verifying, and responding without waiting for an analyst to wake up. The capability does not displace the human. Wayfinder, SentinelOne's 24/7 managed detection and response practice, puts seasoned threat hunters on top of that autonomous layer, with managed response and an incident-readiness retainer when the worst happens. The killer industrialized. The defense industrialized with it.

Next in this series: the trust gap underneath every one of these drivers, and why a certificate revoked sixteen years ago still loads code into the Windows kernel today.

External References

1. "EDR killers are now a thing, and ransomware crews love them," The Register, 14 August 2025.
2. "RansomHub gang deploys new tool to kill EDR software," Security Affairs, August 2024.
3. "GRIT Report: Akira and SonicWall," GuidePoint Security, 5 August 2025.
4. "Event ID 7031: Service crash," ManageEngine EventLog knowledge base.
5. "CVE-2024-51324," National Vulnerability Database.
6. "Reynolds ransomware uses BYOVD to disable security before encryption," Security Affairs.
7. "CVE-2025-68947," National Vulnerability Database.
8. "Advisory AD-2025-018," Cyber Security Agency of Singapore, 16 August 2025.
9. "The Gentlemen RaaS uses GentleKiller," The Hacker News, June 2026.
10. "Inside GentleKiller: the EDR killer powering the Gentlemen," Security Affairs.
11. "Gentlemen Ransomware Gang Standardizes EDR Killing," BankInfoSecurity.
12. "The Dark Web Market for EDR Killers," ExtraHop, 2024.
13. "EDRSandblast," Wavestone CDT, GitHub.
14. "EDRSilencer," netero1010, GitHub.
15. "EDRSilencer red team tool used in attacks to bypass security," BleepingComputer, 15 October 2024.
16. "New EDR-Freeze tool uses Windows WER to suspend security software," BleepingComputer, 22 September 2025.
17. "What Are Bring Your Own Vulnerable Driver (BYOVD) Attacks," Picus Security, 2026.
18. "Qilin EDR killer infection chain," SOC Prime, 7 April 2026.
19. "Windows Drivers Loaded by Signature," Splunk research.
20. "Windows Vulnerable Driver Loaded," Splunk research.
21. "loldrivers.io," live vulnerable-driver reference list, accessed 26 June 2026.

IP Disclaimer:

This blog may include discussion of unreleased services or features. Any unreleased services or features referenced here are still in development and subject to change. Customers should make their purchase decisions based upon features that are currently available.

Attackers are targeting CI/CD pipelines and developer tools instead of application code, requiring total SDLC visibility and strict security controls

The post Connecting the Dots: Securing the Overlooked Corners of the Software Development Lifecycle (SDLC) Supply Chain appeared first on Unit 42.

Attackers can exploit LLM domain hallucinations through phantom squatting to target supply chains. Read the analysis to learn more.

The post Phantom Squatting: AI-Hallucinated Domains as a Software Supply Chain Vector appeared first on Unit 42.

Protect enterprise AI agents from supply chain risks by auditing third-party skills for hidden vulnerabilities and multi-stage attack chains.

The post Trust No Skill: Integrity Verification for AI Agent Supply Chains appeared first on Unit 42.

Unit 42 explores trends in data theft and extortion, outlining key strategies for organizations as frontier AI models advance.

The post Out of the Crypt: The Evolving Cyber Extortion Economy appeared first on Unit 42.

The software supply chain has become one of the most attractive targets for modern adversaries, but the attacks seen in 2025 did not focus solely on poisoning dependencies or hijacking packages. Increasingly, attackers are targeting the infrastructure that powers the software delivery lifecycle itself.

Build servers, CI/CD runners, package managers, and developer workstations all sit inside an organization’s trusted delivery path. They are designed to execute code automatically, often with elevated privileges, and to move artifacts through the environment without scrutiny. Those same design principles make them ideal attack surfaces. Once an adversary gains access to this trusted infrastructure, malicious activity can blend seamlessly into legitimate build and release workflows.

Now, adversaries are increasingly adopting “shift-left” tactics to subvert build runners, poison development dependencies, and weaponize automation tools before code can even reach a production server. Instead of breaching the perimeter and forcing malware inward, attackers are compromising the systems that organizations inherently trust to deliver software. The result is a class of intrusion that is harder to detect, faster to scale, and capable of bypassing traditional security controls by abusing automation itself.

The Subversion of Trusted Infrastructure

Build servers and runners are high-value targets because they routinely execute privileged actions. They compile code, pull dependencies, move artifacts, and deploy software – all activities that mirror the behavior of an attacker attempting to establish persistence or distribute malware.

Threat actors have recognized that compromising build infrastructure gives them an opportunity to weaponize trust. In one case, attackers exploited a vulnerable self-hosted TeamCity server and remained undetected for more than a year. After gaining access, they created a benign-looking build configuration that was executed by a trusted build agent running with SYSTEM privileges. That build job then deployed a backdoor into internal environments.

Since the malicious code was delivered through a legitimate CI/CD task, it appeared indistinguishable from normal operational activity. No suspicious external binary was introduced, no obvious malware delivery mechanism was observed, and the deployment path blended into routine release workflows. This kind of attack points to the core challenge defenders face: In CI/CD environments, malicious behavior often looks exactly like expected behavior.

Turning Automation Against the Organization

Pipeline compromise does not always require direct malware execution on the build server. In many cases, attackers simply manipulate automation workflows to make the organization’s own tools carry out the intrusion.

One observed intrusion, noted in this year’s Annual Threat Report, involved the compromise of a GitLab service account token. The attacker used the token to create projects containing malicious Ansible playbooks, which were then automatically executed by the organization’s CI/CD pipeline. The build system treated the attacker’s commands as authorized automation, effectively turning the deployment pipeline into the orchestration mechanism for the compromise. This is what makes CI/CD subversion so dangerous. Rather than needing to evade the build process, the attacker simply inherits it.

Once inside the pipeline, the adversary gains the same benefits as the automation itself. This includes trusted execution, access to internal resources, and the ability to move laterally under the guise of legitimate activity. Traditional security tools often struggle to distinguish malicious pipeline actions from expected operational tasks, especially when those tasks are executed under valid service identities.

The Human Layer Is Part of the Pipeline

Some of the most effective “shift-left” attacks in 2025 targeted the developers themselves, bypassing the targeting of target code or infrastructure first. Campaigns like Contagious Interview used fraudulent job offers to compromise developers working in cryptocurrency and blockchain sectors. Victims were directed to fake skill-assessment sites where they encountered fabricated technical errors and were instructed to run commands to “fix” the issue. Those commands silently deployed malware on the developer’s workstation. This approach gave attackers direct access to the developer’s local environment, including SSH keys, repository access, tokens, and credentials. From there, the path into source code repositories and CI/CD systems became significantly easier.

By compromising the human operators behind the development process, attackers gain access at the earliest stage of the software lifecycle – what might be the ultimate “shift left” advantage. Instead of attacking production systems, they infiltrate the environments where software is built, tested, and trusted. This reinforces an important reality in which the software pipeline extends beyond infrastructure. Developers, maintainers, and service accounts are all part of the attack surface.

Unauthorized Runners and Persistent Access

Another growing tactic is the unauthorized registration of attacker-controlled systems as legitimate build runners. In the Sha1-Hulud campaign, malware infected systems and registered them as self-hosted GitHub runners under attacker-defined names. These rogue runners were then able to execute build tasks as trusted participants in the CI/CD process.

This is especially dangerous because self-hosted runners are often granted broad access to repositories, secrets, and deployment workflows. Once a malicious runner is registered, the attacker gains persistent, authorized access inside the development pipeline without needing to repeatedly exploit vulnerabilities.

The campaign also used malicious workflow triggers to ensure persistence. Certain workflows were designed to execute code when a user posted a comment in a repository discussion, turning routine collaboration features into execution mechanisms. Attackers no longer hijack the builds, opting instead to embed themselves into the development lifecycle in modern CI/CD compromise tactics.

Dependency Poisoning Evolves

While build infrastructure attacks surged, dependency poisoning remained a critical vector in 2025. Attackers published malicious versions of popular build packages that executed reconnaissance scripts during installation. These scripts harvested tokens, inspected environments, and in some cases targeted locally hosted AI systems.

In parallel, attackers used phishing to compromise trusted maintainer accounts, allowing them to append malicious code to legitimate package updates. As the updates originated from verified accounts and trusted repositories, they passed through normal review channels undetected.

Malicious code inherits the trust of the source that delivers it is now one of the defining characteristics of modern supply chain compromise. When dependencies, runners, and build jobs are all trusted by default, attackers only need to compromise one link in the chain to gain access to the entire pipeline.

Why Traditional Detection Falls Short

The core difficulty in defending CI/CD infrastructure is that standard build activity inherently resembles malicious behavior. Compiling binaries, downloading packages, invoking scripts, opening network connections, and moving artifacts are normal actions in a build environment. These same actions are also hallmarks of compromise. That overlap creates a blind spot. If a malicious job executes under a valid service account on a trusted runner, the behavior may appear legitimate unless the account performs actions that clearly deviate from its role.

This means traditional detection models based on signatures or isolated indicators are insufficient. Defenders need visibility into context – who created the job, what changed, where the runner was registered, what secrets were accessed, and whether the workflow deviates from expected patterns. The challenge is no longer identifying malware alone. It is verifying the integrity of every automated action across the pipeline.

Moving From Trust to Continuous Verification

The solution to CI/CD subversion is removing implicit trust from the automation process. Every build runner, dependency, script, and service identity should be continuously verified. Security teams need to know when new runners are registered, when build configurations change unexpectedly, when secrets are introduced into workflows, and when jobs exhibit suspicious runtime behavior.

This starts with strong dependency integrity controls such as Software Bills of Materials (SBOMs) to detect unauthorized package changes. It extends to secrets hygiene practices that identify exposed credentials in repositories and pipeline configurations.

Build runners should be treated as high-value systems, monitored for suspicious child processes, credential access attempts, reverse tunnels, and persistence mechanisms. Unauthorized registrations or unusual runner names should trigger immediate investigation.

Equally important is behavioral monitoring for build jobs themselves. New or modified pipelines created by service accounts, jobs interacting with unfamiliar repositories, or workflows that establish network tunnels should all be treated as potential indicators of compromise. The objective is to ensure that trust is earned continuously, not granted automatically.

Conclusion | The Future of Pipeline Defense

CI/CD pipelines have become one of the most strategically valuable targets in enterprise environments. They sit at the intersection of source code, secrets, automation, and deployment. A compromise at this layer gives attackers privileged access to the entire software delivery chain. The attacks that continue to make news headlines show that adversaries understand this well. They are exploiting build infrastructure, abusing automation workflows, hijacking developer trust, and embedding themselves directly into the software lifecycle.

For defenders, this means the security model must evolve. Protecting the pipeline requires treating automation infrastructure as critical security infrastructure, applying runtime protection to build agents, verifying the integrity of dependencies, and continuously monitoring every workflow for signs of abuse. The era of implicit trust in CI/CD is over. The organizations that adapt will be the ones that recognize a fundamental truth: In modern software delivery, the pipeline is part of the perimeter – and attackers are already inside it.

Third-Party Trademark Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

Unit 42 analyzes npm supply chain evolution post-Shai Hulud. Discover wormable malware, CI/CD persistence, multi-stage attacks and more.

The post The npm Threat Landscape: Attack Surface and Mitigations (Updated July 15) appeared first on Unit 42.

Some of the biggest and most infamous cyberattacks of the past decade were caused by a security breakdown in the software supply chain. SolarWinds was probably the most well-known, but it was not alone. Incidents against companies like Equifax and tools like MOVEit also wreaked havoc for organizations and customers whose sensitive information was compromised.

Expect to see more software supply chain attacks moving forward. According to ReversingLabs’ The State of Software Supply Chain Security 2024 study, attacks against the software supply chain are getting easier and more ubiquitous.

“For example, Operation Brainleeches, identified by ReversingLabs in July, showed elements of software supply chain attacks supporting commodity phishing attacks that use malicious email attachments to harvest Microsoft.com logins,” the report stated.

It is easier to conduct software supply chain attacks, so they are increasing at an alarming rate. The ReversingLabs report saw a 1,300% increase in threats coming from open-source package repositories last year. That’s the bad news.

The good news is that cybersecurity teams and government entities recognize the risks coming from the software supply chain, and there is a lot of action toward defending against these attacks and steps to solidify security before the software is released into the wild.

Who controls the software?

Who controls the software and who controls the device are the game-changers in software supply chain security, according to Xin Qiu, Sr., Director of Security Product Marketing and Management at CommScope. But that’s hyper-focused down to the developers and system engineers creating the software and setting up the systems. The problem is that there is little integration within an organization to enable effective control.

Companies have a lot of tools, but they are scattered around, says Qiu. Everyone is siloed, doing things in different ways. That approach has to change.

It is the federal government that is taking the lead in tackling software supply chain security with technical regulations and laws.

“To improve your software supply chain security, you need to have a common standard,” says Qiu. “I think this is a good way to fill those gaps.”

The most recognizable action taken by the government entities was the Executive Order(EO) from the Biden administration, which addresses the nation’s cybersecurity but especially emphasizes protecting the software supply chain. In conjunction with that EO, a cross-sector group representing different government agencies, the Enduring Security Framework (ESF) Software Supply Chain Working Panel, put together a comprehensive guide for recommended practices of security in the software supply chain for developers. NIST also has a framework to secure the software supply chain.

4 security solution trends for the software supply chain

But government guidelines and regulations only go so far, and it is up to organizations to better equip themselves with the tools, solutions and processes that allow developers, engineers and security and IT teams to address risks within the software supply chain. There are a number of ideas and tools out there, some initiated by the government, that are trending in the battle against vulnerabilities and threats.

1. Secure by design

At RSAC2024, CISA Director Jen Easterly and a panel of cybersecurity professionals gave a panel on CISA’s Secure by Design initiative. The idea is to build security into products and make it a business feature and core technical requirement rather than the more standard approach of treating security as a failure. “During the design phase of a product’s development lifecycle, companies should implement Secure by Design principles to significantly decrease the number of exploitable flaws before introducing them to the market for widespread use or consumption,” the initiative’s website states.

Part of the presentation was the introduction of the initial group of businesses that took the Secure by Design pledge. According to CISA, “By participating in the pledge, software manufacturers are pledging to make a good-faith effort to work towards the goals listed below over the following year.” The pledge includes a list of goals for developers and organizations to work toward. These goals include standards around MFA, reducing default passwords and better transparency around vulnerability disclosure and reporting. More than 200 organizations have taken the pledge so far.

2. Software bill of materials (SBOMs)

SBOMs are a nested inventory of all the components that make up a software application. The components can include open source, third parties, patch status and licenses. SBOMs have become a key part of the software supply chain security structure and are endorsed by CISA as a way for developers to build a community that works together to share ideas and experiences around operationalization, scaling, technologies, new tools and use cases. To encourage SBOM use and understanding, CISA facilitates regular meetings from those across the software development and design community and also offers a resource library.

SBOMs can help an organization identify risks, especially in third-party and proprietary software packages: track vulnerabilities within the different components; ensure compliance and help the team make better security decisions by being more aware of the component parts of their software.

3. Supply-chain levels for software artifacts (SLSA) frameworks

SLSA is a security framework to safeguard the integrity of software artifacts. It is a checklist of standards to better improve the integrity of the software, prevent tampering and exploitation and keep the infrastructure and application packages secure. The framework was based on Google’s production workloads and offers a structured approach to evaluating the security posture of software components throughout the supply chain.

4. Governance, risk and compliance (GRC) management

GRC management is used to mitigate security risks within a software development supply chain while ensuring the software meets required regulatory compliances and security standards. Some of the areas that GRC monitors include:

• Identifying risks across the entire software supply chain
• Vendor risk management and assessment of third-party security posture before integrating the software into your organization’s system
• Compliance management to meet industry and government standards
• Policy enforcement across the development lifecycle
• Incident response after a cyber incident caused by the software supply chain

GRC management tools can also be used with SBOM analysis.

The evolving puzzle of software supply chain security

This is just a sample of the tools and solutions used to protect the software supply chain from risk. As security is more consciously built into the software and developers and engineers share information in communities rather than working in silos, there is a fighting chance of slowing the threats against the software supply chain.

The post 4 trends in software supply chain security appeared first on Security Intelligence.

To the naked eye, organizations are independent entities trying to make their individual mark on the world. But that was never the reality. Companies rely on other businesses to stay up and running. A grocery store needs its food suppliers; a tech company relies on the business making semiconductors and hardware. No one can go it alone.

Today, the software supply chain interconnects companies across a wide range of industries. Software applications and operating systems depend on segments of the software supply chain to offer improved functionality. But while the software supply chain has improved efficiency and productivity for most organizations, it also means that if there is a vulnerability or a glitch in the software, it can halt business operations at hundreds or thousands of companies. Even the security programs that are used to protect users from cyberattacks can release exploitable software or an update with a coding mistake that can result in anything from massive data breaches to canceled flights to shutting down medical facilities because they can’t access patient records.

These software supply chain failures don’t just hurt the company. Millions of people are impacted. So why do software vendors have such deep access to an individual organization’s system so that one problem could create a nightmare scenario?

The evolution of computing

To understand why systems are so interconnected, you have to look at the evolution of both computing and software applications, according to Shiv Ramji, President of Customer Identity with Okta.

“We started from a world where programmers write on mainframes, and then we went from mainframes to the cloud and a distributed computing model,” Ramji explained during a conversation at the Oktane conference.

The benefit is that companies can now deploy applications faster, and they can be scaled with elasticity. Applications in the cloud are faster. There are a lot of benefits to architecting applications embedded in the cloud and network systems.

However, says Ramji, this also means that the application stack becomes more complicated and more sophisticated.

“The classic example would be if I had to store if I had an app that was a social media app or photo sharing,” explained Ramji. If the user relied on a single data center and single storage mechanism, scaling would become more difficult and expensive.

“But today, you can scale this really fast because you can use S3 from Amazon for storage, and you can scale your compute,” Ramji adds. “And so, it doesn’t matter if I have two users or end up having 200 million users; I’m able to address the needs.”

This evolution in computing has brought application stacks that have become much more complex, with a lot of interdependencies across the system. Cloud computing services, security services and networking capabilities work seamlessly because they are able to be embedded into an organization’s infrastructure.

Locking in with a vendor

These interdependencies are increasingly making organizations overly reliant on specific vendors and applications to keep their business operations running smoothly. The upside to this is having third-party partnerships that integrate with your infrastructure and can be built out seamlessly. The downside is added costs from not shopping around for better deals and the greater risk of a security flaw taking down your system without warning. One bad piece of code due to an embedded vendor application can cause irreparable damage.

According to research from Dashdevs, “vendor lock-in is proven to lead to unanticipated costs and technical debt.” Reliance on these embedded applications is “proven to increase risks and vendor-specific vulnerabilities.”

When these embedded applications have a flaw — a vulnerability exploited or misconfigured code, for example — the fix can be complex. It might look as easy as deleting the bad file or applying a patch, but what happens if the problem doesn’t allow you access to the system at all? To do that, you have to identify which program is causing the problem and where within your system it is located. Is it a problem that can be fixed once via the cloud and will automatically change across all devices, or will it require updating individual machines? Finally, what is the communication between the vendor and your organization? Is the problem something you discovered or was it revealed to you, and how willing and quick is the third party able to take responsibility?

Unfortunately, there are no easy answers. It will come down to the individual situation — the type of vendor, how the application is embedded into your network and the problem that it causes.

“Some of those systems, some of those controls that you have in place have the potential from a resiliency standpoint to mean the difference between your customers having your service being on and available or having a complete destruction caused by an outage similar to what we’ve seen with other vendors recently,” says Charlotte Wylie, Deputy CSO with Okta.

How vendors can keep customers secure

Vendors can take steps to protect their customers from a software breakdown, beginning with recognizing their role inside their customers’ infrastructure. Wylie provided the following tips on how vendors and customers can work together to add security to embedded applications:

• Implement access with least privilege permissions on both sides
• Have controls and protocols in place if there is a degradation of service
• Have well-managed accounts that are maintained and secured with your organization’s IAM team

“I think least privilege and having the right identity is super important,” says Wylie. “And then testing that on a regular basis so you have the right enterprise resiliency in place and know that your disaster recovery plan is ready to go — these are your backup plans when you have a collaboration of vendors.”

Every organization has become more reliant on the software supply chains and applications used across their complex network architecture. It’s almost impossible to run a business efficiently today without this interdependence on third parties who have deep access to not just your system directly but also through the other applications and software you use. Failure will happen. Being prepared with a recovery plan for any worst-case scenario and thinking about how to best architect networks with third-party vendors to work through failure will prevent the downtime from turning into a news event.

The post Why do software vendors have such deep access into customer systems? appeared first on Security Intelligence.