License Plate Readers Explained: How ALPR Works and Who Keeps the Data

An automated license plate reader (ALPR) is a camera, usually with infrared lighting, whose software reads the characters on a plate and saves the plate number with a photo, the time and the place. Stored and searched together, those reads become a record of where a car has been. Who keeps them, for how long and who can search them depends on the operator and on state law, which ranges from detailed rules to almost none.

This post goes one level deeper than our look at GPS and GNSS evolution and location privacy and sits beside browser fingerprinting explained. Those posts cover location data your own devices produce; this one covers data a camera on a pole produces about you whether or not you carry anything. Statements about named agencies come from statutes, court opinions, government audits and the agencies' own published documents. We do not name camera makers or data companies, and nothing here explains how to avoid being read.

Key takeaways

• An ALPR system is cameras, character recognition software and a searchable database. Each read stores the plate text, images, time and place, and often vehicle make and colour. One read is a dot; thousands over months are a travel history.
• Most reads are of cars nobody is looking for. California's State Auditor found in February 2020 that 99.9 percent of the 320 million images the Los Angeles Police Department had stored were of vehicles that were not on a hot list when photographed.
• The same audit found none of four reviewed agencies had audited staff searches, three shared images with hundreds of entities or more without checking each recipient, and retention ran from one year to at least five.
• California law (Civil Code section 1798.90.5 and following, in force since 2016) requires a posted policy, access logs that record who searched and why, and sharing only with other public agencies, which the Attorney General said in 2023 excludes out-of-state and federal agencies.
• Other states cap retention: Maine at 21 days, Minnesota at 60 days with a full audit trail and an independent biennial audit.
• The US Supreme Court has not ruled on ALPR; its closest cases are United States v. Jones (2012, a GPS tracker) and Carpenter v. United States (2018, historical cell site records generally need a warrant). In Commonwealth v. McCarthy (April 2020), Massachusetts' highest court applied that reasoning to plate readers: four cameras on two bridges were not a search, but "with enough cameras in enough locations" historic ALPR data would be.
• The security risks are ordinary ones made worse by scale: exposed management interfaces, unreviewed accounts, missing query logs, weak cloud contracts and sharing beyond the original purpose.

How does an ALPR camera work?

California's State Auditor described the system in one sentence that holds for almost every deployment: cameras capture images of plates, "Software extracts the license plate numbers from the images and stores the images, plate numbers, and dates, times, and locations of the image captures in a searchable database." The engineering inside each of those steps explains both why the systems are accurate enough to be widely used and why they still make mistakes.

Infrared illumination and the camera

Most readers pair a near infrared camera with an infrared illuminator. Infrared light is invisible to drivers, so the scene can be lit at night without dazzling anyone, and the retroreflective sheeting used on most plates sends that light straight back, so the plate stands out brightly from the rest of the frame. A very short exposure keeps a fast car from blurring. Many units add a colour camera for a wider overview image of the vehicle, which an investigator uses to confirm a read. The auditor noted that the image "may also show part of the vehicle itself, including individuals within the vehicle," so a read often captures more than the plate.

From image to plate text

Plate recognition is a pipeline, and each stage can fail in its own way.

1. Capture. Fixed cameras watch continuously or are triggered by motion or a road sensor; patrol car cameras capture as the car drives.
2. Plate localisation. A detection model finds the plate region in the frame.
3. Normalisation. The region is straightened, resized and contrast adjusted.
4. Character recognition. The software reads the characters, one at a time or as a whole string.
5. Jurisdiction inference. It guesses the issuing state from layout and fonts, which is harder than reading the characters.
6. Confidence scoring. Reads below a chosen threshold are discarded or flagged.
7. Hot list comparison and storage. The plate is compared with lists of plates of interest and written to the database, matched or not.

Errors cluster in predictable places: look-alike characters such as 0 and O or 8 and B, damaged or dirty plates, and the same string issued by two states, so a correct read with the wrong state matches someone else's car. That is why policies tell officers to confirm a hit visually against the image and the hot list record before acting.

