OSPO as Open Source Steward Under the EU Cyber Resilience Act

When a company publishes open source it does not monetise, but sustains for commercial use, the EU Cyber Resilience Act can make it an "open-source software steward" for that project. The OSPO is the natural team to classify each project, write the Article 24 security policy and wire up reporting before steward duties apply on 11 December 2027.

The same company can be a manufacturer for one project, a steward for a second and outside the CRA for a third. This guide, written for open source program offices (OSPOs), starts from a September 2026 Linux Foundation post on how OSPOs are preparing for the CRA, then goes to the regulation and to the European Commission's July 2026 guidance, where most of the detail on stewards now lives.

Key takeaways

• Classification is per project, not per company. The Commission's guidance says one legal entity can be a steward for one FOSS project and a manufacturer for another, and is often both for a free community edition and a paid edition of the same codebase.
• A company that publishes a library it does not monetise but builds into its own products is, in the Commission's own example, that library's steward.
• Article 24 gives stewards three duties: a documented, verifiable cybersecurity policy; cooperation with market surveillance authorities; and reporting under Article 14, scaled to how involved the steward is in development and infrastructure.
• Stewards cannot be fined under the CRA (Article 64(10)), and they may not affix the CE marking to the software they support (recital 19). Authorities can still require corrective action (Article 52(3)).
• Dates: manufacturer reporting under Article 14 has applied since 11 September 2026. According to the Commission's reporting page, steward reporting under Article 24(3) applies from 11 December 2027, together with the rest of the regulation.
• The OSPO already holds the list of published projects, licences and maintainer contacts. What it usually lacks is a path to product security and the EU reporting platform.

Why this question exists now

The Linux Foundation post behind this guide, published on 9 September 2026 with contributors from OpenSSF, OpenChain and several company OSPOs, argues that CRA work fragments when nobody coordinates open source: legal lacks dependency data, security cannot list affected products, and teams flood the same maintainers with requests. Its answer is an OSPO that maps products, components, owners and upstream relationships before an incident. It cites 2025 Linux Foundation research in which 92% of 116 organisations with an OSPO involved it in open source security.

Most of that post, and most CRA writing generally, looks at the manufacturer side: the company that consumes open source inside products it sells. Safeguard has already covered that ground, including the steward category in Article 24 as it applies to foundations and whether a manufacturer must report an exploited flaw in an open source component. This guide looks at the other direction. Your company also publishes open source. For some of those projects, the CRA may treat you as a steward, and the OSPO is usually the only team that can answer "which ones?"

Three roles one company can hold at the same time

The CRA attaches obligations to roles, and roles attach to specific software, not to organisations as a whole. Three roles matter for a company that publishes open source.

Manufacturer. Article 3(13) defines a manufacturer as a natural or legal person who develops or manufactures products with digital elements, or has them designed or made, and markets them under its own name or trademark, whether for payment, monetisation or free of charge. Manufacturers carry the full set of CRA duties: essential cybersecurity requirements in Annex I, a risk assessment, technical documentation, conformity assessment, CE marking, a support period of at least five years in most cases (Article 13(8)), and the Article 14 reporting regime.

Open-source software steward. Article 3(14) defines a steward as a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific FOSS products intended for commercial activities, and that ensures the viability of those products. Recital 19 describes the regime that applies to stewards as "light-touch and tailor-made". It names foundations and entities that develop and publish FOSS in a business context, including not-for-profits, as examples.

Neither. Recital 18 says the CRA does not apply to people who contribute source code to FOSS that is not under their responsibility. And footnote 14 of the Commission guidance confirms that a legal person can publish FOSS and be subject to no CRA obligation at all for it, when the software is not placed on the market and the publisher does not meet the steward definition for that project.

Only legal persons can be stewards. An individual publishing their own project is either a manufacturer (if they monetise it) or outside scope.

The Commission guidance settles the "per project" question

On 27 July 2026 the Commission published its guidance on applying the CRA, reference C(2026) 5252, with an annex that runs to dozens of worked examples. Section 3 deals with free and open-source software. For OSPOs, three paragraphs matter most.

