Times Car Breach: 1.46M ID Images and the Cost of Keeping Them

On 23 October 2026 Park24 closed the forensic investigation into the Times Car breach. Its final figures: 6,628,007 accounts with traces of access and outbound transfer, plus 1,464,800 encrypted identity document images sent out. It booked a ¥5.5 billion special loss. Members should expect targeted phishing. Teams that collect ID images should cut how long they keep them.

Park24 (パーク２４, TSE Prime, securities code 4666) runs the Times brand of parking and mobility services in Japan. Its consolidated subsidiary Times Mobility operates Times Car, a car sharing service that asks every new member to upload a driving licence and, depending on the plan, other documents. The breach was first disclosed on 25 September. What is new this week is the fifth report, the matching timely disclosure to the Tokyo Stock Exchange and a separate disclosure of the financial hit, all published on 23 October.

This post is built from Park24's own reports. The change that matters most for anyone who builds identity checks into an app: Park24 had kept ID images for the whole membership and for seven years after a member left, and it is now deleting them as soon as registration checks finish. Park24 has not named the vulnerability, the product or the attacker, and has withheld attack details "to prevent secondary damage." We do not guess at any of them.

What happened

Park24 detected unauthorized access to the Times Car web system at 09:07 JST on Friday 25 September 2026. That day it isolated the server, started an outside forensic investigation, reported to the Personal Information Protection Commission (PPC) and published a first notice. By 07:25 the next morning it had blocked the route in and confirmed the attacker could no longer reach the system. Reports followed on 28 and 29 September (counts), 16 October (retention rule) and 23 October (final results). Park24 also notified the police and the Ministry of Land, Infrastructure, Transport and Tourism (MLIT).

The fifth report confirmed something the earlier reports had not: in connection with the same incident, the attacker reached a second system, the Times Club web system, which serves Park24's broader membership programme.

Timeline

Times are Japan Standard Time and appear only where a source gives one. All entries come from park24.co.jp unless noted.

What is still unknown

• The vulnerability. Park24 says a vulnerability in the web system was exploited. It has not said whether that was in custom code, a framework, a library, a commercial product or a configuration, and it has not cited a CVE.
• Dwell time. The reports give a detection time, not an entry time. Park24 has not said how long the attacker was inside before 09:07 on 25 September. One English language news report said the access took place "at the beginning of the month"; we could not find that statement in any of Park24's own notices, so we do not rely on it.
• The key question. The ID images were stored encrypted. Park24 says the attacker explored the system and used information found there to reach the database and file storage areas. It has not said where the decryption keys lived, or whether the attacker could reach them.
• Who did it. No attribution, no ransom note and no leak site claim appear in any Park24 notice. Park24 says it has seen no evidence so far that the data was sold or published.
• The Times Club path. The fifth report says Times Club was also accessed in connection with this incident. It does not say how the attacker got from one system to the other.

The final numbers

The fifth report and the TSE disclosure carry the same tables. The figures below are Park24's final counts from the completed investigation. Park24 says no further scope has been found so far.

Times Car web system

Three notes from Park24 travel with this table:

• The 6,628,007 figure includes customers who only rent parking spaces and pay by card. Park24 explains that contracts signed up through the Times Business Service "Kantan" route are managed inside the Times Car web system, so those parking customers were in the same store.
• The second report had said nine linked service IDs were exposed, naming the JR West group's WESTER ID among them. The final count is four, and WESTER ID is zero.
• Park24 says the ID images were encrypted, so a trace of access or transfer "does not immediately mean" the images could be viewed. It adds that it cannot completely rule out future decryption of the encrypted data that was sent out.

Times Club web system

Park24 also says identifiers used for member management and system operations were accessed and sent out, without a count. It states that it does not hold full card numbers or security codes at all, so card data cannot be misused. Japan's PPC notes on its own breach reporting page that a leak of only the last four digits and the expiry date of a card does not by itself trigger a mandatory report.

Accounts or images?

One point of care. The third report counted about 1.6 million accounts with document images. The fifth report speaks of about 1.6 million items of image data, of which about 1.46 million were sent out. Park24 counts in 件 (items) throughout. Members on student and family plans could have more than one image on file, so we treat 1,464,800 as a count of image records, not as a count of people, and we avoid the phrase "1.6 million licences leaked."

What kind of documents

