USB Risks Without the Panic: BadUSB, Lost Drives, Air-Gapped Transfer

USB drives are still a real attack and data loss path, but the risk is manageable. The main dangers are malware that spreads through removable media, reprogrammed USB devices that pose as keyboards or network cards, and lost drives holding unencrypted data. Block unknown devices, encrypt every drive you allow, and move files into sensitive networks through a verified, logged process.

USB risk attracts two bad reactions. One is panic: ban every stick and watch staff email files to personal accounts instead. The other is complacency: AutoRun was fixed years ago, so the topic is closed. This post covers what actually goes wrong, what the research measured, which controls exist on Windows, macOS and Linux, and how air-gapped and operational technology (OT) sites can move files across the gap safely.

Key takeaways

• Microsoft restricted AutoRun to CD and DVD media in an August 2009 update and pushed it through automatic updating in February 2011. Removable media malware shifted to tricking users instead.
• BadUSB (Black Hat USA, 7 August 2014) showed that a USB device's controller firmware can be rewritten so it poses as something else, such as a keyboard. File scanners cannot see this.
• In a 2015 field experiment at the University of Illinois, people opened files on 45 percent of 297 dropped drives, and 98 percent of the drives were picked up. The first was connected in under six minutes.
• Every major desktop operating system now has a built-in way to restrict USB devices: Device Installation Restrictions and Removable Storage Access policies on Windows, accessory approval and a storage mount policy on macOS, and kernel USB authorization plus USBGuard on Linux.
• Air-gapped sites should never let a drive go straight from the outside world to a protected host. Use a staging station, verify hashes and signatures, log every transfer, and reformat transfer media after each use.
• A lost unencrypted drive means exposed data. Act on what was on it.
• MITRE ATT&CK T1091 and T1200 both list "Limit Hardware Installation" as a mitigation. T1091 adds disabling AutoRun and restricting removable media by policy; T1200 adds network access control such as IEEE 802.1X.

A short history: how did removable media malware spread?

Boot sector viruses on floppy disks came first, but the modern story starts with AutoRun in Windows. AutoRun let a volume carry a small file, autorun.inf, telling Windows what program to start or offer on insertion. Convenient for installer CDs, it gave malware a free execution path: copy itself to every stick plugged into an infected machine and wait for that stick to reach another one.

MITRE ATT&CK records this as technique T1091, Replication Through Removable Media. Its examples include Agent.btz and Conficker, which MITRE says used autorun.inf or AutoRun to spread over USB, and Stuxnet, which MITRE says used autorun.inf or a Windows shortcut (LNK) file vulnerability, CVE-2010-2568. MITRE also lists APT28 and Raspberry Robin as having used infected USB media.

What changed in Windows?

Microsoft's fix came in stages, and the dates are worth getting right because they are often misquoted. According to Microsoft Security Advisory 967940:

Microsoft's advisory notes two details that still matter. First, the update did not affect CD and DVD AutoPlay. Second, some USB flash drives have firmware that presents them to the computer as a CD drive, and AutoPlay behavior for those drives was not affected by the update. That second point is an early hint of the problem BadUSB later made famous: the computer believes what the device says it is.

The 2016 drop study paper makes the same observation from the other side: Windows no longer automatically executes arbitrary code when a USB drive connects, which defeats many traditional attacks, but connecting a drive still poses significant risk. The risk moved. Today, removable media malware mostly relies on a person opening a file that looks like a document or folder, or on a bug in software that parses files, thumbnails or previews automatically.

What is BadUSB and why can't a normal scanner see it?

BadUSB is the name Karsten Nohl and Jakob Lell of SRLabs gave to their research presented at Black Hat USA 2014, in a talk titled "BadUSB: On Accessories that Turn Evil" on 7 August 2014. The talk abstract describes malware that runs from the controller chips inside USB devices, and a USB stick reprogrammed to impersonate other device types so it can take over a computer, steal data or spy on the user.

To see why that matters, separate the two parts of a typical USB flash drive:

