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

If you build, buy or run software for an Israeli bank, insurer, pension fund, government office or any organisation that keeps personal data in Israel, five sets of rules decide what your software supply chain has to prove: the Israel National Cyber Directorate's Cyber Defense Methodology (ICDM 2.0), the Bank of Israel's Proper Conduct of Banking Business Directive 364, which replaced Directives 357, 361 and 363 when it took effect in May 2026, the Capital Market, Insurance and Savings Authority's cyber circulars, the Privacy Protection Law as amended by Amendment 13 (in force since 14 August 2025), and the Privacy Protection (Data Security) Regulations 2017. None of them is an SBOM law, yet each expects an up-to-date inventory of the software you run, a patch process with testing, managed suppliers and evidence a supervisor can check. This guide sets out each rule from the best source we could reach, maps it to the evidence reviewers ask for, and ends with a 30/60/90-day plan that works with the tools you already have.

This post explains public regulatory texts. It is not legal or regulatory advice. Most of the binding Israeli texts are in Hebrew, and the Hebrew version is the one that counts.

Key takeaways

• Banks have a new directive. Directive 364, published on 18 November 2024, took effect in May 2026 and cancelled Directives 357, 361 and 363. Older contracts must be brought into line at renewal, and no later than three and a half years after commencement.
• The INCD methodology is the common language. ICDM 2.0 (June 2021) is built on NIST CSF 1.1 and NIST SP 800-53 Rev. 5, and is the required methodology for government offices.
• Privacy enforcement changed on 14 August 2025. Amendment 13 strengthened the Privacy Protection Authority's enforcement. The Data Security Regulations (in force since May 2018) remain the technical rulebook.
• Suppliers are inside the perimeter. Directive 364 applies to information assets a third party manages and has a dedicated third party chapter.
• AI is governed by policy and existing law. Israel has no AI statute; privacy law and sector rules carry the weight.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis (GA), software composition analysis with deep transitive dependency scanning (GA), vulnerability management with EPSS and CISA KEV enrichment (GA), reachability analysis (GA), policies and gates (GA), license compliance (GA), the Compliance and GRC suite (GA), Third-Party Risk Manager (GA), Package Firewall (GA), AI-BOM discovery (GA), autonomous remediation (GA, ships switched off), the Safeguard CLI and local runner (GA), Zero AI mode (GA), bring your own model (GA), and private VPC, on-prem and air-gapped deployment (GA).

The situation

In Israel the trigger is usually a document with a date on it: a Banking Supervision circular, a revised Capital Market Authority circular, a bank's supplier questionnaire built on the INCD methodology, a Privacy Protection Authority inspection. Or a public incident hits a widely used component, and the board asks: do we run that, and where?

A bad week looks like this. A supervisor or a large customer wants your software inventory, your patch testing records and your supplier assessments by Thursday. The inventory is a list of servers, the patch records live in a ticketing system nobody exports, and the supplier file is a folder of questionnaires from three years ago.

The good news is that the five regimes overlap heavily. One component-level inventory, one vulnerability and patch process with dated evidence, and one supplier file can answer most of what each regulator asks.

Who this applies to in Israel

Two points matter for software teams. The Data Security Regulations reach almost every Israeli organisation that keeps a database of personal data. And suppliers are pulled in by contract. A software company selling to an Israeli bank meets Directive 364 through the bank's third party assessment, its contract clauses and its right to test controls, even though Banking Supervision does not supervise the supplier. The same is true for suppliers of institutional entities under the Capital Market Authority's circular.

The rules, regulator by regulator

INCD Cyber Defense Methodology (ICDM 2.0)

