License Compliance Before an OTA Release at an Auto Supplier

When someone asks "is there GPL code in this OTA image?", the honest answer comes from an inventory with a license on every line, not from a memory of what the team linked. For an auto supplier the workable routine is to build the license list from the build system, normalize it to SPDX identifiers, classify each license by what it obliges you to do when you ship, decide in advance which classes are allowed, and keep a dated record of every exception. Done that way, the question takes an afternoon to answer instead of a week of emails, and the answer survives an OEM's review.

This post is for the open source program office at a Tier 1 or Tier 2 supplier, the people who own the GPL question before a release goes out. It is not legal advice; your counsel decides what a license requires of your product. Most of the post works with or without Safeguard, which enters at "How Safeguard does this".

Key takeaways

• The release trigger is a question, usually from the OEM or from your own legal team: what open source is in this image, under which licenses, and what do we owe the people who receive it? Treat the answer as a release artifact, not a one-off investigation.
• Distribution is the event that matters. The GPL texts attach their source obligations to conveying or distributing object code, and an OTA package, a flashed ECU and a delivery to an OEM are all distributions. Which of them your contracts treat as one is a question for counsel.
• Read licenses as SPDX identifiers and expressions, not as free text. The difference between GPL-2.0-only and GPL-2.0-or-later, or between an OR and an AND, changes what you owe.
• Embedded Linux builds make the first inventory easy and the second one hard. The build system knows its packages; it often does not know the vendored C library, the board support package blob or the library a vendor binary links.
• Decide the policy before the release: which licenses are allowed, which need review, which are denied, scoped per product type, with exceptions that name an approver and an expiry date.
• In Safeguard, the capabilities used here are all GA: license compliance (GA) with detection, classification, policies and attribution output, SBOM generation and analysis (GA) including upload of SPDX and CycloneDX files, policies and gates (GA) with Block, Warn and Notify actions and approval through exceptions, TPRM (GA) for supplier SBOM requests, Portal (GA) for sharing SBOMs, and the CLI and local runner (GA).
• Safeguard does not give legal advice, does not read a license for you and does not scan a raw flashed binary image into an inventory. The legal reading, the supplier negotiation and the source offer stay with you.

The job and who owns it

The job is narrow and recurring: before each OTA release, say with evidence which open source licenses are in the software you are about to ship and show that what you owe has been done.

The owner differs by company. At many suppliers it is an open source program office, sometimes two people sitting between engineering and legal. Where there is no such office, it falls on a product security lead or a release manager who has been handed the GPL question because nobody else would take it. This post calls that person the program office lead and assumes three neighbours who must say yes: a build or release engineer who owns the pipeline, a legal counsel who owns the interpretation, and a supplier quality or purchasing contact who owns the contracts with the vendors whose software is inside your image.

The trigger is usually one of four things:

• An OEM questionnaire arrives with a block on open source, asking for a list of components and licenses and a statement about copyleft.
• A release gate in your own process asks for a license sign-off before an OTA package is signed.
• A new component is proposed, such as a different media stack or a vendor's binary, and someone remembers that it links a library under a license nobody has read.
• An incident or audit, where a third party points at a file in your product and asks where its source is.

The question "is there GPL in here?" is almost never the real question. The real questions are which components, under which exact license, linked how, shipped to whom, and what has been done about the obligations. The rest of this post is about getting to answers to those, quickly and repeatably.

What the rules actually say, in plain terms

You do not need to be a lawyer to read the main license texts, and a program office should read them once, so that the vocabulary in tickets means something. This section summarizes two of them from the texts on gnu.org. It does not replace your counsel.

GPL version 2

Section 3 of GPL version 2 sets the conditions for distributing a covered program in object code or executable form. You must accompany it with the complete corresponding machine-readable source, or accompany it with a written offer, valid for at least three years, to give any third party that source for a charge no more than your cost of physically distributing it. The same section defines the source of an executable work as the preferred form for making modifications, including interface definition files and the scripts used to control compilation and installation.

Section 4 says that any attempt to copy, modify, sublicense or distribute outside the license is void and automatically terminates your rights, while parties who received copies from you stay licensed as long as they remain in compliance.