The third report lists four document types among the exposed images:

• Driving licence images
• Proof of current address images, for example a utility bill
• Student ID images, for members on a student plan
• Family relationship document images, for members on a family plan

Technical details

Park24 has published no CVE, no affected product or version, no file names, no hashes and no indicators of compromise. It says it is withholding attack details and system configuration "to prevent secondary damage." So this section sets out the concrete, defender useful specifics that the primary sources do contain, and marks clearly where they stop.

Attack path, as far as Park24 describes it

The forensic findings, as stated in both the fifth report and the TSE disclosure, describe three stages:

1. Initial access: a vulnerability that existed in the web system was exploited to get in.
2. Discovery: the attacker searched information inside the system.
3. Data access: the attacker used the information obtained in step 2 to access the database and the file storage area.

That middle step is the one to study. Park24 does not say what "information in the system" was used. In most web stacks, what turns a foothold on an application server into a read of the database or object store is connection strings, service credentials, cloud role tokens and API keys in config files, environment variables or a metadata service. We are not saying that is what happened here; it is the class of material to check first in your own stack.

Containment specifics

From detection to confirmed block took a little over 22 hours. Park24 also said in its first and second reports that services kept running normally throughout.

Data at rest, as described

The encryption scheme, key management, key location and whether the image files and their keys sat in the same trust zone are not described.

Retention rule, before and after

Park24 says it kept the images to run registration checks, to handle suspected misuse, to answer enquiries and for other identity confirmation work, and that it managed them under internal rules and its own retention standard. After deletion it will keep "information to confirm identity" with the stored image, so that it can check a document again if a member raises an enquiry later. It does not say what form that information takes. A cryptographic digest of each image is one common way to do this, because it lets you confirm that a document presented later is byte for byte the same as the one checked, without holding the picture.

Official contacts

Park24 lists a 24 hour hotline, 0120-25-8924, and an inquiry form at share.timescar.jp/inquiry.html. It says it will never ask for passwords or card details by email, SMS or phone. Anyone who receives a call or message claiming to be about the breach and asking for either should treat it as phishing.

What there is not

We found no IOCs (IP addresses, domains, hashes, user agents) published by Park24, the PPC, the police or any national CSIRT. If a list of "Times Car IOCs" circulates, check its origin before you build detections from it.

Why the retention rule was the multiplier

Look at who is in the 6,628,007. The second report says the affected group includes current members, withdrawn members and people who applied but never completed sign up, plus current and former Times Business Service members. The third report and the 16 October rule change explain why that group is so large: images were held for the whole membership and for seven years after a member left.

A store that only holds images for people being checked this week is small. A store that holds every image ever checked, plus seven years of former customers, grows every year whether or not the business does.

The design review question is not only "is the file store encrypted" but "why is this file here at all." A licence image has done its job once the check passes. After that it is mostly risk: it can help a fraudster pass someone else's identity checks, and unlike a password it cannot be rotated.

NIST's identity proofing guidance (SP 800-63A, revision 4) asks identity services to publish a retention schedule for identity records, to say at collection time what will be kept and for how long, and to have a documented deletion process.

What the breach cost, by Park24's numbers

Park24's separate 23 October disclosure gives the financial picture.

The ¥5,500 million special loss covers the goodwill payments to customers whose encrypted ID images show transfer traces, plus other response costs. Park24 has not broken the total down. The annual dividend forecast of ¥65 per share is unchanged. Park24 also says membership numbers in its mobility business were affected for a while after the disclosure, while daily sales held at the level they were at before the incident.

Some rough arithmetic of our own, not Park24's: ¥5.5 billion over 6,628,007 accounts is about ¥830 per account. Over 1,464,800 transferred image records it is about ¥3,750 per record. If each transferred image record matched one eligible person, the ¥3,000 payments alone would be about ¥4.4 billion, but Park24 has not said how many people are eligible, and the payment form (cash or vouchers) and method are still being decided. Treat these as orders of magnitude, not as reported figures.

The legal exposure may not end there. MLex reported on 21 October that a Japanese lawyer is preparing a joint damages suit against Park24, and that the suit would look at the company's data retention practices.

Who is affected

Park24 is notifying people individually. If you have ever held a Times Car account, applied for one or signed a business or parking contract through the Kantan route, assume you are in scope until your notice says otherwise.