• The storage. Flash memory chips that hold your files. This is what you see when you open the drive, and it is what a file scanner reads.
• The controller. A small microcontroller with its own firmware. It speaks the USB protocol, tells the computer what kind of device it is through descriptors, and translates requests into reads and writes on the flash chips.

When you plug a device in, it tells the computer its class (mass storage, keyboard, network adapter) and the operating system loads a driver based on that answer. A device can legitimately present several interfaces at once. BadUSB showed that on some devices the controller firmware could be replaced, so a device that looks like a flash drive can also announce itself as a keyboard or network adapter, and the computer believes it.

That is why a conventional scanner cannot see it. A scanner reads files; the behavior lives in firmware it never reads, and acts through a channel the operating system trusts by design. The Linux kernel's own USB authorization documentation makes the same point in neutral terms: checking a device's class, type or protocol is a weak security check because descriptors can be spoofed.

Two caveats keep this from becoming panic. Not every USB controller can be reprogrammed in the field. And an attacker still needs the device to reach your port. The defenses below target that delivery step and the trust step, not the firmware.

What are keystroke injection devices, and how do operating systems respond?

A keystroke injection device is the simplest form of the BadUSB idea: a small device that presents itself as a USB keyboard and types a prepared sequence very quickly when connected. Operating systems accept keyboards without asking, so the typed commands run with the logged in user's rights.

MITRE ATT&CK T1200, Hardware Additions, covers this family, alongside network taps, rogue access points and devices that read memory through direct memory access (DMA). MITRE notes public reports of threat actor use are scarce, though red teams use these devices routinely; its procedure example is DarkVishnya, which MITRE says connected small computers and cheap laptops to a target's internal network.

Operating systems respond in three ways.

Approve before trust. Mac laptops with Apple silicon ask before a new USB or Thunderbolt accessory can connect. Apple lists four options: Always ask, Ask for new accessories (the default), Automatically allow when unlocked, and Always allow. A declined accessory cannot reach the Mac's data, though it can still charge. On supervised Macs, administrators control the setting.

Allow lists by device identity. Windows Device Installation Restrictions and Linux USBGuard allow only known devices. USBGuard rules can match the interfaces a device presents, so a known keyboard is allowed only as a keyboard.

Interface level control. The Linux kernel can authorize individual interfaces, so a drive's storage function can be accepted while a keyboard interface it also announces is refused.

None of these is perfect, because device identities can be spoofed. They still raise the bar, and they produce log events you can alert on.

What did the 2016 University of Illinois USB drop study find?

The often quoted study is "Users Really Do Plug in USB Drives They Find" by Matthew Tischer, Zakir Durumeric, Sam Foster, Sunny Duan, Alec Mori, Elie Bursztein and Michael Bailey, published at the IEEE Symposium on Security and Privacy in 2016. The fieldwork happened a year earlier.

What the researchers did, in their own description:

• They dropped 297 flash drives across the University of Illinois Urbana-Champaign campus during the week of 27 April 2015, at 30 locations across three areas, in parking lots, hallways, academic rooms, common rooms and outside.
• They used five drive appearances: unlabeled, with keys attached, with keys and a return address label, labeled "confidential", and labeled "final exam solutions".
• The drives held HTML files named like ordinary documents and photos. Opening one loaded an image from the researchers' server, which told them a file had been opened. No code ran automatically, and the study had ethics board approval.

What they found:

Two findings matter more than the headline. Altruism did not protect anyone: nearly half of finders first opened the vacation photos rather than the file labeled as the owner's resume. And the finders were not unusually careless; the authors describe them as typical members of the campus community.

The 45 percent figure is the share of drives where someone opened a file while online. The true connection rate lies between 45 and 98 percent, so "about half" is fair, but any exact rate is not.

The policy lesson: training alone will not close this. Make the safe action easy (a known place to hand in found media) and the unsafe action fail closed (devices not on the allow list do not mount).

What controls exist on Windows, macOS and Linux to restrict USB storage?

