Airline and Aviation Software Supply Chain Security: TSA, FAA, EASA

Airlines, airports and avionics suppliers secure their software supply chain by knowing which components and vendor products sit inside every critical cyber system, patching them on a written risk-based schedule, and holding suppliers to the same rules through contracts and certification evidence. TSA's March 2023 emergency amendment already asks regulated airport and aircraft operators to patch operating systems, applications, drivers and firmware on critical cyber systems "in a timely manner using a risk-based methodology." A 90-day plan built around inventory, patch evidence and supplier flowdown gets most operators and suppliers to records they can show TSA, the FAA, EASA or a customer's auditor.

The plan below works with whatever tools you already have; Safeguard appears only in "How Safeguard does this". Nothing here is legal, regulatory or certification advice. Your security program, your certification basis and your regulator decide what applies to you.

Key takeaways

• TSA has already set the bar for operators. The March 2023 cybersecurity amendment to the security programs of certain TSA-regulated airport and aircraft operators asks for an approved implementation plan, network segmentation between IT and OT, access control, continuous monitoring and timely, risk-based patching of critical cyber systems.
• Earlier TSA measures still apply. TSA says regulated airport and aircraft operators were already required to report significant cybersecurity incidents to CISA, name a cybersecurity point of contact, adopt an incident response plan and complete a cybersecurity vulnerability assessment.
• The FAA wants cybersecurity in the type certificate. The FAA's August 2024 proposed rule would add 14 CFR 25.1319, 33.28(n) and 35.23(f), requiring applicants to identify, assess and mitigate risks from intentional unauthorized electronic interactions and to put the protections in the Instructions for Continued Airworthiness. As of 25 October 2026 the Federal Register shows no final rule under that title, and project-specific special conditions continue.
• EASA already has both halves. Aircraft cybersecurity has sat in EASA certification specifications since Decision 2020/006/R (CS-25 Amendment 25, July 2020), and the Part-IS regulations (EU) 2022/1645 and 2023/203 address the management of information security risks by organisations and authorities.
• Field loadable software and maintenance laptops are named attack paths. The FAA proposal lists them, along with gate link networks, USB devices, satellite communications and electronic flight bags.
• Recent incidents reached aviation through shared software and vendors, not through aircraft: a backdoor in an open source compression library, ransomware on a port authority that runs a major airport, and ransomware affecting a shared passenger processing product used at airports.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, SCA and deep transitive dependency scanning, vulnerability management with EPSS and KEV enrichment, reachability analysis, policies and gates (Block, Warn and Notify, with approvals through exceptions), autonomous remediation (ships switched off, every category set to Manual), license compliance, CSAF and VEX upload, the compliance and GRC suite with a DO-326A framework page, TPRM with SBOM requests, Trust Center, the Safeguard CLI and local runner, Zero AI mode, bring your own model, and on-prem and air-gapped deployment.

The situation

The trigger for most readers in aviation is one of four things. A TSA inspector asks to see how the implementation plan's patching measure is actually carried out on critical cyber systems. A certification engineer is asked, during a design change, to show the configuration of every software component in a connected system. A customer airline sends a supplier questionnaire that now asks for an SBOM. Or an incident lands somewhere else in the industry, and the board asks on Monday morning whether the same software runs in your check-in, crew scheduling or maintenance estate.

A bad week looks like this. An advisory names a library with a critical flaw. Airport IT thinks it is in the baggage reconciliation system, but the vendor has not answered. The avionics team cannot say whether it is in the maintenance laptop software that loads software onto aircraft. Your TSA point of contact asks whether this is a significant incident to report to CISA. Each is a supply chain question you can answer from records built in 90 days.

What software airlines and aviation companies run

Aviation is not one software estate. It is several, with different owners, change rules and regulators. A useful inventory starts by naming them, because the rules for changing a library in a flight control computer are nothing like the rules for changing one in a mobile booking app.

Two features of this table drive the rest of the post. First, most of the software is bought, not built, and much of it is shared. A departure control system or common use check-in platform at a large airport serves many airlines at once. Second, the airborne side moves slowly on purpose. A certified configuration is a fixed list of exact software parts, and changing one is an engineering and airworthiness decision, not a pull request. Both make an exact component inventory more valuable: you cannot patch what you cannot find, or argue that a flaw does not touch a certified part without knowing what is in it.

