Canada Software Supply Chain and AI Security Rules: A 90-Day Plan

In Canada, the rules that reach your software supply chain depend on who supervises you. Federally regulated banks and insurers already answer to OSFI's technology and cyber guideline (in force since 1 January 2024), its third-party risk guideline and a 24-hour incident reporting clock. Telecoms, pipelines, nuclear, transport, banking and clearing operators now have a statute, the Critical Cyber Systems Protection Act, which received royal assent on 15 June 2026 but is not yet in force, while defence suppliers face a new certification program and almost every business answers to PIPEDA and, in Quebec, Law 25.

There is no federal AI statute. This guide sets out each rule from its primary source, maps what it asks of software and open source, and ends with a 30/60/90-day plan that works with or without Safeguard. It is not legal advice; read the rules with your counsel.

Key takeaways

• OSFI B-13 (in force since 1 January 2024) asks FRFIs for a technology asset inventory that includes software, a secure development life cycle with control gates, coding principles covering third-party and open source code, and ranked, timely vulnerability remediation.
• OSFI B-10 makes an FRFI responsible for risk from its third parties' subcontractors and supply chains.
• Incident clocks differ: 24 hours to OSFI for FRFIs; up to 72 hours to the Communications Security Establishment under the new Act once it applies; "as soon as feasible" under PIPEDA; "promptly" under Quebec Law 25.
• Bill C-8 is law, but its cyber part is waiting. Part 1 (telecoms) took effect on assent; Part 2, the Critical Cyber Systems Protection Act, needs an order in council and no operators are designated yet.
• Defence suppliers: CPCSC Level 1 (13 controls, annual self-assessment) is entering select defence contracts from summer 2026.
• AI rules are sector rules for now: OSFI E-23 covers AI and vendor models from 1 May 2027, and Quebec already regulates decisions based exclusively on automated processing. Bill C-36 is a bill, not law.
• Safeguard capabilities covered, all GA: SBOM generation and analysis, SCA, vulnerability management with EPSS and KEV, reachability analysis, policies and gates, autonomous remediation (ships switched off), license compliance, CSAF and VEX upload, TPRM, the compliance and GRC suite, Trust Center, AI-BOM discovery, the CLI and local runner, and private VPC, on-prem, air-gapped and Zero AI options.

The situation

Most Canadian teams meet these rules through a letter or a deadline. An OSFI review asks how the bank inventories software and ranks vulnerabilities. A telecom or payments operator reads the new Act and asks what a "cyber security program" must contain. A defence supplier sees a CPCSC clause before contract award. A vendor breach forces a decision, within days, about reporting to the Privacy Commissioner and, in Quebec, the Commission d'accès à l'information.

A bad week looks the same in every sector. An advisory lands for a component deep in a dependency tree. Security cannot say which applications ship it, procurement cannot say which vendors embed it, and privacy cannot say whether the affected service holds personal information. The Canadian rules increasingly expect a written answer to all three.

Who this applies to in Canada

Provinces with their own private sector privacy statutes can displace PIPEDA for activity inside that province, so check which law covers each data flow. Software vendors are rarely supervised by OSFI directly, but they feel it through contracts, questionnaires and audit rights.

The rules, regulator by regulator

OSFI Guideline B-13: technology and cyber risk

OSFI published the final B-13 in July 2022 and said it "will be effective as of January 1, 2024." It applies to banks, foreign bank branches, insurers and trust and loan companies, in proportion to size and risk. The software-relevant parts:

• Principle 5: keep "an updated inventory of all technology assets," where a technology asset includes software and data, and replace or upgrade assets before maintenance ceases.
• Sections 2.4.1 and 2.4.4: an SDLC framework with control gates in each phase, security risk assessment of acquired software, and coding principles covering the "use of third-party and open-source code."
• Principle 9 (section 2.6.1): timely, tested patching through change management.
• Section 3.1.3: regular vulnerability assessments, ranked with a standard methodology that considers cumulative impact.
• Section 3.2.6: risk-based patching of vulnerabilities "in vendor software and internal applications."

B-13 also tells FRFIs to read it with Canadian Centre for Cyber Security advisories.

OSFI Guideline B-10: third-party risk