Here is the comparison at a glance. Each row is a built-in or first party mechanism described in the operating system vendor's own documentation.

Windows: Device Installation Restrictions

Microsoft documents Device Installation Restrictions as Group Policy settings under Computer Configuration, Administrative Templates, System, Device Installation, Device Installation Restrictions, applying to Windows 10 version 1809 and later. The policies apply per computer, not per user, and there is a separate policy that lets local administrators override them.

The important settings are:

• Prevent installation of devices not described by other policy settings. Turns the default to deny.
• Allow installation of devices that match any of these device IDs and ...device instance IDs. Build an allow list. Instance IDs are specific to a single physical device, which suits a small set of approved transfer drives.
• Prevent installation of devices using drivers that match these device setup classes, Prevent installation of devices that match these device IDs and Prevent installation of removable devices.
• Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria. Microsoft recommends enabling this in most practical setups so a specific allow can override a broad prevent.

Microsoft's guide carries a clear warning that is easy to miss. Each prevent policy has an option to also apply to matching devices that are already installed. If you apply a prevent rule retroactively to the disk drive class, you can disable the internal disk the operating system boots from; if you apply it to network adapters, you can cut the machine off from the network so that fixing it needs hands on the keyboard. Test on a lab machine first.

Windows: Removable Storage Access

Under Computer Configuration, Administrative Templates, System, Removable Storage Access, Windows has per class policies such as "Removable Disks: Deny read access", "Removable Disks: Deny write access", "Removable Disks: Deny execute access", similar settings for CD and DVD, tape, floppy and Windows Portable Devices, and the blunt "All Removable Storage classes: Deny all access". These are exposed through the ADMX_RemovableStorage policy configuration service provider for management tools as well.

A practical pattern for office machines is deny execute and deny write on removable disks, with read allowed where needed. Deny execute closes the common malware path; deny write closes the common data loss path.

macOS: accessory approval and storage policy

For individuals, check System Settings on any Mac laptop with Apple silicon and leave "Allow accessories to connect" on "Ask for new accessories" or stricter. For managed fleets, Apple's storage management declarative configuration, supported from macOS 15, sets a mount policy for external storage and separately for network storage. The options are Allowed, ReadOnly and Disallowed.

Read Apple's definition of ReadOnly carefully: only inherently read-only media such as CDs and DVDs mount, and writable devices such as USB drives cannot mount even read-only.

Linux: kernel USB authorization and USBGuard

The Linux kernel has supported USB device authorization since 2007, according to the USBGuard project. The kernel documentation describes the interface:

• Each host controller has /sys/bus/usb/devices/usbX/authorized_default. Writing 0 makes newly connected devices deauthorized by default. Writing 1 removes the lockdown. Writing 2 authorizes by default only devices on internal ports.
• A specific device is authorized by writing 1 to /sys/bus/usb/devices/DEVICE/authorized, and deauthorized by writing 0.
• Individual interfaces can be authorized or blocked through their own authorized file, and interface_authorized_default sets the default for new interfaces.

USBGuard builds on this with a daemon, a rule language and command line tools. Its rules have three targets: allow authorizes a device, block deauthorizes it, and reject removes it from the system. If no rule matches, the daemon blocks the device until someone decides. Rules can match vendor and product ID, name, serial, the port the device is attached through, a hash of its descriptors, and the interfaces it presents.

Step by step: lock down USB on a Linux workstation

This walkthrough uses USBGuard on a typical distribution. Package names and service names may differ slightly by distribution; check yours.

Warning before you start. A wrong policy can block your own keyboard and mouse. Do this from a session where you have another way in, such as SSH from a second machine or a console you can reach, and keep the default rules file backed up.

1. Install USBGuard from your distribution's packages.

# Debian or Ubuntu
sudo apt install usbguard
# Fedora or RHEL family
sudo dnf install usbguard

2. With only your trusted devices plugged in (keyboard, mouse, any built-in readers), list what is attached right now.

lsusb
sudo usbguard list-devices