Vehicle attribute recognition

Newer systems also classify body type, make, colour and features such as roof racks. That lets a user search for a car without its plate ("a dark pickup with a ladder rack near this address"), which turns the archive into a search tool for vehicles on no list at all.

Where ALPR cameras are mounted

Hot lists and alerts

A hot list is a list of plates of interest. Agencies build their own and receive lists from state and federal sources; the auditor noted that California's Department of Justice supplies lists covering missing persons, gang members and suspected terrorists. A match raises an alert, often in near real time. A hit is a lead, not proof: the entry may be stale or the read wrong.

What does each ALPR read record?

The fields vary by system, but a typical stored read looks like this.

Some agencies add more. The auditor found two of the four agencies it reviewed adding names, addresses, dates of birth and criminal charges to their systems, at which point the plate database is no longer only a list of plates.

How reads become a location history

One read says a car passed a camera. The auditor described the real value: personnel "can search the accumulated images to determine the vehicles present at particular locations and to track vehicles' movements at particular times."

A worked example shows how fast the dots join up.

• A commuter passes three fixed cameras each way, five days a week: 6 reads a day, about 130 in a month of 22 working days.
• Weekly trips to a place of worship, a gym and a grocery store, one camera each, add about 12 reads a month at places that say something about the driver.
• Over a one year retention period that is roughly 1,700 reads, enough to show where the car usually sleeps, where it goes on weekday mornings and which places it visits regularly. Five years of retention shows changes of job, home and routine.

Patrol car cameras add a second kind of record: a car that drives through an apartment complex every night records which cars are parked there overnight, close to a record of where people sleep. Network density decides how much the history reveals, and a dense, pooled network approaches the "detailed, encyclopedic, and effortlessly compiled" record the Supreme Court described in Carpenter.

The archive, not the alert, is where the privacy questions sit. At the Los Angeles Police Department, "only 400,000 of the 320 million images it has accumulated over several years" produced an immediate hot list match.

Who operates and shares ALPR data?

Four broad groups run plate readers or buy their output, and the same read can pass between them.

Police and other public agencies

California's auditor surveyed 391 police and sheriff departments in 2019: 230 used ALPR and 36 planned to, about 70 percent in all, and roughly 84 percent of operators shared their images. Transportation agencies read plates for tolling and traffic studies under separate rules; California's ALPR statute excludes a transportation agency "when subject to Section 31490 of the Streets and Highways Code," the toll data section.

Private businesses, property managers and homeowner associations

Shopping centres, parking operators, hospitals, campuses and homeowner associations use readers for access, parking and security. Their data is governed by contract, their own policy and whatever state privacy law applies. Some share reads or alerts with local police, which extends a public agency's reach onto private property without it installing a camera.

Repossession firms and commercial data aggregators

Repossession firms read plates while driving routes to find vehicles with defaulted loans. Commercial aggregators pool reads from such collectors and sell search access to lenders, insurers, investigators and government agencies. This is the least visible category, because private vehicles take the reads on public streets and private companies keep them.

How cross-agency sharing works

Most platforms make sharing a setting. The auditor found an agency "could choose to share ALPR images only, to share hot lists only, or to share both," and that an agency without cameras can still search others' images through sharing agreements. Sharing a hot list means a partner's cameras alert on your plates; sharing images means a partner can search your archive.

Convenience was the problem. Fresno and Marin had arranged to share with hundreds of entities each and Sacramento with more than a thousand, and the auditor "did not find evidence that the agencies had always determined whether an entity receiving shared images had a right and a need to access the images or even that the entity was a public agency." The agencies' responses are published with the report.

Federal access to commercial plate data

Federal agencies can buy access to commercial databases instead of running cameras. The Department of Homeland Security's December 2017 privacy impact assessment update for Immigration and Customs Enforcement's use of a commercial LPR service (DHS/ICE/PIA-039(a)) describes the stated controls:

• Every query needs a plate, state, reason code, timeframe and case reference; the service "will not process any queries that do not specify a timeframe."
• Enforcement and removal queries are capped at five years, "the approximate average length of time for vehicle ownership."
• Alert list entries (batch uploads of up to 2,500 plates are allowed) expire after one year unless renewed, and all alert list activity is audited.
• The vendor keeps ICE's audit logs for the contract term or seven years, whichever is sooner, and at contract end transfers records within 30 days and then deletes all copies.

These are the agency's own stated controls, not an independent finding about practice, but they are a useful model: a reason, a time window and a case reference attached to every search.

What do US state laws say about ALPR?

No federal statute sets retention or sharing rules for plate readers. The rules are in state law, and they vary widely.

California: Civil Code section 1798.90.5 and following (SB 34)

Senate Bill 34 (Statutes of 2015, Chapter 532) took effect on 1 January 2016. As the Attorney General's 2023 bulletin summarises it:

1. Definitions. An "ALPR system" is "a searchable computerized database resulting from the operation of one or more mobile or fixed cameras combined with computer algorithms to read and convert images of registration plates and the characters they contain into computer-readable data." Operators (who run a system) and end-users (who access one) can be private or public.
2. Security. Both must keep "reasonable security procedures and practices" against "unauthorized access, destruction, use, modification, or disclosure" (sections 1798.90.51 and 1798.90.53).
3. A posted usage and privacy policy covering purposes, authorised users, monitoring, sharing and retention. The Attorney General warned that a policy buried in a manual without a link from the main web page "may not satisfy" the "posted conspicuously" rule.
4. Access logs. Each access must record date and time, the plate or data used to query, the user and organisation, and "the purpose for accessing the information" (section 1798.90.52).
5. Sharing and public comment. A public agency "shall not sell, share, or transfer ALPR information, except to another public agency, and only as otherwise permitted by law," with hosting and towing carved out, and must offer public comment at a regularly scheduled meeting before starting a program (section 1798.90.55).

SB 34 sets no maximum retention period. In the auditor's 2019 survey, 180 of the 230 agencies using ALPR (nearly 80 percent) kept images for more than six months and about 20 for more than five years, which is why the auditor recommended that the Legislature "specify a maximum retention period for ALPR images."

The Attorney General's 2023 guidance on out-of-state and federal sharing

On 27 October 2023 the California Department of Justice issued Information Bulletin 2023-DLE-06. Because "public agency" covers only the state and California local agencies, it concluded that "SB 34 does not permit California LEAs to share ALPR information with private entities or out-of-state or federal agencies, including out-of-state and federal law enforcement agencies," including through vendor databases that pool many agencies' data. It told agencies to review their data user agreements and attached a template policy.

States with retention caps and audit duties

The California auditor, citing a National Conference of State Legislatures compilation dated 15 March 2019, listed 13 states with maximum retention periods for ordinary reads, most of them six months or less, with longer retention allowed for specific purposes such as investigations.

This is an early 2019 snapshot; legislatures have amended these laws since and some carry sunset dates, so check a state's current statute before relying on a figure. Two examples checked against the current statute text:

• Maine (29-A M.R.S. section 2117-A). Data that is not intelligence and investigative record information or commercial vehicle screening data "may not be stored for more than 21 days." ALPR data is confidential and limited to law enforcement functions and the collecting agency's intended purpose; aggregate reports that do not reveal an individual's activities may be published.
• Minnesota (Minn. Stat. section 13.824). Data "not related to an active criminal investigation must be destroyed no later than 60 days from the date of collection." Access must be role based, "All queries and responses, and all actions in which data are entered, updated, accessed, shared, or disseminated, must be recorded in a data audit trail," and an independent biennial audit is public. If the state finds a pattern of substantial noncompliance, the agency "must immediately suspend operation of all automated license plate reader devices" until authorised to resume.

What did state audits find?

