Software Supply Chain Security for Agriculture and Food: A 90-Day Plan

Software supply chain security in agriculture and food means knowing which software components run across your farms, plants, warehouses and ordering systems, who supplied each one, which carry known vulnerabilities, and how you will fix or contain them without missing a harvest window or a delivery slot. For the software you build (traceability services, farm management apps, grower portals, plant integration code) you produce SBOMs and fix dependencies yourself. For the software you buy (precision ag equipment, food processing controls, ERP, warehouse and EDI systems) you require SBOMs, advisories and patch commitments from vendors and track them against your own inventory.

No single US rule covers this for the sector. FDA's Food Traceability Rule makes the systems that hold traceability records part of food safety compliance, federal advisories describe the threat, SEC rules apply to listed companies, and EU rules reach exporters and equipment makers. This guide covers the software, the rules, recent incidents, who owns what, and a 30/60/90-day plan that works with the tools you have.

Key takeaways

• The sector runs three layers of software: farm and field (precision ag equipment, telematics, farm management, grain and livestock controls), plant and warehouse (PLCs, HMIs, SCADA, MES, cold chain, WMS) and business (ERP, traceability, EDI and ordering). Open source runs through all three.
• FDA's Food Traceability Rule requires covered firms to provide records within 24 hours of a request. FDA will not enforce it before 20 July 2028, after Congress directed the delay.
• CISA lists Food and Agriculture as a critical infrastructure sector. FBI, FDA and USDA advisories describe ransomware timed to harvest and email fraud used to steal food shipments.
• Listed companies file Form 8-K Item 1.05 within four business days of deciding an incident is material. Recent filings and notices from a distributor, a bakery chain, a grocer and a brewer show incidents stopping ordering and shipping.
• In the EU, NIS2 covers food as an "other critical sector", Cyber Resilience Act reporting has applied since 11 September 2026, and the Machinery Regulation applies from 20 January 2027.
• Safeguard capabilities in this guide, all GA: SBOM generation and analysis, software composition analysis and vulnerability management with EPSS and KEV, Third-Party Risk Manager (TPRM), CSAF and VEX upload, the compliance and GRC suite with NIS2 mappings, policies and gates (Block, Warn, Notify), the CLI and local runner, air-gapped and on-prem deployment with Zero AI mode, and autonomous remediation with Griffin fix pull requests (ships switched off, every category set to Manual).

The situation

In this sector the trigger is rarely a regulator. It is a retailer's supplier questionnaire, an EU distributor asking whether your connected implement meets the Cyber Resilience Act, or a co-op board that has read about a distributor whose ordering systems went dark and wants to know whether harvest could survive the same thing. Or it is a quality lead preparing for FSMA 204 who realizes the traceability system that must answer FDA within 24 hours is a SaaS product nobody in security has reviewed.

A bad week looks like this. A critical vulnerability lands on Monday in a widely used library. Corporate IT patches servers by Tuesday. Nobody can say whether the same library sits in the yield monitoring gateway, the pasteurizer HMI, the cold storage monitors or the traceability platform, because the asset list records model numbers, not components. Vendors answer at different speeds, and it is harvest, so nobody will approve a change to the elevator controls. By Friday the CISO is still reporting "under investigation". This guide is about making that week shorter.

What software agriculture and food actually runs

Before any rule or tool, map the software. The sector is broad, from a family row crop farm to a multinational protein processor, but the same three layers appear almost everywhere.

Farm and field systems

• Precision agriculture equipment. Tractors, combines, sprayers and planters carry controllers, displays, guidance and section control software, often on embedded Linux with open source libraries underneath.
• Telematics and connected machinery platforms. Cellular modems send machine data and diagnostics to manufacturer clouds, viewed through web and mobile apps; remote diagnostics and software updates come back down the same path.
• Farm management information systems. Field mapping, prescriptions, input planning and records, usually SaaS with mobile clients.
• Livestock, grain and irrigation controls. Robotic milking and feeding, barn climate control, elevator and bin monitoring, dryer and feed mill batching, pivot and pump controllers, and the PLCs and HMIs behind them.

Plant, warehouse and cold chain systems