3. Generate an initial allow policy from the currently attached devices and review it before installing. The USBGuard documentation recommends exactly this review step.

sudo usbguard generate-policy > /tmp/rules.conf
less /tmp/rules.conf

Each line will look broadly like allow id 1050:0011 serial "" name "..." hash "..." with-interface 03:00:01. Check that every device listed is one you recognize, and that your keyboard rule lists only keyboard interfaces.

4. Install the reviewed policy and start the daemon.

sudo install -m 0600 -o root -g root /tmp/rules.conf /etc/usbguard/rules.conf
sudo systemctl enable --now usbguard

5. Test with an unknown device, for example a spare drive. It should appear as blocked.

sudo usbguard list-devices --blocked

6. When you genuinely need to allow a new device, allow it by number for this session only, or permanently with the -p flag after you have checked its interfaces.

sudo usbguard allow-device <number>
sudo usbguard allow-device -p <number>

7. Forward USBGuard and kernel USB events to your central log so that an unexpected keyboard or network interface on a server shows up somewhere a person will see it. MITRE's T1200 detection guidance for Linux suggests correlating udev and kernel hotplug logs, udisks mounts and DHCP data.

On Windows, the equivalent walkthrough is Microsoft's own Scenario 5 in its device installation guide: prevent installation of all USB devices while allowing only an authorized thumb drive. Follow it exactly as written and test retroactive options on a lab machine before production.

How should an air-gapped site move files in?

An air gap only protects you if what crosses it is controlled; MITRE's T1091 page names removable media as a way onto air-gapped networks. NIST SP 800-82 Revision 3, the Guide to Operational Technology (OT) Security published in September 2023, says that removable media should be protected and its use restricted by policy, and that unauthorized removable media or devices should not be permitted on any node that is part of or connected to the OT network. It allows the control to be procedural or technical, and stresses that physically protecting or encrypting media matters because media holding OT data can give an attacker useful information.

The procedure below builds on that guidance. Adapt it to your site's safety rules and change management process.

The model: three zones and one direction

Think of three zones:

1. Outside. The corporate network or the internet, where files come from: vendor portals, patch catalogs, your own build systems.
2. Staging. A dedicated transfer station that is not part of either network in normal operation. Its only job is to receive files, check them, and write them to transfer media.
3. Inside. The air-gapped or OT network.

Files move outside to staging to inside, never directly. Transfer media used inside never goes back outside without being reformatted.

For data leaving the protected network (logs, historian data, reports), NIST SP 800-82r3 describes unidirectional gateways, or data diodes: hardware that lets data move in only one direction and cannot be reprogrammed to allow the reverse. That removes many routine reasons to carry drives out.

The procedure for every inbound file

1. Request and record. Someone inside asks for a specific file or update by name and version. The request is logged with who asked, why, and which systems will use it. Unrequested files do not cross.
2. Fetch from the authoritative source. Download on the outside from the vendor's or project's official location, along with its published checksum and signature.
3. Verify on the staging station. Check the signature against a vendor public key you obtained and pinned in advance, not one downloaded alongside the file. Then check the hash. Commands are below.
4. Inspect. Run your organization's content inspection at staging, whether a dedicated media scanning kiosk or a hardened workstation, before media touches the inside.
5. Write to controlled transfer media. Use only organization issued drives that are on the allow list inside. Hardware-encrypted drives with a keypad or write-protect switch are a useful category here: a physical write-protect switch set before the drive goes inside prevents an infected inside host from writing back to it.
6. Re-verify inside. On the receiving host or an inside staging host, compute the hash again and compare it to the value recorded at staging. This catches corruption and tampering in transit.
7. Log and close. Record the file name, version, hash, who carried it, and when. Then reformat the transfer media on the staging station before reuse.

Verification commands

Run these on the staging station. Replace file names with yours. The signature check should come first, because a hash only tells you the file matches the hash file, and an attacker who can change one can change both.

