South Africa's software and AI security rules: a 90-day plan for 2026

If you build, buy or run software in South Africa, two regimes do most of the work in 2026. Financial institutions answer to Joint Standard 2 of 2024 on cybersecurity and cyber resilience, in force since 1 June 2025, and since 1 September 2026 they report material IT and cyber incidents on a set template, with the first notice due within 24 hours of classifying the incident as material. Every organisation that processes personal information answers to POPIA, whose section 19 asks for reasonable security safeguards and whose section 22 requires notice to the Information Regulator, through its eServices portal, as soon as reasonably possible after a security compromise.

Both land on the same questions. What software do you run, including the open source underneath it? Who supplies it? How fast do you fix what is vulnerable? How quickly can you tell a regulator what happened? This guide covers each regime as it stands on 25 October 2026, maps the requirements to the evidence a supervisor asks for, and ends with a 30/60/90-day plan that works with the tools you already have. Safeguard appears only near the end. Nothing here is legal advice; check the primary texts in Sources or ask your counsel.

Key takeaways

• Joint Standard 2 of 2024 is in force. The Financial Sector Conduct Authority (FSCA) and the Prudential Authority (PA) published it on 17 May 2024; their Joint Communication 3 of 2025 records it as effective 1 June 2025.
• It reaches into development and open source. Paragraph 7.7.5(a)(iii) requires a policy on third-party and open-source code, reviewed and tested before integration. Paragraph 7.7.6(b) requires known major flaws to be fixed before production and reported vulnerabilities in open-source software to be tracked.
• The incident clock is fixed. Joint Notice 2 of 2026, effective 1 September 2026, sets a template with an immediate notification within 24 hours of classification as material and updates within 14 calendar days.
• POPIA has no reporting threshold. The Information Regulator says every security compromise must be reported, through the eServices portal since 1 April 2025.
• The Regulator is fining. A R5 million infringement notice to the Department of Basic Education (December 2024), a R100,000 fine on Lancet Laboratories after unreported compromises, and a May 2026 enforcement notice that included a section 22 failure.
• The Cybercrimes Act's section 54 is not yet in force on the government's own commencement record.
• Safeguard capabilities used in this guide, all GA: SBOM generation and analysis, software composition analysis, vulnerability management with EPSS and KEV, reachability analysis, SAST and DAST, policies and gates, Package Firewall, the Compliance and GRC suite with its POPIA framework page, TPRM SBOM requests, Portal and Trust Center, AI-BOM discovery, autonomous remediation (ships switched off), the CLI and local runner, Zero AI mode, and private VPC, on-prem and air-gapped deployment.

The situation

This is an illustrative scenario; the organisations are invented.

The CISO of a mid-sized insurer has read Joint Notice 2 of 2026. A material cyber incident now means a filled template on the Umoja Portal within 24 hours of classification. Her question: if a widely used open source library were found compromised this afternoon, how long would it take to say which of the insurer's systems contain it?

The head of AppSec at a fintech that administers a pension fund has a different letter. The fund, preparing for its own Joint Standard review, wants evidence that the fintech tests code before release, reviews open source components before use, and does not ship known major flaws. The fintech is not itself in the Joint Standard, but its customer is, and paragraph 4.2.3 makes the customer define security roles in its supplier contracts.

The information officer of a hospital group has the third problem. A supplier's portal, built on an open source framework with a published vulnerability, may have exposed patient records. Section 22 says she must notify the Regulator and the patients as soon as reasonably possible, and the Regulator says she need not wait for confirmation.

A bad week is one where "do we run the affected component?" takes days of spreadsheets, the notice goes in late, and the explanation is that nobody knew what software was where.

Who this applies to in South Africa