OSFI announced the revised B-10 in April 2023. It asks for a third-party risk framework across the life of each arrangement and reads directly onto software suppliers. Under section 2.2.4, "The FRFI is responsible for identifying, monitoring and managing risk arising from subcontracting arrangements undertaken by its third parties," where a subcontractor includes any entity in the third party's "supply chain." Contract options include written notice when a subcontractor is retained or substituted, a right to refuse one and audit rights over subcontractors. Due diligence should cover the cyber security and privacy practices of the third party and its subcontractors, arrangements with a presence outside Canada need a review of foreign legal and security risk, and OSFI expects prompt notice of substantive third-party issues affecting critical operations.

OSFI incident reporting and Guideline E-23

Under OSFI's Technology and Cyber Security Incident Reporting Advisory (effective 13 August 2021), FRFIs "must report a technology or cyber security incident" to OSFI's Technology Risk Division and their Lead Supervisor "within 24 hours, or sooner if possible."

Guideline E-23 on model risk takes effect on 1 May 2027. It responds to the growth of AI and machine learning models, expects model risk management to cover models "sourced from external sources like foreign offices or third-party vendors," and asks institutions to identify models used across the enterprise, "including vendor and third-party models." That is an AI inventory requirement in all but name.

Bill C-8 and the Critical Cyber Systems Protection Act

Bill C-8 (An Act respecting cyber security, amending the Telecommunications Act and making consequential amendments to other Acts) received royal assent on 15 June 2026 as Statutes of Canada 2026, chapter 9. Public Safety Canada said it "will be implemented gradually."

Part 1 is in force. It makes the security of the telecommunications system a policy objective and lets the Governor in Council and the Minister of Industry direct telecom service providers, backed by administrative monetary penalties.

Part 2 is not in force. It enacts the Critical Cyber Systems Protection Act (CCSPA), which comes into force "on a day or days to be fixed by order of the Governor in Council." The Justice Laws text, last modified 15 October 2026, notes "Part 2 not in force." Schedule 1 lists six vital services and systems: telecommunications; interprovincial or international pipelines and power lines; nuclear energy; federally regulated transportation; banking; and clearing and settlement. Schedule 2, which will name classes of operators and their regulators, is empty.

Once it applies, a designated operator must:

• Section 9: within 90 days, establish a cyber security program that identifies and manages risks "associated with the designated operator's supply chain and its use of third-party products and services," and protects, detects and limits the impact of incidents.
• Section 14: notify its regulator of material changes in its supply chain or use of third-party products.
• Section 15: mitigate supply chain and third-party risks "as soon as" they are identified. Section 15.1 lets the Communications Security Establishment issue mitigation guidelines.
• Section 17: report incidents to the Communications Security Establishment within a regulated period "not to exceed 72 hours."
• Section 30: keep records of program steps, incidents and supply chain mitigation, in Canada.

Penalties can reach $15,000,000 per violation for an organisation. Until the order, designations and regulations exist, nobody is a designated operator; that is preparation time.

Canadian Program for Cyber Security Certification (CPCSC)

PSPC introduced CPCSC Level 1 on 14 April 2026. It requires "an annual cyber security self-assessment" of 13 security requirements and controls, was available to suppliers from 1 April 2026, and is entering select defence contracts from summer 2026, with certification needed at contract award rather than at bid. Level 2, an external assessment every three years, is planned for select contracts from spring 2027; Level 3 is government-assessed. PSPC describes the standard as technically identical to NIST SP 800-171 and SP 800-172 controls and says Canada may accept a valid US CMMC status case by case.

PIPEDA

PIPEDA remains the federal private sector privacy law. Clause 4.1.3 of Schedule 1 makes an organisation responsible for information "transferred to a third party for processing," requiring a comparable level of protection by contract. Principle 7 (clause 4.7) requires safeguards appropriate to sensitivity, including technological measures. Section 10.1 requires a report to the Commissioner of any breach creating a real risk of significant harm "as soon as feasible after the organization determines that the breach has occurred," plus notice to individuals. The Breach of Security Safeguards Regulations require a record of "every breach of security safeguards for 24 months."

Quebec Law 25