The regulations and frameworks that apply

Aviation cybersecurity rules come from two directions. Security regulators (TSA in the United States) set requirements for the operators of airports and aircraft, which are mostly about ground systems and incident response. Airworthiness regulators (the FAA and EASA) set requirements for the design of aircraft, engines and propellers, which are about protecting aircraft systems from intentional unauthorized electronic interaction. Software supply chain work sits in both.

TSA cybersecurity amendment for airport and aircraft operators (March 2023)

On 7 March 2023 TSA announced a cybersecurity amendment, issued on an emergency basis, to the security programs of certain TSA-regulated airport and aircraft operators. TSA described it as following similar measures for passenger and freight railroad carriers announced in October 2022.

Per TSA's announcement, the amendment requires affected entities to develop an approved implementation plan that describes the measures they are taking to improve cybersecurity resilience and prevent disruption and degradation of their infrastructure, and to proactively assess how effective those measures are. TSA lists four measures:

1. Network segmentation. Policies and controls so that operational technology systems can keep operating safely if an information technology system is compromised, and the reverse.
2. Access control. Measures to secure critical cyber systems and prevent unauthorized access.
3. Continuous monitoring and detection. Policies and procedures to defend against, detect and respond to threats and anomalies affecting critical cyber system operations.
4. Patching. Reducing the risk of exploiting unpatched systems by applying security patches and updates for operating systems, applications, drivers and firmware on critical cyber systems in a timely manner, using a risk-based methodology.

The same announcement notes earlier requirements for TSA-regulated airport and aircraft operators: reporting significant cybersecurity incidents to CISA, establishing a cybersecurity point of contact, developing and adopting a cybersecurity incident response plan, and completing a cybersecurity vulnerability assessment.

Two practical points follow. First, this post relies on TSA's public announcement; regulated entities work from the amendment text in their own security program, which is the document that governs. Second, the patching measure is a software supply chain requirement in all but name. You cannot patch operating systems, applications, drivers and firmware on a schedule without a current inventory of what runs on each critical cyber system, which versions, and who supplies the fix.

FAA proposed rule: Equipment, Systems, and Network Information Security Protection (August 2024)

On 21 August 2024 the FAA published a notice of proposed rulemaking (Docket FAA-2024-1398, Notice No. 24-23) titled "Equipment, Systems, and Network Information Security Protection." Comments were due by 21 October 2024.

What it would do, per the proposal:

• Add new requirements at 14 CFR 25.1319 (transport category airplanes), 33.28(n) (engines) and 35.23(f) (propellers), and revise their appendices, to protect equipment, systems and networks against intentional unauthorized electronic interactions (IUEI) that could create safety hazards.
• Require design approval applicants to identify and assess the security risks posed by IUEI, through a security risk analysis covering threat conditions associated with the system, architecture and external or internal interfaces, and to mitigate those risks as necessary for safety, functionality and continued airworthiness.
• Require applicants to include the procedures needed to maintain those protections in the Instructions for Continued Airworthiness (ICA), which is how the rule would reach future operators.
• Consider equipment, systems and networks "separately and in relation to other systems," because threats can propagate from one system to another.

The proposal says its substance generally reflects the special conditions the FAA has used since 2009 to address product cybersecurity, beginning with the Boeing 787 program, and that the intent is to reduce certification cost and time and harmonize with other authorities. It notes that industry wanted to use RTCA's DO-326, DO-355 and DO-356 as a means of compliance, and that the FAA developed a proposed Advisory Circular, AC 20-XXX, "Aircraft Systems Information Security/Protection (ASISP)," as guidance.

The proposal also lists the sources of vulnerability that connected designs can introduce. For a supply chain reader the list is worth quoting in summary: field loadable software, maintenance laptops, airport or airline gate link networks, public networks, wireless aircraft sensors, cellular networks, USB devices, satellite communications, portable electronic devices and electronic flight bags, and GPS and satellite-based augmentation data. Several of those are software that the airline, not the manufacturer, installs and updates.