Two scope points are easy to miss. Joint Standard 2 of 2024 defines "financial institution" for itself in paragraph 2.1, and paragraphs 3.2 and 3.3 make banking and insurance groups cover cyber risks from juristic persons and branches structured under them, local and foreign. And POPIA section 21 requires a responsible party to bind its operators, by written contract, to the section 19 safeguards. A software or cloud provider processing personal information for a South African customer will see those terms in its contract.

The rules, regulator by regulator

Joint Standard 2 of 2024: cybersecurity and cyber resilience (PA and FSCA)

Status: in force since 1 June 2025.

The standard was made under section 107, read with sections 105, 106 and 108, of the Financial Sector Regulation Act 9 of 2017. Drafts went to consultation on 15 December 2021 and 13 December 2022, and it was tabled in Parliament on 30 November 2023. It carries a publication date of 17 May 2024. Paragraph 10.2 left commencement to a notice, and Joint Communication 3 of 2025 (3 September 2025) footnotes it as "Effective 1 June 2025." Some commentators describe a further twelve-month grace period; the standard itself contains no transitional provision, so this guide treats it as fully in force.

The parts that matter most for software and supply chains:

• Governance. The governing body is ultimately responsible (4.1) and must make sure security roles are clearly defined in contracts or SLAs with third-party service providers (4.2.3). The strategy is reviewed at least annually (6.1.2), and the framework gets an independent review at least annually (6.2.2).
• Identification. Identify business processes and information assets, including those managed by third parties (7.1.1(a)), and keep an inventory of all information assets with location and ownership (7.1.1(d)), reviewed at least every two years (7.1.2). "IT asset" expressly includes software.
• Application and system security. Build security into every phase of software development (7.2.4(a)(i)), specify security requirements at the start of development or acquisition (7.2.4(a)(iii)), and review and test changes to business-critical applications (7.2.4(a)(iv)).
• Data security. Assets managed by third parties get the same protection (7.2.3(a)(iii)); sensitive data in non-production is restricted (7.2.3(a)(vii)).
• Detection and response. Logs are collected, retained and protected (7.3.2(a)); a tested incident response plan identifies the control deficiencies behind a compromise (7.5.1).
• Testing. Frequency reflects how fast vulnerabilities and threats change (7.7.1(a)(i)); reliance on a third party's testing must be justified (7.7.1(b)); vulnerabilities are addressed in a timely manner (7.7.2); internet-facing systems are penetration tested at major changes and at least annually (7.7.3(a)(iii)); scenario-based simulation exercises are run (7.7.4).
• Application security testing (7.7.5). Test web-based and critical applications during development; adopt standards on secure coding, source code review and application security testing; and keep a policy and procedure on the use and update of third-party and open-source code, so it is reviewed and tested before integration (7.7.5(a)(iii)) and the policy is reviewed regularly (7.7.5(a)(iv)).
• Remediation management (7.7.6). Severity classification, risk-based prioritisation and timeframes by severity (7.7.6(b)(i)). All issues, including software defects from code review and testing, are tracked, and known major issues and security flaws "must be remediated before production deployment" (7.7.6(b)(ii)). Track updates and reported vulnerabilities in in-house, third-party and open-source software (7.7.6(b)(iii)).
• Hygiene. Third parties with access get the same monitoring and restrictions as staff (8.1.1(f)); MFA for critical, privileged and internet-facing sensitive access (8.3.1); patches within a timeframe commensurate with each vulnerability's risk, tested first, with compensating controls where no patch exists (8.5.1); secure configuration standards (8.6.1); malware protection (8.7.1).
• Notification. Notify the responsible authority, in the form and manner the Authorities determine, after classifying a cyber incident or information security compromise as a material incident (9.1).

A "material incident" is a disruption with, or likely to have, a severe and widespread impact on the institution's operations, its customers, or the wider financial system and economy. Paragraph 3.4 makes everything proportionate to nature, size, complexity and risk profile, so every institution must be able to explain why its choices fit its risk.

Joint Standard 1 of 2023: IT governance and risk management (PA and FSCA)

