Camera Evolution: CCD to Stacked CMOS, and How Camera Privacy Works

Digital cameras began with the charge coupled device (CCD), invented at Bell Labs in 1969 and honoured with the 2009 Nobel Prize in Physics. CMOS active pixel sensors from NASA JPL (early 1990s) replaced it, followed by back illuminated and stacked designs. Camera privacy now rests on indicator lights, OS indicators and per app permissions.

Below: a dated timeline, sensor and USB Video Class tables, how indicator lights work and which ones software can bypass, permissions on each OS with audit commands, documented abuse cases, and what app developers should do.

Key takeaways

• A CCD shifts charge across the chip to one output amplifier. A CMOS active pixel sensor amplifies at every pixel and is made on the same processes as logic chips, which is why it became cheaper, lower power and easier to integrate.
• Back illuminated (BSI) sensors flip the silicon so light reaches the photodiode without passing through wiring. Stacked sensors put the pixel layer on top of a separate logic chip.
• USB Video Class (UVC) is the standard that lets a webcam work without a vendor driver. Versions are 1.0 (2003), 1.1 (2005) and 1.5 (2012).
• A camera light only means something if hardware ties it to the sensor. Researchers disabled the LED on early MacBook iSight cameras in 2014 by reprogramming the camera's firmware from user space.
• iOS shows a green dot for camera use, Android 12 and later shows status bar icons and offers a global camera toggle, macOS lights a green light beside the camera, and Windows uses the camera light or an on screen notification.
• Windows desktop apps cannot be switched off one by one for the camera, and Microsoft says some may still reach the camera when the setting is off. A physical shutter covers every software path for video, but not for audio.
• The FTC's 2013 TRENDnet and 2023 Ring cases were about access control failures, not sensors.

A dated timeline of image sensors and camera privacy

Dates come from the primary sources listed at the end; dates resting on a secondary source are marked.

How did CCD and CMOS sensors differ, and why did CMOS win?

Both sensor types rely on the photoelectric effect. The Nobel committee's press release puts it plainly: in a sensor, light is turned into electric signals, and the hard part was collecting and reading out those signals from a large number of pixels quickly. The committee called the CCD "the digital camera's electronic eye."

How a CCD reads an image. Each pixel collects charge during the exposure. At readout, the chip shifts that charge, row by row and then pixel by pixel, across the silicon to a single output node where it is converted to a voltage. The transfer is clean, which is why CCDs were valued in astronomy and medical imaging, but the whole array is clocked in sequence and conversion lives on separate chips.

How a CMOS active pixel sensor reads an image. NASA's Spinoff account of the JPL work says the CMOS APS "integrates active amplifiers inside each pixel." Each pixel converts its own charge to a voltage, and the rows are addressed like memory. JPL's own release on Fossum's Hall of Fame induction says the design used about one hundredth of the power of its predecessors and could do its own analog to digital conversion on chip.

Why CMOS won. NASA gives the core reason: CMOS image sensors are made with the same processes as microprocessors and other semiconductor devices, so they can be made more easily than CCDs and at lower cost. Add on chip conversion and low power and you get the economics of a phone camera.

Security note. The integration that made CMOS cheap is also why a modern camera module is a small computer. Once timing, conversion and processing sit next to the pixels, the camera has registers, firmware and a control bus. The iSeeYou research described below depended on exactly that: a register in the image sensor and firmware on the camera's USB controller.

What are BSI and stacked sensors?

Back illuminated (BSI) sensors

In a conventional front illuminated sensor, light enters from the side where the metal wiring and transistors are built, so some of it is blocked or scattered before reaching the photodiode. A back illuminated sensor turns the silicon over and thins it so light enters from the back. Sony Semiconductor Solutions says it developed a back illuminated CMOS sensor product in 2009 with roughly double the sensitivity of conventional front illuminated products, while also reducing noise, because light no longer has to get past wiring and transistors.

Stacked sensors