Status. As of 25 October 2026, a Federal Register search shows the proposed rule and no final rule under that title. The FAA was still publishing project-specific special conditions for electronic system security protection in 2026, for example on 7 August 2026 for a regional turboprop design. Treat the proposal as the direction of travel and the special conditions as the current requirement for design projects.

RTCA DO-326, DO-355 and DO-356

The FAA proposal says that after RTCA published its guidance (DO-326, DO-355 and DO-356), industry wanted to use those documents as a means of compliance with cybersecurity special conditions. They are paid standards, so this post does not quote their clauses or summarize their contents beyond that. What matters for the supply chain is the shape of the work the FAA proposal describes: identify and assess risks across the system, its architecture and its interfaces, mitigate them, and keep the protections working in service through the ICA. Each of those steps needs an exact list of the software in scope.

EASA: certification specifications and Part-IS

EASA moved first on both halves of the problem.

• Aircraft cybersecurity in certification specifications. According to the FAA proposal, EASA released NPA 2019-01, "Aircraft Cybersecurity," on 22 February 2019, and Decision 2020/006/R finalized amendments on 1 July 2020, issuing CS-25 Amendment 25, CS-E Amendment 6 and CS-P Amendment 2, along with amendments for other product types. Those amendments brought the provisions of EASA's earlier special conditions into the specifications.
• Part-IS for organisations and authorities. EASA's cybersecurity domain page lists Regulations (EU) 2022/1645 and 2023/203, known together as Part-IS, with acceptable means of compliance and guidance material (AMC and GM) for the organisation requirements (Part-IS.I.OR and Part-IS.D.OR) and the authority requirements (Part-IS.AR). EASA's rulemaking work behind that guidance is titled "Management of information security risks." Read the regulations and AMC on EASA's site for who is in scope and from when; this post does not restate them.

US operators with European operations, and suppliers to European manufacturers and airlines, should expect Part-IS questions in contracts. For a deeper look at what Part-IS means for supplier software, see the related reading at the end.

NIST SP 800-161 Revision 1 and SP 800-218 (SSDF)

Neither is an aviation rule, but both are the vocabulary US buyers and auditors use. SP 800-161 Revision 1 covers cybersecurity supply chain risk management practices for systems and organizations. SP 800-218, the Secure Software Development Framework, describes secure development practices and is a natural reference for questions to ground software vendors.

CISA 2026 Minimum Elements for an SBOM

CISA released updated Minimum Elements for a Software Bill of Materials in July 2026, replacing the 2021 NTIA minimum elements. When you ask a supplier for an SBOM, name this document and a format (SPDX or CycloneDX) so you get something you can compare and load.

How the pieces fit

Real public incidents from the last three years

The incidents below come from official or primary sources. They are listed to show how software and vendors carry risk into aviation, not to judge the organisations involved. This post draws no conclusions beyond what the sources say.

A backdoor in a widely used open source library (March 2024)

On 29 March 2024 CISA reported a supply chain compromise affecting XZ Utils, a data compression library included in many Linux distributions, tracked as CVE-2024-3094. Malicious code had been inserted into versions 5.6.0 and 5.6.1. CISA recommended that developers and users downgrade to an uncompromised version and look for malicious activity.

Why it matters for aviation: Linux and its libraries run inside ground systems, kiosks, servers, containers and many embedded platforms. The question on the day was simple and hard: which of our systems, and which of our vendors' products, contain those two versions? Teams with an SBOM per system answered in hours. Teams without one waited for vendor letters.

Ransomware at a port authority that runs a major airport (August 2024)

On 24 August 2024 the Port of Seattle, which operates Seattle-Tacoma International Airport (SEA), identified system outages consistent with a cyberattack and isolated critical systems. In a statement dated 13 September 2024, the Port said it was a ransomware attack by the criminal organization known as Rhysida, and that the attacker had encrypted access to some data. The Port said the encryption and its own response, which included disconnecting systems from the internet, hindered services including baggage, check-in kiosks, ticketing, Wi-Fi, passenger display boards, the Port website, the flySEA app and reserved parking. Most of those systems were back within the week. The Port refused to pay the ransom, and later notified individuals whose personal information, mostly about employees and contractors, was taken.

Why it matters: airport operations depend on systems that the airport operator, not any one airline, runs. Baggage, display boards, check-in kiosks and websites were hit together, and some of the disruption came from the containment steps themselves. Knowing which systems depend on which others is part of recovering safely.

