JETS breach: historical card numbers in Jamaica's payment admin files

JETS Limited, which operates Jamaica's MultiLink debit card network and its Automated Clearing House (ACH), says attackers reached part of its internal administrative systems and accessed files that may hold historical debit card numbers and names of some ACH transfer recipients. PINs, CVVs and expiry dates were not stored there. Both payment networks kept running.

The Bank of Jamaica (BOJ) dates the JETS statement to 22 October 2026 and issued its own statement on 23 October. Neither JETS nor the central bank has said how many cards or people are involved, how the attackers got in, or when the intrusion started. This post sets out exactly what the two organisations have published, why the specific detail about "historical administrative data" matters more than it first appears, and what any payment switch, processor, bank or fintech can check this week in its own reporting and back office systems. We do not guess at the access method, because nobody has disclosed it.

What happened

Timeline

All times are as published. Neither organisation has given a detection time or an intrusion window.

There is a small discrepancy on timing. The BOJ and The Gleaner date the JETS statement to Thursday 22 October. The Observer's 24 October report describes a JETS release early on Friday. A news report summarising the coverage also points out the difference. It may simply be a statement issued late on Thursday and circulated widely on Friday. It does not change anything a reader needs to do.

What JETS said

According to the JETS statement as carried by The Gleaner and the Observer, the company's Cyber Monitoring Team spotted suspicious activity in a limited section of its domain. It shut the affected administrative system down, isolated the area, and launched a forensic investigation with specialist cybersecurity consultants. That investigation, JETS says, found no evidence that the MultiLink or ACH payment networks were compromised.

The most specific sentence came in the version the Observer quoted on 24 October. JETS said that while the payment networks were not affected, reports containing payment transactions were accessed. Those reports may have exposed names of some customers who received ACH transfers, along with some card numbers "from historical administrative data files on the debit network". JETS added that PINs, CVVs and expiry dates "are never stored and would not have been impacted", per the Observer.

JETS also said it and its member financial institutions had taken steps to protect the payment systems and customer information, and that it had strengthened its defences against what The Gleaner quotes as "this elevated and evolving threat".

What the Bank of Jamaica said

The BOJ statement, posted on 23 October, does four things:

1. It confirms the BOJ has been engaged with JETS, member institutions and national authorities since it was informed.
2. It restates, based on information from JETS, that files accessed may have exposed some card numbers in historical administrative data on the debit network, plus names of some ACH transfer recipients, and that PINs, CVVs and expiry dates are not stored in these systems.
3. It says the BOJ supports JETS's decision to inform the public.
4. It lists consumer precautions and says the BOJ, in its oversight of the national payments system, will keep monitoring and take action as necessary.

The BOJ statement is the most authoritative public record of the incident, because it is published by the overseer of the payment system and is based on information JETS gave the regulator.

What has not been said

There is no public answer yet to any of these:

• How many card numbers and how many ACH recipient names are in the accessed files.
• How old the "historical" data is, or which years it covers.
• Whether the card numbers are full or partial, and whether any were masked or truncated. The word "numbers" is used throughout, without qualification.
• How the attackers reached the administrative system.
• When the intrusion started and when it was detected.
• Whether the attackers removed copies of the files or only viewed them. JETS uses the word "accessed".
• Whether any extortion demand has been made.
• Whether cards issued outside Jamaica, or senders outside Jamaica, are in the data. A news report notes neither JETS nor the BOJ has addressed this.
• Whether issuers will reissue cards.

We will not fill those gaps with assumptions.

Who is affected

How the networks are organised

The BOJ payment systems page is useful context, because it shows the ownership is not as simple as "JETS owns the networks":

• ACH: the BOJ says the ACH infrastructure is owned and operated by Automated Payments Limited (APL), with operations executed by J.E.T.S. Limited under a management contract. Retail Payments Jamaica Limited, chaired by the BOJ, is the oversight body for ACH operations. The ACH clears cheques, direct debits and credits on a deferred net settlement basis.
• MultiLink: the BOJ describes it as owned and operated by commercial banks and selected deposit taking institutions, as a shared network for ABM and point of sale transactions against a customer's own bank account. In their incident statements both JETS and the BOJ describe JETS as the operator.