Paragraph 72 says being a steward for one FOSS project does not make a legal person a steward for other FOSS it publishes, and being a manufacturer for one FOSS project does not stop it being a steward for another. Paragraph 73 adds that one legal entity may have to fulfil different roles for different FOSS projects. Paragraph 74 then sets the method: for each specific FOSS it publishes, the legal person has to work out whether that software is placed on the market. If yes, it is the manufacturer. If no, it may be the steward, provided the software is intended for commercial activities and the entity sustains it.

That method is a portfolio exercise. It needs a list of every project the company publishes, who runs it, how it is funded, how it is distributed and whether any version of it is sold. In most companies, only the OSPO has that list or can build it quickly.

When is your open source "placed on the market"?

The steward role only exists for FOSS that is not placed on the market, so the first test for every project is monetisation. The Commission guidance walks through the cases in sections 3.2.1 to 3.2.7. In summary:

• Charging for the software itself, such as for pre-compiled binaries, places it on the market (paragraph 51).
• Community and paid editions are different products. In open core and similar models, the paid edition is placed on the market and the free one is not (paragraph 52). A legal person publishing the free edition is its steward (paragraph 53).
• Monetising other services through the software, such as a free app that earns commission, places it on the market (paragraph 54).
• Requiring personal data processing as a condition of use, beyond security, compatibility or interoperability, does too (example 16).
• Paid support services alone do not. The test is whether access to the software or its maintenance depends on payment (paragraphs 55 and 56). Gating a version behind payment does count (paragraph 57).
• Donations and third party financing do not, by themselves, make the activity commercial (sections 3.2.4 and 3.2.5).
• Not-for-profits that use all earnings after costs for their objectives do not place their FOSS on the market, but may be its steward (paragraph 66).

When are you the steward?

If a project is not placed on the market, the second test is the steward definition. Recital 19 and paragraph 75 of the guidance list what sustained support can look like: hosting and managing collaboration platforms, hosting source code or software, governing or managing FOSS projects, and steering their development. The list is open ended.

Two Commission examples describe ordinary corporate open source almost exactly:

• Example 25. A legal person publishes a FOSS user interface library, does not monetise it, and integrates it into one of its own products that it does sell. The library is not placed on the market, it is intended for integration into products, and the publisher is its steward.
• Example 26. A legal person places an operating system on the market and also publishes FOSS reference libraries for that system, which it does not monetise. It is the steward of those libraries.

If your company has an engineering blog, a GitHub organisation with a few hundred public repositories and a handful of libraries that your products depend on, examples 25 and 26 are about you.

The guidance also covers status changes. Paragraph 83 says an entity that stops providing sustained support may no longer meet the steward definition and is encouraged to say so publicly. Paragraph 84 says a steward that starts monetising a project becomes its manufacturer from the date it places it on the market, but not for earlier versions it supported as steward.

Decision table for one published project

Use this table per repository or per distributable package. It summarises the regulation and the Commission guidance; it is not legal advice, and edge cases should go to counsel.

What Article 24 actually asks a steward to do

Article 24 has three paragraphs.

1. A cybersecurity policy. Stewards must put in place, and document in a verifiable manner, a policy that fosters secure development and effective vulnerability handling by the project's developers. It must encourage voluntary reporting under Article 15 and cover documenting, addressing and remediating vulnerabilities, plus sharing vulnerability information within the open source community.

2. Cooperation with market surveillance authorities. On request, stewards must cooperate with authorities to mitigate risks posed by the FOSS they support and, after a reasoned request, hand over the policy documentation in a language the authority understands.

3. Reporting, scaled to involvement. Article 14(1), the duty to notify actively exploited vulnerabilities, applies to stewards only insofar as they are involved in developing the product. Article 14(3) and 14(8), the duties to notify severe incidents and to inform users, apply to the extent that severe incidents affect network and information systems the steward provides for developing the product.

Three other provisions shape the regime. Under Article 52(3), market surveillance authorities check steward obligations and can require corrective action. Under Article 64(10)(b), the CRA's administrative fines do not apply to any infringement by stewards. And recital 19 says stewards may not affix the CE marking to the products they support.