Law 25 (S.Q. 2021, c. 25; Loi modernisant des dispositions législatives en matière de protection des renseignements personnels) amended Quebec's private sector privacy Act in phases on 22 September 2022, 22 September 2023 and 22 September 2024. The sections that touch software:

• Section 3.3: a privacy impact assessment for "any project to acquire, develop or overhaul an information system" involving personal information.
• Sections 3.5 and 3.8: after a confidentiality incident with a risk of serious injury, "promptly notify" the Commission and the persons concerned, and keep a register of all incidents.
• Section 12.1: tell a person when a decision about them is based exclusively on automated processing and, on request, explain the factors.
• Section 17: a privacy impact assessment before communicating personal information outside Quebec.
• Section 18.3: service provider mandates in writing, specifying the protection measures.

Penal fines for enterprises reach $25,000,000 or 4% of worldwide turnover.

Bill C-36 and the state of AI rules

On 15 June 2026 the government tabled Bill C-36, which would enact the Protecting Privacy and Consumer Data Act. ISED's backgrounder says it would require organisations to "assess and mitigate any privacy risks before sending personal information outside of Canada" and increase transparency around automated decision systems, and the Privacy Commissioner notes it would move oversight to a new Digital Safety and Data Protection Commission. It is a bill; PIPEDA stays in force until a replacement passes.

The Artificial Intelligence and Data Act, proposed in Bill C-27 in the previous Parliament, never became law, and no federal AI statute is in force. The AI for All strategy, launched on 4 June 2026, says it "will introduce new legislation" over five years. ISED's AI transparency consultation describes the generative AI Voluntary Code of Conduct as "voluntary and not enforceable." The binding AI-relevant rules today are OSFI E-23 (from May 2027) and Quebec's section 12.1.

Cyber Centre guidance on SBOMs and open source

The Cyber Centre is not a regulator, but OSFI points FRFIs to it and its parent, the Communications Security Establishment, receives CCSPA reports. It joined the joint guidance A Shared Vision of Software Bill of Materials (SBOM) for Cybersecurity on 3 September 2025 and co-issued the 2026 Minimum Elements for an SBOM, which "replaces the 2021 Minimum Elements" and applies to open source, AI software and SaaS. ITSAP.10.059 tells organisations to "request a software bill of materials (SBOM) for all software," ITSM.10.071 covers vendor update channels and dependencies as attack paths, and its agentic AI guidance points buyers to the SBOM guidance. The National Cyber Security Strategy, Securing Canada's Digital Future (6 February 2025), sets the policy direction.

How the rules fit together

What the rules ask of software and open source

The table maps each requirement to the evidence a supervisor or commissioner is likely to ask for. It is a starting point for your own control set, not a statement of what any regulator will accept.

No Canadian statute names an SBOM today, but an SBOM is the cheapest way to produce the inventory that B-13, the CCSPA and Law 25 all assume. The clocks run in parallel: a bank whose vendor leaks customer data may owe OSFI a report within 24 hours and the Privacy Commissioner one as soon as feasible. And the CCSPA's records-in-Canada rule and Law 25's transfer assessment make the location of your security tooling's own data a compliance question.

Real public incidents in or affecting Canada

These come from official Canadian sources only and show the shape of the problem, not judgements about any organisation.

FINTRAC cyber incident (March 2024)

FINTRAC's 2024 to 2025 departmental results report says it detected a cyber incident in March 2024 and "some of its systems were taken offline." Forensic work by the Cyber Centre found "no evidence that any information had been removed." Restoring full capacity took months, followed by investment in detection, zero-trust architecture and cloud reporting security.

PowerSchool breach affecting Canadian schools (2025)

On 11 February 2025 the Privacy Commissioner opened a PIPEDA investigation after a breach report from PowerSchool, an education technology vendor serving Canadian school boards. On 22 July 2025 the OPC said a hacker had obtained names, contact details, dates of birth and, in some cases, medical information and Social Insurance Numbers of students, educators and parents across several provinces and territories. The OPC discontinued its investigation after PowerSchool committed to stronger measures, while Ontario and Alberta commissioners continued reviews from the school boards' side. One vendor incident created duties for many controllers at once.