# Linux: verify a detached GPG signature, then the checksum list
gpg --verify SHA256SUMS.asc SHA256SUMS
sha256sum --check --ignore-missing SHA256SUMS

# macOS
shasum -a 256 package-1.2.3.tar.gz

# Record the hash you will re-check inside
sha256sum package-1.2.3.tar.gz | tee -a transfer-log.txt

# Windows PowerShell
Get-FileHash .\update-1.2.3.msi -Algorithm SHA256 | Format-List
Get-AuthenticodeSignature .\update-1.2.3.msi

For container images and packages that publish Sigstore signatures or SLSA provenance, verify those on the staging station with the project's documented verification command before the artifact is written to media.

Reformatting transfer media between uses

Warning: the commands below erase the target device completely. A wrong device path will erase the wrong disk, including your system disk. Before every run, unplug every other removable drive, then confirm the device path by size, model and serial.

Check the device path first on Linux:

lsblk -o NAME,SIZE,MODEL,SERIAL,TRAN,MOUNTPOINTS
# Confirm that /dev/sdX is the transfer drive: TRAN should be usb,
# and SIZE, MODEL and SERIAL should match the label on the drive.

Only after that check, create a fresh partition table and file system:

sudo wipefs --all /dev/sdX
sudo parted /dev/sdX --script mklabel gpt mkpart transfer ext4 1MiB 100%
sudo mkfs.ext4 -L TRANSFER /dev/sdX1

On macOS, check first with diskutil list external and confirm the identifier, then erase only that identifier:

diskutil list external
# Confirm diskN is the transfer drive by size and name before continuing.
diskutil eraseDisk ExFAT TRANSFER GPT /dev/diskN

A quick reformat is about hygiene, not sanitization. If a drive has held sensitive data and is leaving your control, follow your media sanitization procedure, which for flash media generally means a cryptographic erase on an encrypted drive or physical destruction, rather than a format.

How do you move software updates and SBOMs into an air-gapped network?

Updates are the most common thing to cross an air gap, and the riskiest, because they will execute on protected systems. Three habits help.

Batch and schedule. A predictable update window means fewer crossings and a clear owner. Emergency crossings get the same procedure with faster approval, not a shortcut.

Bring the bill of materials with the software. A software bill of materials (SBOM) in a standard format such as CycloneDX or SPDX lists the components inside a package or image. Bring the vendor's SBOM across with the update, verify it the same way as the binary, and keep it inside. When a new vulnerability is announced later, you can answer "do we run this component, and where" by searching the SBOMs you already hold, without carrying anything new across the gap. Our post on using SBOMs to find affected products fast covers that workflow.

Move vulnerability data in, not code out. Carrying source code or build outputs out to be scanned elsewhere is the transfer you most want to avoid. Bring signed vulnerability data and scanning capability in instead, and check inside. The air-gapped environment software updates post goes deeper on mirror repositories and update cadence.

Here is a simple decision table for what should cross, and how.

What should happen when a drive is lost?

Treat a lost drive as a security incident. CISA notes that anyone holding an unencrypted drive can read its contents. A workable response:

1. Report quickly. Make reporting blame free, or people will delay.
2. Establish what was on it from the transfer log, the source system or backups.
3. Establish whether it was encrypted. With hardware encryption, or software encryption and a strong passphrase kept off the drive, exposure risk is low. NIST SP 800-111, the Guide to Storage Encryption Technologies for End User Devices, covers the options: full disk encryption, volume or virtual disk encryption, and file and folder encryption. If it was not encrypted, assume the contents are exposed.
4. Act on the contents. Rotate any credentials, keys, recovery codes or configuration secrets that were on the drive. Assess personal data against your breach notification obligations. For OT data such as network diagrams or controller configurations, tell the site's security owner, because NIST SP 800-82r3 notes that OT data on media can help an attacker plan.
5. Record and learn. Ask why that data was on a removable drive at all; the best fix is often a workflow that does not need one.

What do MITRE ATT&CK T1091 and T1200 describe, and which mitigations do they list?