A BSI sensor still needs a supporting substrate under the thinned pixel layer. Sony's description of the stacked structure is that the supporting substrate is replaced by a second chip that carries the signal processing circuit, placed under the pixel section. Each layer can then be built on the process that suits it: one tuned for image quality, the other for logic performance. We could not confirm a first shipping date for stacked sensors on a primary page, so the timeline leaves it out.

What is computational photography and where does it run?

Computational photography builds the final image from processing, not one exposure: merging frames for dynamic range, stacking them to cut noise, estimating depth to blur a background.

The work is split across several places:

• On the sensor stack. Stacked sensors can do early processing such as fast readout and some HDR combining on the logic layer, per Sony's description of what the stacked structure enables.
• In the image signal processor (ISP). Phone and laptop SoCs include an ISP that demosaics raw data, removes noise, balances colour and runs the multi frame pipelines. The ISP runs its own firmware.
• On neural or GPU hardware. Segmentation, depth estimation, face detection for exposure and many night modes use machine learning models on the SoC's neural engine or GPU.

Two security points follow. First, a frame passes through sensor registers, ISP firmware, kernel drivers and user space frameworks before an app gets it, so the camera's trust boundary is a chain, not one chip. Second, a face can be reconstructed or replayed from video. The iSeeYou authors note that Android's early Face Unlock was defeated shortly after release by holding a picture of the owner's face to the camera, and they point out that covert video could be used to defeat face recognition logins. Treat face images as sensitive data.

What is USB Video Class and which versions exist?

USB Video Class (UVC) is the USB device class for cameras. A UVC device describes itself with standard descriptors (USB interface class 14, "Video"), and the host OS loads a generic class driver for it. That is why a plain USB webcam works on Windows, macOS and Linux without installing anything.

USB-IF confirms the 1.5 document set, including H.264 and VP8 payload documents; the earlier revision dates come from a secondary summary. We did not find a later public UVC version.

Extension units: where the generic driver ends

UVC defines standard controls such as exposure, focus and white balance. Vendors add their own through extension units (XUs). The Linux kernel's UVC driver documentation describes two ways to reach them: control mappings that expose XU controls as normal V4L2 controls, and a driver specific interface for applications that need direct XU access, "e.g. for testing purposes, firmware upload" and similar. In other words, the standard class has a vendor shaped door in it, and on some devices that door leads to firmware.

How do camera indicator lights work, and which are hardware tied?

An indicator is only as trustworthy as the thing that drives it. There are three broad designs.

1. Software controlled LED

The LED is a GPIO pin that firmware or a driver switches on when it starts streaming. Anything that can change that firmware or driver can stream without lighting it. The iSeeYou paper notes that at least one consumer webcam shipped with an explicit "LED control" setting, and the authors call such controls "a very bad idea": giving the user the power to disable a privacy feature gives malware the same power.

2. Hardware interlocked LED

The LED is wired to a signal that must be active for the sensor to produce images. The first generation internal iSight in some MacBook and iMac models did this. Per Brocker and Checkoway, the LED was connected to the image sensor's STANDBY line: when STANDBY was asserted the LED was off and the sensor stopped outputting data, so it looked impossible for firmware to stream with the light off.

The researchers found that the Micron image sensor had a configuration register that could tell the sensor to ignore STANDBY. The camera's USB controller loaded its firmware from the host at startup, so an unprivileged user space program could load modified firmware that kept STANDBY asserted (LED off) while the sensor, told to ignore STANDBY, kept producing frames. They also showed the controller could pose as a USB keyboard to escape a virtual machine that had the camera passed through.

Scope matters. The authors stress that the LED result "only applies to the first generation internal iSight webcams," and they make no claim about later FaceTime cameras. They disclosed it to Apple on 16 July 2013, built a kernel extension that blocked firmware changes from user space, and concluded that the correct fix is in hardware.

3. Indicator enforced by dedicated silicon or system architecture

Apple's Platform Security guide, in a page published 11 March 2026, describes the camera indicator on MacBook Neo. It says the design combines system software with dedicated silicon in the A18 Pro to protect the camera feed, and is designed so that no untrusted software, "even with root or kernel privileges," can engage the camera without visibly lighting the on screen indicator. That is a different design from a discrete LED: the indicator is drawn on the display, and the guarantee comes from the silicon controlling the camera path.