How far reporting reaches depends on the kind of support you give

Paragraphs 79 to 82 of the Commission guidance split stewards into three profiles. All must meet Article 24(1) and (2); reporting depends on the profile.

Most corporate OSPOs will find their important projects in the third row: if your engineers merge the pull requests and cut the releases, you are involved in development. Paragraph 216 adds that the duty is triggered by awareness of active exploitation, not by a flaw existing in the code, and that stewards will usually hear of exploitation from a downstream manufacturer, user or researcher. Your inbound intake channel is where the reporting clock starts.

The dates, confirmed against the text

The dates in this table come from Article 71 of Regulation (EU) 2024/2847 and from the Commission's CRA pages, checked on 23 October 2026. A longer walk through each date is in what the CRA requires, and when.

One point needs care. The Linux Foundation post frames 11 September 2026 as the next major deadline, which is right for manufacturers, and a reader could assume stewards had to report from then too. The Commission's reporting page says steward reporting under Article 24(3) applies from 11 December 2027: Article 71(2) brings forward only Article 14, and steward duties run through Article 24. The OpenChain CRA checklist, version 1.0 of 11 September 2026, also dates its steward section to 11 December 2027.

That is a window, not a reason to wait: if your company also sells products, it has been reporting since September, and your stewarded projects are often inside those products.

Why the OSPO is the right home for steward work

The Linux Foundation post describes an OSPO as the people, skills and practices that let an organisation manage open source; in a small company that can be one person. For steward duties, the OSPO already owns most of the inputs:

• The list of published projects, because OSPOs usually approve outbound open source.
• Contribution and release policy, which the Article 24(1) policy extends.
• Maintainer relationships, upstream and in house.
• Inventory and SBOM practice. The Linux Foundation post cites an ENISA 2026 finding that 78% of surveyed organisations had started SBOM adoption but only 9% had reached mature, fully automated use.

What OSPOs lack is reporting machinery, which sits with product security. The split in OSPO or security team: who owns which dependency governance task still holds. For steward work, the OSPO owns classification and the Article 24(1) policy; security owns the Article 14 notification.

The OSPO steward operating model

This model assumes a company that both sells products in the EU and publishes open source.

1. Build the steward register

List every public repository and every published package. For each one, record:

• Repository, package coordinates and licence.
• Whether any version is monetised, with a written reason.
• Whether it is intended for commercial activities.
• Support profile: non-technical, infrastructure or engineering.
• Owner and security contact.
• Status: stewarded, manufacturer product, not stewarded, or archived.
• Which of your own products integrate it, at which versions.

The last field is where the two roles meet. If a library you steward is exploited inside your product, your manufacturer duties under Article 14 apply today.

2. Write the Article 24(1) cybersecurity policy

"Verifiable" suggests something an authority can read and check against practice. A structure mapped to the text:

• Scope. Which projects the policy covers, linked to the register.
• Secure development. Code review, protected branches, signed releases, dependency updates, multi-factor authentication. The OpenSSF Open Source Project Security Baseline gives a measurable list.
• Vulnerability handling. Intake, triage, response targets, private fixes, advisories and CVE requests.
• Voluntary reporting to a coordinating CSIRT or ENISA under Article 15, which Article 24(1) asks the policy to foster.
• Information sharing with the open source community and downstream users.
• Authority requests. Who answers, in which languages, and where the documentation lives.
• Status changes. How you announce that a project is no longer stewarded or has become a paid product.

The OpenSSF OSS Stewards Obligations Checklist turns Article 24 into checkable items, summarising the policy duty as a security.md plus a published reporting process. The CRA Stewards Playbook covers cooperation with authorities and support for downstream manufacturers.

3. Set up intake and the reporting path

Intake is the critical control. Each stewarded project needs a SECURITY.md with a private reporting route, a findable company security contact, an internal route to maintainers and product security, and a record of your coordinating CSIRT. Under Article 14(7), notifications go through the ENISA Single Reporting Platform to the CSIRT where you have your main establishment. The Commission says manufacturers and stewards both use that platform, so steward reports should share your PSIRT's accounts and runbook.