• Food processing OT. PLCs, HMIs, SCADA, batch and clean-in-place control, pasteurization and thermal process controls, packaging, inspection and labeling. The FBI notes that disrupting a protein or dairy plant can spoil product and push effects back to the farm.
• Execution, quality and cold chain. MES, recipe management, lab systems, historians, WMS, temperature monitoring and the gateways that carry sensor data to the cloud.

Business and trading systems

• ERP and traceability, including commodity contracts, grower settlements and the Key Data Elements FDA can request.
• EDI, electronic ordering and invoicing, linking growers, processors, distributors and retailers. Several incidents below turned on these systems.
• E-commerce and online ordering in grocery retail and food service.
• In-house software: grower portals, plant to ERP integrations, agronomy data platforms and field staff apps.

Where open source and third-party code sits

The split in the last column drives the whole plan. For code you build, you can see and change every dependency. For code you buy, you can only see what the vendor discloses, so the work becomes asking for SBOMs and advisories, judging them, and deciding what to do while you wait.

The regulations and frameworks that apply

This section summarizes the rules from their primary sources. It is not legal advice; check how each one applies to your company with your own counsel.

FDA Food Traceability Rule (FSMA section 204)

FDA's Food Traceability Rule, at 21 CFR Part 1 Subpart S, applies to persons who manufacture, process, pack or hold foods on the Food Traceability List. They must keep records of Key Data Elements tied to Critical Tracking Events and provide information to FDA within 24 hours of a request, or within a reasonable time FDA agrees to. Unless exempt, firms must also provide an electronic sortable spreadsheet with the relevant traceability information within 24 hours. Electronic records may include working electronic links to the required information.

The date has moved. FDA's page states that the original compliance date was 20 January 2026, that FDA proposed a 30 month extension to 20 July 2028, and that the Continuing Appropriations, Agriculture, Legislative Branch, Military Construction and Veterans Affairs, and Extensions Act of 2026 then directed FDA not to enforce the rule before that same date. FDA says it intends to comply.

The rule says nothing about cybersecurity, and it does not ask for SBOMs. Its effect on software risk is indirect: the traceability system, its integrations and its SaaS host now sit on the path to a 24 hour regulatory answer. If ransomware takes them down during an outbreak investigation, the compliance problem and the security problem become one. That is a judgment, not a rule, but it is why traceability platforms belong in the vendor tier you review first.

CISA, FBI, FDA and USDA guidance for the sector

CISA lists Food and Agriculture as one of the critical infrastructure sectors and names the U.S. Department of Agriculture and the Food and Drug Administration among the sector's partners. The sector page links a Food and Agriculture cybersecurity checklist and working group resources, and it points to a joint FBI, FDA and USDA advisory on business email compromise.

That advisory, AA22-340A of 15 December 2022, was co-authored by the FBI, the FDA Office of Criminal Investigations and USDA. It describes criminals spoofing legitimate companies' emails and domains to order food products and ingredients that the victim ships and is never paid for, in thefts valued at hundreds of thousands of dollars.

The FBI's Private Industry Notification of 20 April 2022, coordinated with CISA and USDA, warned that ransomware actors may target agricultural cooperatives during planting and harvest, recording attacks on six grain cooperatives between 15 September and 6 October 2021. Among initial intrusion vectors it lists known but unpatched vulnerabilities and compromise of shared network resources or managed services, which are supply chain entry points. Both documents are older than the incident window below and serve here as sector context.

CISA 2026 Minimum Elements for an SBOM (29 July 2026)

CISA, NSA, FBI and international partners published the 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026, replacing the 2021 NTIA minimum elements. It is guidance, not a rule for private companies, but it gives procurement a neutral, citable definition of a complete SBOM for equipment, MES and SaaS contracts.

SEC cybersecurity disclosure rules

The SEC's 2023 rules require listed companies to disclose material cybersecurity incidents under Item 1.05 of Form 8-K, describing the nature, scope and timing of the incident and its material or reasonably likely material impact. The filing is generally due four business days after the company determines the incident is material. Annual reports must describe cybersecurity risk management, strategy and governance. Food processors, ingredient makers, distributors, grocers and equipment makers that are listed in the US are covered. Several filings below show what these disclosures look like in this sector.

EU rules, as context for exporters, EU plants and equipment makers