The most detailed public audit is California State Auditor report 2019-118, published on 13 February 2020 at the request of the Joint Legislative Audit Committee. It reviewed the Fresno Police Department, Los Angeles Police Department, Marin County Sheriff's Office and Sacramento County Sheriff's Office in detail and surveyed 391 departments.

The auditor treated the CJIS Security Policy as a model of "reasonable security measures" for ALPR data and recommended a state policy template (which the 2023 bulletin supplied), a statutory retention cap, better vendor contracts, sharing checks and account auditing. Minnesota takes a different route, writing a public biennial audit into the statute so residents can read whether local plate data was used and destroyed as required.

What have courts decided about location tracking and ALPR?

United States v. Jones (2012)

Police attached a GPS device to a suspect's car and tracked it for 28 days. The Supreme Court held that installing and using the device was a Fourth Amendment search, resting on the physical intrusion onto the car. Five Justices, across two opinions, also signalled that long term monitoring of a car's movements raises privacy concerns even without a physical intrusion.

Carpenter v. United States (2018)

Decided on 22 June 2018, Carpenter concerned historical cell site location information (CSLI) obtained from carriers with a Stored Communications Act order that needed only "reasonable grounds." The records held 12,898 location points "cataloging Carpenter's movements over 127 days," about 101 a day. The Court held that acquiring them was a search and that the government "will generally need a warrant." It called such data "detailed, encyclopedic, and effortlessly compiled," a "comprehensive chronicle of the user's past movements," and refused a safe harbour for short requests: "It is sufficient for our purposes today to hold that accessing seven days of CSLI constitutes a Fourth Amendment search."

The Court also called the decision "narrow." It did not "call into question conventional surveillance techniques and tools, such as security cameras." Plate readers sit between those lines: each camera is a conventional tool on a public road, while a dense network with long retention looks more like the comprehensive chronicle the Court described.

How lower courts have applied Carpenter to ALPR: Commonwealth v. McCarthy (2020)

The Massachusetts Supreme Judicial Court decided Commonwealth v. McCarthy on 16 April 2020 under the Fourth Amendment and article 14 of the Massachusetts Declaration of Rights. Police had used readers on the Bourne and Sagamore bridges onto Cape Cod to learn how often the defendant's car crossed over three months and to receive real time alerts, one of which led to his arrest.

The court held that a person "has a constitutionally protected expectation of privacy in the whole of his public movements," but that it was "not invaded by the limited extent and use of ALPR data in this case," which involved "four cameras placed at two fixed locations." It drew the line plainly: "With enough cameras in enough locations, the historic location data from an ALPR system in Massachusetts would invade a reasonable expectation of privacy and would constitute a search for constitutional purposes." It added that the state's one year retention period "certainly is long enough to warrant constitutional protection." Camera count, placement, retention and search use are the variables; the US Supreme Court has not taken an ALPR case.

What are the data security risks of ALPR systems?

Plate data is location data about people mostly suspected of nothing, collected at scale and often held by a third party. The risks are ordinary ones, made worse by volume and by the number of hands the data passes through.

Exposed management interfaces and camera streams

Readers are networked cameras with web interfaces and often live video streams. Like any networked camera, one can end up reachable from the internet through a port forward for remote maintenance, a cellular modem with a public address or a forgotten firewall rule. With default or weak credentials, anyone who finds it can see what it sees and, depending on the device, change settings or read stored data. No camera or console should be reachable from the internet; remote access belongs behind a VPN or managed gateway with strong authentication.

Weak access controls and unread logs

The auditor found "few safeguards for the creation of ALPR user accounts" and that none of the four agencies had audited searches. Shared accounts, accounts that outlive an employee and unreviewed partner accounts mean a search cannot be traced to a person, and a log nobody reads deters nobody. California requires the purpose of each search, Minnesota a full audit trail, and the federal assessment above a reason code and case reference.

Cloud storage and vendor contracts

The auditor listed terms the CJIS policy recommends for cloud contracts: the agency owns the data it uploads, the data stays in the United States or Canada, and vendor staff with access to unencrypted criminal justice information are trained and background checked. A contract silent on storage location, vendor access, breach notice and deletion at exit leaves the agency with no way to enforce any of it.