Salt Typhoon in a Canadian telecom's network devices (February 2025)

A Cyber Centre and FBI bulletin says three network devices registered to a Canadian telecommunications company "were compromised by likely Salt Typhoon actors in mid-February 2025," through CVE-2023-20198, with configuration files retrieved and a GRE tunnel configured for traffic collection. This is the class of operator the CCSPA was written for.

Hacktivists tamper with industrial control systems (October 2025)

Cyber Centre alert AL25-016 (29 October 2025) reports incidents involving internet-accessible industrial control systems, including a water facility where tampering with pressure values degraded service, an oil and gas tank gauge and a grain drying silo. Firmware and vendor remote access software in those devices are part of the supply chain too.

The Cyber Centre's National Cyber Threat Assessment 2025 to 2026 notes continuing attacks on software, IT and cloud vendors to reach their customers, including "double supply chain attacks where one supply chain attack enables another."

The personas who own the problem

• CISO at an FRFI. Owns the B-13 conversation with OSFI and the 24-hour report. Trigger: a supervisory letter, an audit finding or a vendor incident. Needs one inventory that joins applications, components, vendors and data, a ranking method they can explain, and, by May 2027, AI models in that inventory.
• GRC and regulatory affairs. Turns clauses into controls and evidence across OSFI, PIPEDA, Law 25 and possibly CPCSC and the CCSPA. Trigger: the audit calendar and new law. Needs a clause-level control map and honest statuses, because the CCSPA and Bill C-36 are not yet obligations.
• Head of AppSec and VP of Engineering. Feels B-13 Principle 7 and CPCSC as pipeline gates and a backlog. Trigger: a failed gate, an expired exception or an SBOM request from a customer. Needs SBOMs on every build, a gate with clear outcomes and a short list of what to fix first.
• Procurement and vendor risk. Owns B-10, PIPEDA clause 4.1.3 and Law 25 section 18.3 in practice. Trigger: a renewal or a vendor breach notice. Needs to know which vendors are critical, what each disclosed about components and subcontractors, and which contracts carry notice and audit clauses.
• Privacy officer and the Law 25 person in charge. Owns PIAs under sections 3.3 and 17, the incident register and the PIPEDA breach decision. Trigger: a new system, a transfer or an incident. Needs to know which systems hold personal information, which providers sit inside them and where data goes, including security tool data.
• Defence supplier CTO. Often one person doing all of the above. Trigger: a CPCSC clause before award. Needs a Level 1 self-assessment they can stand behind.
• Operators expecting CCSPA designation. Need a program ready within 90 days of designation, a supply chain section, a 72-hour reporting path and records kept in Canada.

Step by step: a 30/60/90-day plan that works with or without Safeguard

Days 1 to 30: inventory and clocks

1. Decide which regimes apply now, on a known date (E-23 on 1 May 2027, CPCSC Level 2 from spring 2027) or possibly later (CCSPA designation, Bill C-36).
2. List critical business services and the applications behind them.
3. Generate an SPDX or CycloneDX SBOM for each critical application and store it with its release.
4. Match components against vulnerability data and record EPSS and CISA KEV beside CVSS, so your ranking can be explained as B-13 s. 3.1.3 asks.
5. Write the incident clock sheet below.
6. Pull the vendor list, mark critical vendors and note which have provided an SBOM or attestation.

Days 31 to 60: gates, contracts and a drill

1. Turn on a CI policy gate in Warn mode for critical applications, moving to Block for critical, exploitable vulnerabilities once the backlog allows. Approvals run through a documented exception with an expiry date.
2. Fix the top of the list through normal change management, starting with reachable or known exploited vulnerabilities.
3. Add the clauses below to contract templates and use them at each critical renewal.
4. Request SBOMs from critical vendors and record refusals; accept VEX statements that explain why a vulnerability does not affect a product.
5. Run a tabletop on a vendor component compromise and time the answer to "which applications and vendors ship this, and do they hold personal information?"
6. Start the AI inventory: AI SDK imports, model files, agents and AI services by application and vendor.

Days 61 to 90: evidence, residency and review