US rules lead this guide, but many food and ag companies sell into or operate in the EU.

• NIS2 (Directive (EU) 2022/2555). The Commission's NIS2 FAQ lists food among the "other critical sectors". Covered entities must address supply chain security and send an early warning of a significant incident within 24 hours, a notification within 72 hours and a final report within one month. The transposition deadline was 17 October 2024; scope depends on national law and company size.
• Cyber Resilience Act. In force since 10 December 2024, with reporting of actively exploited vulnerabilities from 11 September 2026 and main obligations from 11 December 2027. It covers products with digital elements sold in the EU, which can include connected farm equipment, sensors and gateways.
• Machinery Regulation (EU) 2023/1230. Adopted on 14 June 2023, it adds cyber safety provisions for compliance-relevant software, data and safety control systems. Machinery placed on the EU market before 20 January 2027 still follows the Machinery Directive. Check your product's scope with your notified body or counsel.

What each source asks for, side by side

Real public incidents from the last three years

The incidents below come from official advisories, company filings and company notices. We describe only what those sources say and draw no conclusions about what any company should have done. None of the company sources below names the exact entry point except Asahi's.

December 2023: controllers used in food and beverage plants defaced

CISA, FBI, NSA, EPA and Israeli partners published advisory AA23-335A in December 2023, last revised 18 December 2024. It describes actors affiliated with Iran's Islamic Revolutionary Guard Corps compromising Unitronics Vision Series PLCs and HMIs and leaving a defacement image. The victims spanned multiple US states and other countries. CISA notes that these PLCs are commonly used in water and wastewater and in other industries, including food and beverage manufacturing. For this guide the lesson is narrow: a component made by one supplier shows up across sectors, and an asset owner needs to know where it sits.

29 March 2024: the XZ Utils backdoor (CVE-2024-3094)

On 29 March 2024, CISA published an alert about malicious code in XZ Utils versions 5.6.0 and 5.6.1, a data compression library that may be present in Linux distributions, and recommended downgrading to an uncompromised version. For food and agriculture the question was which Linux based displays, gateways, HMIs and servers carried it. Teams with SBOMs could answer quickly; teams without them had to ask every vendor.

November 2024: a grocery group's US network

Ahold Delhaize reported on 8 November 2024 that its US business had detected a cybersecurity issue within its US network. In an update of 17 April 2025, it said stores, business operations and e-commerce services had been restored shortly afterward, and that it believed certain files were taken from some internal US business systems.

29 November 2024: a bakery chain's online ordering

Krispy Kreme filed a Form 8-K under Item 1.05 on 11 December 2024. It said it was notified on 29 November 2024 of unauthorized activity on a portion of its IT systems. Shops stayed open and took orders in person, but online ordering was disrupted in parts of the US, while daily deliveries to retail and restaurant partners were uninterrupted. The company said the incident had had, and was reasonably likely to have, a material impact on operations until recovery was complete.

5 June 2025: a food distributor's ordering and distribution

United Natural Foods, a US grocery wholesaler, filed a Form 8-K on 9 June 2025 saying it became aware of unauthorized activity on certain IT systems on 5 June and took some systems offline, which temporarily affected its ability to fulfill and distribute customer orders. In a later Item 1.05 filing in late June 2025, it said the activity was contained and that it had restored the core systems customers and suppliers use for electronic ordering and invoicing.

29 September 2025: a brewer's ordering, shipping and production

Asahi Group Holdings announced on 29 September 2025 a system failure caused by a cyberattack, affecting order and shipment operations and call centers at group companies in Japan. In its notice of 18 February 2026, the company reported that an attacker had entered through network equipment at a group site about ten days before the disruption, gained administrative privileges in the main data center and deployed ransomware on 29 September, encrypting several servers and some PCs. Ordering and shipping through its electronic ordering system resumed on 2 and 3 December 2025. Its recurrence measures included removing remote access VPN equipment and strengthening authentication.

23 September 2025: a self-replicating worm in the npm registry

On 23 September 2025, CISA reported that a self-replicating worm publicly known as "Shai-Hulud" had compromised over 500 packages in npm, the largest JavaScript registry. Any food or ag company that builds grower portals, ordering front ends or farm apps faced the same question: did any of our builds install an affected version?