Sharing beyond the purpose and bad hits

Data collected to find stolen cars can be searched for anything by anyone with access, and every sharing partner adds users and policies the collecting agency never reviewed. Separately, a misread or a stale stolen vehicle entry produces a stop of someone who did nothing; the control is to confirm the characters, the state and the currency of the list entry before acting.

How does ALPR compare with other ways of tracking a car?

Phones, cars and transponders produce data from something the person carries or enabled, so there is at least a setting to change. A plate reader records a car for being on the road, and the only levers are the law, the operator's policy and public oversight. For the device side, see our post on GPS and GNSS location privacy.

Step by step: governing an ALPR program as an operator

This walkthrough is for an agency, city, campus or business that runs readers. It maps the statutes above onto concrete controls. The commands assume a self-hosted PostgreSQL archive on Linux; hosted platforms expose the same controls in their administration settings, and their own documentation is the authority there.

How the legal requirements map to standard security controls

Teams that already work to NIST SP 800-53 Revision 5 can map the ALPR statutes onto controls they already test. The mapping is ours, not an official crosswalk.

Step 1: Write and post the policy

Start from a template if your state has one; California's is attached to Information Bulletin 2023-DLE-06. Name the purposes, the roles that may search, training, retention, sharing, monitoring and the responsible official, and link it from your main web page.

Step 2: Set retention from evidence and enforce it in code

Pick a period based on how old the reads your investigators actually use are, within any statutory cap, then enforce it with a scheduled job rather than manual deletion.

-- Delete reads older than the policy period that are not attached to an open case.
-- Run the same WHERE clause as SELECT count(*) first to check what will be removed.
DELETE FROM plate_reads r
WHERE r.captured_at < now() - interval '60 days'
  AND NOT EXISTS (
    SELECT 1 FROM case_holds h
    WHERE h.read_id = r.id AND h.released_at IS NULL
  );

# Nightly at 02:15, logging the result.
15 2 * * * psql "$ALPR_DB_URL" -v ON_ERROR_STOP=1 -f /opt/alpr/purge.sql >> /var/log/alpr-purge.log 2>&1

Warning: this job permanently deletes data. Before scheduling it, run the conditions as SELECT count(*), confirm the count, and confirm that $ALPR_DB_URL points at the intended database. Apply the same rule to backups and exports, or a five year backup quietly undoes a 60 day purge.

Step 3: Require a reason for every search and read the log

Block searches without a reason code and case number, then have someone outside the users' chain of command review a weekly report and record that they did.

-- Searches in the last 7 days without a case number, by user.
SELECT user_name, count(*) AS searches
FROM alpr_query_log
WHERE queried_at > now() - interval '7 days'
  AND coalesce(case_number, '') = ''
GROUP BY user_name
ORDER BY searches DESC;

Step 4: Review accounts and sharing every quarter

Disable accounts of leavers and role changers, remove shared logins, and record each sharing partner's legal status, agreement and continuing need. In California, partners that are not California public agencies should not be on the list, per the 2023 bulletin.

Step 5: Keep cameras and consoles off the internet

From outside your network, and only against addresses your organisation owns and is authorised to test, confirm nothing answers:

# Check your own public range for camera web or RTSP (554) ports.
nmap -Pn -p 80,443,554,8080,8443 203.0.113.0/28

# Confirm the console's certificate subject and expiry.
openssl s_client -connect alpr-console.example.gov:443 -servername alpr-console.example.gov </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -enddate

Any open port on a camera address is a finding: move the device behind the VPN or gateway, change default credentials and keep firmware on a supported release.

Step 6: Put security and exit terms in the contract

State data ownership, storage location, vendor staff access and logging, the security standard (the CJIS Security Policy for US law enforcement data), breach notice timelines, and transfer plus verified deletion at contract end, including at subcontractors.

Step 7: Inventory the software you build or host