4. Connect steward work to manufacturer work

For a company that is both, three links matter:

• Article 13(5) due diligence. Manufacturers must take due diligence on third party components, including FOSS not placed on the market. Apply the same intake checks to your own published libraries.
• Article 13(6) reporting upstream. A manufacturer that finds a flaw in an integrated component must report it to the component's maintainer and share any fix. When your product team finds a flaw in a library you steward, that report should land in your steward intake.
• Article 14(8) user information. Manufacturers, and stewards with engineering involvement, must inform users where appropriate, in machine readable form where appropriate. One advisory pipeline that emits CSAF or VEX alongside human readable advisories serves both roles.

5. Coordinate upstream for projects you do not steward

Most open source in your products belongs to someone else, but under Article 13(6) your company still reports the flaws it finds there and shares fixes. The Linux Foundation post asks OSPOs to consolidate requests and coordinate disclosure so maintainers are not flooded. In practice: one outbound security contact, a shared log of what you reported to whom, and a rule that fixes go upstream as pull requests rather than staying in private forks.

6. Keep the register honest over time

A project you stop maintaining may stop being stewarded (paragraph 83); one you start selling becomes a manufacturer product from that date (paragraph 84). Review the register on a schedule and publish status changes in the repository.

Step by step: a 90 day steward readiness plan

A 90 day push gets the foundations in place well before 11 December 2027. The commands use the GitHub CLI; adapt them for your forge.

Days 1 to 15: inventory every published project

# List public, non-archived repos with licence and last push date
gh repo list your-org --visibility public --no-archived --limit 1000 \
  --json name,licenseInfo,pushedAt,isFork \
  --jq '.[] | [.name, (.licenseInfo.spdxId // "NONE"), .pushedAt, .isFork] | @tsv' \
  > published-repos.tsv

wc -l published-repos.tsv

Record forks too, including private forks of upstream projects that ship in your products, and packages published from monorepos.

Days 15 to 30: classify each project

Create a register file in a repository the OSPO controls. A plain YAML file is enough to start:

# steward-register.yaml
- project: ui-widgets
  repo: https://github.com/your-org/ui-widgets
  licence: Apache-2.0
  monetised: false
  monetisation_note: "Free download; no paid edition; support contracts sold separately (guidance para 55-56)"
  intended_for_commercial_activities: true
  integrated_in_our_products: ["console-web 4.x", "mobile-app 7.x"]
  support_profile: engineering   # non-technical | infrastructure | engineering
  cra_role: steward
  owner: platform-ui-team
  security_contact: security@your-company.example
  status: stewarded
  last_reviewed: 2026-10-23

Run every row through the decision table and send edge cases to counsel.

Days 30 to 50: publish security policy and intake

Check which stewarded repositories lack a SECURITY.md:

for repo in $(yq -r '.[] | select(.cra_role=="steward") | .repo' steward-register.yaml \
  | sed 's#https://github.com/##'); do
  if gh api "repos/$repo/contents/SECURITY.md" >/dev/null 2>&1; then
    echo "OK      $repo"
  else
    echo "MISSING $repo"
  fi
done

Enable private vulnerability reporting on each stewarded repository so reports never need to arrive as public issues:

gh api -X PUT "repos/your-org/ui-widgets/private-vulnerability-reporting"

A minimal SECURITY.md that points to the company policy:

# Security policy

This project is stewarded by Your Company Ltd under its open source
cybersecurity policy: https://your-company.example/open-source/security-policy

## Reporting a vulnerability
Use this repository's private vulnerability reporting, or email
security@your-company.example. Please include affected versions and
whether you have seen active exploitation.

## Supported versions
| Version | Supported |
|---------|-----------|
| 4.x     | Yes       |
| < 4.0   | No        |

Publish the policy itself on your domain, with a version number and date, and add a security.txt file at the well known path so researchers can find the contact.

Days 50 to 70: generate release evidence and check project health