What the sources show in common

Without speculating beyond the sources: ordering, invoicing, shipping and e-commerce systems are where outages showed up in this sector, and several companies kept serving customers through workarounds while those systems were restored. Shared components, from a PLC model used across industries to a compression library and npm packages, put many companies on the same clock at once.

The personas who own the problem

Software supply chain risk in food and agriculture does not belong to one person. Here is who owns each part, what they need, and when the need becomes urgent.

For the CISO, the board question after an incident in the news is "could that happen here, and how long would we be down?" Answer it with three numbers you can measure within 90 days: the share of Tier 1 suppliers that have delivered an SBOM, the time it took to answer the last widely reported vulnerability, and the count of known exploited vulnerabilities open past your deadline.

For the plant OT lead, nobody should ask you to patch a pasteurizer HMI mid run. You need to know which line carries which vendor product and version, what the vendor has said, and a written decision for each vulnerability: patch at the next shutdown, mitigate now, or accept with an expiry date.

For the GRC and food safety lead, FSMA 204 makes the traceability system a regulated dependency. Your evidence should show it is inventoried, that its vendor has a vulnerability process, and that you can produce the 24 hour spreadsheet if it is down.

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

This plan assumes a mid-sized food or ag company with a security team of a few people, several plants or sites and a mix of in-house and vendor software. Scale it down for a co-op and up for a multinational. Every step works with open source tools, spreadsheets and contracts; the next section shows how the same steps run in Safeguard.

Days 1 to 30: know what you have

1. List the systems that would stop operations. Per site, one page: grain receiving and scale software, line controls, cold storage monitoring, WMS, EDI and ordering, traceability.
2. Rank vendors into three tiers. Tier 1 is any vendor on that list or holding FSMA traceability records. Tier 2 touches plant or farm networks. Tier 3 is everything else.
3. Generate SBOMs for everything you build, with any CycloneDX or SPDX generator, and store each one with the release.
4. Request SBOMs from Tier 1 vendors with the template below.
5. Subscribe to the feeds that matter: CISA's Known Exploited Vulnerabilities catalog, CISA ICS advisories and each Tier 1 vendor's advisory page.
6. Set a baseline. Pick one recent widely reported vulnerability and time how long it takes to answer "where do we have it?" across all three layers.

Template: vendor SBOM request

Use this text in an email or a supplier portal. Edit the bracketed parts.

We are building an inventory of third-party software components in systems that support our food production and distribution. For each product and version we run, listed below, please provide: (1) a software bill of materials in CycloneDX or SPDX format that meets CISA's 2026 Minimum Elements for an SBOM; (2) the location where you publish security advisories, and whether you publish CSAF or VEX documents; (3) your process and target timeline for notifying customers of vulnerabilities that are known to be exploited; (4) the support end date for each version. Products: [list]. Please reply by [date, about four weeks out]. If you cannot provide an SBOM yet, tell us when you expect to.

Days 31 to 60: decide how you will act

1. Match SBOMs against vulnerability data, enriched with EPSS and the KEV catalog so known exploited vulnerabilities rise to the top.
2. Agree release rules for your own software: at minimum, no known exploited vulnerability and no critical vulnerability with an available fix. Decide who grants exceptions, for how long, and where they are recorded.
3. Write the patch decision table below with OT, food safety and operations, before the next advisory.
4. Plan for peak seasons. Mark planting, harvest and holiday peaks, move routine changes out of them and agree which vulnerabilities justify an emergency change.
5. Test the traceability fallback: could you produce FDA's sortable spreadsheet if the main system were down for a week?
6. Draft contract language on SBOMs, notification and support periods for upcoming renewals.

Decision table: patching in plants and on farms

Days 61 to 90: make it routine and show it working

1. Turn release rules into CI gates, with Block for known exploited vulnerabilities and Warn for the rest while teams catch up.
2. Score Tier 1 vendors on SBOM delivery and quality, open known exploited vulnerabilities and response speed, and feed the score into renewals.
3. Rerun the baseline on a new widely reported vulnerability and report the change.
4. Write the board summary: the three numbers, the top five supplier risks and next quarter's plan.
5. Prepare the disclosure path. Confirm who decides materiality for the 8-K clock and, in the EU, who sends the NIS2 early warning.