Both techniques are useful as a checklist because they tie the attacker behavior to concrete mitigations.

T1091, Replication Through Removable Media (version 1.3, last modified 24 October 2025). Malware copied to removable media for lateral movement or initial access, including tampering with the media, the systems used to format it, or its firmware. Listed mitigations:

• M1040, Behavior Prevention on Endpoint: block unsigned or untrusted executables from running off USB drives.
• M1042, Disable or Remove Feature or Program: disable AutoRun if it is not needed, and restrict removable media at the policy level if the business does not need it.
• M1034, Limit Hardware Installation: limit the use of USB devices and removable media within the network.

T1200, Hardware Additions (version 1.7, last modified 24 October 2025). Listed mitigations:

• M1035, Limit Access to Resource Over Network: network access control such as device certificates and IEEE 802.1X, and DHCP restricted to registered devices, so an unregistered device cannot reach trusted systems.
• M1034, Limit Hardware Installation: block unknown devices and accessories through endpoint configuration and monitoring.

MITRE's T1200 detection guidance is a good logging template: correlate a new device with a new volume mount, process activity in the same session, and any new network interface. On Windows that includes Security event 6416. We cover each technique in more depth in T1091 explained, T1200 explained and T1052.001, exfiltration over USB.

What does CISA recommend for everyone else?

CISA's "Using Caution with USB Drives" guidance (released 1 February 2021) is short and still sound for homes and ordinary offices:

• Do not plug in drives you do not know. Hand found drives to your security or IT team rather than opening them to find the owner. The drop study shows exactly why.
• Use passwords and encryption, and keep backups, so a lost drive is neither a leak nor a loss of work.
• Keep personal and business drives separate. No personal sticks on work machines, no work sticks in personal computers.
• Disable AutoRun.
• Keep security software and the operating system updated.

CISA also lists devices infected during manufacturing and attackers booting a machine from a USB drive. For the latter, disk encryption and boot restrictions matter as much as port controls.

If public charging ports are your worry rather than drives, our separate post on what is documented about juice jacking covers that evidence.

Common mistakes

• Believing AutoRun was the whole problem. It was the easiest path, and it is mostly closed. Users opening files and parsers handling files automatically are still open.
• Allow listing by vendor and product ID alone. Those values are easy to spoof and shared by every unit of the same model. For transfer drives, use instance IDs or serial numbers, combined with physical control of the drives.
• Applying "prevent" policies retroactively to broad classes. Microsoft warns this can disable the boot disk or network adapter. Test first.
• Setting macOS external storage to ReadOnly and expecting USB drives to mount read-only. They will not mount.
• Trusting a hash that came from the same place as the file. Verify a signature against a key you pinned in advance, then the hash.
• Moving data straight from a laptop to an OT host "just this once." The exception becomes the habit. Everything goes through staging.
• Carrying code or build outputs out to scan them. Bring signed scanning data in instead.
• Treating a lost unencrypted drive as low risk because it was "probably not found." Act on what was on it.
• Banning USB entirely with no alternative. People will route around the ban through personal email or cloud storage, which is harder to see and control.

FAQ

Can a USB drive infect a computer just by being plugged in?

On a current, updated Windows, macOS or Linux system with default settings, a plain storage drive does not run programs automatically. The remaining risks are a device that is not just storage (for example one that also announces a keyboard), a bug in software that previews or indexes files automatically, and a person opening a disguised file. Device controls address the first; updates address the second; a deny execute policy and training address the third.

Is BadUSB still a threat in 2026?

The underlying issue, that a computer trusts what a USB device says it is, remains because that is how USB works. Operating systems now offer accessory approval, allow lists and interface controls; risk is highest on unlocked machines with no device policy.

Will antivirus detect a BadUSB device?

Generally not, because the behavior lives in the device's controller firmware rather than in files on its storage. That is the core finding of the 2014 research. Defenses work at the device trust layer: block unknown devices, flag new keyboard or network interfaces, and require approval for new accessories.