This matters for one practical reason. In shared payment infrastructure, the data in an operator's back office belongs to many institutions at once. A single report file can carry records from every member bank. That is why the response involves the operator, every member institution and the overseer at the same time.

The fraud risk, stated plainly

A card number and a name, without the expiry date and the card verification code, is less useful to a criminal than a full card record. Card schemes and issuers generally validate expiry and CVV for online transactions, and MultiLink is a domestic debit network used at ABMs and point of sale terminals, where debit transactions typically require a PIN. Nobody has published fraud figures for this incident.

The bigger, more immediate risk is social engineering. A caller who can read out your real card number and full name sounds like your bank. That is exactly why the BOJ guidance focuses on unsolicited contact and on never sharing a PIN, CVV or one-time password. A name from an ACH report also tells a criminal that the person receives payments from a particular payer, which is useful pretext for invoice and payroll scams.

Why "historical administrative data" is the headline

The most important technical fact in this incident is not about the attack. It is about where the card numbers were.

According to JETS, the systems that process card transactions were untouched. The card numbers that were exposed sat in historical administrative data files and in reports containing payment transactions. In other words, they were in the back office: exports, reports, reconciliation files and similar artefacts that payment operators produce every day for settlement, disputes, member billing, audit and regulatory reporting.

This is a pattern that payment security standards have been pushing against for years, and it is worth explaining why.

The data card security standards care about

PCI DSS, the card industry's data security standard, separates account data into two kinds:

On the record, JETS's systems did what the second row asks: PINs, CVVs and expiry dates were not there to take. That is a real control and it narrowed the damage. Whether JETS or MultiLink are assessed against PCI DSS has not been stated, and we make no assumption about it. We use PCI DSS here because it is the most widely used public description of how card data should be stored, and because its requirements map closely to what went wrong in this type of incident at many organisations over the years.

Requirements that apply to back office files

These PCI DSS v4.0.1 requirements are written for exactly the kind of data that ends up in reports and exports. The wording below is summarised from the PCI SSC requirement text.

PCI SSC says version 4.0.1 is a limited revision of 4.0 with no added or deleted requirements, so these requirement numbers are the same in both. Several of them, including 12.10.7 and the keyed hash rule in 3.5.1.1, were best practice until 31 March 2025 and are now in force for assessed entities.

Truncation formats: how much of a PAN you can keep

PCI SSC FAQ 1091 sets the baseline for truncation at a maximum of the first six and last four digits, with brand specific allowances where more digits are needed:

The FAQ also warns that keeping different truncation formats of the same PAN makes reconstruction much easier. That matters for report pipelines, where one export truncates one way and another export truncates a different way.

Domestic networks may define their own formats. The general point holds anyway: a historical settlement or dispute report rarely needs a full card number. A truncated number or a token is usually enough to reconcile, and is far less useful to anyone who steals it.

Technical details

This section collects the concrete, defender useful specifics on the public record. There is no published CVE, malware family, file hash, IP address, domain or other indicator of compromise for this incident, and no published access method. If one appears in an official advisory, the right move is to add it to detection rules, not to assume it applies to you before then.

Disclosure records

Payment infrastructure facts

The BOJ's oversight powers come from section 27 of the Bank of Jamaica Act and section 3(1) of the Payment Clearing and Settlement Act 2010. The BOJ page quotes the latter as charging the Bank with "regulation, supervision and monitoring of clearing and settlement systems". The BOJ also says its oversight checks that operating financial market infrastructures comply with the Principles for Financial Market Infrastructures.

Record retention in the ACH rules

The ACH rules published by Retail Payments Jamaica Limited (Section E, Electronic Items, amended July 2020) require the ACH Operator and each participating institution to retain records of all entries, including returns and adjustments, for a defined Retention Period (rule E.9.7 and related clauses). Retention requirements like this are legitimate and necessary. They are also the reason payment operators accumulate years of transaction records. The security question is not whether to keep records, but in what form. A record kept for dispute and audit purposes can usually carry a token or truncated PAN, with the full PAN held only in the switch's protected store.