Produce an SBOM and vulnerability report per release. The Safeguard CLI writes JSON results under ./output:

git clone https://github.com/your-org/ui-widgets && cd ui-widgets
git checkout v4.3.0
safeguard scan --dir .
ls output/

You can also scan a published container image or an SBOM file you already produce:

safeguard scan --image your-org/ui-widgets:4.3.0
safeguard scan --sbom ui-widgets-4.3.0.cdx.json

The OpenSSF Scorecard CLI, which the OSPO Book recommends, checks practices such as branch protection and code review:

export GITHUB_AUTH_TOKEN=...   # a read-only token
scorecard --repo=github.com/your-org/ui-widgets --format=json > ui-widgets-scorecard.json

Days 70 to 90: run a tabletop on the reporting chain

The Linux Foundation post recommends testing the full 24 hour workflow in a tabletop exercise. A steward scenario:

1. A downstream manufacturer emails your security contact: a flaw in your published library is being exploited inside their product.
2. Clock check: when did "awareness" start, and who recorded it?
3. The OSPO confirms from the register that you steward the library and have an engineering profile, so Article 14(1) reporting will apply to you as steward from December 2027.
4. Product security checks whether your own products integrate the affected versions. If they do, the Article 14 manufacturer clock is already running today.
5. Draft the 24 hour early warning, the 72 hour notification, and the user information under Article 14(8), in the Single Reporting Platform's format.
6. Coordinate the fix in the open source project, publish an advisory and share machine readable vulnerability data.
7. Write down every point where you lost time.

Run it again with an infrastructure incident, such as a compromised build runner for a stewarded project, to exercise Article 14(3).

Where Safeguard fits, honestly

Safeguard does not decide whether you are a steward, does not file notifications on the Single Reporting Platform, and is not a CRA conformity assessment. It helps with the evidence and data both roles depend on:

• SBOM generation and analysis in SPDX and CycloneDX for repositories, images and SBOM files [GA].
• Open source inventory through the Open Source Manager [GA].
• Component lookup: which of your projects contain a given component and version [GA], step 4 of the tabletop.
• Vulnerability matching with EPSS and CISA KEV enrichment, and reachability analysis to see whether your code calls the vulnerable path [GA].
• CSAF and VEX upload [GA], useful when you publish machine readable vulnerability information for users.
• Policies and gates evaluated at build, CI and release [GA], for example to stop a stewarded library releasing with a known exploited vulnerability.
• Compliance suite with frameworks, controls, evidence and tasks; its framework catalogue includes the EU Cyber Resilience Act [GA]. The public Trust Center for sharing SBOM and VEX documents is early access [EA].
• Autonomous remediation opens tested fix pull requests [GA]. It ships switched off, with every category set to Manual.

Steward classification, your policy, your security contact and upstream coordination remain people and process.

Common mistakes

• Treating CRA status as company wide. Roles are per project; one blanket statement will be wrong for part of your portfolio.
• Assuming free means out of scope. Free community editions and free libraries you build into your products are, per the Commission, usually yours to steward.
• Assuming paid support makes you a manufacturer. Services around freely downloadable software do not; gating maintenance or a version behind payment does.
• Mixing up the dates. Manufacturer reporting started 11 September 2026; steward duties apply from 11 December 2027.
• Ignoring the support profile. Reporting depends on whether you give non-technical, infrastructure or engineering support. Write the profile into the register; it decides which Article 14 paragraphs apply.
• Leaving dead projects ambiguous. Unmaintained samples and demos in your organisation look like stewarded projects. Mark them clearly as unmaintained and not stewarded, as the guidance encourages for status changes.
• Running steward intake separately from the PSIRT. The same flaw can trigger manufacturer and steward duties. Two disconnected inboxes means two clocks and two inconsistent stories.
• Believing "no fines" means "no consequences". Stewards cannot be fined under the CRA, but market surveillance authorities can require corrective action under Article 52(3), and your manufacturer side remains fully fineable.

FAQ

What is an open source steward under the Cyber Resilience Act?