Ransomware affecting a shared passenger processing product (September 2025)

In a Form 8-K filed in September 2025, RTX reported that on 19 September 2025 it became aware of a product cybersecurity incident involving ransomware affecting its MUSE (Multi-User System Environment) passenger processing software, which lets multiple airlines share check-in and gate resources, including baggage handling. RTX said the MUSE airport systems operate outside the RTX enterprise network, that customers moved to backup or manual processes, and that some flight delays and cancellations followed. It said the incident had not had, and was not reasonably expected to have, a material impact on the company.

Why it matters: this is the shared software problem in one event. A product built so that many airlines share the same check-in and gate resources meant that, when it was affected, every airline using it at those airports fell back to backup or manual processes together. For each airline, the affected software was a vendor product it did not build.

For a fuller account of the airport disruption and the port ransomware, see the incident posts in the related reading list.

The personas who own the problem

Software supply chain security in aviation has no single owner. The table maps the roles that do own a piece of it, what they need, and the moment it becomes urgent.

Three roles with the hardest clock

The CISO wants one sentence for the board after any incident: which of our systems contain the affected component or vendor product, what we have done, and when the rest will be done. That requires an inventory that covers bought software as well as built software, and a patch rule written down before the incident.

The avionics or product security lead works on a different clock. A library in a certified configuration may stay for a decade. What they need is an exact, version-pinned list of every component in each configuration, its supplier, and a way to record why a reported vulnerability does or does not affect that configuration, without forcing a change that would need new certification work.

The MRO and engineering IT lead owns some of the most sensitive machines in the company: the laptops and loaders that put software onto aircraft. Their question is whether the software on those machines is exactly what it should be.

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

The plan works with whatever tools you already have. Adjust the scope to your role: an airline will start with ground systems and the digital estate, a supplier with its product configurations, an airport with shared and OT systems.

Days 1 to 30: scope and inventory

1. List critical cyber systems. Start from your TSA implementation plan if you have one. For each system, record owner, supplier, where it runs and whether it is IT, OT or airborne.
2. Collect SBOMs for what you build. Generate an SBOM in SPDX or CycloneDX for every application, service and container image your teams build, starting with internet-facing apps and anything that connects to operations.
3. Ask for SBOMs for what you buy. Send a written request to the suppliers of each critical cyber system. Use the template below.
4. Inventory the maintenance and loading estate. List every maintenance laptop, data loader and EFB image, its build, and the software parts it carries.
5. Write the patch rule. Define "timely" for critical cyber systems by severity and exploitation status (for example, known exploited vulnerabilities first), with a documented path for systems that cannot be patched quickly. This is the risk-based methodology the TSA measure refers to.
6. Name the reporting path. Confirm who decides whether an event is a significant cybersecurity incident and how it reaches CISA, and test that path with a tabletop exercise built around a vendor compromise.

Days 31 to 60: fix, gate and flow down

1. Match components to vulnerabilities. Run every SBOM, built and received, against vulnerability data. Enrich with EPSS and the CISA KEV catalog so the list is ordered by likely exploitation, not only by CVSS.
2. Fix what you build. Open upgrade pull requests for vulnerable dependencies in the apps and services you own. Start with internet-facing and operations-connected systems.
3. Gate new risk. Add a check to CI that stops builds introducing known exploited or critical vulnerabilities, with an exception process that has an approver and an expiry.
4. Record what does not apply. For product configurations and vendor systems where a CVE is present but not exploitable, record a VEX statement with a reason, so the next auditor sees the decision rather than an open finding.
5. Flow requirements down. Add SBOM delivery, vulnerability disclosure and incident notification terms to renewals and new contracts for critical cyber system suppliers.
6. Lock down loading software. Check that maintenance laptops and data loaders run only approved software builds, and that loadable software parts are verified against their integrity records before loading.

Days 61 to 90: prove it and keep it running

1. Measure against the rule. Report how many findings on critical cyber systems met the patch rule, how many have exceptions, and how many are overdue.
2. Assemble the evidence pack. Use the checklist below. Store it where the TSA coordinator, GRC and auditors can reach it.
3. Re-run the tabletop. Use the illustrative scenario below and time how long it takes to answer "which systems contain this component?"
4. Set a cadence. Rescan on every build, refresh received SBOMs at each vendor release, and review exceptions monthly.
5. Report up. One page for the CISO and board: coverage, overdue findings, supplier response rate and open exceptions.