What to do now

If you are or were a Times Car member

1. Read your individual notice. Park24 has been sending them since 26 September in stages. It should tell you which categories apply to you.
2. Treat unexpected contact as hostile. Park24 lists phishing emails and sites, impersonation in applications and enquiries, unsolicited sales approaches and misuse of personal data as the expected risks. A message that knows your name, address, birth date and licence details will look convincing. Call the official hotline on the number above rather than any number in a message.
3. Change your password if you reused it. Only four hashed passwords were sent out according to the final table, but reuse is still worth fixing.
4. Watch for credit applications in your name. Hackread reported that Japan's credit information agency CIC saw difficulty with online disclosure requests on 29 September and that people were checking for loans or cards opened in their names. It also noted that no agency has said the breach caused that surge. Japan's credit agencies run disclosure and self report services; using them is a reasonable step if your licence image was in scope.
5. Keep the goodwill payment notice. If your encrypted ID image shows transfer traces, Park24 says it will contact you about the ¥3,000 payment once the form and method are decided.

If your product collects ID document images

The steps below are for any team running identity checks: car sharing, rentals, fintech, marketplaces, telecom, gaming age checks. They use AWS, Google Cloud, Azure, Kubernetes and PostgreSQL as examples; translate them to your stack.

1. Count what you hold and how old it is. Start with a number you can put in front of leadership. For an S3 bucket of ID images:

# Total objects and bytes under the ID image prefix
aws s3 ls s3://example-kyc-images/id-docs/ --recursive --summarize | tail -2

# Objects older than one year (adjust the date)
aws s3api list-objects-v2 --bucket example-kyc-images --prefix id-docs/ \
  --query "Contents[?LastModified<='2025-10-24'].Key" --output text | wc -w

For Google Cloud Storage and Azure Blob Storage:

gcloud storage ls --recursive --long gs://example-kyc-images/id-docs/ | tail -1

az storage blob list --account-name examplekyc --container-name id-docs \
  --query "length([?properties.lastModified<='2025-10-24'])" --auth-mode login

2. Join images to member status. The question is how many images belong to people who are no longer customers, or never became one.

SELECT m.status,
       count(*)                          AS images,
       min(d.uploaded_at)                AS oldest,
       count(*) FILTER (WHERE d.verified_at IS NOT NULL) AS already_verified
FROM   id_documents d
JOIN   members m ON m.id = d.member_id
GROUP  BY m.status
ORDER  BY images DESC;

If "withdrawn", "incomplete" or "already verified" rows dominate, you are holding images that no longer serve the check they were collected for.

3. Replace the image with the result. After a check passes, keep what you need to prove it happened: the result, the document type, the checker, the timestamp and a digest of the image. For example:

sha256sum licence_front.jpg licence_back.jpg

Store the hex digests with the verification record, then delete the files. If a member disputes the check later, you can hash the document they present and compare.

4. Put deletion on a timer the storage layer enforces. Application code forgets; lifecycle rules do not. On S3, a rule that expires anything in a pending prefix after seven days:

{
  "Rules": [
    {
      "ID": "expire-id-docs-pending",
      "Filter": { "Prefix": "id-docs/pending/" },
      "Status": "Enabled",
      "Expiration": { "Days": 7 },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 1 }
    }
  ]
}

aws s3api put-bucket-lifecycle-configuration --bucket example-kyc-images \
  --lifecycle-configuration file://lifecycle.json
aws s3api get-bucket-lifecycle-configuration --bucket example-kyc-images

The Google Cloud and Azure equivalents:

gcloud storage buckets update gs://example-kyc-images --lifecycle-file=lifecycle.json
az storage account management-policy create --account-name examplekyc \
  --resource-group kyc-rg --policy @policy.json

Remember versioned buckets: deleting the current version leaves old versions in place unless a rule removes them, which is why the example also expires noncurrent versions.

5. Find out who can decrypt. Encryption at rest only helps if the identity that can read the files cannot also get the key. On AWS, check whether the web tier's role can call decrypt on the key that protects the images:

aws kms get-key-policy --key-id alias/kyc-images --policy-name default --output text

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/web-frontend \
  --action-names kms:Decrypt s3:GetObject \
  --resource-arns arn:aws:kms:ap-northeast-1:111122223333:key/EXAMPLE-KEY-ID \
                  arn:aws:s3:::example-kyc-images/id-docs/sample.jpg