The same guide describes a related hardware control for audio. Apple silicon Mac laptops and Intel Mac laptops with the T2 chip disconnect the microphone in hardware when the lid closes, designed so that no software, even with root or kernel privileges or firmware on the T2, can engage it. Apple notes the camera is not disconnected on lid close because the closed lid blocks its view.

Comparing indicator designs

An OS indicator is a strong signal against an ordinary app, and a weaker one against code that already controls the kernel or the camera's firmware.

What OS privacy indicators exist on iOS, Android, macOS and Windows?

iOS and iPadOS

Apple's iPhone User Guide says that whenever an app uses the camera, including camera and microphone together, a green indicator appears. An orange indicator appears when an app uses the microphone without the camera. A message at the top of Control Center tells you when an app has recently used either. These indicators arrived with iOS 14 in 2020; Apple's page documents the behaviour but does not name the release.

Android

The Android Open Source Project documentation says that on Android 12 or higher, status bar icons appear whenever an app has ongoing access to the microphone, camera or location. The icon first appears in full, then shrinks to a dot that stays until the app is dismissed or closed. Tapping it in Quick Settings shows which apps are using what.

AOSP defines camera use as active if the system marks it running or it is under five seconds old; a "recent access" indicator covers the prior 15 seconds. The System UI draws the icons from app ops records of each access.

Android 12 also added camera and microphone toggles. Android's developer documentation says supported devices let users turn camera and microphone access off for every app at once, with a single toggle in Quick Settings or on the Privacy screen in system settings.

macOS

Apple's Mac User Guide says the camera turns on when you open an app that can use it, and a green light beside the camera glows to show it is on. The camera and light turn off when all apps that can use the camera are closed. MacBook Neo, as covered above, uses an on screen indicator enforced by dedicated silicon.

Windows

Microsoft's "Windows camera, microphone, and privacy" page says that if a device has a camera light, it turns on when the camera is active. If it does not, Windows shows a notification when the camera turns on or off. For the microphone, an icon appears in the taskbar notification area when an app is using it. Microsoft does not describe the camera light as hardware interlocked; that depends on the device's design.

Browsers

The W3C Media Capture and Streams specification, a Candidate Recommendation Draft dated 9 October 2025, puts privacy indicator requirements on the browser itself. The browser must tell the user when access to a camera or microphone changes and when capture starts or stops, and any off to on change must stay visible long enough for a reasonably observant user to notice, which the spec says should be at least 3 seconds.

How do camera permissions work on each OS, and how do you audit them?

iOS and iPadOS

Apps must ask before using the camera or microphone, and must explain why. In Settings, open Privacy & Security, then Camera: the list shows every app that has asked, with a switch for each. Apple's developer documentation explains the mechanics: an app must include an NSCameraUsageDescription string in its Info.plist, the system shows that string in the permission alert the first time, and it remembers the answer, so the alert does not appear again. Users change it later in Settings.

Android

Camera is a runtime ("dangerous") permission, android.permission.CAMERA, requested at runtime on Android 6.0 (API level 23) and higher. Users see and change it under the app's permissions screen or the Privacy settings, and on Android 12 and later the global camera toggle overrides individual grants.

macOS

macOS applies the same consent model. Apple's developer documentation says that on macOS 10.14 and later the user must grant each app access to the camera and microphone. Sandboxed apps also need the com.apple.security.device.camera entitlement. In System Settings, open Privacy & Security, then Camera, and switch apps on or off. Apple notes that FaceTime, Photo Booth and other built in apps have access automatically. For websites, Safari keeps a separate per site camera setting under Settings, Websites, Camera.

Windows

Windows has three layers under Settings, Privacy & security, Camera:

1. Camera access: a device level switch. If it cannot be changed, an administrator controls it.
2. Let apps access your camera: covers Microsoft Store apps, each with its own switch.
3. Let desktop apps access your camera: one switch for all desktop apps. Microsoft says desktop app camera settings "can't be changed at an individual desktop app level," and that desktop apps may not appear in the list and may still reach the camera even when these settings are off.

Windows Hello sign in uses the camera even when app access is off, and browsers and video conferencing apps count as desktop apps.

Browsers

The W3C specification defines "camera" and "microphone" as policy controlled features with a default allowlist of "self", so a site can switch them off for itself and any embedded frames with a Permissions Policy header. The interfaces are restricted to secure contexts.

Step by step: audit camera devices and permissions

These commands are read only unless noted. They show what cameras exist, which process has one open and which apps hold permission.

1. Linux: list cameras and see who is using one.

# List video devices and their drivers (package: v4l-utils)
v4l2-ctl --list-devices

# Show UVC interfaces on USB (class 14 is Video)
lsusb -v 2>/dev/null | grep -B4 -A2 "bInterfaceClass *14"

# Is the generic UVC driver loaded?
lsmod | grep uvcvideo

# Which processes have a camera node open right now?
sudo fuser -v /dev/video*
sudo lsof /dev/video* 2>/dev/null

If you never use the built in camera on a Linux workstation, you can stop the UVC driver from loading. This changes system configuration, so record the original state first.

# Check first: confirm the camera you want to disable uses uvcvideo
v4l2-ctl --list-devices
lsmod | grep uvcvideo

# Unload now (fails if a process holds the device)
sudo modprobe -r uvcvideo

# Keep it from loading at boot
echo "blacklist uvcvideo" | sudo tee /etc/modprobe.d/disable-webcam.conf

Note that this disables every UVC camera on the machine, including external ones.

2. macOS: list cameras and reset camera permissions.

# List built in and attached cameras
system_profiler SPCameraDataType

# Reset camera permission for one app (it will ask again next time)
tccutil reset Camera com.example.someapp

# Reset camera permission for every app
tccutil reset Camera

tccutil reset removes stored decisions. Apps will prompt again, so run it when you want a clean slate, not as a routine check. To review without changing anything, use System Settings, Privacy & Security, Camera.

3. Windows: list cameras and review access settings.

# List camera devices (older webcams may register under the Image class)
Get-PnpDevice -Class Camera,Image -PresentOnly | Format-Table Status,Class,FriendlyName,InstanceId

# Read the per app camera consent entries for the current user (read only)
Get-ChildItem "HKCU:\Software\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\webcam" -Recurse |
  Get-ItemProperty | Select-Object PSChildName, Value, LastUsedTimeStart, LastUsedTimeStop

The registry location is an implementation detail that Microsoft's support pages do not document, so treat its contents as a hint and confirm in Settings. To turn a camera off at the device level, an administrator can disable it in Device Manager or with PowerShell:

# Check first: copy the exact InstanceId from the listing above
Get-PnpDevice -Class Camera -PresentOnly

# Disable that one device (asks for confirmation)
Disable-PnpDevice -InstanceId "<paste InstanceId here>" -Confirm

4. Android: check and revoke camera grants with adb.

# Which packages hold the camera permission, and is it granted?
adb shell dumpsys package com.example.someapp | grep -i "android.permission.CAMERA"

# When did an app last use the camera?
adb shell appops get com.example.someapp CAMERA

# Revoke the grant (the app will need to ask again)
adb shell pm revoke com.example.someapp android.permission.CAMERA

pm revoke changes the app's state. On a managed fleet, prefer the device policy console so the change is logged.

5. iOS and iPadOS. There is no shell. Open Settings, Privacy & Security, Camera, and switch off any app that does not need it. After a call or a capture session, open Control Center: the top line tells you which app recently used the camera or microphone.

6. Browsers. Open the browser's site settings for camera and remove sites you no longer use. For sites you run, send a Permissions Policy header that turns camera off everywhere except the pages that need it:

Permissions-Policy: camera=(), microphone=()

What documented camera abuse cases and research exist?

These come from regulator releases and peer reviewed research.