Status: in force since 15 November 2024.

Published on 10 November 2023 and recorded by Joint Communication 3 of 2025 as effective 15 November 2024, this standard sets IT governance and risk management; Joint Standard 2 sets the cybersecurity controls on top. Its paragraph 15.1 is the basis for reporting material IT incidents, as paragraph 9.1 of Joint Standard 2 is for cyber incidents, and the 2026 determination covers both.

Joint Notice 2 of 2026: the material IT and cyber incident template

Status: in force since 1 September 2026.

The regulators consulted on a draft in Joint Communication 3 of 2025 (comments due 5 October 2025). Joint Notice 2 of 2026 was signed on 31 August 2026, published with Joint Communication 5 of 2026 on 1 September 2026, and took effect that day.

• Form. The "Reporting of Material IT and Cyber Incident Template" (Annexure A, an Excel workbook).
• Manner. Banks, branches, controlling companies, mutual banks and insurers submit on the PA's Umoja Portal. The other institutions submit on the FSCA's Joint Standards Submission Portal.
• Period. Set on the template's cover page: an immediate notification within 24 hours following classification of an incident as material; updates within 14 calendar days of notification; and a full incident report on timelines agreed with the responsible authority.

Two consequences follow. The clock runs from classification, so your criteria and who signs them off matter. And if a software component is involved, you will want to say within hours which systems carry it.

POPIA and the Information Regulator

Status: in force; amended Regulations in effect since 17 April 2025; eServices reporting mandatory since 1 April 2025.

The Protection of Personal Information Act 4 of 2013 was published in Government Gazette No. 37067 on 26 November 2013. The provisions that matter most for software:

• Section 19. Secure personal information through appropriate, reasonable technical and organisational measures (19(1)): identify reasonably foreseeable internal and external risks, maintain safeguards, regularly verify them, and keep them updated in response to new risks or deficiencies (19(2)(a) to (d)), with due regard to generally accepted information security practices (19(3)).
• Sections 20 and 21. Operators process only with authorisation and in confidence. A written contract must make the operator maintain the section 19 measures (21(1)), and the operator must notify the responsible party immediately of suspected unauthorised access (21(2)).
• Section 22. Where there are reasonable grounds to believe personal information was accessed or acquired by an unauthorised person, notify the Regulator and the data subject (22(1)) "as soon as reasonably possible after the discovery of the compromise" (22(2)), in writing (22(4)), with enough detail for data subjects to protect themselves (22(5)).
• Section 71. Limits decisions with legal or substantial effect based solely on automated profiling, with exceptions and a duty to explain the underlying logic.
• Section 72. Transfers abroad only on listed grounds, such as a recipient bound by law, binding corporate rules or agreement giving adequate protection, consent, or contractual necessity.
• Section 73. Non-compliance with sections 22, 71 or 72, among others, is an interference the Regulator can enforce.

The Regulator has added practical detail. Its 7 April 2025 statement made the eServices portal mandatory for security compromise reports from 1 April 2025, replacing email. Its fact sheet of 19 August 2025 says POPIA has no reporting threshold, a compromise need not be confirmed before it is reported, an investigation need not be finished, and any delay must be explained; an operator tells the responsible party, which notifies the Regulator. Its 13 November 2025 briefing said the amended POPIA Regulations took effect on 17 April 2025. And its December 2024 statement on the Department of Basic Education cited its power to impose an administrative fine not exceeding R10 million for failing to comply with an enforcement notice.

Cybercrimes Act 19 of 2020

Status: mostly in force since 1 December 2021; section 54 not commenced on the official record.