For an auto supplier the practical reading is that "complete corresponding source" is a build deliverable, not a courtesy. It includes your modifications and the build scripts, so it has to be assembled per release and stored with the release record.

GPL version 3

GPL version 3 keeps the same shape in its section 6, which lists the ways to convey object code with the corresponding source: source on a durable physical medium with the product, a written offer valid for at least three years and for as long as you offer spare parts or support for that model, access from a designated network place, and a few others with limits. The span "as long as you offer spare parts or support for that model" matters to anyone with a long product life, because vehicle programs are long.

Section 6 also adds the rule that has made version 3 a recurring discussion in automotive. If you convey object code in a User Product, meaning a consumer product or a product designed for a dwelling, as part of a transaction that transfers possession and use, you must include the Installation Information along with the source. Installation Information is whatever is needed to install and run modified versions of the covered work on that product, and it must not stop modified code from working merely because it was modified. The text says the rule does not apply where no one retains the ability to install modified code, such as software in ROM.

Whether a given vehicle ECU is a User Product, and what Installation Information would mean for a safety relevant controller whose software is also governed by type approval rules, is not a question this post answers. It is exactly the kind of question counsel should settle once, in writing, per product line, so that engineers are not deciding it in a code review.

Section 8 covers termination and reinstatement. Distributing outside the license ends your rights under it. They are reinstated provisionally when you stop violating the license, permanently if the copyright holder does not notify you within 60 days after you stop, and also permanently when this is the first notice you have received from that holder and you cure within 30 days after receiving it. The consequence for a release process is simple. Finding a problem before shipping is cheap. Finding it after shipping starts a clock.

Weak copyleft, permissive and everything else

Not every license in your image has these obligations. Safeguard's license compliance docs sort licenses into permissive (for example MIT, BSD and Apache-2.0), weak copyleft (for example LGPL and MPL-2.0), strong copyleft (GPL), network copyleft (AGPL and SSPL), commercial and proprietary, public domain and unknown, and they say strong copyleft carries high risk for proprietary products. That sorting is a reasonable first pass for a program office. Weak copyleft licenses vary in what counts as a modification and how you may link, which is why the LGPL entries in a policy are usually "review", not "allow".

SPDX identifiers and expressions

A license inventory is only useful if two people reading it mean the same thing. The SPDX License List gives each commonly found license a short identifier, and it deprecates the bare GPL-2.0 form in favour of the explicit GPL-2.0-only and GPL-2.0-or-later. That matters because the difference is a legal choice, not a spelling.

The SPDX specification's license expression syntax, in Annex D, adds operators. AND means you must comply with all the named licenses at once. OR means a choice is offered. WITH attaches a listed exception to a license. The plus suffix means that version or any later version. Precedence runs plus, WITH, AND, OR, and parentheses override it. For a license not on the list, the specification defines a LicenseRef identifier. CycloneDX carries the same idea, letting a component list SPDX identifiers, named licenses, or a single SPDX expression.

The REUSE specification applies the same vocabulary to source files. Each covered file carries an SPDX-License-Identifier tag with a valid expression, and the project keeps a plain-text copy of each license in a LICENSES directory named after its identifier. If your own team's source files carry those tags, your inventory of what you wrote becomes machine readable too.

Process standards

ISO/IEC 5230, published in 2020 as the international version of OpenChain, describes where an organization's open source license compliance processes should exist, how roles and responsibilities are assigned, and how the processes are kept alive. It is a process standard for the program office itself, not a check on any one release. Organizations can self-certify against it or use an assessment. If an OEM asks whether you have an open source compliance program, this is the vocabulary for the answer.

How teams do it today and where it breaks

Most suppliers already do part of this. The honest picture, with or without any tool:

The build system is the best source, and it has gaps. An embedded Linux build assembled with the Yocto Project knows its recipes and their declared licenses. The Yocto docs describe a license manifest generated at image creation, checksums on license text so that a changed license fails the build, and an archiver class for collecting the source of what you ship, grouped by license. They also state a limit worth remembering: packages linked against static libraries may be missing from the license manifest and the source archive, because the license and archiver logic assume only packages that end up in the image. The same build can generate an SPDX SBOM for an image, in JSON, with licenses, sources and changes described.