Lower Merion School District (2008 to 2010)

The iSeeYou paper summarises court and press records: from the start of the 2008 school year, a Pennsylvania school district issued MacBooks with remote administration software that could capture webcam images, and over 18 months officials captured more than 30,000 images. The paper notes the indicator LED worked as designed, flashing briefly with each capture, which is how people first noticed.

TRENDnet SecurView cameras (FTC, 2013)

The FTC announced on 4 September 2013 that TRENDnet, which marketed its SecurView internet connected cameras for home security and baby monitoring and called them "secure," had settled charges. According to the FTC, faulty software let anyone who knew a camera's internet address watch, and in some cases listen to, the feed. A hacker exploited the flaw in January 2012, and links to live feeds from nearly 700 cameras were later posted. The FTC also said the company sent login credentials over the internet in readable text and its mobile apps stored them in readable text. The order required a security program and third party assessments every two years for 20 years.

Ring (FTC, 2023)

On 31 May 2023 the FTC said Ring had let employees and contractors access customers' private videos without adequate restrictions. One employee viewed thousands of recordings from female users' cameras, including in bedrooms and bathrooms, and Ring could not determine how many others had done similar things because it lacked basic monitoring. The FTC also alleged that hackers used credential stuffing and brute force attacks to reach stored videos, live streams and account profiles of about 55,000 US customers, and that some used two way audio to harass people. Per the FTC, Ring saw credential stuffing in 2017 and 2018 but added multi factor authentication only in 2019. The proposed order required $5.8 million in refunds and a privacy and security program with multi factor authentication for employee and customer accounts.

iSeeYou (USENIX Security, 2014)

Covered in detail above: an LED that was hardware interlocked in principle, bypassed through a sensor register and reloadable controller firmware, on one generation of one manufacturer's camera.

Remote access tools

The iSeeYou authors describe "ratters" who install remote administration tools to watch victims through the webcam. Such malware usually runs as a normal user, where an OS indicator and a hardware tied light both still work.

Do covers and shutters help?

Yes, for video. A physical shutter or opaque cover blocks the lens no matter which software path is streaming, including firmware that has silenced an LED. That is why the iSeeYou paper mentions both that people taped over webcams and that some teachers in the Lower Merion case covered their own lenses.

Limits to know:

• Audio is untouched. A cover does nothing for the microphone. On laptops, the hardware microphone disconnect on lid close (where the vendor provides it) is the audio equivalent.
• Thin laptops. A thick cover can stop a lid from closing flat. Check your laptop maker's guidance before sticking anything on the bezel, and prefer a built in shutter where the laptop has one.
• Other cameras. Infrared and depth cameras used for face sign in sit next to the colour camera. A cover over one lens may leave another uncovered.
• Built in shutters and kill switches. Some laptops ship with a sliding shutter or a switch that cuts power to the camera. Either is better than an add on cover because it is designed for that lid and bezel.

What should app developers do to request camera access responsibly?

The platform guidance converges on the same rules. Android's permissions guide lists them as principles: ask "in context, when the user starts to interact with the feature," do not block the user, let them cancel any explanation, and degrade gracefully if they say no.

iOS and macOS

Write an honest NSCameraUsageDescription that names the feature, request access only when the user starts that feature, and handle denial. On macOS, enable the camera entitlement in Signing & Capabilities. Apple warns that the app must contain the right Info.plist key, and the entitlement on macOS, before it requests authorization or tries to use a capture device.

import AVFoundation

func startScanFlow() {
    switch AVCaptureDevice.authorizationStatus(for: .video) {
    case .authorized:
        beginCapture()
    case .notDetermined:
        AVCaptureDevice.requestAccess(for: .video) { granted in
            DispatchQueue.main.async { granted ? beginCapture() : showManualEntry() }
        }
    default:
        // Denied or restricted: offer another path, do not nag
        showManualEntry()
    }
}

Android