Checklist at day 90

• Every in-house application and container image produces an SBOM on each build.
• Tier 1 vendors have received an SBOM request; responses and gaps are tracked.
• Vendor and in-house SBOMs are checked daily against KEV and new vulnerabilities.
• A written patch decision table exists and has been used at least once.
• Peak season change windows are agreed.
• Release gates block known exploited vulnerabilities in your own software.
• A traceability fallback has been tested.
• The board has seen the three numbers.

What if an equipment vendor has never produced an SBOM?

Ask in writing, ask for a date, and raise it again at renewal with contract language. Meanwhile, take what they can give: a list of major third-party components and versions, their advisory page and support end dates. A partial list still helps you answer the XZ question. Score thin first SBOMs and track improvement rather than rejecting the vendor.

How Safeguard does this

This section shows how the same plan runs in Safeguard, using only flows from Safeguard's documentation. Commands are shown as the docs show them; we did not run them for this post.

1. Generate SBOMs for the software you build. SBOM generation and analysis (GA) and software composition analysis with deep transitive dependency scanning (GA) cover grower portals, ordering front ends, farm management apps, telematics backends and edge containers. The Safeguard CLI (GA) signs in with an OAuth device code flow; on a machine without a browser, --no-browser prints a URL and a code to enter elsewhere:

   safeguard login --no-browser
   safeguard scan --dir .
   safeguard scan --image myregistry.example.com/cold-chain-gateway:3.1
   

   The image name is illustrative. Results are written under ./output by default. The docs note that safeguard scan does not fail on findings: it exits 0 when the scan ran, whatever it found, 1 when the command itself failed, and 2 when results were written but the vulnerability scan did not run. Gating is done by policy gates in the platform.

2. Check and track vendor SBOMs. The CLI checks a vendor SBOM against its specification and scans it locally with safeguard validate sbom.json and safeguard scan --sbom sbom.json. To monitor it over time, go to Integrations, use the Upload SBOM card, enter a project name and version, and upload the file. Safeguard validates format, schema and required fields, enriches components with vulnerability matches, EPSS scores, CISA KEV status, license and supplier data, and keeps scanning daily for new vulnerabilities and KEV additions. Vulnerability management with EPSS and KEV is GA.

3. Request SBOMs from vendors. Third-Party Risk Manager (TPRM, GA) turns the request template into a tracked workflow: navigate to the vendor, click Request SBOM, select products, choose a template, set a deadline and send, or bulk request from the Vendors list. Custom templates under Settings, Request Templates can name CISA's 2026 minimum elements. Requests move from Sent through Submitted to Validated or Rejected, with reminders 7 days before and at the deadline and an escalation 7 days after. Submitted SBOMs are checked for format and completeness and scanned; Request Revision sends corrections back.

4. Score and monitor vendors. TPRM scores each vendor from 0 to 100 (higher means lower risk) from vulnerability risk including EPSS and known exploited vulnerabilities, SBOM quality and age, component health and response time. It alerts you, by email, Slack, Microsoft Teams, PagerDuty or webhook, when a new critical vulnerability or a KEV addition affects a vendor SBOM, a score drops below threshold or an SBOM goes stale. Re-assessment can run daily for critical vendors or on contract renewal. Accept Risk records a justification, a review date and approvals.

5. Ingest vendor advisories and VEX. CSAF and VEX upload (GA) takes CSAF 2.0 advisories and VEX in CycloneDX, OpenVEX and CSAF VEX formats, from the Upload CSAF/VEX card under Integrations. Vendor VEX lets you record that a vulnerability does not affect a product, which is the "vendor VEX states not affected" row of the decision table.

6. Map evidence to NIS2 where it applies. The compliance and GRC suite (GA) includes NIS2 and the Cyber Resilience Act. For NIS2, each product scan checks the SBOM for what Article 21(2)(d) supply chain security, 21(2)(e) vulnerability handling, 21(2)(a) risk analysis and Article 23 reporting readiness presuppose: known suppliers, identifiable components, an inventory and exact versions. These checks do not assess your whole NIS2 program.