The inventory stops where the build system stops. The vendored C library in the telematics code, the binary blob from the chipset vendor, the Android or QNX layer a different team owns, the container image on the cloud side of the OTA service and the mobile companion app are all outside the Yocto manifest. Each has its own license data or none.

The license field lies sometimes. A package declares MIT in its metadata while its LICENSE file says something else. A copied file carries a header from another project. A dual-licensed library is recorded as one of its licenses. Readers who trust a single signal get surprised later.

Suppliers hand over components without license data. The OEM asks the Tier 1 for a list; the Tier 1 asks the Tier 2; the Tier 2 sends a PDF.

Questions arrive late. The OEM's open source questionnaire lands in the same week as the release. Legal wants a list; the engineer who knows the build is on another program.

Exceptions live in email. Someone approved a GPL component for a test bench image and the approval was never recorded, so it quietly became a production dependency.

Nobody owns the source offer. The written offer, the source archive and the notice text are all deliverables with a lifetime of years, and the person who built the first release has changed jobs.

These problems are fixable with process, and many suppliers fix them with a spreadsheet and discipline. The spreadsheet breaks at the second product line. The workflow below is the same either way; the question is how much of it is manual.

Illustrative scenario: a telematics supplier faces the GPL question

This is a composite example built for this post, not a customer story. The company, its products and its timeline are invented, and every number below is an example input you can replace with your own. No outcome is claimed.

Example Telematics Co. (fictional) is a Tier 1 supplier. It builds a telematics control unit that runs an embedded Linux image assembled with Yocto, a companion mobile app and a cloud service that delivers OTA packages to vehicles. As example inputs, the OEM customer (also fictional) expects an OTA release every quarter, and the next one is three weeks away.

The OEM's supplier quality team sends a questionnaire as part of the release readiness review. It asks for the list of open source components in the OTA image and the cloud service, the license of each, whether any component is under a strong copyleft license, how corresponding source is made available, and who approves exceptions.

Week 1, days 1 and 2. The program office lead names the deliverables that matter: the OTA image, the app and the cloud service container. She confirms the owner of each with the build engineers. The OTA image is the focus because it is the one that reaches vehicles.

Week 1, days 2 to 4. The release engineer exports the image SBOM from the Yocto build and the lead asks the mobile and cloud teams for theirs. The first inventory shows what the build knows. It also shows a handful of components with no license, which the team marks unknown rather than guessing.

Week 1, days 3 to 5. The lead checks the gaps by hand. The vendored C library in the telematics code is the main one: its metadata says one license, its LICENSE file another. She raises it as a discrepancy with the engineer who vendored it, who finds the original project and corrects the record. A chipset vendor binary has no source and a proprietary license; the purchasing contact confirms the contract covers redistribution inside an OTA package.

Week 2, days 1 and 2. The lead and counsel agree the policy. As example inputs: permissive licenses are allowed; weak copyleft goes to review; GPL-2.0-only and GPL-3.0 components are allowed in the OTA image only after review of how they are linked and shipped, and denied in the app and in anything delivered as an SDK; AGPL and SSPL are denied in the cloud service. The policy is scoped by product type so that one policy does not fit all.

Week 2, days 3 to 5. The policy runs against the inventories. Two components in the OTA image fall in the review class. For one, counsel confirms how the component is used and records what is owed. For the other, an engineer proposes a replacement, and for the next two releases the team accepts a time limited exception with a named approver and an expiry date, because the replacement needs validation.

Week 3. The release engineer attaches the corresponding source archive and the notice file to the release record and the lead answers the questionnaire from the same records. Counsel signs off on the source offer wording. The OTA package is signed by the usual process.

The lesson is sequencing: inventory first, discrepancies second, policy third, exceptions fourth, delivery of source and notices last. The second quarter's release starts from the same records and only looks at what changed.

Step by step: the license check before an OTA release, with or without Safeguard