Ingestion services, search applications and their containers are built from open source packages. If you build them, scan each release:

safeguard scan --dir ./alpr-ingest
safeguard scan --image registry.example.gov/alpr/ingest:2026.10
# Results are written as JSON under ./output.

Step 8: Publish aggregates

Publish camera count, reads, hits and searches per month, number of sharing partners and the retention period. Aggregates that reveal no individual let the public judge proportionality.

What can individuals and communities do?

None of this involves avoiding cameras. These are the ordinary tools of public oversight.

File a public records request

Policies, contracts, sharing lists, audit reports and aggregate statistics are usually public records even where the reads themselves are exempt. Ask for the posted policy, the agencies shared with and received from, the retention setting, the vendor contract, search and hit counts for a period, and any audits. Whether you can get reads of your own plate depends on how your state classifies the data.

Use public comment and local ordinances

California requires public comment at a regularly scheduled meeting before a public agency starts an ALPR program. Some cities go further. Seattle's City Council passed Ordinance 125376, the "Surveillance Ordinance" (Seattle Municipal Code chapter 14.18), on 1 September 2017, requiring a surveillance impact report and council approval for covered technologies and a new ordinance for any material change in use. The records it produces for plate readers:

• A 2018 draft impact report for police patrol ALPR, released for public comment, said patrol reads were stored on premises and automatically deleted after 90 days unless exported to an investigation file.
• The council approved the report in April 2021 (Council Bill 120025) and a material update on 18 June 2024 (Council Bill 120778). The city's 2024 equity report says the update expands ALPR to the department's fleet of about 350 vehicles, not yet deployed when the report was written.
• The same report says parking enforcement ALPR data is deleted at the end of each officer's shift and must stay limited to routine parking enforcement.

Whatever you think of a given decision, that is what governance looks like: a written purpose, a stated retention period, public comment, a vote and a report you can check later.

Ask about retention, sharing, audits and private operators

Ask the questions the California audit raised: how long are non-matching reads kept and why, who outside the agency can search them, who reviews the search log and when it was last reviewed, and whether any outside audit is public. If a homeowner association, campus, landlord or employer installs readers, ask for its written purpose, retention, access and sharing terms; where your state gives access and deletion rights against businesses, a plate read tied to an account is personal information.

Common mistakes

• Writing rules for hits, not the archive. The stored reads of cars that matched nothing are most of the data and most of the risk.
• Choosing retention without evidence. The auditor found searches clustered on images up to six months old while policies kept them for one to five years.
• Purging the database but not the backups, exports and partner copies.
• Treating sharing as a checkbox. Every partner adds users; record each partner's legal status, agreement and need.
• Logging searches without a reason field, or never reading the log.
• Port forwarding cameras for remote access, the usual way devices end up on the internet.
• Acting on an unverified hit. Confirm characters, state and that the list entry is current.
• Adding names and charges to the plate database, which turns it into a dossier.

FAQ

How do license plate reader cameras work?

An infrared camera and light photograph plates day and night; software finds the plate, reads its characters and guesses the issuing state, then saves the text with images, time and location and checks it against hot lists of plates of interest.

How long do police keep license plate reader data?

It depends on the state and agency. Maine caps most data at 21 days and Minnesota at 60 days unless tied to an active investigation. California sets no statutory cap, and agencies in its 2020 audit kept data from one year to at least five.

Can police track my car with license plate readers?

A network records a car each time it passes a camera, and stored reads can be searched to reconstruct where it has been. How complete that picture is depends on camera count, placement and retention, and state law and policy govern who may search and why.

Do police need a warrant to search license plate reader data?

The US Supreme Court has not decided. Carpenter (2018) requires a warrant for historical cell site records, and Massachusetts' highest court said in 2020 that a dense enough ALPR network would be a search, but limited ALPR data has generally not required a warrant. State law may add limits.

Who can see license plate reader data?

The operator's authorised users and anyone it shares with. California public agencies may share only with other public agencies, which the Attorney General reads as excluding out-of-state and federal agencies. Private operators follow their contracts and state law.