If both come back "allowed" for the web tier, a foothold on the web tier is a foothold on the images. The OWASP Cryptographic Storage Cheat Sheet puts it simply: where possible, keep keys in a separate location from the encrypted data, and keep the key encryption key on a separate system from the data encryption keys.

6. Look for keys and credentials an attacker would find on the box. This is the "information in the system" step. On a host or in a container you own:

# Config files that mention keys, secrets or connection strings
grep -rIlE "(ENCRYPTION_KEY|KMS_KEY|SECRET_KEY|DATABASE_URL|AWS_SECRET)" /etc/app /srv/app 2>/dev/null

# Environment of the running app process (names only)
cat /proc/$(pgrep -f gunicorn | head -1)/environ | tr '\0' '\n' | cut -d= -f1 | sort

On Kubernetes, check whether the web service account can read the secrets that unlock the document store:

kubectl auth can-i get secrets -n kyc --as=system:serviceaccount:web:web-frontend
kubectl auth can-i list secrets -n kyc --as=system:serviceaccount:web:web-frontend
kubectl get networkpolicy -n kyc

"yes" from the first two, or no network policy in the document namespace, means the web tier and the image store share a trust zone.

7. Log reads of the image store, and alert on volume. Park24's figures separate images that were accessed from images that were sent out. That distinction came from logs. Make sure you can draw it too. If you log S3 data events through CloudTrail into Athena, a per principal hourly count looks like this:

SELECT useridentity.arn,
       date_trunc('hour', from_iso8601_timestamp(eventtime)) AS hour,
       count(*) AS reads
FROM   cloudtrail_logs
WHERE  eventsource = 's3.amazonaws.com'
  AND  eventname  = 'GetObject'
  AND  json_extract_scalar(requestparameters, '$.bucketName') = 'example-kyc-images'
GROUP  BY 1, 2
HAVING count(*) > 500
ORDER  BY reads DESC;

Pick a threshold from your normal traffic. A checker that reviews a few hundred documents a day should never read hundreds of thousands in an hour.

8. Watch egress from the tiers that touch documents. Large outbound transfers to an unfamiliar destination are the "sent out" half. Flow logs or proxy logs summarised by bytes per destination per hour will show it.

9. Patch the web tier's dependencies on a short clock. Know every framework, library and base image in your internet facing services, and rebuild quickly when one gets a fix.

10. Write the notice before you need it. Japan's PPC asks businesses to report promptly and, where the leak may have been for an improper purpose, to file the full report within 60 days of discovery. Draft the template, data map and member segments now.

What changed since the first reports

• From "about 6.6 million" to 6,628,007, with the explicit note that parking only customers who joined through Kantan are included.
• From "about 1.6 million accounts with ID images" to 1,464,800 images sent out and 891,602 accessed only. The forensic work split access from transfer.
• Times Club added. The 25 to 29 September reports concerned Times Car only. The fifth report adds the Times Club web system.
• Linked service IDs corrected from nine to four, with WESTER ID at zero.
• Cause stated, in outline. An exploited web system vulnerability, followed by internal discovery, followed by access to the database and file areas.
• Retention rule changed on 16 October and confirmed with a deletion deadline of the end of October.
• Money. A ¥5,500 million special loss, a 12.5% cut to the full year net profit forecast and a ¥3,000 goodwill payment for people whose encrypted images show transfer traces.
• Governance. A committee led by outside directors, with outside experts, will review internal control and governance. Security and governance measures will be published by the end of the year.

Open questions

• Which component held the vulnerability, and was a fix available for it before 25 September?
• When did the attacker first get in, and how long did discovery inside the system take?
• What information did the attacker find inside the system and use to reach the database and file store?
• Were the image decryption keys, or credentials that could use them, reachable from the compromised system?
• How did the attacker reach the Times Club web system, and why were 135,436 linked service IDs there in scope?
• How many people, as opposed to image records, are eligible for the ¥3,000 payment?
• What exactly will Park24 keep after deleting the images, and for how long?
• Will the end of year report describe the vulnerability class, now that the investigation is closed?

What would have helped

None of this is a judgement on Park24. It blocked the access within a day, reported to the regulator on the day of detection, notified members individually and changed its retention rule within three weeks. Its forensic work separated images that were only touched from images that left. The question for everyone else is how to make the same class of event smaller.