The Act creates cybercrime offences, regulates investigation and international cooperation and, in the government's summary, imposes duties to report cybercrimes. The gov.za record lists the commencement in Government Gazette 45562 of 30 November 2021: from 1 December 2021 most of the Act applied, but Chapter 8 commenced "excluding section 54." The government record does not describe section 54; legal commentary we reviewed describes it as a duty on electronic communications service providers and financial institutions to report certain offences to the police. We found no later proclamation on a primary source. For now, the binding breach reporting duties are POPIA section 22 and, for financial institutions, the Joint Standard notification. Check the Gazette before relying on section 54's absence.

AI rules

We could not confirm an AI-specific statute in force, or the current status of national AI policy, on a primary source, so this guide does not describe one. Two existing rules already reach AI. POPIA section 71 limits solely automated decisions about people. And under Joint Standard 2 of 2024, models, AI libraries and external AI services are IT assets: they belong in the 7.1.1(d) inventory, and third-party and open-source AI components fall under the 7.7.5(a)(iii) policy.

What the rules ask of software and open source

Neither regime uses the word "SBOM," but together they ask for a recognisable set of supply chain practices. The evidence column describes the usual shape of a request, not any particular letter.

The inventory is the hinge: you cannot track vulnerabilities in open-source software you have not listed, and you cannot classify a supply chain incident in 24 hours without querying it in minutes. And the two regimes meet at the supplier, who is both a third-party service provider under the Joint Standard and an operator under POPIA. One contract and one evidence pack can serve both if you design them that way.

Real public incidents in or affecting South Africa

These cases come from the Information Regulator's own statements. We report what it said and draw no wider conclusions.

• Department of Basic Education, 2024 to 2025. After an assessment of how the department publishes matric results, the Regulator issued an enforcement notice on 18 November 2024 and, when no undertaking came, an infringement notice on 23 December 2024 with a R5 million fine. Its January 2025 urgent application was dismissed and placed on the ordinary roll; the department's appeal was argued on 27 and 28 October 2025, with judgment reserved, per the 13 November 2025 briefing.
• Lancet Laboratories, reported November 2025. An enforcement notice followed a compliance assessment prompted by the number of security compromises the company had experienced. The Regulator said it had not notified the Regulator under section 22, nor the affected data subjects. A R100,000 infringement fine followed non-compliance and was paid.
• Blouberg Municipality, reported November 2025. A former employee's personal information was exposed on the internet. The municipality did not follow the enforcement notice, became liable for a R500,000 fine, and the Regulator started recovery proceedings.
• Central Johannesburg TVET College, May 2026. An enforcement notice dated 22 May 2026, announced on 2 June 2026, included findings of failure to maintain appropriate security safeguards and failure to notify the Regulator and affected individuals under section 22.
• Volume. The Regulator said 2,374 security compromises were reported in 2024/25, an average of 198 a month, and 1,947 from April 2025 to 13 November 2025, an average of 284 a month, which it called a 40% increase.

None of these statements names a vulnerable software component. What they show is that failure to notify under section 22 is treated as a finding in its own right, alongside failure to keep safeguards.

The personas who own the problem

CISO

Owns the classification that starts the 24-hour clock and the governing body reporting under paragraphs 4 and 6. Needs written materiality criteria, tested portal access, and a way to answer "do we run it?" within an hour. When: before the next 7.7.4 simulation exercise.

Head of AppSec or product security

Owns 7.2.4, 7.7.5 and 7.7.6. Will be asked for the open-source code policy and proof it is enforced, test results per release, and the record that no known major flaw shipped without an approved exception. When: the next internal audit and the annual independent review under 6.2.2.

VP or Director of Engineering or Platform

Owns the cost. The risk is four separate processes for code testing, open source review, patching and release approval. Needs one pipeline where policy, tests and the release gate run together, with exceptions in one place. When: the next platform planning cycle.

GRC, compliance and regulatory affairs

Owns the evidence: a control owner, test and artefact for each Joint Standard paragraph, plus the POPIA information officer registration, section 22 procedure and section 72 transfer map. Needs an evidence store that stays current. When: the next supervisory review or on-site inspection.

Procurement and vendor risk