Jamaica's breach reporting rules

The Data Protection Act, 2020 sets the reporting duty that applies to personal data breaches in Jamaica. The relevant clauses, from the Act's text:

JETS says it notified the Office of the Information Commissioner. Whether JETS is the data controller, a processor acting for member banks, or both, has not been stated, and the answer affects who owes which notices. The OIC runs an online "Report a Data Breach" form that asks for controller, representative, data protection officer, processor and third party details, which reflects exactly that multi party reality.

The fifth standard is the legal mirror of PCI DSS Requirement 3.2.1: data you no longer need is data you should not still have.

How the data likely moves, in general terms

We do not know JETS's architecture and do not describe it. In general, a payment switch has two worlds:

1. The switching and clearing platform, which authorises and routes transactions, calculates settlement positions and talks to member institutions. This is where cards are processed, and where PCI DSS style segmentation, hardware security modules and tight access control live.
2. The corporate and administrative environment, which handles email, finance, member billing, reporting, dispute handling, analytics and audit support. This is where reports, extracts and reconciliation files are produced and stored, usually on file shares, document management systems or reporting databases.

The weak point at many organisations is the bridge between them: scheduled report jobs that pull transaction data out of the platform and drop it into the administrative environment, often as CSV or spreadsheet files with full card numbers because that is how the report was first designed. Once those files are on a file share, they inherit the file share's security, not the switch's. On the public record, JETS's description fits this pattern: the networks were untouched, while reports and historical files in administrative systems were accessed.

What changed since first reports

No numbers of affected cards or people have been published as of 24 October.

What to do now

If you are a cardholder or ACH recipient in Jamaica

1. Turn on transaction alerts in your banking app if they are not already on.
2. Check your debit card and account activity regularly, and report anything unfamiliar to your bank promptly.
3. If someone calls or messages you about your card, hang up and call the number on the back of the card or on your bank's official website. A caller knowing your card number does not prove they are your bank.
4. Never share a PIN, CVV, one-time password or online banking login. The BOJ says legitimate institutions will not ask for them.
5. Be wary of messages that claim to come from JETS or the BOJ. The BOJ statement warns specifically about impersonation of itself, JETS and banks.
6. If you receive ACH payments from an employer or supplier, be suspicious of any message asking you to "update" or "verify" your bank details.

If you run a payment switch, processor, bank back office or fintech

These steps are generic. They do not describe anything known about JETS's environment.

Step 1: find full card numbers outside the card environment. Start with file shares, report output folders, document management systems and mailboxes used by finance, operations, disputes and audit. A simple defensive scan looks for 13 to 19 digit runs and filters them with the Luhn check that valid card numbers pass. The Python below reads files and prints only a count and masked examples per file, so the scan output itself does not become another copy of card data.

#!/usr/bin/env python3
# pan_discovery.py: report files that appear to contain full card numbers.
# Prints masked values only (first 6 and last 4). Defensive inventory use.
import os, re, sys

CANDIDATE = re.compile(rb'(?<!\d)(?:\d[ -]?){12,18}\d(?!\d)')

def luhn_ok(digits: str) -> bool:
    total, alt = 0, False
    for ch in reversed(digits):
        d = ord(ch) - 48
        if alt:
            d *= 2
            if d > 9:
                d -= 9
        total += d
        alt = not alt
    return total % 10 == 0

def mask(d: str) -> str:
    return d[:6] + '*' * (len(d) - 10) + d[-4:]

def scan(path: str, max_bytes: int = 50_000_000):
    hits = []
    try:
        with open(path, 'rb') as f:
            data = f.read(max_bytes)
    except (OSError, PermissionError):
        return hits
    for m in CANDIDATE.finditer(data):
        digits = re.sub(rb'\D', b'', m.group()).decode()
        if 13 <= len(digits) <= 19 and luhn_ok(digits):
            hits.append(mask(digits))
    return hits