Practices any team can use

• Keep the result, not the document. Once a licence check passes, store the outcome and a digest. Delete the image on a timer the storage layer enforces.
• Set retention by purpose, and publish it. Write down why each document type is kept and for how long, the way NIST SP 800-63A asks identity services to do. "Membership plus seven years" should have to justify itself against a named need.
• Separate the people you no longer serve. Withdrawn members and abandoned applications should not sit in the same live store as current members. If you must keep something, move it to cold storage with a separate key and a separate access path.
• Put keys in a different trust zone. Use envelope encryption with the key encryption key in a key management service or HSM that the web tier cannot call directly. Route decryption through a small service with its own credentials, rate limits and audit log, as the OWASP Key Management Cheat Sheet describes.
• Keep credentials off the web tier. Short lived role credentials instead of static keys in config files; no connection strings for the document store on internet facing hosts; network policy that blocks the web tier from the file store.
• Segment shared back ends. Park24 explains that parking contracts sat in the Times Car web system because of the Kantan sign up route. Shared stores are convenient; they also mean one breach touches several products.
• Shorten the patch clock for the web tier. Inventory every framework, library and base image in internet facing services, and rebuild fast when a fix ships.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists, in two modes: an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases, and it covers seven package ecosystems. Gold Open Source (gold.safeguard.sh, free, no login) is searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, with a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) supplies hardened drop in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages; an artifact loses its badge if it regresses.

To be plain about the limits: Park24 has not said what the vulnerability was, so nobody outside the investigation can say whether it sat in an open source package, in custom code, in a commercial product or in configuration. Safeguard has no advisory for it and no patched build of anything related to it. Where these capabilities help is in the layer every web platform shares: the frameworks, libraries and base images its web tier is built from. Pulling patched, signed components from a curated source and rebuilding fast when an advisory lands removes one common way in. It does nothing about retention, key placement or segmentation, which are the lessons that matter most here.

Where Safeguard fits

Honest scope first: Safeguard would not have prevented this incident, and it would not have shortened how long Park24 kept ID images. Retention policy, key management, network segmentation and runtime detection are design and operations questions that sit outside what Safeguard scans.

What Safeguard does cover, at GA:

• Dependency and image scanning of the repositories, container images and SBOM files behind a web platform, with JSON results under ./output (commands below).
• Component search across projects: the platform shows which projects contain a given component and version, so when an advisory lands for a framework your sign up service uses, you can see every place it ships.
• Vulnerability matching and reachability analysis, to rank the vulnerable code paths your application actually calls first.
• Policies and gates evaluated in the platform, so a build of an internet facing service with a known exploited vulnerability can be blocked or held for approval.
• Autonomous remediation with tested fix pull requests, which ships off by default.
• The Safeguard CLI assistant, which can edit code and configuration and run commands only with your approval, under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. You could ask it to add a storage lifecycle rule to your infrastructure code, write a migration that replaces stored images with digests, or add a test that fails if the web tier's role can decrypt the document key, and approve each change as it is made.

safeguard scan --dir .                 # a repository
safeguard scan --image <name>          # a container image
safeguard scan --sbom <file>           # an SBOM file

Where Safeguard does not help: it does not monitor production traffic or egress, does not manage encryption keys or retention schedules, does not replace data loss prevention or anomaly detection, and does not see inside a vendor's hosted identity check service.

Common mistakes and troubleshooting

• Calling encryption at rest the end of the story. If the identity that reads the files can also use the key, encryption protects against a stolen disk, not against a stolen session on the app server.
• Deleting the current object in a versioned bucket and calling it done. Old versions stay unless a lifecycle rule or an explicit delete removes them. Check with aws s3api list-object-versions.
• Forgetting the copies. Backups, analytics exports, support ticket attachments and fraud review queues often hold copies of ID images. A deletion project that only covers the primary bucket leaves the rest.
• Treating abandoned sign ups as nobody's data. Park24's second report lists people who applied but never finished joining among those affected. Expire incomplete applications quickly.
• Waiting for a CVE before acting. Park24 has not published one and may never. Retention, key placement and logging reviews do not need it.

FAQ

What happened at Times Car?