Owns 4.2.3, 7.2.3(a)(iii), 7.7.1(b) and 8.1.1(f), and POPIA section 21. Needs contract clauses for security roles and immediate compromise notice, a way to collect supplier software disclosures, and a register of which supplier runs which system. When: each contract renewal.

Information officer and DPO

Owns section 22 and the eServices notice. Needs a registered eServices profile, a ready notification draft, and a fast route to learn from IT and suppliers which systems and data were exposed. When: before the next compromise.

Step by step: a 30/60/90-day plan

This plan works with or without Safeguard. Organisations covered only by POPIA can skip the Joint Standard items.

Days 1 to 30: know what you have and which clocks apply

1. Confirm scope. Match each licensed entity to a class in paragraph 2.1 and list foreign subsidiaries and branches caught by 3.2 or 3.3.
2. Write the classification rule. Turn "material incident" into criteria your team can apply in minutes. Name the decision maker and deputies.
3. Test portal access. Umoja or the FSCA Joint Standards Submission Portal, and the Regulator's eServices portal. Pre-fill the template's contact tab.
4. Build a first software inventory. Generate an SBOM for every critical and customer-facing application you build, with owner and location. For bought systems, record the supplier and whether it can supply one.
5. List operators and service providers, with the systems they run, whether they process personal information, their notification clauses and hosting locations.
6. Run a one-hour drill. Pick a widely used open source component and time how long it takes to list every system and version that contains it.

Days 31 to 60: connect inventory to risk and to the pipeline

1. Link vulnerabilities to the inventory, enriched with EPSS and CISA KEV so prioritisation under 7.7.6(b)(i) rests on more than CVSS.
2. Set remediation timeframes by severity, aligned with 8.5.1, with compensating controls for when no fix exists.
3. Write the 7.7.5(a)(iii) policy: approval of new components, acceptable licences, review and testing before integration, and how updates are taken.
4. Enforce it in CI with a gate that fails a release carrying a known major flaw, and an exception path recording justification, approver and expiry.
5. Test during development with static and dynamic testing on web-based and critical applications, keeping results per release.
6. Ask top suppliers for SBOMs with a deadline, and check what comes back.

Days 61 to 90: evidence, governance and rehearsal

1. Map controls to paragraphs. Owner, test and artefact for each row of the table above.
2. Update contracts at renewal for security roles, immediate compromise notice, testing evidence and component disclosure.
3. Rehearse the 24-hour notice with a 7.7.4 exercise: a compromised open source component in a customer-facing system. Classify it, fill the template, draft the section 22 notice.
4. Report to the governing body: inventory coverage, open vulnerabilities by severity and age, exceptions in force, drill results.
5. Inventory AI systems and mark any making solely automated decisions under section 71.
6. Schedule reviews: strategy and framework annually, inventory at least every two years, the open-source policy regularly.

A template you can use today

How Safeguard does this

Everything below is GA and comes from Safeguard's offering documentation and docs.safeguard.sh. Safeguard holds no South African certification or assessment; it helps a team produce and keep the evidence these rules ask for.