What percentage of people plug in USB drives they find?

In the University of Illinois experiment published in 2016, files were opened on 45 percent of 297 dropped drives and 98 percent of drives were taken, giving an estimated success range of 45 to 98 percent. The first drive was connected within six minutes. It was one campus in 2015, so treat it as strong evidence that the behavior is common, not as a universal rate.

How do I block USB storage but keep my keyboard and mouse working?

On Windows, use Removable Storage Access policies to deny access to removable disks, which does not affect input devices, or use Device Installation Restrictions with an allow list. On Linux, write USBGuard rules that allow your known input devices and block devices presenting mass storage interfaces. On managed Macs running macOS 15 or later, set the external storage mount policy to Disallowed.

Is a hardware-encrypted USB drive safe to use in an air-gapped network?

It protects confidentiality in transit, and a physical write-protect switch stops an inside host writing back to it. Encryption does not make the files trustworthy, so verify signatures and hashes at staging and again inside.

What is a data diode and do I need one?

NIST SP 800-82r3 describes it as hardware that lets data travel in one direction only. It suits letting logs leave an OT network; inbound transfers still need a staging procedure.

How should I verify files before moving them into an air-gapped system?

Download from the official source, verify the publisher's signature against a key you obtained ahead of time, check the SHA-256 hash, record it, and compute it again on the inside after transfer. Use only approved transfer media and log every crossing.

Fix it without waiting for upstream

USB controls protect the path into a machine, but the software that arrives by that path still has to be trusted once it lands. When a laptop is rebuilt or an air-gapped site imports a quarterly batch of updates, open source dependencies and container images come along with it, and keeping those on fixed versions is the part of the problem this section addresses; the fit with USB itself is indirect.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

Where Safeguard fits, honestly

Safeguard does not control USB ports, inspect USB firmware, scan removable media or manage devices; the operating system controls above do that. Where it helps is the "fewer things need to cross" problem. Safeguard can be deployed fully air-gapped, including its AI models running inside your environment, with signed offline snapshot delivery, so dependency inventories, SBOM analysis and vulnerability matching can run inside the protected network instead of code being carried out to be scanned. Outside a full air gap, the local runner scans repositories on a machine you control and sends only encrypted results, which our post on how the local runner and offline mode work explains. The CLI can scan a directory, a container image or an SBOM file you have brought across, for example safeguard scan --sbom vendor-sbom.json, and write results as JSON under ./output.

See how Safeguard would help

These demos show the software side of the problem, not USB hardware. To try them on your own machine, download Safeguard and follow the CLI docs.

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. It shows scanning that happens on hardware you control, which is the same principle behind keeping vulnerability checks inside a protected network rather than carrying code out on a drive.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session. You install the CLI, open the interactive terminal with safeguard, and ask it to "fix the lodash CVE in this repo"; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. On a project that lives inside a restricted network, the same approve each step flow lets an engineer fix a dependency in place, so the fix does not have to be prepared outside and carried in.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• CISA: Using Caution with USB Drives
• MITRE ATT&CK: T1091 Replication Through Removable Media
• MITRE ATT&CK: T1200 Hardware Additions
• Tischer et al.: Users Really Do Plug in USB Drives They Find (IEEE S&P 2016)
• Black Hat USA 2014 talk listing: BadUSB, On Accessories that Turn Evil (InfoCon archive)
• Microsoft Security Advisory 967940: Update for Windows Autorun
• Microsoft Learn: Manage Device Installation with Group Policy
• Microsoft Learn: ADMX_RemovableStorage Policy CSP
• Apple Support: Allow accessories to connect on a Mac laptop with Apple silicon
• Apple Platform Deployment: Storage management declarative configuration
• Linux kernel documentation: Authorizing (or not) your USB devices to connect to the system
• USBGuard project
• USBGuard: Rule language
• NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security
• NIST SP 800-111: Guide to Storage Encryption Technologies for End User Devices
• Safeguard: How the local runner and offline mode work

Last reviewed: 23 October 2026.