root = sys.argv[1] if len(sys.argv) > 1 else '.'
for dirpath, _, files in os.walk(root):
    for name in files:
        p = os.path.join(dirpath, name)
        h = scan(p)
        if h:
            print(f'{len(h):6d}  {p}  e.g. {h[0]}')

Run it with python3 -I pan_discovery.py /mnt/reports > pan_hits.txt from a dedicated host with read only access, and treat the output file as sensitive. Expect false positives from long reference numbers that happen to pass Luhn; the count per file is what tells you where to look. Compressed archives and binary spreadsheet formats need extraction first. Commercial data discovery tools do this at scale; the point of the script is that you can get a first answer today.

On Windows file servers, a quick first pass with PowerShell:

# List report-type files with long digit runs, newest first. Review matches manually.
Get-ChildItem -Path '\\fileserver\reports' -Recurse -Include *.csv,*.txt,*.xml -File -ErrorAction SilentlyContinue |
  Select-String -Pattern '(?<!\d)\d{13,19}(?!\d)' -List |
  Select-Object Path |
  Sort-Object Path

Step 2: find old files that should not exist. Retention policies fail quietly. List report files older than your documented retention period:

# Files under the reports tree not modified in more than 400 days
find /srv/reports -type f -mtime +400 -printf '%TY-%Tm-%Td  %s  %p\n' | sort | head -200

$cutoff = (Get-Date).AddDays(-400)
Get-ChildItem '\\fileserver\reports' -Recurse -File |
  Where-Object { $_.LastWriteTime -lt $cutoff } |
  Select-Object LastWriteTime, Length, FullName |
  Sort-Object LastWriteTime | Select-Object -First 200

Compare what you find with the retention period in your own policy and in any network rules you operate under. PCI DSS Requirement 3.2.1 asks for a check at least every three months that expired account data is gone.

Step 3: find card numbers in reporting databases. Column names give the first clue. In PostgreSQL:

SELECT table_schema, table_name, column_name, data_type
FROM information_schema.columns
WHERE column_name ~* '(pan|card_?no|card_?num|cardnumber|acct_?num)'
ORDER BY 1, 2, 3;

In SQL Server, the same query works against INFORMATION_SCHEMA.COLUMNS with LIKE '%pan%' OR LIKE '%card%'. Then sample a handful of rows from each match to see whether the values are full, truncated or tokenised.

Step 4: fix the report, not just the file. Every hit in steps 1 to 3 came from somewhere. Trace each file back to the job that produced it and change the job so it writes a token or a truncated PAN. Otherwise the next run recreates the problem. This is what PCI DSS Requirement 12.10.7 means by remediating the process gap that put the data where it was not expected.

Step 5: log access to the places reports land. If you cannot say who opened a report share last month, you cannot scope an incident quickly. On Windows file servers, enabling the "Audit Detailed File Share" policy produces Security event 5145 for each access check on a shared file, and "Audit File Share" produces 5140 when a share is accessed. On Linux, an auditd watch on the report directory records reads:

sudo auditctl -w /srv/reports -p r -k report_reads
sudo ausearch -k report_reads --start today | aureport -f -i | head

Send those events to central logging and keep them long enough to cover a slow investigation. PCI DSS Requirement 10.4.1 asks for daily review of security event logs and logs of systems that store cardholder data.

Step 6: check the bridge between environments. List every scheduled job, integration account and file transfer that moves data from the payment platform into the administrative environment. For each one, record who owns it, what fields it carries and where the output lands. If a job carries full PANs, ask whether the consumer really needs them.

Step 7: re-test segmentation. If you rely on segmentation to keep administrative systems out of card processing scope, PCI DSS Requirement 11.4.5 asks for penetration tests of segmentation controls at least every 12 months, and 11.4.6 asks service providers to do it every six months. An incident at a peer is a good reason to bring the next test forward.