It is a legal person, not an individual, that is not the manufacturer of a given free and open-source project but systematically supports it on a sustained basis, where the project is intended for commercial activities and the legal person ensures its viability. The definition is in Article 3(14) of Regulation (EU) 2024/2847.

Can a company be both a manufacturer and a steward?

Yes. The Commission's July 2026 guidance says the same legal entity can have different roles for different FOSS projects, and is typically the manufacturer of a paid edition and the steward of the free community edition of the same software.

Is my company a steward if we publish a library we use in our own products?

Probably, if you do not monetise the library, it is intended for integration into products, and you sustain it. Example 25 in the Commission guidance describes exactly this case and calls the publisher the library's steward.

When do open source steward obligations apply?

From 11 December 2027, when the CRA applies in full. The Commission's reporting page states that steward reporting under Article 24(3) applies from that date under Article 71(2). Manufacturer reporting under Article 14 has applied since 11 September 2026.

Do open source stewards have to report vulnerabilities within 24 hours?

Only to the extent they are involved in development. A steward that provides engineering resources must notify actively exploited vulnerabilities it becomes aware of, using the Article 14 timelines: an early warning within 24 hours, a notification within 72 hours and a final report within 14 days of a fix being available. A steward giving only non-technical support does not have that duty.

Can open source stewards be fined under the CRA?

No. Article 64(10)(b) excludes any infringement by stewards from the CRA's administrative fines. Market surveillance authorities can still require stewards to take corrective action under Article 52(3).

Does a foundation that hosts our project become the steward instead of us?

It can be, for projects it systematically supports; the Commission guidance names such foundations as stewards. If your engineers run development, check whether you also meet the definition, since it turns on who provides the sustained support.

What should an OSPO put in a CRA steward cybersecurity policy?

At minimum: which projects it covers, secure development practices, how vulnerabilities are reported, triaged, fixed and disclosed, a commitment to consider voluntary reporting under Article 15, how vulnerability information is shared with the community, and who answers authority requests. Article 24(1) requires the policy to be documented in a verifiable way.

Fix it without waiting for upstream

Steward work does not stop at policy: the projects you sustain and the products that integrate them both pull in other people's open source, and an actively exploited flaw in one of those dependencies can start a reporting clock on either side. Closing the gap between a fix existing and that fix shipping, in your stewarded releases and in your products, is the most direct way to keep reporting rare and short.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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

These demos show tools, not CRA compliance. You can download Safeguard and read the CLI documentation to try the same flows on a project you steward.

This first demo is a real CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repo, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan. For a stewarded library, this is the shape of step 6 in the tabletop: a fix prepared locally, reviewed by a maintainer, and only then released.

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

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. An OSPO that keeps release evidence for each stewarded project can run those scans on infrastructure it controls, alongside the release process.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. The Linux Foundation post notes OSPOs exploring agentic workflows for collecting component evidence, with human approval and traceable sources; choosing a narrow tool set per connection is how you keep that kind of assistant read only and reviewable.

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

Quick check

Sources

• Linux Foundation: How OSPOs Are Preparing Organizations for the EU Cyber Resilience Act (9 September 2026)
• Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal text on EUR-Lex
• European Commission: Cyber Resilience Act policy page
• European Commission: Cyber Resilience Act, Open source
• European Commission: Cyber Resilience Act, Reporting obligations
• European Commission: Summary of the Cyber Resilience Act legal text
• European Commission: Commission publishes new guidance to support timely CRA implementation (27 July 2026)
• European Commission: C(2026) 5252 Annex, Commission guidance on the application of the CRA (PDF)
• European Commission services: FAQs on the Cyber Resilience Act (PDF)
• OpenSSF: OSS Stewards Obligations Checklist
• OpenSSF: Linux Foundation CRA Stewards Playbook
• OpenSSF: CRA Brief Guide for Open Source Software Developers
• OpenChain Project: CRA Compliance Requirements and Checklist
• TODO Group OSPO Book, Chapter 5: Managing Open Source Security

Last reviewed: 23 October 2026. This is general information, not legal advice. Commission guidance is non-binding and may be updated; check the linked regulation and Commission pages for the current position.