An attacker exploited a vulnerability in the Times Car web system, explored the system, and used information found there to reach the database and file storage. Park24 detected the access at 09:07 JST on 25 September 2026 and blocked it by 07:25 the next day. The forensic investigation ended on 23 October.

How many people are affected?

Park24's final count is 6,628,007 accounts with traces of access and transfer. Separately, 1,464,800 encrypted ID document images show transfer traces and 891,602 show access only. Some Times Club data was also taken.

Were driving licence images stolen?

Encrypted image files were sent out: 1,464,800 of them, including driving licences, proof of address documents, student IDs and family documents. Park24 says encryption means that does not immediately make them viewable, but it cannot completely rule out future decryption.

Were passwords or card numbers taken?

Four hashed passwords were sent out. Park24 holds no full card numbers or security codes; 28 Times Club card last four digits were taken.

What was the vulnerability?

Park24 has not said. It describes it only as a vulnerability in the web system and withholds attack details to prevent secondary damage. No CVE has been published.

Is this linked to other Japanese breaches this autumn?

Park24 has not linked it to any other incident, and we have seen no primary source that does. Several listed Japanese companies published breach updates on the same day, 23 October, according to a market news roundup, but shared timing is not evidence of a shared cause.

Why did Park24 hold images of former members?

Its rule kept images for the whole membership and for seven years after withdrawal, for identity checks, suspected misuse cases and enquiries. On 16 October it changed the rule to delete images once registration checks finish, and it will delete every image it holds by the end of October 2026.

Would Safeguard have prevented this?

No. The lessons here are about retention, key placement, segmentation and monitoring, which Safeguard does not manage. Safeguard helps with one shared layer: finding and fixing known vulnerable components in the web services you build.

Fix it without waiting for upstream

Park24 has not said whether the flaw in its web system was in an open source component. For teams whose web tier is built on open source frameworks and libraries, though, the time between a fix and a rebuild is one of the few parts of a breach like this that is fully in your hands.

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 have helped

None of these demos shows Times Car, Park24 or their systems. Each is a real Safeguard session, and each intro says how the same flow would apply to a service that collects ID document images.

This real CLI session fixes a lodash CVE in a sample repository: the assistant 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, and pushes nothing. For a sign up service that handles licence uploads, you would run /scan . in its repository, then ask the assistant to add a seven day lifecycle rule for the pending documents prefix to your infrastructure code and a test that fails if the web role can decrypt the document key, approving each edit and command as it runs.

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

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. A platform team could pick the folder holding its identity check service, ask for a migration that stores a digest and verification result in place of each image, and approve or deny every file change before it lands.

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

This real Android session sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. If an advisory lands at night for a framework your sign up service uses, the on call engineer could approve the dependency bump and test run from a phone, and deny anything that touches the document store or key policy until a second person has looked.

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

To try it on your own services, download Safeguard and follow the CLI docs. For the wider month, read October 2026 security incidents and what would have helped, and for scoping which of your products contain a given component, see SBOM incident response: finding affected products fast.

Quick check

Sources

• Park24: Fifth report on the Times Car web system breach, investigation results and response (23 Oct 2026)
• Park24: TSE disclosure, results of the unauthorized access investigation and future response (23 Oct 2026, PDF)
• Park24: Special loss and revision of full year consolidated forecast (23 Oct 2026, PDF)
• Park24: Fourth report, change to ID image retention rule (16 Oct 2026)
• Park24: Third report, about 1.6 million accounts with ID document images (29 Sep 2026)
• Park24: Second report, about 6.6 million accounts, detection and block times (28 Sep 2026)
• Park24: First notice of possible personal data leak (25 Sep 2026, with 26 Sep addendum)
• Personal Information Protection Commission: Breach reporting (漏えい等報告について)
• NIST SP 800-63A-4: Digital Identity Guidelines, Identity Proofing and Enrollment
• OWASP Cryptographic Storage Cheat Sheet
• OWASP Key Management Cheat Sheet
• MLex: Park24 should compensate victims of ID-document leaks, Japanese lawyer says (21 Oct 2026)
• Nihon Interview Shimbun (media-ir): Five listed companies including Park24 disclose unauthorized access (23 Oct 2026)
• BleepingComputer: Times Car confirms data breach affecting 6.6 million user accounts
• Hackread: Japanese car-sharing site Times Car data breach affects 6.6M accounts

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.