The Israel National Cyber Directorate (in Hebrew, Ma'arach HaSyber HaLeumi) sits in the Prime Minister's Office and is the national authority for cyber defence. NIST's published success story, written with the INCD, records the history. The INCD published the Israeli Cyber Defense Methodology 1.0 in 2017, adopting NIST Cybersecurity Framework 1.0. It published ICDM 2.0 in June 2021, built on NIST Cybersecurity Framework 1.1, NIST SP 800-53 Revision 5 and other NIST standards, and adding MITRE threat-informed defence and zero trust. In 2021 the whole Israeli government adopted ICDM as the required cyber risk methodology for its offices, and the INCD said it was working with selected regulators to adopt it in their sectors.

Each ICDM control comes with a maturity model, explanations, templates and mappings to other standards.

For a software team, three control areas carry the weight. Because ICDM 2.0 draws on NIST SP 800-53 Rev. 5, we have added NIST identifiers below as our own cross-walk; they are not the INCD's mapping, and your register should use the INCD's own control numbering from the methodology itself.

• Asset management. The identify function starts with an inventory of hardware, software and data. In SP 800-53 terms this is CM-8, system component inventory, which asks for an inventory that reflects the system accurately and at the level of detail needed for tracking and reporting.
• Vulnerability and patch management. Identify vulnerabilities in your assets, assess them and remediate on a defined cadence. In SP 800-53 terms this is RA-5, vulnerability monitoring and scanning, and SI-2, flaw remediation, which includes testing updates before installation.
• Supply chain risk management. Assess and manage the risk suppliers and the software they deliver bring in. SP 800-53 Rev. 5 groups this in the SR family, including SR-3 (supply chain controls and processes), SR-4 (provenance) and SR-11 (component authenticity).

For most private organisations ICDM is guidance rather than statute. It becomes binding in practice when a sector regulator builds it into its rules or a customer writes it into a contract, which is common in Israeli procurement.

Bank of Israel Directive 364: Management of IT, Information Security and Cyber Defense Risks

This is the biggest change for Israeli banks in a decade, and many summaries still describe the old directives. On 18 November 2024 the Supervisor of Banks published Circular C-06-2799, which issued Proper Conduct of Banking Business Directive 364. The circular says the directive replaces three existing directives: 357 on Information Technology Management, 361 on Cyber Defense Management and 363 on Cyber Risk Management in the Supply Chain. Two older supervisory letters, on IT asset management (2009) and on key IT processes (2009), are cancelled too.

The dates, from the circular's transitional provisions (the paragraph numbers below are the circular's; the section numbers elsewhere in this post are the directive's, as the circular cites them):

• Commencement. The directive takes effect 18 months from publication (paragraph 194 of the circular), which places commencement in May 2026. As of today it is in force.
• Cancellation. On commencement, Directives 357, 361 and 363 are cancelled (paragraph 192). Approvals the Supervisor issued under them stay in effect (paragraph 193).
• Existing contracts. Contracts concluded before publication must be adapted at their next renewal, and no later than three and a half years after commencement, five years in total from publication (paragraph 195).
• Early adoption. A bank could apply the directive earlier if it notified the Supervisor 30 days in advance (paragraphs 196 and 197).

The directive is mainly principles-based and technology neutral. Its building block is the information asset, and it applies to information assets managed by a third party, whether inside or outside the bank's premises (section 5). Its sixteen chapters are grouped in six parts. The ones that matter most for software:

• Chapter B, corporate governance. Roles for the board, senior management and the Chief Cyber Defense and Information Security Officer, among others.
• Chapter C, the IT risk management framework. Identification and classification of information assets and their sensitivity. The circular calls this identification a basic condition for meeting the rest of the directive.
• Chapter E, IT management. Technology infrastructure controls (section 58), with examples that include an up-to-date inventory of hardware and of the hardware and software that make up networks and communications, and patch management (section 61.4). The circular says a bank must set procedures for constantly updating patches against vulnerabilities, for examining patches in a separate environment and for installing them, with a separate route for emergency changes (section 97).
• Chapter F, project and change management. Acquisition, system development, APIs and change management.
• Chapters G to I, information security. The framework (section 103), the controls and their ongoing assessment. For timely identification and remediation of new vulnerabilities, the circular's examples are patch and configuration management, tested with vulnerability scanning and penetration testing.
• Chapter M, third party risk management. This brings together the directive's requirements on third parties, defined more broadly than "service provider" under the outsourcing directive. A bank must assess the adequacy of a third party's information security capability, using interviews, service reporting, control testing and independent assurance (section 102), and must evaluate controls over information assets a third party manages by the same principles it applies to itself (section 140).
• Chapter P, reporting to Banking Supervision.

Directive 364 also defines sensitive information to include "information of special sensitivity" as Amendment 13 defines it, which ties bank IT controls to the privacy law.

The old Directives 361, 357 and 363

You will still see these numbers in questionnaires and audit reports. Directive 361 came with Circular 2457-06-H on 16 March 2015, which described a principles-based framework rather than a strict list of controls. Directive 357 covered IT management and Directive 363 supply chain cyber risk. If a questionnaire still cites them, map each question to the matching Directive 364 chapter and answer against the current text.

Capital Market, Insurance and Savings Authority cyber circulars

The Capital Market, Insurance and Savings Authority supervises insurers, pension and provident funds and other institutional entities, and licenses a range of non-bank financial service providers. We could not load the Authority's own pages from our location, so the names and dates below come from published legal summaries. Check the Authority's site for later updates or replacements before relying on them.

For institutional entities, a 2016 summary on law.co.il reports the circular on Cyber Risk Management at Institutional Entities (Institutional Entities Circular 2016-9-14), taking effect on 2 April 2017 with some provisions from October 2017. According to that summary, it requires an annually approved board cyber policy, a chief cyber defence officer, a CEO-led steering committee and a cyber risk management programme.

A June 2022 summary by the law firm Barnea Jaffa Lande reports a further cyber circular for licensed financial service providers (deposit and credit, peer to peer, payment and digital wallet, financial information services), requiring a board-approved cyber policy, a cyber defence officer and a work plan, with a one-year preparation period.

Privacy Protection Law and Amendment 13

The Privacy Protection Law 5741-1981 is Israel's general privacy statute, enforced by the Privacy Protection Authority (in Hebrew, HaRashut LeHaganat HaPratiyut) in the Ministry of Justice. Amendment 13 entered into force on 14 August 2025, the date given in the Authority's own published guidance and in the US Library of Congress's legal monitor. It strengthens the Authority's enforcement and changes several duties, including who must appoint a privacy protection officer. Directive 364 already refers to Amendment 13's definition of information of special sensitivity.

We could not load the amended statute or the Authority's guidance from our location, so this post does not summarise the amendment's detailed duties. Read the amended law and the Authority's guidance on it directly, in particular on the privacy protection officer, database registration, the Authority's enforcement powers and damages.

Privacy Protection (Data Security) Regulations 2017

The Data Security Regulations 5777-2017 are the most operational privacy text for engineers. According to the State Comptroller's 2019 annual report (69b), the Knesset's Constitution, Law and Justice Committee approved them in March 2017 and they came into force in May 2018. The same report describes three security levels for databases (basic, intermediate and high) and says the level decides, among other things, how a serious security incident is reported and handled, whether the database is audited and how detailed its security procedure must be. It gives as an example of a high-level database one holding data on a person's criminal record or financial situation for 100,000 people or more, and says the owner of a high-level database must carry out a risk survey and penetration tests at least once every 18 months.

Beyond that, read the regulations themselves and their schedule of security levels before you map controls; the Authority publishes an English translation for convenience, with the Hebrew text binding.

AI policy and privacy guidance on AI

Israel has no general AI statute. In December 2023 the Ministry of Innovation, Science and Technology and the Ministry of Justice's Office of Legal Counsel and Legislative Affairs published Israel's first policy on AI regulation and ethics. As the US International Trade Administration summarises it, the policy addresses challenges such as bias, transparency, safety, accountability and privacy, and proposes an AI Policy Coordination Center and forums for regulators. Its approach is sector regulators applying existing law, risk-based thinking and soft tools such as guidelines and standards before hard regulation.

The Privacy Protection Authority has published draft guidance on applying the Privacy Protection Law to AI systems. We could not confirm its current status or final content, so check the Authority's site before relying on it.

So the AI controls you need today come from privacy law, sector cyber rules (an AI service is still an information asset under Directive 364) and your own policy.

What the rules ask of software and open source

Read side by side, the regimes ask the same seven things.

Three points from the table deserve emphasis.

No Israeli text we read says "SBOM". None needs to. A bank that must identify every information asset, including those a third party manages, and keep patches current cannot do either for software without component-level data.

Patch testing in a separate environment is explicit for banks. Directive 364 section 61.4, as the circular explains it, expects procedures for examining patches in a separate environment before installation. That rules out "upgrade straight in production" as a default, and it means your remediation workflow has to leave a test record.

Third party evidence must be tested, not just collected. Section 140 expects a bank to evaluate a third party's controls by the same principles it uses internally; supplier SBOMs, scan results and independent assurance give it something to test.

Real public incidents in or affecting Israel from the last three years

Three public cases, all from official reporting, show how supply chain exposure reaches Israeli organisations and Israeli-made technology.

Unitronics programmable logic controllers, from November 2023. The FBI, CISA, the NSA, the US Environmental Protection Agency, the INCD, the Canadian Centre for Cyber Security and the UK National Cyber Security Centre published joint advisory AA23-335A, first released on 1 December 2023 and updated on 18 December 2024. It reports that, from November 2023, actors the agencies tie to Iran's Islamic Revolutionary Guard Corps, using the persona CyberAv3ngers, compromised Israeli-made Unitronics Vision Series PLCs and human machine interfaces, with victims in several US states and other countries. The advisory says the PLCs were internet-facing and used default passwords or none, and recommends checking PLCs for default or missing passwords and removing insecure internet exposure.

XZ Utils, March 2024 (CVE-2024-3094). On 29 March 2024 CISA reported malicious code embedded in XZ Utils versions 5.6.0 and 5.6.1, a compression library that ships with many Linux distributions, and advised downgrading to an uncompromised version. Any Israeli organisation running an affected distribution was exposed through a component few teams had listed by name.

npm ecosystem compromise, September 2025. On 23 September 2025 CISA reported a self-replicating worm, publicly known as Shai-Hulud, that had compromised over 500 npm packages. CISA says the malware looked for credentials, including GitHub personal access tokens and cloud API keys, sent them to the actor and used the stolen npm access to publish compromised versions of further packages. CISA's recommendations included a dependency review of all npm-based software, checking lock files for affected packages including nested ones, pinning to versions released before 16 September 2025 and rotating developer credentials immediately.

None of these reports tells a specific Israeli organisation what it should have done, and this post does not either.

The personas who own the problem

Chief Cyber Defense and Information Security Officer, or CISO. Owns the framework, reports to the board and answers the supervisor. Needs one defensible view of software risk across the organisation and its third parties, for the board report and within hours of a public incident.

Head of AppSec or VP Engineering. Owns the pipeline and Directive 364 chapter F in practice. Needs the inventory, patch testing and change record to come out of the normal development flow, and a gate that stops real risk without stopping releases.

GRC and regulatory affairs lead. At a bank, the urgent job is re-mapping a control register written for 357, 361 and 363 to Directive 364. Needs dated evidence keyed to the regulator's own numbering, ready for inspection or internal audit.

Procurement and vendor risk owner. Directive 364's transition puts renewals on their calendar. Needs a standard clause set and evidence request (SBOM, vulnerability handling, incident notice, right to test) for every renewal.

Privacy protection officer. A role Amendment 13 changed. Needs to know which systems hold which databases at which security level, which suppliers process them, how fast a serious incident would be reported, and which AI systems use personal data.

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

Days 1 to 30: establish scope and inventory

1. Write down which regimes apply and who owns each. Use the "who this applies to" table. For each regime, record the supervisor, the binding text and its version (for banks, Directive 364 and its companions 362, 359A, 355 and 366), the internal owner and the next known date: an inspection, a board report, a renewal.
2. Re-map the control register (banks). Take every control that cites 357, 361 or 363 and point it at the matching Directive 364 chapter and section. Flag gaps, especially chapter M third party requirements and the section 61.4 patch testing procedure.
3. Join the systems list to the privacy databases. List your personal data databases, record each one's security level under the Data Security Regulations, and attach each one to the applications and suppliers that hold it.
4. Generate an SBOM for every product and internal application you build. Use SPDX or CycloneDX. Include transitive dependencies and container base images. Store each SBOM with the date, the commit and the information asset it describes.
5. Ask your highest-risk suppliers for theirs. Start with suppliers that manage sensitive information assets or databases at the high security level.
6. List your AI use. Models, AI services, coding assistants and agents, with the data each touches and its owner.

Days 31 to 60: set rules and remediation cadence

7. Agree a severity and timeline table. One page, approved by the cyber defence officer and risk management, saying what blocks a release, what can wait and how long. An illustrative starting point is below.
8. Put the table into the pipeline. A gate that fails on what you agreed to block and warns on the rest, with exceptions that expire.
9. Write the patch testing procedure. Who tests, in which separate environment, what evidence is kept, and the emergency route for a critical patch.
10. Control what comes in. Restrict package sources to approved registries or a proxy, and check integrity at install and build time.
11. Prepare the supplier clause set. Use the checklist below, and load it into every contract that renews from now on.

This table is an illustrative scenario with round numbers. None of the Israeli texts above sets these timelines; set yours with your risk owner and your supervisor's expectations in mind.

Supplier clause and evidence checklist (use the same day):

• SBOM in SPDX or CycloneDX for each delivered product and each major release
• Vulnerability handling commitment: how the supplier learns of, assesses and fixes vulnerabilities, and how fast it tells you
• Security incident notice: what counts, how fast, to whom
• Your right to test or receive independent assurance on controls over your information assets (Directive 364 sections 102 and 140 for banks)
• Remote access rules and logging for any access to your systems
• Location of processing and of any personal data, and the transfer basis
• Subcontractors who touch your data or code
• AI use: which AI services process your data, and whether your data trains any model

Days 61 to 90: prove it and keep it current

12. Run a tabletop on a supply chain incident. Use one of the public cases above. Time how long it takes to answer "where do we run it, and which databases and suppliers are affected?"
13. Build the evidence register. One row per requirement, one column per regime, so a single evidence item (a dated SBOM, a gate result, a patch test record) can serve ICDM, Directive 364 and the Data Security Regulations at once.
14. Test your incident reporting path. Walk a mock serious security incident through classification and the reports you would send to Banking Supervision, the Capital Market Authority or the Privacy Protection Authority. Record who decides and how long each step takes.
15. Report to the board. Inventory coverage, critical findings past their timeline, supplier coverage against renewals, patch testing compliance and AI inventory status.

Evidence register template:

How Safeguard does this

Safeguard is a software supply chain security platform. Everything below is GA and is described from Safeguard's offering documentation and docs.safeguard.sh. It helps a team produce and keep the evidence that ICDM, Directive 364, the Capital Market Authority circulars and the Data Security Regulations ask for. It does not make an organisation compliant, and switching on a framework in Safeguard certifies nothing.

1. Decide where Safeguard runs. For Israeli banks and insurers this question often comes first. Safeguard's SaaS runs in multiple regions (US, EU and Gov); there is no Israeli SaaS region. Where Directive 362 on cloud computing or your own policy rules out an outside service, the GA answers are a private VPC or dedicated tenancy, a full on-prem installation in your own data centre, or a fully air-gapped deployment that includes Safeguard's own AI models, updated through signed offline bundles. Per the offering, the platform holds no open connections, and customer code, SBOMs and telemetry are not used to train shared models.

2. Keep source code on your own machines with the local runner (GA). The runner ships with the Safeguard CLI (GA). Per the docs, it polls the platform for scan jobs assigned to that machine, runs each one locally and uploads only the resulting SBOM and findings, never the source code. All traffic is outbound HTTPS. Install and first run, as the docs show them:

   # macOS and Linux
   curl -fsSL https://cli.safeguard.sh/install | bash
   # then open the interactive terminal and type /login
   safeguard
   # or run headless for a workspace
   safeguard runner start --workspace ./path/to/repo
   safeguard runner status
   

   We did not run these commands for this post; the docs point to the CLI installation page for version pinning and checksums.

3. Choose how much AI is in the loop. Zero AI mode (GA) runs the whole platform deterministically with no LLM. Bring your own model (GA) uses a model already on your approved list, and local models (GA) run Safeguard's models inside your environment. That gives a privacy protection officer a configuration to point to when asked how AI touches code and data.

4. Generate the inventory. SBOM generation and analysis (GA) produces SPDX and CycloneDX inventories. Software composition analysis (GA) covers the full transitive dependency tree and container layers. Vulnerability management (GA) enriches findings with EPSS and CISA KEV. Reachability analysis (GA) ranks findings on code paths your application actually calls, so patch testing effort goes to the ones that matter first.

5. Use the Israel INCD framework. In the Compliance and GRC suite (GA), the Israel INCD page says the framework is on in your workspace unless you switch it off in Compliance, then Manage, then the Frameworks tab. Per the docs, each product scan checks five things: a software asset inventory, version and patch tracking, that the supplier of each component is known, integrity hashes for components, and that components can be matched against vulnerability databases by package URL or CPE. The remaining controls are evidenced with automated tests, uploaded evidence, policies or an attestation. The control labels on that page are Safeguard's own, not the INCD's numbering, and per the docs a readiness score "is not an audit opinion or a certification".

6. Start policies from templates. The INCD framework includes policy templates written for it: an organisational cyber defence policy, an ICT supply chain cyber security policy and a cyber awareness, training and recovery policy, plus adapted templates from Safeguard's standard set.

7. Enforce the gate in CI. Policies and gates (GA) turn your decision table into rules. Each policy's action is Block (the gate fails), Warn (the gate passes with a warning naming the policy) or Notify (the gate passes and a notification is sent); approvals for legitimate cases run through exceptions. The docs show this CI command; we did not run it:

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

8. Stop bad packages at install time. Package Firewall (GA) is an install-time proxy for npm and pip that blocks malicious, typosquatted and dependency-confusion packages before they reach a build. License compliance (GA) evaluates component licenses against your policy.

9. Collect supplier inventories. Third-Party Risk Manager (GA) handles the chapter M ask. Per the docs, you navigate to the vendor, click Request SBOM, select products, choose a request template, set a deadline and send; bulk requests go out from the Vendors list. Requests are tracked by status, and vendor risk is scored and monitored over time.

10. Inventory AI. AI-BOM discovery (GA) builds a continuously updated inventory of AI assets across code, cloud and connected SaaS; in code, for example, it picks up AI SDK imports and model weight files. That is the starting point for the privacy officer's AI register.

11. Fix with approval. Autonomous remediation (GA) can open tested fix pull requests, single or in bulk, through Safeguard's Griffin models. It ships switched off, with every category set to Manual, so each change goes through your patch testing procedure and change management before it reaches production.

What Safeguard does not do

• It does not make you compliant or certified. Safeguard is not certified, approved or assessed under any Israeli regime, including ICDM. Its own posture is SOC 2 Type II audit in progress and designed for FedRAMP High. It helps you produce and keep evidence; Banking Supervision, the Capital Market Authority, the Privacy Protection Authority and your auditors decide.
• It does not host data in Israel as SaaS. The SaaS regions are US, EU and Gov. If your rules need processing inside Israel or inside your own perimeter, use private VPC, on-prem, air-gapped or the local runner, and confirm the setup with your own supervisor where approval is needed.
• It does not file your notifications. Reports to Banking Supervision, the Capital Market Authority or the Privacy Protection Authority are yours to classify, approve and send. Safeguard helps you find affected systems faster.
• Its control labels are its own. The control catalogue on Safeguard's framework pages uses Safeguard's identifiers, which do not match the INCD's ICDM numbering or Directive 364's sections. Keep your register keyed to the regulator's numbers.
• It does not test your patches for you. Directive 364 expects patches examined in a separate environment. Safeguard can open the pull request and run your gate; your test environment, your test results and your change approval stay yours.
• It does not replace contract work, legal review or a privacy protection officer. Clause drafting, legal basis decisions for AI under the privacy law and supplier negotiations stay with your people.
• It does not fix code you do not build. A vulnerability inside a supplier's hosted service or a device's firmware still needs that supplier's fix.

Common mistakes

• Mapping to cancelled directives. Since May 2026, Directives 357, 361 and 363 are cancelled for banks. A control register, policy or supplier questionnaire still built on them is out of date, even if most of the substance carried over.
• Treating ICDM as optional because it is not a statute. Government offices must use it, and customers and sector regulators write it into contracts and guidance.
• Inventorying servers and not components. Directive 364 starts from identifying information assets. A server list cannot answer "where do we run XZ Utils 5.6.1?"
• Patching straight into production. For banks, the expectation is patch examination in a separate environment, with an emergency route that is documented, not improvised.
• Starting supplier evidence at the last renewal. The Directive 364 transition runs on renewal dates. Load the clause set now so every renewal counts.
• Leaving AI out of the inventory. Privacy and sector rules still apply to AI systems that use personal data or count as information assets; you cannot assess models and services nobody has listed.

FAQ

Is the INCD Cyber Defense Methodology mandatory?

For government offices, yes: the government adopted ICDM in 2021 as its required methodology. For most private organisations it is guidance that becomes binding when a regulator adopts it or a contract cites it.

Does Israel require an SBOM?

No Israeli text we reviewed requires an SBOM by name. ICDM asset management, Directive 364's identification of information assets and the Data Security Regulations all ask for an inventory that, for software, is hard to produce without component-level data. An SBOM is the practical way to meet them.

What replaced Bank of Israel Directive 361?

Directive 364, Management of IT, Information Security and Cyber Defense Risks, published on 18 November 2024. On its commencement 18 months later, in May 2026, it cancelled Directives 357, 361 and 363. Pre-publication contracts must be adapted at renewal and no later than three and a half years after commencement.

What changed on 14 August 2025?

Amendment 13 to the Privacy Protection Law entered into force. It strengthened the Privacy Protection Authority's enforcement and changed several duties, including who must appoint a privacy protection officer. Read the amended law and the Authority's guidance for the detail.

Does Israel have an AI law?

No. Israel's December 2023 policy on AI regulation and ethics favours sector regulators, existing law and soft tools. The Privacy Protection Authority has published draft guidance on applying privacy law to AI systems; we could not confirm its current status.

When did the Israeli Data Security Regulations take effect?

In May 2018, according to the State Comptroller's 2019 report, about a year after the Knesset committee approved them in March 2017. They set three security levels, basic, intermediate and high, and the level decides how much of the regulations applies to each database.

Can Safeguard run inside Israel?

Safeguard has no Israeli SaaS region; its SaaS regions are US, EU and Gov. It can run in your own private VPC or dedicated tenancy, fully on-prem or fully air-gapped with its AI models inside your environment, or as a local runner that keeps source code on your machine and sends back only results. Zero AI mode runs the platform with no LLM.

Is Safeguard INCD certified or approved?

No. Safeguard is not certified, approved or assessed under ICDM or any other Israeli regime. It helps teams produce and keep the evidence those regimes ask for. Its own posture is SOC 2 Type II audit in progress and designed for FedRAMP High.

Every regime in this guide expects vulnerabilities in the software you run to be found, tracked and closed on a cadence you can show a supervisor, and Directive 364 adds that patches are examined before they are installed. The section below covers how Safeguard helps close the gap between a published fix, or no fix at all, and the build you actually ship.

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 first demo shows the local runner: you set it up on your own machine, approve it with its device code, then scan from the terminal. For an Israeli bank or insurer whose repositories cannot be connected to an outside cloud service, this is the route where only the SBOM and findings leave the machine.

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

The second demo is a real CLI session: asked to fix the 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 approval at each change, and the test run before anything ships, is the habit Directive 364's patch testing expectation describes.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. For a GRC lead re-mapping a register to Directive 364, that means asking an assistant for the critical findings on a system while keeping its access limited to the tools you allow.

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

Quick check

Related reading

• Saudi Arabia software supply chain and AI security rules: 90-day plan
• India software supply chain and AI security rules: 90-day plan
• Japan software supply chain and AI security rules: 90-day plan

Sources

• Bank of Israel, Circular C-06-2799, Management of IT, Information Security, and Cyber Defense Risks (Directive 364), 18 November 2024, English
• Bank of Israel, Circular 2457-06-H, Cyber Defense Management (Directive 361), 16 March 2015, English
• NIST, Cybersecurity Framework success story: Israel National Cyber Directorate, version 2.0
• NIST, Israeli National Cyber Directorate success story, PDF
• CISA and partners including the INCD, AA23-335A, IRGC-affiliated cyber actors exploit PLCs in multiple sectors
• CISA, Reported supply chain compromise affecting XZ Utils, CVE-2024-3094
• CISA, Widespread supply chain compromise impacting npm ecosystem
• US International Trade Administration, Israel ICT policy on artificial intelligence regulation and ethics
• State Comptroller of Israel, Annual Report 69b (2019), privacy protection and information security at the Ministry of Agriculture, in Hebrew
• law.co.il, Israeli Ministry of Finance issues circular on cyber risk management at institutional entities
• Barnea Jaffa Lande, New Israeli directives on cyber risk management for regulated financial service providers
• Safeguard docs, Israel INCD
• Safeguard docs, Compliance frameworks
• Safeguard docs, Local Runner
• Safeguard docs, Policies and Gates
• Safeguard docs, TPRM SBOM Requests
• Safeguard docs, Package Firewall
• Safeguard docs, AI-BOM Discovery
• 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.