1. Build a register mapping each clause (B-13, B-10, PIPEDA, Law 25, CPCSC) to its evidence and owner.
2. Document where SBOMs, scan results and evidence live; check whether Quebec data needs a section 17 assessment and plan for records in Canada if you expect designation.
3. Prepare a customer-facing security pack if you sell into Canadian regulated buyers.
4. Brief the board with honest statuses: in force, law but not in force, proposed.
5. Set a quarterly cadence for vendor SBOM requests and the AI inventory, and a twice-yearly tabletop.

Template: incident clock sheet

Checklist: clauses for software and service provider contracts

• A written mandate specifying the provider's protection measures (Law 25 s. 18.3; PIPEDA cl. 4.1.3).
• Incident notice with a clock short enough to meet your own regulatory clock.
• Notice of new or substituted subcontractors, a right to object, and audit rights that reach subcontractors (B-10 s. 2.2.4).
• An SBOM per release in SPDX or CycloneDX, and VEX statements for disclosed vulnerabilities.
• A vulnerability handling commitment with fix times by severity.
• Data location terms covering your data and the vendor's telemetry about you.
• Return or destruction of data at exit, and an exit plan for critical services.
• For AI features: which models, where inference runs, and whether your data trains them.

Decision table: the vendor will not provide an SBOM

How Safeguard does this

Everything below is available today (GA). Safeguard helps a team produce and keep the evidence these regimes ask for; it does not make an organisation compliant, and it holds no Canadian certification or government listing.

1. Map the frameworks. The compliance and GRC suite (GA) includes framework pages for Canada PIPEDA and Quebec Law 25. Each scan of a product checks the page's requirements against its SBOM, for example PIPEDA Principle 4.7, clause 4.1.3 and section 10.1 readiness, or Law 25 sections 3.3 and 3.5 and its service provider requirements, and each page lists controls and policy templates. A Canada CPPA page follows the Consumer Privacy Protection Act from the former Bill C-27, which did not become law; treat it as a forward-looking checklist and expect Bill C-36 to differ. There is no framework page for OSFI guidelines, the CCSPA or CPCSC, so map those clauses yourself using the evidence below.
2. Build the inventory. SBOM generation and analysis (GA) produces SPDX and CycloneDX SBOMs from connected repositories, container registries, Hugging Face models and uploaded manifests, and software composition analysis (GA) covers the full transitive tree. From a terminal:

safeguard scan --dir .
safeguard scan --image myregistry.azurecr.io/myapp:v1

3. Rank what matters. Vulnerability management (GA) adds EPSS and CISA KEV, and reachability analysis (GA) shows whether your code calls the vulnerable path: a documented ranking method for B-13 s. 3.1.3.
4. Gate the pipeline. Policies and gates (GA) evaluate SBOMs against severity, CVSS, EPSS, license and maintenance conditions. Each failed policy's action is Block, Warn or Notify, and approval for an exception runs through a request with a justification and an expiry date. The docs show the CI form:

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

5. Fix with a human in the loop. Autonomous remediation (GA) has Griffin open tested fix pull requests, singly or in bulk (one per repository). It ships switched off, with every category set to Manual, so fixes still pass your change management.
6. Bring vendors in. TPRM (GA) keeps a vendor directory with risk tiers and contract status, sends single or bulk SBOM requests with deadlines and reminders, and validates submitted SBOMs before scanning them. CSAF and VEX upload (GA) puts vendor advisories and "not affected" statements on file. License compliance (GA) checks open source licences against your policy.
7. Inventory AI. AI-BOM discovery (GA) catalogues AI SDK imports, model weight files, prompt templates, MCP server configuration, managed inference endpoints and vector stores, the starting list for E-23 and Law 25 s. 12.1 work.
8. Show customers your posture. Trust Center (GA) publishes your frameworks, controls, policies and documents for Canadian buyers' due diligence.
9. Choose where the data lives. Safeguard's SaaS runs in US, EU and Gov regions; there is no Canadian region. For residency, the GA options are private VPC or dedicated tenancy, full on-prem, and fully air-gapped deployment with the AI models inside your environment and signed offline update bundles. The local runner (GA) scans on your own machine and uploads only the resulting SBOM and findings, so source code stays with you, and it opens outbound HTTPS only. Zero AI mode (GA) runs the platform with no LLM in the loop, and bring your own model (GA) uses a model you have already approved. Whether these satisfy a particular rule is for you and your counsel.