Step 8: rehearse member and customer communication. Shared infrastructure incidents need a pre agreed statement with member institutions and the overseer. Both JETS and the BOJ published consistent consumer guidance within about a day, which is the outcome to aim for.

What would have helped

This section is about any organisation that runs or depends on shared payment infrastructure. It is not a judgement on JETS. On the public record, JETS detected the activity itself, shut down and isolated the affected system, brought in outside specialists, notified the regulator, the Information Commissioner, police and member institutions, and kept the payment networks running. Its systems also did not hold PINs, CVVs or expiry dates, which limited what could be taken.

Practices that shrink the blast radius

Keep full card numbers inside the card environment. Reports and extracts that leave the switching platform should carry tokens or truncated PANs by default. Where a full PAN is needed for a specific dispute or chargeback, retrieve it on demand from the protected store, with logging, rather than pre printing it into every report. This is the single change that would most reduce the impact of an administrative system breach at any payment operator.

Delete what has outlived its purpose. "Historical" is the risk word. Retention periods exist for good reasons, but expired files left on shares or in mailboxes are pure exposure. Automate deletion, and verify it on a schedule.

Treat report pipelines as data flows in scope. Most scoping exercises draw the card environment around the switch and stop. The report job, the file share it writes to and the people who open the files are a data flow too. Requirement 12.5.2 in PCI DSS asks you to map all data flows, and that includes these.

Encrypt at the file and field level, not only at the disk. Disk encryption protects against stolen hardware. It does nothing against an intruder who reads files through the operating system with a valid account. Field level encryption or tokenisation inside the report does.

Separate administrative identities. Administrative accounts for the payment platform should not be the same accounts people use for email and file shares, and both should use multi factor authentication. PCI DSS Requirement 8.4.2 asks for multi factor authentication for all access into the card environment.

Patch and know the software on the administrative side too. We do not know how the attackers got in here. In general, internet facing applications, remote access systems and back office web tools are common starting points. Many payment operators build their own reporting portals, dispute tools and member dashboards. Those applications carry open source dependencies and container images that need the same vulnerability management as the switch itself.

Plan the cross institution response. Shared infrastructure means shared incidents. A rehearsed plan for who tells members, who tells the overseer, who tells the data protection authority within seventy two hours, and who tells the public saves hours when it matters. International guidance for financial market infrastructures, such as the CPMI and IOSCO cyber resilience guidance from 2016, sets the same expectation of rapid response and coordinated recovery.

Where Safeguard fits

Safeguard is a software supply chain security platform. For an incident like this, it is important to be precise about what that does and does not cover.

What Safeguard does not do here. It does not scan file shares or databases for card numbers, classify personal data, monitor file access, detect data leaving your network or manage tokenisation and encryption keys. It is not a data loss prevention tool, a SIEM or an EDR. The access method in this case is undisclosed, so we cannot say Safeguard would have prevented anything, and we do not claim it.

What Safeguard does do that is relevant. Administrative environments at payment operators are full of software that teams build and ship themselves: reporting services, dispute portals, member dashboards, batch jobs and the container images they run in. Known vulnerable components in that software are one common way into back office systems. That part is in scope.

• Know what you run. safeguard scan --dir . scans a repository, safeguard scan --image <name> scans a container image, and safeguard scan --sbom <file> reads an existing SBOM. Results land as JSON under ./output. In the platform you can see which projects contain a given component and version, which is the question you need answered within hours of a new advisory.
• Match against vulnerability data, then rank by reachability. Findings are matched against vulnerability databases, and reachability analysis shows which vulnerable code paths your application actually calls, so the reporting service that reads transaction data gets fixed before a tool nobody uses.
• Stop vulnerable versions shipping. Policies and gates are evaluated in the platform and in CI with safeguard exec, so a dispute portal or report service cannot deploy with a known exploited vulnerability.
• Fix with approval. Autonomous remediation opens fix pull requests and ships switched off by default. The Safeguard CLI's assistant can edit code and run commands with your approval, with /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. Desktop and phone apps can send work to a computer running the CLI and approve each command.