1. List the deliverables. The OTA image, the companion app, the cloud service images, any SDK or tooling you give to a customer. License duties depend on what you hand over, so each is its own inventory.
2. Pick the release unit. For OTA, a release is a signed package with a version. Each version gets its own inventory so that you can say what was in the package a particular vehicle received.
3. Generate the inventory from the build. Use the build system's SBOM output for the embedded image, and your package manager's output for apps and containers. Record SPDX identifiers where available.
4. Fill the gaps deliberately. For every component with no license, a vendored library, a vendor binary or a supplier component, decide whether to find out, replace it or escalate. Do not let "unknown" become "permissive" by default.
5. Cross check the signals. Compare the declared license, the license file and the source headers for the components that matter most. Treat a disagreement as a finding.
6. Classify by obligation. Sort licenses into permissive, weak copyleft, strong copyleft, network copyleft, proprietary and unknown, and write down what each class obliges you to do for each deliverable.
7. Write the policy. Allow, review and deny lists, scoped by deliverable, with who may approve exceptions and for how long.
8. Apply the policy before the release gate, not at it. Run it on the pull request that adds a dependency, so the answer arrives when changing course is cheap.
9. Handle exceptions in the open. A named approver, a written justification, an expiry date and a re-evaluation when it expires.
10. Assemble what you owe. For components with source obligations, the corresponding source and build scripts; for components with attribution obligations, a notice file and the license texts; for each, the offer or the delivery mechanism your counsel chose.
11. Check your suppliers' side. Ask suppliers for SBOMs with license data, and run the same policy on what they send. A copyleft component inside a supplier's binary is still in your image.
12. Keep the record with the release. Inventory, policy version, findings, exceptions, source archive and notice file, stored under the release version. When the OEM asks next year, the answer is a file.
13. Re-run on change. New components, new versions and a supplier relicensing a library all change the answer. Treat license changes between versions as a signal worth looking at.

For vehicle programs there is one more reason to keep these records tidy. UN R156 and ISO 24089 are about software updates, and INCIBE's guide to R156 says the manufacturer stores, for each RXSWIN, a verifiable record of the composition of the approved software before and after an update. A license inventory tied to the same release identifier is the same kind of record, kept for a different purpose. Safeguard does not make your R156 determination; the point is only that one clean per release inventory serves both.

A short template for the OEM questionnaire answer

Keep the answer to what your records support. The structure that works:

• Scope. The release version, the deliverables covered and the date of the inventory.
• Method. The build system and tools that produced the inventory, the formats, and how gaps and discrepancies were handled.
• Findings. Components by license class, without marketing language. Name the review class and say who reviewed it.
• Source and notices. How corresponding source and attribution are made available, and for how long.
• Exceptions. Count of active exceptions and their expiry dates, if the OEM asks for them.
• Contact. The program office address, so that the next question has an owner.

How Safeguard does this

Safeguard covers the detection, classification, policy, exception and sharing steps above on one platform. The legal reading, the supplier negotiation and the source offer stay with you. Each step below links to the docs page it is built from. Commands and YAML are copied from those pages; they were not run for this post.

1. Get the inventory in. For code and containers you build, connect the repository or registry as a project under Integrations, as the Generate SBOM page describes; the On Release trigger scans when a new tag is created. For the embedded image, upload the SBOM your build produced. The Existing SBOM page lists CycloneDX 1.3 to 1.6 and SPDX 2.2 and 2.3 as supported, and says uploaded SBOMs are validated and then enriched with vulnerability, EPSS, KEV, license and supplier data. Check which SPDX version your Yocto release emits against that list before you rely on it. The same docs page notes that its /v1 REST endpoints are not available yet, so use the in-app flow.

2. Or generate locally when source cannot leave the building. The Safeguard CLI (GA) builds an SBOM for a directory, image or repository. These commands are from the CLI usage page:

# A local directory (your own or proprietary code)
safeguard scan --dir .

# An SBOM you already have (SPDX or CycloneDX, detected automatically)
safeguard scan --sbom sbom.json

# Validate an SBOM against its specification
safeguard validate sbom.json

The docs say results include license.json alongside vuln.json and others, written under the output folder, and that scanning from the interactive terminal while signed in uploads the SBOM and findings to the platform, never your source. The local runner (GA) is that flow. The docs also say there is no CLI command for license listing, reports or policy evaluation yet, so the license review itself happens in the platform.