safeguard runner start --workspace ./path/to/repo
safeguard runner status

Safeguard's own posture is "SOC 2 Type II audit in progress" and "designed for FedRAMP High". Neither is a Canadian certification.

What Safeguard does not do

• It does not report incidents for you. OSFI, the Communications Security Establishment, the Privacy Commissioner and the CAI hear from you. Safeguard shows which products and vendors carry an affected component; the reportability decision and the report stay with your team.
• It does not ship OSFI, CCSPA or CPCSC framework pages. Mapping those clauses to evidence is your work.
• It does not offer a Canadian SaaS region. If data must stay in Canada, look at on-prem in your own data centre, private VPC or dedicated tenancy, air-gapped deployment or the local runner, and confirm the fit with counsel.
• It does not replace legal judgement or contracts. It can track whether a vendor sent an SBOM; it cannot negotiate a subcontractor clause or decide whether a transfer outside Quebec is adequately protected.
• It does not fix code it cannot change. Vendor appliances, hosted services and operating system runtimes still need fixes from their suppliers.
• It does not certify you. Readiness views help you prepare for a CPCSC self-assessment or an OSFI review; they are not an assessment by any Canadian authority.

Common mistakes

• Treating Bill C-8 as fully in force. Part 2, the CCSPA, is not, and nobody is designated.
• Treating Bill C-36 or AIDA as law. PIPEDA is the law today, and there is no federal AI statute.
• Running one incident clock. One incident can trigger OSFI's 24 hours, PIPEDA's "as soon as feasible" and Law 25's "promptly" at once.
• Inventorying applications but not components. Vulnerabilities live several layers down.
• Forgetting the security tools' own data. SBOMs and scan results describe your architecture and fall under Law 25 s. 17 and, later, CCSPA s. 30.
• Leaving AI out of the inventory. E-23 covers vendor and third-party models from 1 May 2027.
• Collecting vendor SBOMs and never scanning them. Record the outcome or the request is theatre.

FAQ

What is OSFI Guideline B-13 and when did it take effect?

OSFI's guideline on technology and cyber risk for federally regulated financial institutions, published in July 2022 and effective since 1 January 2024. It covers asset inventory, secure development, patching and vulnerability management, among other things.

Is the Critical Cyber Systems Protection Act in force?

Not yet. Bill C-8 received royal assent on 15 June 2026 and its telecom amendments took effect then, but Part 2, the CCSPA, needs an order in council and no operator classes are designated.

What is the incident reporting deadline under the CCSPA?

Once in force, section 17 requires a designated operator to report to the Communications Security Establishment within a regulated period not exceeding 72 hours.

How fast must a bank report a cyber incident to OSFI?

Within 24 hours, or sooner if possible, to OSFI's Technology Risk Division and the institution's Lead Supervisor.

Does Canada require a software bill of materials?

Not by statute. The Cyber Centre recommends requesting an SBOM for all software and co-issued the 2026 minimum elements, and OSFI and the CCSPA expect the inventory and supply chain risk management that SBOMs support.

What is CPCSC Level 1?

An annual self-assessment against 13 security requirements for defence suppliers handling specified information, entering select defence contracts from summer 2026 and required at contract award.

Does Canada have an AI law?

No federal AI statute is in force; the Artificial Intelligence and Data Act was never enacted. OSFI E-23 (from 1 May 2027) and Quebec's automated decision rule are binding today, and Bill C-36 would add federal transparency rules if passed.

What does Quebec Law 25 require before sending data outside Quebec?

Section 17 requires a privacy impact assessment that weighs the information's sensitivity, the purposes, the protection measures including contractual ones, and the destination's legal framework.

Does OSFI B-10 cover open source and subcontractors?

B-10 makes the FRFI responsible for its third parties' subcontractors and supply chains. Open source in your own code falls under B-13's coding principles; open source inside a vendor's product reaches you through B-10 due diligence.