1. Switch on the POPIA framework page. The Compliance and GRC suite (GA) includes a South Africa POPIA framework page, on in your workspace unless you switch it off in Compliance › Manage. Each scan checks requirements against the product's software inventory, tied to POPIA sections 16, 17, 19, 21 and 22 and the information officer duties. Further controls from Safeguard's own catalog cover areas such as cross-border transfers and information officer registration, evidenced by tests, uploads, policies or attestation. Policy templates include a Security Compromise Notification Procedure for section 22. The docs list no Joint Standards page, so map those paragraphs to controls in the suite yourself.
2. Generate SBOMs and scan dependencies. SBOM generation and analysis (GA) produces SPDX and CycloneDX, and software composition analysis with deep transitive scanning (GA) covers the open source underneath. In the Safeguard CLI, safeguard scan builds an SBOM and matches it against vulnerability databases, and safeguard validate checks CycloneDX, SPDX and VEX documents. That is your 7.1.1(d) component inventory and the base for 7.7.6(b)(iii).
3. Rank by real risk. Vulnerability management (GA) adds EPSS and CISA KEV status, and reachability analysis (GA) shows which vulnerable code paths your application actually calls, a defensible basis for 7.7.6(b)(i).
4. Test during development. SAST and DAST (GA) provide static testing of your code and dynamic testing of verified targets, supporting 7.7.5(a)(i) and (ii).
5. Enforce the policy and the release gate. Policies and gates (GA) let you create rules in Settings → Policies → Create Policy, such as no critical CVEs, a CVSS ceiling, no actively exploited CVEs or a licence rule. Each policy's action is Block, Warn or Notify, and approval for a justified exception runs through the exception workflow. In CI, the docs show:

safeguard ci scan --wait --fail-on-gate <gate>

The job fails when the gate fails, which is your record for 7.7.6(b)(ii).

6. Stop bad packages at install. Package Firewall (GA) sits on the npm and pip install path and can block malicious, typosquatted and dependency-confusion packages before they reach a build, supporting review before integration under 7.7.5(a)(iii).
7. Collect supplier SBOMs. TPRM SBOM requests (GA): open a vendor, click Request SBOM, choose products and a template, set a deadline and send, or send in bulk. Received SBOMs are checked for format and completeness and scanned automatically, with reminders seven days before the deadline, at it and seven days after. That supports 4.2.3, 7.2.3(a)(iii), 7.7.1(b) and POPIA section 21.
8. Share your own posture. Suppliers can use the Portal publish and share product (GA) and the Trust Center (GA) to publish posture and share SBOMs with regulated customers.
9. Inventory AI. AI-BOM discovery (GA) inventories AI assets across code (AI SDK imports, model weight files, prompts, notebooks, MCP server configuration), cloud inference endpoints and connected SaaS: the starting list for AI in your inventory and for section 71.
10. Fix with a human in charge. Autonomous remediation (GA) can open tested, policy-gated pull requests to a fixed version, singly or in bulk. It ships switched off, with every category set to Manual.
11. Keep code where your rules need it. SaaS runs in US, EU and Gov regions; there is no South Africa region. Where code or data should stay in your environment, the GA options are private VPC or dedicated tenancy, full on-prem, fully air-gapped deployment with the AI models inside your environment, the local runner built into the CLI (the scan runs on your machine; source code never leaves your environment and only encrypted results are sent), and Zero AI mode, with no LLM in the loop.

What Safeguard does not do

• It does not classify or file incidents. Deciding materiality, filing on Umoja or the FSCA portal, and notifying through eServices stay with your named people.
• It does not make you compliant. Met scan requirements are evidence, not a finding. Your governing body, independent reviewer, the PA, the FSCA and the Regulator decide.
• It holds no South African certification. Its own posture is "SOC 2 Type II compliant" and "designed for FedRAMP High."
• It does not host in South Africa. Use private VPC, on-prem, air-gapped deployment or the local runner if data must stay put.
• It does not cover the whole Joint Standard. MFA, perimeter defence, endpoint malware protection, backups, key management and training sit in other systems.
• It has no Joint Standards framework page. You map those paragraphs yourself.
• It does not patch what you do not build. Vendor appliances, hosted services and operating system packages still need the vendor's fix.

Common mistakes

• Starting the 24-hour clock in the wrong place. It runs from classification; without criteria and an owner, it is meaningless.
• Treating the open-source policy as paper. 7.7.5(a)(iii) asks for review and testing before integration, which needs enforcement.
• Skipping low-risk breaches. POPIA has no threshold.
• Emailing the Regulator. Since 1 April 2025, reports go through eServices.
• Assuming suppliers are someone else's problem. Both the Joint Standard and POPIA section 21 put them on your desk.
• Leaving AI out of the inventory. Models and AI services are IT assets.