7. Gate releases of in-house software. Policies, gates and guardrails (GA) enforce the release rules from days 31 to 60. Go to Settings, Policies, click Create Policy, define conditions with the visual builder or YAML (for example no critical CVEs, no actively exploited CVEs, no abandoned packages, approved licenses only), set severity and actions, then save and enable. 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). Exceptions carry a business justification and an expiration date and are submitted for approval. In CI, with policy outcomes on for your workspace, the docs show:

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

   Replace the placeholder with your gate's name; the job fails when the gate fails.

8. Scan where farm and plant networks allow only outbound traffic. The local runner (GA) is part of the CLI. Run safeguard, type /login, approve the session, and the machine starts polling the platform for scan jobs. All traffic is outbound HTTPS that the runner opens; nothing connects to it. It scans locally and uploads only the resulting SBOM and findings, never your source code. Where held connections are forbidden, the docs show safeguard runner start --workspace ./path/to/repo with --poll-wait 0 to poll at a fixed interval.

9. Run fully inside an isolated site. On-prem and air-gapped deployment (GA) runs Safeguard inside your perimeter, with signed snapshot bundles of vulnerability feed deltas, including CISA KEV and EPSS, arriving through a DMZ receiver by diode, signed media or scheduled sync. No component inside the perimeter calls outbound. Zero AI mode (GA) runs the platform with no language model in the loop. Safeguard's own posture: designed for FedRAMP High, with the SOC 2 Type II audit in progress.

10. Fix dependencies in software you build. Autonomous remediation (GA) uses Griffin to open tested, policy gated fix pull requests, single or in bulk. It ships switched off, with every category set to Manual. It applies to your portals, apps, integration services and edge containers, never to a vendor's firmware or controller.

The plan, mapped

What Safeguard does not do

• It does not read or change PLC logic, equipment controller settings or recipes. It works on SBOMs, dependencies, container images and vendor documents. Monitoring controller logic and configuration is a different class of OT tool.
• It does not patch vendor firmware, equipment displays or appliances. Those fixes come from the equipment maker or vendor, through your change process and shutdown windows.
• It does not discover devices on plant or farm networks. The device inventory comes from your OT asset and network tools and your equipment records; Safeguard holds the software component side.
• It cannot make a vendor produce a good SBOM. TPRM tracks, validates and reminds; a missing or thin SBOM is a contract matter.
• It does not make you FSMA 204 compliant. Traceability records, Key Data Elements and the 24 hour spreadsheet are the job of your traceability system and food safety team.
• It does not decide your risk. Deferring a patch on a food safety control during harvest stays with your OT lead, food safety lead and CISO.
• It does not file disclosures. SEC filings, NIS2 notifications and CRA reports are prepared and submitted by your company.

Common mistakes

• Treating farms and plants as out of scope. The open source in a telematics gateway or HMI is the same open source in your servers; leave it out and the "where do we have it?" answer stays partial.
• Asking for SBOMs without saying what good looks like. Name CISA's 2026 minimum elements and a format.
• Rejecting vendors for weak first SBOMs. Score and track improvement instead.
• Forgetting the traceability vendor. FSMA 204 puts it on the path to a 24 hour answer.
• Patching in peak season without a plan. Agree the decision table and change windows before planting, harvest and holiday peaks.
• Ignoring ordering and EDI systems. In the public incidents above, that is where customers felt the outage.
• Gating everything at once. Start with Block on known exploited vulnerabilities and Warn on the rest.

FAQ

What is software supply chain security in agriculture and food?

It is the practice of knowing which third-party and open source components run in your farm equipment, plant controls, warehouse systems and business software, who supplied them, which have known vulnerabilities, and how you will fix or contain them. It covers both software you build and software you buy.

Does the FDA Food Traceability Rule require cybersecurity controls?

No. The rule at 21 CFR Part 1 Subpart S sets recordkeeping requirements and a 24 hour response to FDA requests. It does not mention cybersecurity. It does make the systems that hold traceability records part of compliance, which is why many teams review their traceability vendor first.

When does FSMA 204 compliance start?

FDA's page says the original date was 20 January 2026, and that after FDA proposed a 30 month extension, Congress directed FDA not to enforce the rule before 20 July 2028. FDA says it intends to comply with that direction.