Template: evidence checklist for the patching and monitoring measures

Template: supplier SBOM request (plain text you can adapt)

Subject: Software bill of materials request for [system name]

We are updating the inventory for systems we treat as critical cyber systems. Please provide, for the version of [system name] currently deployed with us: an SBOM in SPDX or CycloneDX that meets CISA's 2026 Minimum Elements for an SBOM; your security contact and vulnerability disclosure process; how and how quickly you notify customers of security incidents affecting the product; and, where a published CVE does not affect your product, a VEX statement explaining why. Please send an updated SBOM with each major release. We would like the first SBOM by [date].

Decision table: what to do with a finding on a critical cyber system

Illustrative scenario: one advisory, one morning

This is an illustrative scenario with invented, round numbers. At 08:00 a critical advisory names a logging library with a known exploited flaw. The security team searches its SBOMs and finds the vulnerable version in 12 of 400 built services, including the mobile booking backend and a crew app API. Upgrade pull requests for the 12 are open by 11:00. Supplier SBOMs show the library in two vendor systems: a flight information display platform and a baggage reconciliation tool. The vendor risk owner sends patch requests to both, and the airport OT lead adds a temporary network rule for the display platform while the vendor answers. The avionics lead checks the configuration list for the cabin network server and records a VEX statement because the library is not present in the certified build. By 17:00 the CISO has a three-line note: 12 built services fixed or in testing, two vendor systems mitigated with patches requested, no airborne configurations affected. The TSA coordinator has the records to show the patch rule was followed.

How Safeguard does this

Safeguard is a software supply chain security platform. The steps below follow the plan above and use only flows described in Safeguard's offering documentation and docs.safeguard.sh. Every capability named here is generally available (GA).

1. Choose where Safeguard runs. Safeguard deploys as SaaS, private VPC, on-prem or fully air-gapped (GA). The air-gapped deployment docs describe a signed snapshot bundle that ships on a cadence you choose, through a receiver in your DMZ that verifies signatures, with no component inside the perimeter calling outbound. If you want no AI in the loop at all, Zero AI mode (GA) runs the platform deterministically; bring your own model (GA) is the other option.
2. Keep source code on your machines with the local runner. The Safeguard CLI and local runner (GA) scan on your own systems. The docs show the scan commands:

   # Your own or proprietary code
   safeguard scan --dir .
   
   # A container image
   safeguard scan --image myregistry.azurecr.io/myapp:v1 \
     --registry-username "$REGISTRY_USER" \
     --registry-password "$REGISTRY_PASSWORD"
   
   # An SBOM you already have (SPDX or CycloneDX)
   safeguard scan --sbom sbom.json
   

   The docs say results are written as JSON under ./output by default.
3. Build the inventory. SBOM generation and analysis (GA) produces SPDX and CycloneDX, and SCA with deep transitive dependency scanning (GA) covers application dependencies and container layers. You can see which projects contain a given component and version, which is the lookup the illustrative scenario depends on.
4. Validate what suppliers send. The CLI docs show a validator for SBOM and VEX documents:

   safeguard validate sbom.json --strict -o report.json
   

   These snippets are copied from the docs and were not run for this post.