Are license plate readers legal on private property?

Generally yes in the US, subject to state law. California's statute applies to any "person" operating or using a system, private or public, and general state privacy laws may give individuals rights over the data.

Can I find out if a license plate reader recorded my car?

You can request an agency's policy, sharing list and statistics as public records. Whether it must release reads of your own plate depends on state law, and some states classify ALPR data as confidential.

What did the California license plate reader audit find?

The February 2020 report found that none of four reviewed agencies had a fully compliant policy or audited searches, three shared with hundreds of entities or more without checking recipients, three lacked cloud contract safeguards, and retention far exceeded the age of images usually searched.

Where Safeguard fits

Safeguard does not operate, audit or analyse plate reader cameras, their firmware or their recognition models, and nothing in the governance advice above depends on it. The fit is indirect and sits with the teams that build and host the software around the cameras: ingestion services, search applications, sharing integrations and the containers they run in. Those are assembled from open source packages, and a vulnerable dependency in an archive of location data is a privacy problem as much as a security one. Safeguard scans repositories, container images and SBOM files, builds an inventory of their components, shows which projects carry a given component and version, matches components against vulnerability databases with reachability analysis, and evaluates policies and gates in the platform. It does not tell you whether a system's retention or sharing settings comply with state law, which remains a policy and audit question.

Fix it without waiting for upstream

An ALPR program's search portal, ingestion pipeline and hosting stack are ordinary software built on open source components, and when one of those components has a published vulnerability, millions of stored reads are only as safe as the patched build. The fit with plate reader privacy is indirect, but keeping that software inventoried and patched is part of protecting the archive; the fork and patch route described below is early access.

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.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It asks the assistant to fix a lodash CVE in a repository; the assistant reads the finding and advisory, asks before each command, edits package.json to a fixed version and runs npm install and npm test with approval, pushing nothing. The same flow applies when a scan of an ALPR search portal or ingestion service shows an outdated library: you ask for the upgrade and approve each step.

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

The second demo sets up the local runner on your own machine, approves it with a device code and then scans from the terminal. It suits an agency IT team that wants a component inventory of a self-hosted plate data system before a security review, without sending source code anywhere first.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It helps when you want to ask an assistant which of your projects carry a given component version while you work through the contract and patching steps above.

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

To try it on your own projects, download Safeguard and follow the CLI documentation.

Quick check

Sources

• California State Auditor: Automated License Plate Readers, Report 2019-118 (13 February 2020)
• California State Auditor: Report 2019-118, full PDF
• California Department of Justice: Information Bulletin 2023-DLE-06, California Automated License Plate Reader Data Guidance (27 October 2023)
• California Civil Code section 1798.90.5 and following (California Legislative Information)
• Maine Revised Statutes, Title 29-A, section 2117-A, Use of automated license plate recognition systems
• Minnesota Statutes section 13.824, Automated license plate readers
• Supreme Court of the United States: Carpenter v. United States, No. 16-402 (22 June 2018)
• United States v. Jones, 565 U.S. 400 (2012) (Legal Information Institute)
• Massachusetts Supreme Judicial Court: Commonwealth v. McCarthy, SJC-12750 (16 April 2020), opinion text (CourtListener)
• City of Seattle: Draft Surveillance Impact Report, Automated License Plate Recognition (Patrol), for public comment (8 October 2018)
• City of Seattle: 2024 CTO Surveillance Technology Community Equity Impact Assessment and Policy Guidance Report
• NIST: SP 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations
• Department of Homeland Security: Privacy Impact Assessment Update for the Acquisition and Use of License Plate Reader Data from a Commercial Service, DHS/ICE/PIA-039(a) (27 December 2017)

Related reading: GPS and GNSS evolution and location privacy and browser fingerprinting explained.

Last reviewed: 24 October 2026. State ALPR laws and court decisions change; check the linked statutes and opinions for the current text before relying on them.