None of this replaces tokenisation, retention enforcement, data discovery, file access logging or segmentation. It covers the software you build and run on the administrative side, so that a missing patch is one fewer step an intruder can take.

Zero-Day Discovery and Gold

Two Safeguard capabilities are aimed at the time just before and just after a vulnerability becomes public. They support the general habit this post argues for, which is shortening the time between "a fix exists" and "the fix is running". Nothing below is about this incident's access method, which is undisclosed.

• Zero-Day Discovery looks for previously unknown flaws 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. It covers seven package ecosystems. It does not cover operating systems, network appliances or closed commercial payment software, so it would not apply to a vendor's switching platform or a file server's operating system.
• Gold Open Source at gold.safeguard.sh is free and needs no login. It gives searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action.
• Gold Registry at registry.safeguard.sh is paid. It provides 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.

The habit that matters is pulling patched, signed components from a curated source and rebuilding quickly, so the internal tools that touch transaction data are not the easy way in.

Common mistakes after an incident like this

Assuming "the network was not affected" means your data is safe. At a payment operator, the most sensitive data at rest is often in the back office, not in the switch. Check both.

Searching only databases. Card numbers in spreadsheets, CSV exports, PDF reports, email attachments and backup archives are the usual surprise. Requirement 3.5.1 in PCI DSS explicitly includes flat files, backups and logs.

Making the discovery output another copy of the data. A scan report listing full card numbers is a new liability. Mask results, as the script above does, and restrict who can read them.

Keeping two truncation formats of the same number. PCI SSC warns that different truncation formats of the same PAN make reconstruction easier. Pick one format across all reports.

Hashing card numbers without a key. The space of valid 16 digit card numbers for a given BIN is small enough to enumerate. PCI DSS Requirement 3.5.1.1 asks for keyed cryptographic hashes for this reason.

Fixing the file, not the job. Deleting old reports without changing the report job means the exposure grows back.

Forgetting the seventy two hour clock. Under section 21(3) of Jamaica's Data Protection Act, the report to the Information Commissioner is due within seventy two hours of becoming aware of a breach. Similar clocks apply in many jurisdictions, and multi party incidents make it easy for everyone to assume someone else filed.

Open questions

• How many card numbers and ACH recipient names were in the accessed files, and over what time span?
• Were the card numbers complete, or were some masked or truncated?
• How did the attackers reach the administrative system, and when?
• Were files copied out, or only viewed?
• Will issuers reissue affected cards, or rely on monitoring?
• Will the Office of the Information Commissioner or the BOJ publish findings or direct further notifications?
• Does the incident change the timetable for Jamaica's proposed Cybersecurity Act? Reporting says its drafting instructions still await Cabinet approval.

We will update this post if JETS, the BOJ or the OIC publish answers.

FAQ

What data was exposed?

According to the BOJ, based on information from JETS, the accessed files may have exposed some card numbers in historical administrative data on the debit network and the names of some customers who received ACH transfers. PINs, CVVs and card expiry dates are not stored in these systems and were not affected.

Can I still use my debit card?

Yes. JETS and the BOJ both say the MultiLink and ACH networks were not affected and are fully operational. Customers can keep using debit cards and making ACH payments as normal.

How many people are affected?

That has not been disclosed. Neither JETS nor the BOJ has published a number of cards, customers or records.

Should I cancel my card?

Neither JETS nor the BOJ has advised cancelling cards. Follow your bank's guidance. If you are worried, call the number on the back of your card and ask whether your card is affected and whether a replacement is recommended.

Can someone use my card with just the number?

Card numbers without the expiry date and CVV are less directly useful, and debit transactions at ABMs and point of sale terminals typically require your PIN. The bigger risk is someone using your card number and name to convince you they are your bank and get your PIN, CVV or one-time password. Never give those to anyone who contacts you.

How did the attackers get in?

That has not been disclosed. JETS says a forensic investigation with specialist consultants is ongoing.

What does Jamaican law require after a breach like this?