3. Let detection reconcile the signals. The license compliance page says Safeguard identifies licenses from package metadata, SPDX identifiers, full text matching of LICENSE, COPYING and NOTICE files, source file headers, and, for container layers, copyright files and embedded license strings. When the signals disagree, it raises a license discrepancy finding. That is the metadata says MIT but the file says something else case from the previous section, caught without anyone reading every file.

4. Read the classification. Each license is classified by obligation category, with deep links to explanations of attribution, source disclosure and patent grants. The page also says Safeguard understands full SPDX expression syntax, including OR, AND and WITH, and that for an OR the most permissive option that matches your policy is chosen automatically. Dual-licensed components therefore do not show up as false alarms. Open the Suppliers and Licenses tab on a project to see the licenses and, per the Suppliers and Licenses page, the license text, obligations and attribution requirements for each component.

5. Write the license policy. The license compliance page shows the policy format. The example below is the one on the docs page, trimmed to the parts this post uses:

apiVersion: safeguard.sh/v1
kind: LicensePolicy
metadata:
  name: default
spec:
  allow:
    - MIT
    - BSD-3-Clause
    - Apache-2.0
  deny:
    - AGPL-3.0-or-later
    - SSPL-1.0
  require_review:
    - GPL-2.0-only
    - LGPL-3.0-or-later
  context_overrides:
    - apply_to: { env: server }
      allow:
        - LGPL-3.0-or-later

The docs show context_overrides scoping by environment and say policies can be scoped to asset labels, so a policy for an embedded image can differ from the one for the cloud service. Your own allow, review and deny lists come from your counsel, not from this example. The settings path in the docs is Settings, then License Policies, where you set allowed and blocked licenses, a review list and scope.

6. Turn the policy into a gate. Under Settings, Policies, the Policies and Gates page lists a License condition and a License Compliance template. Each policy has one Action. Block fails the gate. Warn lets the gate pass with a warning that names the policy. Notify lets it pass and sends a notification. License policies plug into guardrails at CI time, at admission and at pull request time, according to the license compliance page. For a CI job, safeguard ci scan --wait --fail-on-gate <gate> fails the job when the gate fails, once policy outcomes are on for your workspace. A new direct dependency with a denied license gets a blocking check at pull request time, which is where you want it.

7. Record exceptions properly. Exceptions on the Policies and Gates page follow a workflow: a developer requests an exception, selects the policy and finding, gives a business justification and sets an expiration date, approvers are notified, one decides, and the audit trail records it. The license docs say temporary license exceptions use the same workflow, with a named approver, an expiry date and a documented justification, and that they auto expire and re-evaluate. In the scenario, that is how the review class component rides for two releases without becoming permanent by accident.

8. Generate what you owe for attribution. The license compliance page says that for redistributed artifacts Safeguard generates a NOTICE or third party notices file with the required attributions, a licenses directory with each required license text, and a machine readable SPDX document for each release. The Suppliers and Licenses page describes the in-app route, Export and then Attribution Notice, with TXT, HTML or Markdown output. The docs say there is no CLI command for generating attribution yet, so this step is in the app. Corresponding source for copyleft components stays with your build, and so does the choice of source offer wording.

9. Run the same analysis on supplier SBOMs. The license page says vendor SBOMs get the same classification: are their licenses compatible with your product, does any component trigger a deny listed license for you, and has the license set changed between versions, which the page calls a sign of unexpected relicensing. This flows into TPRM (GA) assessments. The SBOM Requests page covers asking vendors for SBOMs, setting a deadline, automated reminders and validation of format and completeness when one arrives.

10. Review the dashboard. The Licenses dashboard shows license distribution across your fleet, new license introductions over time, policy violation counts and trends, and a per asset license manifest you can export as Excel, CSV, SPDX or CycloneDX. The new license introductions view is the one a program office will watch after a release, because it shows when a new obligation entered the product.

11. Share the answer. For the OEM, the Portal (GA), meaning the SBOM publish and share product, not the free entry tier, lets you share an SBOM with named recipients, or by link with expiration date, download limit and password. The Sharing page lists requiring authentication, restricting to approved domains, requiring NDA acceptance, tracking access and revoking it. Whether a license inventory belongs in an NDA covered channel is your call.