Every Canadian regime above, from B-13 section 3.2.6 to Law 25's incident duties, ends in the same practical question: how quickly a known vulnerable component stops running in your software. The block below describes the ways Safeguard closes that gap, whether a fixed version already exists or upstream has not shipped one yet.

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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. 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 sets up the runner on your own machine, approves it with its device code, then scans from the terminal. For a Canadian team weighing Law 25 transfer assessments or CCSPA records planning, this is the flow that keeps source code on your own hardware while the SBOM and findings go to the platform.

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

The CLI demo is a real session: install, open the interactive terminal, ask it to fix a lodash CVE, and watch it read the finding and advisory, edit package.json, and run npm install and npm test, asking before any command that changes something and pushing nothing. That is the B-13 pattern of a timely fix that still passes through testing and a human decision.

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 chooses which tools Claude can use. GRC and vendor risk teams can use the same connection to ask questions of their inventory in plain language while keeping control over what the assistant may touch.

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

Quick check

Related reading

• Canada's National Cyber Security Strategy and SBOMs
• Canada Bill C-8 and the Critical Cyber Systems Protection Act
• PIPEDA requirements in plain language
• PIPEDA safeguards, the software supply chain and SBOMs
• The Canadian Cyber Centre's supply chain guidance
• The Air Canada chatbot ruling: a company is liable for its chatbot's advice

Sources

• OSFI Guideline B-13, Technology and Cyber Risk Management
• OSFI news release on final Guideline B-13 (July 2022)
• OSFI Guideline B-10, Third-Party Risk Management
• OSFI news release on Guideline B-10 (April 2023)
• OSFI Technology and Cyber Security Incident Reporting Advisory
• OSFI Guideline E-23, Model Risk Management (2027)
• S.C. 2026, c. 9, An Act respecting cyber security (Justice Laws)
• Public Safety Canada, royal assent of Bill C-8 (16 June 2026)
• PSPC, Government of Canada introduces Level 1 of the CPCSC (14 April 2026)
• PSPC backgrounder, CPCSC Level 1
• PIPEDA, full text (Justice Laws)
• Breach of Security Safeguards Regulations, SOR/2018-64
• OPC, What you need to know about mandatory reporting of breaches of security safeguards
• Quebec, S.Q. 2021, c. 25 (Law 25), annual statute PDF
• ISED backgrounder on Bill C-36 (15 June 2026)
• Privacy Commissioner's statement on Bill C-36
• Department of Justice, Charter statement on Bill C-36
• Prime Minister's Office, AI for All national AI strategy (4 June 2026)
• ISED, Enhancing trust in artificial intelligence through increased transparency
• Public Safety Canada, National Cyber Security Strategy release (6 February 2025)
• Cyber Centre, joint guidance on a shared vision of SBOM
• CISA, Shared Vision of SBOM release
• Cyber Centre, joint guidance on minimum elements for an SBOM
• Cyber Centre, ITSAP.10.059 open source software
• Cyber Centre, ITSM.10.071 software supply chain threats
• Cyber Centre, careful adoption of agentic AI
• Cyber Centre, National Cyber Threat Assessment 2025 to 2026
• FINTRAC 2024 to 2025 departmental results report
• OPC statement on the PowerSchool breach (11 February 2025)
• OPC news release on PowerSchool commitments (22 July 2025)
• Cyber Centre and FBI bulletin on PRC actors targeting telecommunications companies
• Cyber Centre alert AL25-016, internet-accessible ICS abused by hacktivists
• Safeguard docs, Canada PIPEDA framework
• Safeguard docs, Quebec Law 25 framework
• Safeguard docs, Canada CPPA framework
• Safeguard docs, Compliance
• Safeguard docs, Generate SBOM
• Safeguard docs, CLI usage
• Safeguard docs, Policies and Gates
• Safeguard docs, Reachability Analysis
• Safeguard docs, AI Remediate
• Safeguard docs, TPRM SBOM Requests
• Safeguard docs, TPRM Vendor Management
• Safeguard docs, CSAF/VEX Upload
• Safeguard docs, AI-BOM Discovery
• Safeguard docs, Trust Center setup
• Safeguard docs, Local Runner
• Safeguard docs, Air-Gapped Deployment

Start with the free tier at safeguard.sh/download and read the Safeguard docs.

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