Re: [open-regulatory-compliance] Kicking off the CRA Attestations projec

["Salve J. Nilsen" <sjn@xxxxxxxxxxxx>]

Hei Mathias & all,


Here's my take on your 3 questions, with a nod to our conversation on
Monday. Thank you for reminding me of this! I haven't read many of the
other messages in this thread, so if any of my points resonate with
other's, please interpret this as a happy coincidence and my statement of
their support. :-)

I'll reply inline below.


On Thu, 23 Oct 2025, Mathias Schindler via open-regulatory-compliance wrote:
>
> 1. Regarding the due diligence obligations under Article 13(5), is the list
> of actions in Recital 34—such as checking conformity, reviewing update
> history, and scanning vulnerability databases—generally understood to
> represent the typical scope of a manufacturer's duty?

I think we should look at this first from a security professional's
perspective, then informed by the Manufacturer's risk assessment, and with
these in mind decide what requires the involvement someone outside the
Manufacturer's area of influence.

So let's start with what we mean with "Due Diligence".

1. What "Due Diligence" entails is "Pracicing the activities that maintain
Due Care effort."

2. What "Due Care" entails is "doing what a reasonable person would do in
a given situation."

(These definitions are from the «How to "Think like a Manager" for the
CISSP Exam» youtube presentation by Pete Zergers[1].)

So when a Manufacturer does Due Diligence, they need to have some
understanding of _all_ the pieces that are on the board. What this
actually entails, can be illustrated with a series of questions:

- What components do I depend on?
  - (full dependency graph)

- Who is in control of these components?
  - (ownership, licenses)

- Are these individuals capable and willing to assist us in an emergency?
  - (community responsiveness, policy documents, other leading indicators)

- What are our options for improveing immediate risks related to this?
  - (funding, forking, adoption, in-housing/vendoring, abandonment)

- What are our options for addressing long-term risks related to this?
  - (funding, community assistance, co-maintaineship)

- What are the actions we need to do during an incident?
  - (upstreaming fixes, coordinated disclosure)

- What are the actions we need to do to ensure compliance?
  - (correct metadata is made available upstream)

- What are the actions we need to do to ensure package ids are usable?
  - (correct extrinsic and/or intrinsic package identifies available)

etc. etc.

In short, for a Manufacturer, what is "Due Diligence" and "Due Care" for
any given component, may vary wildely depending on multiple factors - most
importantly the Manufacturer's risk assessment of their applications and
their dependencies.

On the other hand, we'll have to keep in mind that from the Maintainer and
Steward's perspective, they are likely to experience the full range of
requests - from "lightweight" interactions in the form of a friendly issue
raised, to "full autopsy security reviews" required by that one
Manufacturer who decided to make use of the component in some critical
code path.

So the Maintainer might as well prepare for the worst case - and so should
their Steward.


> 2.  Given that a manufacturer can always fulfill their Article 13(5) due
> diligence by conducting an internal assessment or by commissioning a
> private one from any third party, what is the justification for proposing
> to limit who gets to issue attestations under Article 25? This refers both
> to the proposals I heard in the room allowing an open source project to
> select who gets to issue article 25 attestations or limiting it to - for
> example - stewards.

There are a bunch of reasons, in my opinion:

By involving (upstream) component owners/maintainers/authors…

- …the cost of preforming due diligence on the component may be reduced by
  sharing this expense with other users of said component. (This requires
  a mediator/facilitator, which the Steward is well positioned to become.)

- …the TCO of a the consuming application is lowered, since there is
  less reason to fork, patch, adopt or vendor in this component if it
  continues to be maintained by upstream. (This matters when one depends
  on tens of thousands of components – something not uncommon!)

- …any fixes applied directly upstream reduce the need to manage and apply
  local (vendor) patches. This is especially useful regarding issues found
  during due diligence.

- …the Manufacturer can get access ot primary/leading indicators of
  long-term project health, instead of relying on lagging indicators like
  everyone else.

- …the Manufacturer can get guaranteed/attested-to-be-correct metadata
  required to avoid penalties in Article 64(4).

- …the Manufacturers may get assurances for the continued availability and
  responsiveness of the Maintainer in case of vulnerability discoveries or
  incidents.

Some, if not all of the above, require the cooperation of the Maintainer,
and possibly the facilitation of a Steward; and some of this information
can be witheld or services denied.

(Malapropos: Here, it's also worth underlining that some of the above
activities are _MIND-NUMBINGLY BORING_. Only the most twisted
self-flagellating ascetic subs would willingly go through a massive
security review on their own (unpaid, and non-refundable) time. Asking
anyone to so this unpaid should be interpreted as an insult of the gravest
kind, and be responded to proportionally. (HHOS ;-)))


> 3. Is an attestation issued as a voluntary security attestation under an
> article 25 system bound to the software alone or *also* to the recipient?
> For instance, if Manufacturer A gets an attestation for libfoo 0.9.6c, can
> Manufacturer B, who uses the exact same component, also use that
> attestation for their own due diligence (assuming for the purpose of this
> question that B learned of the existence of this attestation)? If the
> answer is 'no, it's recipient-bound,' could you help me understand what law
> or rule creates that restriction?

My recommendation is that an attestation is bound to the following
conditions:

0. A list of assurances, like the ones listed above…
1. …Related to a specific component, named and uniquely identified
2. …limited to a single specific versioned release of said component
3. …limited in duration, depending on the Maintainer's resources
4. …Addressed to the requesting Manufacturer, named and uniquely ID'd
5. …Signed and attested by the entities offering the assurance
6. …Verifiable by the Manufacturer, Market Authorities and other Auditors

I think the legal instrument most suited for the commercial
(Manufacturer's) end of this transaction, can be found in contract law.

This being in iterest of reducing cost to the Manufacturer, any work
required needs to be limited to the components that the Manufacturer
actually uses (which itself should be considered proprietary information,
and should be treated accordingly), and may contain instructions or
priorities stemming from the Manufacturer's risk assesment process. This
cost-saving measure screams for a contract, so let's assume we use this
also to set terms that are acceptable for the Steward (and by implication,
the Maintainer) too.

On the Maintainer's side of the Steward, I think it's necessary to assume
the Steward has NO LEVERAGE over the Maintainer's project, other than any
terms they come to agreement with. By default, I believe it's best to
assume the absolute minimum, as to avoid undue (and unpaid) impositions on
the Maintainer. I have some ideas here, but will leave them unsaid for
now. ;-)


I hope this was useful for someone.


With regards,


- Salve J. Nilsen (CPAN Security Group volunteer)

[1] https://youtu.be/vfC9OLsCqgk?si=wEEPz37lWjX0C_vI&t=144

-- 
#!/usr/bin/env perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':50,$'.#    <sjn@xxxxxx>
'3!=0"59,6!`%%P\0!1)46%!F.Q`%01,`'."\n"));eval "&{'@_'}";  __END__ is near! :)