12. Keep watching. Safeguard rescans connected projects on a schedule you set, and Notify policies alert your channels when a policy starts failing, so a new component or a relicensed version surfaces between releases rather than at the gate.

For the full picture of the job, see the matching use case page: license compliance.

What maps to what

What to measure

These are measures to track, not outcomes anyone should expect. Pick the few that fit your program and record them per release.

• Share of components in each shipped deliverable that have a license recorded, and the number marked unknown.
• Share of components with the license confirmed from more than one signal for your high risk classes.
• Open license discrepancy findings at the release gate, and how many were resolved by changing the record versus changing the component.
• Components in the review and deny classes per deliverable, per release.
• Active exceptions, each with approver and expiry, and how many expired and were re-evaluated since the last release.
• New licenses introduced since the last release.
• Time from an OEM questionnaire to a sourced answer, measured by your own clock.
• Whether a corresponding source archive and notice file exist under each release version, and where the written offer text is kept.
• Share of suppliers who provided an SBOM with license data, and of those, the share that passed validation.
• Whether the policy version used for a release can be named afterwards.

What Safeguard does not do

• It does not give legal advice. It classifies licenses by obligation category and enforces the policy you write. Whether linking, shipping on an ECU or delivering an OTA package triggers a given obligation is for your counsel.
• It does not read a raw flashed image into an inventory by itself. The inventory comes from SBOMs, repositories, container images and manifests. For an embedded image, that means the SBOM your build produces or a supplier provides. Components the build does not know about stay unknown until someone supplies the data.
• It does not assemble corresponding source or write your source offer. The docs describe generating notices, license texts and an SPDX document. Gathering the source and build scripts for a copyleft component, and choosing how to offer them, stays with your build and your counsel.
• It does not generate attribution from the CLI. The docs say there is no CLI command for generating attribution or for license reports and policy evaluation yet. These are in the app.
• It does not make suppliers cooperate. TPRM tracks requests, reminders and validation. The contract clause that obliges a supplier to answer is yours to negotiate.
• It does not make your type approval determinations. Whether a software update, an RXSWIN or a vehicle type complies with UN R155 or R156 is for your approval authority and technical service.
• It does not decide what a license means in your market. License texts are interpreted differently in different courts, and the policy example in this post is not a recommendation.

Common mistakes

• Treating the build manifest as the whole inventory. It is the best single source and it is not all of it. Vendored code, vendor binaries and anything outside the image build need their own entries.
• Trusting one license signal. Metadata, the license file and file headers can disagree. Look at the disagreement, because that is where surprises hide.
• Reading GPL-2.0 as GPL-2.0-or-later, or the reverse. The identifier is a legal statement.
• Mixing up an OR with an AND. An OR gives you a choice and an AND gives you both sets of obligations.
• Writing one policy for every product. An embedded image, a cloud service and an SDK have different obligations. Scope the policy.
• Granting exceptions without expiry. The test bench component becomes the production component. Every exception needs an approver and a date.
• Leaving the source offer to the person who built release one. Written offers last for years, and some last for as long as you support the model. Give them an owner and a place.
• Checking licenses at the release gate only. By then the cost of change is highest. Put the check on the pull request.
• Ignoring licenses changing between versions. A supplier or an upstream project relicensing a library is a new obligation arriving in a minor version.
• Asking suppliers for a list instead of an SBOM. A PDF is not a machine readable record and cannot be checked against your policy.

FAQ

Is there GPL code in an automotive OTA image?

Very likely, if the image runs Linux or ships tools built on it. Whether that creates an obligation for your product depends on the exact license, how components are combined and what you distribute, which is why the answer comes from an inventory and your counsel rather than from a yes or no.

Does shipping an OTA update count as distributing software under the GPL?

The GPL texts attach their source obligations to distributing or conveying object code. Version 2 speaks of copying and distributing in object code or executable form, and version 3 of conveying. Whether each OTA delivery, each ECU flash and each hand over to an OEM is a distribution under your contracts and applicable law is a question for counsel. Many programs treat all of them as distributions to be safe.