Request CAMERA at the moment the user taps the feature, show a rationale when the system says one is needed, and offer an alternative path when the user declines. Android also lets you add a rationale activity (the VIEW_PERMISSION_USAGE intent filters) that opens from an information icon on your app's permission page or the Privacy Dashboard.

private val requestCamera =
    registerForActivityResult(ActivityResultContracts.RequestPermission()) { granted ->
        if (granted) startScanner() else showManualEntry()
    }

fun onScanClicked() {
    when {
        ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA) ==
            PackageManager.PERMISSION_GRANTED -> startScanner()
        shouldShowRequestPermissionRationale(Manifest.permission.CAMERA) ->
            showRationaleThen { requestCamera.launch(Manifest.permission.CAMERA) }
        else -> requestCamera.launch(Manifest.permission.CAMERA)
    }
}

Web

Call getUserMedia after a user action, request only the kind you need, and stop tracks as soon as you are done so the indicator goes off. The W3C revocation algorithm ends live tracks when permission is revoked, so handle the track ending.

async function startVideo() {
  const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: false });
  const [track] = stream.getVideoTracks();
  track.addEventListener("ended", () => showCameraStopped());
  return stream;
}

function stopVideo(stream) {
  stream.getTracks().forEach((t) => t.stop()); // releases the camera and clears the indicator
}

Rules that apply on every platform

• Ask late and once. Ask when the user starts the feature, not at install or first launch.
• Release the camera as soon as the feature ends. An app that holds the camera in the background keeps the indicator lit and erodes trust in it.
• Never ship a way to turn off the indicator. The iSeeYou authors' advice applies to products too.
• Keep frames on device where you can, and say who can review any you upload.
• Require MFA for any account that can view a camera feed, and never send credentials in readable text. Both appear in FTC orders above.
• Inventory your media dependencies. Camera SDKs, codec libraries and WebRTC stacks are third party code that parses data from a device or the network.

For connected camera makers, NIST IR 8259A (May 2020) sets out a core baseline of device cybersecurity capabilities: device identification, device configuration, data protection, logical access to interfaces, software update and cybersecurity state awareness. It is a starting point for deciding what a camera you build or buy should support.

Where Safeguard fits, honestly

Safeguard does not see your camera, read indicator state, manage device permissions or scan camera firmware. The overlap is the software that handles camera data. A video calling app, a document scanner or a doorbell companion app pulls in camera SDKs, image and video codec libraries and WebRTC stacks as dependencies, and those ship inside your repositories and container images. Safeguard scans repositories, container images and SBOM files, matches components against vulnerability databases, ranks findings with reachability analysis and shows which projects carry a given component and version, so you can find every app that bundles a vulnerable media library and update it.

Common mistakes

• Trusting any light. A software driven LED proves nothing against code that controls the camera's firmware. Know which kind your device has.
• Leaving the LED control on. Some webcam utilities let you disable the light. Do not, and do not ship that option.
• Assuming the Windows camera switch covers everything. Desktop apps share one switch, and Microsoft says some may still reach the camera when it is off. Use the device level switch or disable the device if you need certainty.
• Forgetting Windows Hello and IR cameras. Hello uses the camera regardless of the app setting, and IR and depth cameras sit beside the colour one.
• Covering the lens and forgetting the microphone. A shutter blocks video only.
• Leaving default credentials on IP cameras. Both FTC cases involved access control failures, not sensor flaws.
• Ignoring media libraries in your dependency inventory. Image and video parsers are classic places for memory safety bugs.

FAQ

What is the difference between CCD and CMOS camera sensors?

A CCD moves charge across the chip to one output amplifier; a CMOS active pixel sensor converts charge to voltage inside each pixel and digitises on chip. CMOS is cheaper, lower power and built on standard chip processes, so it took over phones and webcams.

Who invented the CCD and the CMOS image sensor?

Willard Boyle and George Smith invented the CCD at Bell Labs in 1969 and shared the 2009 Nobel Prize in Physics. Eric Fossum's team at NASA JPL invented the CMOS active pixel sensor in the early 1990s.

Can a webcam record without the light turning on?