Section 21 of the Data Protection Act, 2020 requires a data controller to report a security breach affecting personal data to the Information Commissioner within seventy two hours of becoming aware of it, and to notify affected individuals in the manner regulations prescribe.

Could Safeguard have prevented this?

We cannot say that, and we do not claim it. The access method is unknown, and Safeguard does not scan for card data, monitor file access or watch network traffic. Safeguard helps teams find and fix known vulnerable components in the software and container images they build and run, which narrows one common route into back office systems.

Related reading

• October 2026 security incidents: what would have helped
• IDCF Cloud ransomware and third party risk
• Edge device zero-days in October 2026
• SBOM incident response: finding affected products fast

Fix it without waiting for upstream

The JETS incident is about stored data, not a vulnerable library, so this section applies to the internal tools around a payment operation rather than to the incident itself. Reporting services, dispute portals and batch jobs are built from open source components, and keeping those patched is part of keeping a back office hard to enter.

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

These are real product sessions on other examples. None of them shows this incident, JETS systems, card data or a payment network.

The CLI demo shows the assistant fixing 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 your approval, and pushes nothing. For a payment operator, you would run the same scan against the repository behind a dispute portal or report service and ask the assistant to move a vulnerable dependency to its fixed version. It asks before each command.

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

The runner demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. Payment operators often keep back office build hosts inside a segmented network, and this is how you would run scans of report service images from a machine you control there.

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

The mobile demo is a real Android session: it sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. In this case the story broke over a Thursday night and Friday morning. The same flow lets an on call engineer approve an urgent upgrade of an internal tool from a phone, with a human deciding each step.

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

To try it on your own code, download Safeguard and follow the CLI docs.

Quick check

Sources

• Bank of Jamaica: Statement on Cyber Incident at JETS Limited (23 Oct 2026) (primary)
• Bank of Jamaica: Payment Systems, oversight and financial market infrastructures (primary)
• Retail Payments Jamaica Limited: ACH Rules, Section E, Electronic Items, amended July 2020 (PDF, hosted by the BOJ) (primary)
• Houses of Parliament of Jamaica: The Data Protection Act, 2020 (PDF) (primary)
• Office of the Information Commissioner, Jamaica: home page (primary)
• Office of the Information Commissioner, Jamaica: The Data Protection Act (primary)
• Office of the Information Commissioner, Jamaica: Report a Data Breach to the OIC (primary)
• Office of the Information Commissioner, Jamaica: Data Protection Act, the Minister's Regulations 2024 (primary)
• PCI SSC: PCI DSS v4.0 Self Assessment Questionnaire D for Service Providers, requirement text (PDF) (primary)
• PCI SSC: Summary of Changes from PCI DSS v3.2.1 to v4.0 (PDF) (primary)
• PCI SSC blog: Just Published, PCI DSS v4.0.1 (primary)
• PCI SSC FAQ 1091: What are acceptable formats for truncation of primary account numbers? (primary)
• PCI SSC: PCI Data Storage Do's and Don'ts (PDF) (primary)
• PCI SSC: PCI DSS standard page (primary)
• CPMI and IOSCO: Guidance on cyber resilience for financial market infrastructures (June 2016) (primary)
• NIST SP 800-122: Guide to Protecting the Confidentiality of Personally Identifiable Information (primary)
• NIST SP 800-88 Rev. 2: Guidelines for Media Sanitization (primary)
• Microsoft Learn: Event 5145, a network share object was checked to see whether client can be granted desired access (primary)
• Microsoft Learn: Event 5140, a network share object was accessed (primary)
• auditctl(8) manual page
• The Gleaner: JETS Limited reports data breach but says core payment networks unaffected (23 Oct 2026)
• Jamaica Observer: Cyberattack on JETS exposes customer information; MultiLink and ACH networks unaffected (23 Oct 2026)
• Jamaica Observer: Money worries (24 Oct 2026)
• IRIE FM: BOJ assures public MultiLink and ACH networks remain operational after JETS cyber incident
• Rio Times: Jamaica data breach at JETS payment networks

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