Which US agencies cover cybersecurity for the food and agriculture sector?

CISA lists Food and Agriculture as a critical infrastructure sector with USDA and FDA among its partners, and the FBI, FDA's Office of Criminal Investigations and USDA have issued joint advisories. Listed companies also follow SEC disclosure rules.

Does NIS2 apply to food companies?

NIS2 lists food among the "other critical sectors". Whether a company is in scope depends on its activity, size and the Member State's law; check with counsel.

Does the EU Cyber Resilience Act apply to connected farm equipment?

The CRA covers products with digital elements placed on the EU market, which can include connected equipment, sensors and their software. Reporting of actively exploited vulnerabilities has applied since 11 September 2026 and the main obligations apply from 11 December 2027. Equipment makers should also check the Machinery Regulation, which applies to machinery placed on the market from 20 January 2027.

How do I scan software at a plant or co-op site with limited connectivity?

Use tools that work offline or with outbound only connections. In Safeguard, the local runner polls over outbound HTTPS and uploads only SBOMs and findings, and a fully air-gapped deployment takes signed offline updates.

Can Safeguard scan farm equipment or controller firmware directly?

Safeguard works with SBOMs, dependencies, container images and vendor advisories. For equipment and controller firmware, the practical path is the vendor's SBOM and advisories, tracked in TPRM, not direct analysis of the device.

Most of the risk in this guide lives in software you buy, where the vendor owns the fix. The part you can change today is the open source in the portals, apps, integrations and containers you build, and the block below covers how Safeguard closes that gap when upstream is slow.

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 sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. It is the pattern for a plant, elevator or co-op network that allows only outbound connections.

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

The second demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal with safeguard, and asks it to "fix the lodash CVE in this repo". The assistant 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. The same flow applies to the JavaScript dependencies in a grower portal or online ordering front end your team maintains.

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

The third demo is a real desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with the upgrade done and tests passing.

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

Quick check

Try it on your own software: download Safeguard at safeguard.sh/download, and read the docs at docs.safeguard.sh.

Related reading

• Earlier, shorter posts on this sector: AgTech and food-tech software supply chain risk in 2026, precision agriculture IoT security, SBOMs for agricultural machinery firmware, SBOMs for food processing machines and firmware and the JBS Foods ransomware attack as a supply chain lesson.
• Related in this series: 90-day plan for manufacturing and OT and 90-day plan for logistics and freight.

Sources

• FDA: FSMA Final Rule on Requirements for Additional Traceability Records for Certain Foods
• CISA: Food and Agriculture Sector
• CISA: Food and Agriculture Cybersecurity Checklist and Resources
• FBI, FDA OCI and USDA: AA22-340A, Criminal Actors Use Business Email Compromise to Steal Large Shipments of Food Products and Ingredients (PDF)
• FBI: PIN 20220420-001, Ransomware Attacks on Agricultural Cooperatives Potentially Timed to Critical Seasons (PDF)
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• SEC: SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure
• European Commission: NIS2 Directive
• European Commission: NIS2 Directive FAQs
• European Commission: Cyber Resilience Act
• European Commission: Machinery
• CISA: 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
• Ahold Delhaize: Update on the 8 November 2024 cybersecurity issue
• SEC: Krispy Kreme Form 8-K, 11 December 2024
• SEC: United Natural Foods Form 8-K, 9 June 2025
• SEC: United Natural Foods Form 8-K, Item 1.05, June 2025
• Asahi Group Holdings: Notice of System Failure Due to Cyberattack, 29 September 2025
• Asahi Group Holdings: Measures to Prevent Recurrence, 18 February 2026
• Safeguard Docs: TPRM SBOM Requests
• Safeguard Docs: TPRM Risk Assessment
• Safeguard Docs: TPRM Monitoring
• Safeguard Docs: Existing SBOM
• Safeguard Docs: CSAF/VEX Upload
• Safeguard Docs: NIS2
• Safeguard Docs: EU Cyber Resilience Act
• Safeguard Docs: Policies and Gates
• Safeguard Docs: CLI Usage
• Safeguard Docs: Local Runner
• Safeguard Docs: Air-Gapped Deployment

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