It depends on the design. Researchers showed in 2014 that first generation MacBook iSight cameras could, by reprogramming the camera's firmware from user space. Indicators enforced in hardware or dedicated silicon are designed to prevent this.

What does the green dot on my iPhone mean?

An app is using the camera, or the camera and microphone together. An orange dot means the microphone alone. Control Center shows which app recently used either.

How do I turn off the camera for all apps on Android?

On Android 12 and later, on supported devices, use the camera access toggle in Quick Settings or on the Privacy screen in system settings. It applies to every app until you turn it back on.

How do I see which apps can use my camera on Windows 11?

Open Settings, Privacy & security, Camera. Store apps have individual switches; desktop apps share one switch, and Windows Hello is an exception.

What is USB Video Class (UVC)?

The USB standard that lets webcams work with a generic driver. Versions are 1.0 (2003), 1.1 (2005) and 1.5 (2012), which added H.264 and VP8.

Should I put tape over my laptop camera?

A cover blocks video from any software path, so it is a reasonable extra step. It does not block the microphone, and a thick cover can stop a thin laptop lid from closing properly.

Fix it without waiting for upstream

Camera privacy is mostly a device and OS question, so the connection here is indirect. It still matters because every app that touches the camera ships open source codec, image and WebRTC libraries, and those dependencies need the same patch discipline as anything else you build.

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.

To try it on your own machine, download Safeguard from https://safeguard.sh/download and see the CLI documentation at https://docs.safeguard.sh/docs/cli .

See how Safeguard would help

The first demo is a real Safeguard CLI session: asked to fix a lodash CVE, 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 approval, and pushes nothing. The same approve each step flow applies when a media or WebRTC library in your camera app needs an upgrade. It covers your app's dependencies, not the camera hardware.

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

The second demo sets up Safeguard's local runner on your own machine, approves it with a device code, and runs a scan from the terminal. Run it against the repository of a video or scanning app to see which codec and capture libraries it pulls in.

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

The third demo is a real Android session: you send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. It is the same principle as a good camera prompt: the person decides each time, in context.

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

Related reading: how to check a phone for a keylogger on Android and iOS, what iPhone Communication Safety does for kids, USB and Thunderbolt evolution and DMA attacks, BadUSB, lost drives and air gapped transfer and memory evolution from core to DDR5, HBM and CXL.

Quick check

Sources

• Nobel Prize in Physics 2009: press release (CCD, Boyle and Smith)
• Nobel Prize in Physics 2009: summary
• NASA JPL: National Inventors Hall of Fame taps former JPL engineer (CMOS APS, Photobit)
• NASA Spinoff 2010: CMOS active pixel sensor
• Sony Semiconductor Solutions: back illuminated structure
• Sony Semiconductor Solutions: stacked structure
• USB-IF: Video Class v1.5 document set
• Wikipedia: USB video device class (secondary summary of UVC revision history)
• Linux kernel documentation: the Linux USB Video Class (UVC) driver
• Brocker and Checkoway, iSeeYou: Disabling the MacBook Webcam Indicator LED, USENIX Security 2014 (PDF)
• Apple Platform Security: Mac on screen camera indicator light
• Apple Platform Security: hardware microphone disconnect
• Apple iPhone User Guide: control access to hardware features
• Apple Mac User Guide: control access to the camera
• Apple Developer: requesting authorization to capture and save media
• Android Open Source Project: privacy indicators
• Android Developers: behavior changes in Android 12 (camera and microphone toggles and indicators)
• Android Developers: request runtime permissions
• Android Developers: explain access to more sensitive information
• Microsoft Support: Windows camera, microphone, and privacy
• Microsoft Support: manage app permissions for your camera in Windows
• W3C: Media Capture and Streams, Candidate Recommendation Draft
• FTC: Marketer of internet connected home security video cameras settles FTC charges (TRENDnet), 4 September 2013
• FTC: FTC says Ring employees illegally surveilled customers, 31 May 2023
• NIST IR 8259A: IoT Device Cybersecurity Capability Core Baseline

Last reviewed: 23 October 2026.