5. Prioritize flaws. Vulnerability management (GA) matches components against vulnerability sources and enriches findings with EPSS and CISA KEV. Reachability analysis (GA) ranks findings by whether your code actually calls the vulnerable path, which helps you write a risk-based patch rule that puts exploitable flaws first.
6. Gate new risk in CI. Policies and gates (GA) evaluate SBOMs and findings. Each policy's action decides what a failed policy does to the gate: 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 are requested with a business justification and an expiration date, and are submitted for approval. In CI, the integration docs list two flags for safeguard ci scan that matter here: --wait, and --fail-on-gate followed by a gate name, id or all, which fails the step when that policy gate is not Passed or Warning. Plain English policy creation (GA) lets you describe a rule in words. License compliance (GA) applies license policy to components.
7. Open fix pull requests, under your control. Autonomous remediation (GA) has Griffin open tested, policy gated pull requests that move a dependency to a fixed version, one repository at a time or in bulk. It ships switched off, with every category set to Manual. For certified configurations, leave it on Manual and record the engineering decision instead.
8. Map evidence to DO-326A. The compliance and GRC suite (GA) includes a DO-326A framework page. Per the docs, each scan of a product checks scan-decided requirements against the product's SBOM: security scope asset identification (DO326A-SCOPE), certified configuration traceability with exact versions (DO326A-CONFIG), no floating or ranged versions (DO326A-SPEC), software integrity hashes (DO326A-INT), supplier attribution for each component (DO326A-SUPP) and dated, identifiable evidence (DO326A-EVID). Other controls, such as the airworthiness security risk assessment and the airworthiness security plan, are evidenced with uploaded evidence, policies or an attestation, and the page includes policy templates written for DO-326A, including an Airworthiness Cybersecurity Plan and an Avionics Cybersecurity Vulnerability Disclosure Policy.
9. Request SBOMs from suppliers. TPRM (GA) lets you send single or bulk SBOM requests from a vendor record, with a template that sets the format, a deadline and automated reminders. Received SBOMs get format validation, a completeness check and an automatic vulnerability scan.
10. Record and publish exploitability. CSAF and VEX upload (GA) lets you record not-affected statements for configurations you cannot change. Suppliers can use Trust Center (GA) to publish their security posture and answer customer questionnaires.

Requirement, what Safeguard does, what you still own

What Safeguard does not do

• It does not certify anything. Type certification, special conditions and any Part-IS compliance finding come from the authorities. Safeguard helps you collect and organize evidence; it does not make a compliance finding or approve a design.
• It does not report incidents. Whether an event is a significant cybersecurity incident, and the report to CISA or any other authority, stay with your team.
• It does not segment networks, manage identities or monitor operations. Three of TSA's four measures need network, identity and monitoring tools and processes.
• It does not patch vendor systems, appliances or firmware. Fixes for passenger processing platforms, OT controllers, operating systems and appliances you do not build must come from those vendors. The incidents above were mostly that kind of case.
• It does not decide airworthiness. Whether a library change in a certified configuration needs new certification work is an engineering and airworthiness decision.
• It does not inspect loadable software parts on aircraft. The DO-326A checks look at the integrity records in the product's SBOM; verifying the parts loaded onto an aircraft is your maintenance procedure.
• Safeguard's own posture. Safeguard is designed for FedRAMP High, and its SOC 2 Type II audit is in progress. Neither is a certification of your environment.

Common mistakes

• Scoping only what you build. Most aviation software is bought and much is shared at airports. The incidents above came through a shared vendor product, an airport operator's systems and an open source library.
• Leaving maintenance laptops out. The FAA proposal names them. They are often managed outside central IT.
• Undefined "timely". Without a written rule, every open finding looks like a failure. Write the rule, including what happens when operations cannot take a patch.
• Forcing changes into certified configurations. Recording a VEX statement or engineering decision is often the right outcome for a fielded product.
• Gates with no exception path. A gate that blocks a release with no approved way through gets switched off. Exceptions with an approver and an expiry keep the gate on.
• Asking suppliers for "an SBOM" with no standard. Name the format and the CISA 2026 Minimum Elements, and validate what comes back.
• Treating the TSA plan as the evidence. An inspector will ask for records, not the plan's wording.
• Ignoring Part-IS because you are a US company. European operations, customers and manufacturers will flow it down.

FAQ

What cybersecurity rules apply to US airlines and airports?

TSA's March 2023 cybersecurity amendment to the security programs of certain TSA-regulated airport and aircraft operators asks for an approved implementation plan with network segmentation, access control, continuous monitoring and timely, risk-based patching of critical cyber systems. Earlier TSA requirements cover incident reporting to CISA, a cybersecurity point of contact, an incident response plan and a vulnerability assessment.

Has the FAA finalized its aircraft cybersecurity rule?

As of 25 October 2026, the Federal Register shows the August 2024 proposed rule, "Equipment, Systems, and Network Information Security Protection," and no final rule under that title. The FAA continues to issue project-specific special conditions for electronic system security protection.