FAQ

When did Joint Standard 2 of 2024 on cybersecurity come into force?

It was published on 17 May 2024 and, per Joint Communication 3 of 2025, became effective on 1 June 2025, with no transitional period in the standard itself.

Who has to comply with the cybersecurity Joint Standard?

The twelve classes in paragraph 2.1, from banks, mutual banks and insurers to CIS managers, market infrastructures, FSPs, pension funds, OTC derivative providers, section 13B administrators and credit rating agencies. Suppliers are affected through contracts.

How quickly must a South African financial institution report a cyber incident?

Under Joint Notice 2 of 2026, effective 1 September 2026, the immediate notification is due within 24 hours following classification as material, updates within 14 calendar days, and a full report on agreed timelines.

Where is the material incident template submitted?

Banks, branches, controlling companies, mutual banks and insurers use the PA's Umoja Portal; other institutions use the FSCA's Joint Standards Submission Portal.

Does POPIA require breach notification within 72 hours?

Section 22 sets no fixed hours. It requires notice as soon as reasonably possible after discovery, and the Regulator says not to wait for confirmation or a finished investigation.

Do I have to report a low-risk data breach in South Africa?

Yes. The Regulator's fact sheet says there is no threshold and every security compromise must be reported.

Does the Joint Standard require an SBOM?

Not by name. It requires a software-inclusive asset inventory (7.1.1(d)), an open-source code policy (7.7.5(a)(iii)) and tracking of open-source vulnerabilities (7.7.6(b)(iii)). An SBOM is the practical way to meet all three.

Can our source code stay in South Africa if we use Safeguard?

There is no South African SaaS region. Keep code in your environment with private VPC, on-prem or air-gapped deployment, or the CLI's local runner, which scans on your machine and sends only encrypted results. Zero AI mode removes the LLM entirely.

Every rule above comes back to one question: when a component turns out to be vulnerable, how fast can you move each affected system to a fixed version, or protect it while no fix exists? The section below is how Safeguard closes that gap, whether the trigger is a Joint Standard remediation timeframe or a POPIA section 19 duty to keep safeguards updated.

Fix it without waiting for upstream

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 categories include dependencies, licenses, security posture and findings, and each one is set separately. 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.

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

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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. 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 local runner demo shows the residency answer in practice: you set up the runner on your own machine, approve it with its device code, then scan from the terminal. For a team whose section 72 analysis says source code should stay in its environment, this is how SBOMs and findings get produced without the code going anywhere.

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

The CLI demo is a real session: it installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. That is how a remediation timeframe gets met with a human approving each change.

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

The Claude demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. A CISO or information officer can use the same pattern to ask which products contain a component in the first hours of an incident, with access limited to the tools you allow.

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

Quick check

Sources

• FSCA and PA: Joint Communication 2 of 2024
• FSCA and PA: Joint Standard 2 of 2024 package
• FSCA and PA: Joint Communication 3 of 2025
• Prudential Authority: Joint Communication 5 of 2026
• FSCA and PA: Joint Notice 2 of 2026
• FSCA and PA: Material IT and Cyber Incident Template
• Government Gazette 37067: POPIA
• gov.za: Cybercrimes Act 19 of 2020
• Information Regulator: eServices reporting statement
• Information Regulator: security compromises fact sheet
• Information Regulator: DBE infringement notice
• Information Regulator: 13 November 2025 briefing
• Information Regulator: 2 June 2026 enforcement notices
• Information Regulator: eServices portal
• Safeguard docs: South Africa POPIA
• Safeguard docs: CLI
• Safeguard docs: Policies and gates
• Safeguard docs: TPRM SBOM requests

To try the CLI and local runner yourself, download Safeguard at safeguard.sh/download and read the documentation at docs.safeguard.sh/docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.