Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [open-regulatory-compliance] Kicking off the CRA Attestations project

On Wed, Oct 29, 2025 at 22:46 Tobie Langel <tobie@xxxxxxxxxxxxxx> wrote:
On Wed, Oct 29, 2025 at 10:10 PM <aeva.black@xxxxxxxxxxxxxxxxxxxxxx> wrote:
On Tue, 2025-10-28 at 22:07 +0100, Tobie Langel via open-regulatory-compliance
wrote:
>
> When it comes to scale (and implementation), I think the main thing to
> compare it to is CE-marking. While CE-marking itself doesn't entirely resolve
> your due diligence requirements, it greatly simplifies them. Unsurprisingly,
> checking for CE-marking is the first thing that the horizontal standards tell
> you to do. In the words of the Commission, security attestations are to be
> thought of as a near equivalent to the CE-mark, bringing similar benefits to
> the due diligence obligations of manufacturers as the CE-mark does. They
> should therefore be relatively similar in terms of implementation.
>

> Much like third regular products self-assess to apply the CE mark, so should
> most FOSS components.

> The requirements of self-assessment for security attestations should be lower
> but not too far away from what is required of manufacturers to self-assess.

Broadly speaking, I agree, however I believe the commission is looking for
attestations to come in two tiers. I called these "light" and "heavy" /
"process-based" and "outcome-based" in my slides last week. In my understanding
of this, the latter is closer to a CE mark than the former.

These would apply, respectively, to:
- open source projects that are relatively low complexity (e.g., libraries),
which have litle connection to the type of final product they might be used in,
and which can demonstrate the conformity of their development process to
established security practices (e.g., branch protections, code reviews,
vulnerability handling, developer documentation).
- open source projects that are very nearly product-like, including those which
could self-apply an Annex III Vertical Standard if given sufficient support.

Interesting. That's essentially what I was suggesting should happen on a timescale (first the 'light'-version, then the 'heavy' one), but flipped on a criticality-scale instead.

Either way, this requires that the Commission publishes guidance stating that "light" attestations are good-enough for due diligence of FOSS libraries (and ideally CEN revising PT1 to say as much).

This would be an ideal outcome.

Worst case scenario, if my predictions are correct and the 'heavy' model becomes the norm in the next iteration of the legislation, we'll have experience with it already, it will have been designed with open source ecosystem's needs in mind, and we'll get a chance to revise it then.

The Secure Software-Lifecycle for OSS guidelines (TR-03185-2) that the BSI just released seem like a fairly interesting candidate for the light version of the attestation Aeva was describing above: 

This seems like something the Commission could get onboard with as sufficient for due diligence given who’s behind it. 

I’m unsure how valuable attesting of such information would be though, or what would prevent a third party from issuing them. 

—tobie

Back to the top