What is the difference between GPL-2.0-only and GPL-2.0-or-later?

The first means that version only and the second means that version or any later version. The SPDX License List deprecates the bare GPL-2.0 identifier because it left that ambiguous. The plus suffix in SPDX expressions means the same as the or-later forms.

What does GPL version 3 add that matters for vehicles?

Section 6 adds Installation Information for User Products, which is what is needed to install and run modified versions of the covered work on the product. The text says the rule does not apply where no one retains the ability to install modified code. Whether a vehicle component is a User Product is for counsel.

How long must a written offer for source stay open?

GPL version 2 section 3 says valid for at least three years. GPL version 3 section 6 says at least three years and for as long as you offer spare parts or support for that model. Vehicle support periods are long, so treat the offer as a long term commitment with an owner.

What does a license discrepancy finding mean?

It means two signals disagree, for example a package metadata field says MIT while the license file says something else. The Safeguard docs say this is usually a packaging mistake or a relabeled license. Treat it as a question to answer, not a verdict.

Can a policy handle dual licensed components?

Yes, if it understands SPDX expressions. The Safeguard docs say it does, and for an OR it picks the most permissive option that matches your policy. Check that the chosen option is one your counsel accepts.

How do I get license data from suppliers who send binaries?

Put an SBOM with license data in the sourcing pack and the contract, ask for it per software version, and validate what arrives. In Safeguard, TPRM SBOM requests track the request, reminders and validation, and the vendor license analysis runs the same classification on what comes back.

Does ISO/IEC 5230 certify a product?

No. It describes the processes of an organization's open source compliance program, and organizations can self-certify or use an assessment. It does not approve any one release.

Who should own license compliance at a supplier?

One named person with authority over the release gate, backed by counsel for interpretation and by build engineering for the pipeline. A shared mailbox with no owner is how exceptions get lost.

License findings and vulnerability findings often land in the same release review, and both end with a change to a component version or a replacement. The block below covers the vulnerability side, and its limit applies here too: where a component sits inside a vendor binary you do not build, the change has to come from that vendor.

Where a license problem means swapping a dependency you build, the same upgrade and policy tooling applies, and a replacement still needs your normal validation before it reaches a vehicle.

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. For a build that cannot leave a supplier's isolated network, this is how the inventory and its license data reach the platform while the source stays on the machine.

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

The second demo is a real CLI session: safeguard is asked to fix the lodash CVE in a repository, 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. When a license policy blocks a new dependency in the cloud or app code, the same flow applies: the CLI proposes the change, you approve each step and nothing is pushed for you.

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

The third demo connects Claude to the Safeguard MCP server (GA) with OAuth and shows how you choose which tools Claude can use. For a program office lead, that means asking in plain language which projects have a failing license policy or an exception expiring this month while preparing the OEM answer, with access limited to the tools you allow.

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

Quick check

Related reading

• Related in this series: 90-day plan for automotive software supply chain security.
• SBOMs for automotive ECU firmware and embedded software.
• UN R155, R156 and ISO 21434 in plain terms.
• What Uptane is.
• Scoping a vehicle software recall with an SBOM.
• An SBOM with every release, a logistics use case.

Try it yourself: download Safeguard or read the Safeguard docs.

Sources

• GNU General Public License, version 3 (sections 6 and 8)
• GNU General Public License, version 2 (sections 3 and 4)
• SPDX License List
• SPDX specification 2.3.1, Annex D: license expressions
• REUSE specification 3.3
• OpenChain: ISO/IEC 5230 license compliance
• CycloneDX 1.6 JSON reference
• Yocto Project: Working with licenses
• Yocto Project: Creating a Software Bill of Materials
• INCIBE: New 2024 cybersecurity regulations for vehicles (guide, June 2024)
• UK Vehicle Certification Agency: Cyber Security and Software Updating
• Safeguard docs: License Compliance
• Safeguard docs: Suppliers and Licenses
• Safeguard docs: Policies and Gates
• Safeguard docs: Generate SBOM
• Safeguard docs: Existing SBOM
• Safeguard docs: CLI usage
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: Portal Sharing

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