What would 14 CFR 25.1319 require?

Under the proposal, applicants for transport category airplanes would have to protect equipment, systems and networks from intentional unauthorized electronic interactions that may adversely affect safety, by identifying and assessing the risks, mitigating them, and including procedures to maintain the protections in the Instructions for Continued Airworthiness.

Does the TSA amendment require an SBOM?

TSA's announcement does not use the word SBOM. It asks for timely, risk-based patching of operating systems, applications, drivers and firmware on critical cyber systems. An SBOM is the most practical way to know what needs patching on each system.

What is DO-326A and is it mandatory?

DO-326A is a revision of RTCA's DO-326 aviation cybersecurity guidance. The FAA proposal says industry wanted to use DO-326, DO-355 and DO-356 as a means of compliance with cybersecurity special conditions. Whether and how it applies to a project is set by its certification basis and the means of compliance agreed with the authority.

What is EASA Part-IS?

Part-IS is the name for Regulations (EU) 2022/1645 and 2023/203. EASA publishes acceptable means of compliance and guidance material for the organisation requirements (Part-IS.I.OR and Part-IS.D.OR) and authority requirements (Part-IS.AR), under rulemaking work titled "Management of information security risks." Check EASA's text for scope and dates.

How should airlines handle vulnerabilities in vendor passenger processing systems?

Ask for SBOMs, disclosure processes and incident notification terms in the contract; match received SBOMs against vulnerability data; and keep compensating controls and manual fallback procedures ready, because the fix has to come from the vendor.

What should avionics suppliers give their customers?

An exact, version-pinned SBOM per configuration with supplier attribution and integrity hashes, a vulnerability disclosure process, and VEX statements for published CVEs that do not affect the product.

Related reading

• Related in this series: 90-day plan for aerospace and defense and 90-day plan for hospitality and travel.
• Aviation Part-IS and supplier software after 22 February 2026
• RTCA DO-326A and the software supply chain
• Avionics security under DO-326A and ED-202A
• The Collins Aerospace MUSE airport disruption, September 2025
• Port of Seattle Rhysida ransomware and airport operations

Aviation teams often cannot wait for an upstream maintainer, and some cannot change a component in a certified configuration at all without new certification work. The options below cover the software you build and ship, where a fixed version exists and where it does not, so the exception list for your critical cyber systems stays short and every item on it has a reason.

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, and then scans from the terminal. This is the pattern for an engineering network that holds avionics or certification data: the scan happens where the code lives, and only results leave the machine.

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

The second demo is a real CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository. The assistant reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, and runs npm install and npm test with approval. It prints a summary and pushes nothing. The same flow applies to an airline's booking or crew app repository, where a fix should be prepared for review rather than merged automatically.

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

Quick check

Sources

• TSA: TSA issues new cybersecurity requirements for airport and aircraft operators (7 March 2023)
• Federal Register: Equipment, Systems, and Network Information Security Protection, proposed rule (21 August 2024)
• govinfo: full text of FAA Notice No. 24-23, Docket FAA-2024-1398
• Federal Register: Special Conditions, ATR42-500 and ATR72-212A, Electronic System Security Protection From Unauthorized Internal Access (7 August 2026)
• EASA: Cybersecurity domain, Part-IS AMC and GM for Regulations (EU) 2022/1645 and 2023/203
• NIST SP 800-161 Revision 1, Cybersecurity Supply Chain Risk Management Practices
• NIST SP 800-218, Secure Software Development Framework
• CISA: Updated Minimum Elements for a Software Bill of Materials (29 July 2026 release notice)
• CISA alert: Reported supply chain compromise affecting XZ Utils, CVE-2024-3094 (29 March 2024)
• Port of Seattle: Port cyberattack archive, including the 13 September 2024 statement
• RTX Corporation Form 8-K (September 2025)
• Safeguard docs: DO-326A framework
• Safeguard docs: Air-gapped deployment
• Safeguard docs: CLI usage
• Safeguard docs: CI/CD integration
• Safeguard docs: Policies and gates
• Safeguard docs: TPRM SBOM requests
• Safeguard docs: Generate SBOM

To try the flows above, download Safeguard at safeguard.sh/download and read the documentation at docs.safeguard.sh/docs.

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