[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [open-regulatory-compliance] Vulnerability reporting Re: CRA Standardisation request
|
Hi all,
Just dipping in - for me as a minor maintainer I can see that
there's almost certainly going to be a requirement to spend time
on this even if just to be a good opensource actor.
It also worries me what the (legal and other) ramifications of
opensource project stewards getting something wrong on this would
look like and what best practice should be.
We're out at Embedded World in coming weeks. Is there something
like a birds of a feather meeting being organised out there to
discuss?
KR, Alex
On 18/02/2025 09:15, Olle E. Johansson
via open-regulatory-compliance wrote:
Marta,
I think we need a meeting where we discuss how we think the
requirements on reporting affects Open Source and
if there’s a missing mechanism here. Do we need to get
engaged in coordinated disclosure and how?
Do we need to report anything to the ENISA or CSIRT and
how?
If commercial products downstream are certified - how will
this affect a project?
For all these issues I think we need to agree on something
to communicate to ENISA/Commission.
In the meeting we had there was also a discussion about
abandoned or half-abandoned projects. How do we handle
them if there’s a vulnerability - for a project with a
steward and projects without? CISA had a very generous
attitude
that they communicated in the meeting.
So there are a lot of issues to sort out in my point of
view.
/O
Hello all,
I've changed the thread title so that we can
distinguish this stream.
Following today's SIG meetings, what are the
points of concern of the EUCC today?
We have listed the massive coordinated
vulnerability disclosure between multiple projects
(aka log4j case). Anything else?
From my perspective, there's the whole
recommended delay timeline and of course it includes
all notifications and loops with the certification
authority. However IMO overall this is not worse
than the BSI document.
Kind regards,
Marta
Hi all,
the Commission stated last week that a
study by ENISA will soon be published on how
EUCC can work with the CRA.
Viele Grüße,
Best Regards,
Steffen Zimmermann
Industrial Security @ VDMA
…sent from my mobile phone, please
excuse any typos
On
Mon, Feb 17, 2025 at 9:25 AM Olle E.
Johansson <
oej@xxxxxxxxxx>
wrote:
Yes, the EUCC applies
to third party
certification, but it
mentions the CRA. Also
it makes sense to have
the vulnerability
reporting process the
same in both cases, as
there is no reason (IMO)
to make them different.
I think the requirements are
different. For certified
products (in this document)
there seems to me like there’s a
requirement to report all
vulnerabilities. For the rest of
products there’s a requirement
to report exploited
vulnerabilities. I have to read
this doc again to understand the
details, but there’s discussions
about re-certification. I
remember discussions with Enisa
a long time ago where they
clamed that all vulnerabilities
in an SBOM would be
non-compliance. The doc doesn’t
discuss VEX files where a vendor
can report their triage results
either.
Again, clarification would be
good. I may be totally wrong :-)
You're right, in the CC (Common
Criteria) scheme there's a need to
report vulnerabilities to the
certification issuer. There are also
expected timelines for various
severities. I find it also
interesting that they describe in
detail the process of confirmation
of a vulnerability: not everything
reported is considered a
vulnerability. This could be useful
as an example for the CRA-related
processes.
However, the general flow of the
process is what we see in security
processes typical to open source
projects.
One thing I'm missing in the EUCC
vs CRA is the clear mention of
notifying the upstream, if the issue
is in a different product.
Also, some open
source components with
their processes may (and
do) end up as components
of certified solutions.
Common requirement would
make the process easier
for everyone.
Yes, that’s a concern. How would
that affect the relationship
between the vendor and the
project?
<room for discussion>
This is something that is already
happening. CC certifications have
been there for years and of course
they include products with open
source components.
The innovation of the CRA is that
it forces reporting upstream. From
what I know, this is not the case
with CC.
Kind regards,
Marta
/O
Kind regards,
Marta
Note that this
does not apply to
all products
affected by the CRA,
only the small
percentage that are
in the classes
important and
critical and need
third party
certification.
/O
FYI: The
CISA Software
Acquisition
Guide
recommendations
for
vulnerability
management are
consistent
with this
latest
guidance from
Europe
(February
2025):
The holders of EUCC
certificates
should use the
following
standard for
the general
guidelines
related to
vulnerability
disclosure:
• ISO/IEC 29147:2018 Information technology -
Security
techniques -
Vulnerability
disclosure.
Here is
the CISA
Software
Acquisition
Guide language
that aligns
with this EUCC
guidance: (
https://cisa.gov/sag)
NIST SP 800-161r1 RA-5 and “NIST Guidance” as specified
in OMB
M-22-18, call for the issuance of
vulnerability
disclosure
reports (VDR)
as an
attestation
showing that a
software
supplier has
checked each
component in a
software
product SBOM
for
vulnerabilities
and reports
the status of
each
vulnerability
discovered, following recommendations for coordinate
vulnerability
disclosure
programs
contained in IEC
29147:2018. A VDR is a machine-readable
artifact and
is considered
a “product
centric”
artifact. A
VDR is issued
simultaneously
with a SBOM at
product
release and
remains online
as a living
document. It
is updated by
the software
supplier when
new
vulnerabilities
affect the
product to
which the VDR
is attesting.
This enables a
consumer to
know if the
software
product is
affected when
a new
vulnerability
is reported.
NOTE: NIST has renamed
“Vulnerability
Disclosure
Report” to
“Vulnerability
Advisory
Report” in SP
800-161r1-upd1
to align more
closely with
IEC 29147:2018
vernacular and
eliminate any
confusion with
a
“vulnerability
report” that
researchers
produce and
submit to
software
suppliers.
NIST VDR/VAR
are produced
by software
suppliers and
provided to
software
customers to
inform of any
vulnerabilities in a software product. NIST recommends that software
suppliers
ensure that
SBOM’s and
vulnerability
advisory
reports are
maintained and
aligned:
Enhancing Capabilities
-
Ensure that
third-party
suppliers
continuously
enrich SBOM
data with a
VAR.
-
Acquiring
entities
should develop
risk
management and
measurement
capabilities
to dynamically
monitor the
impacts of
SBOM-related
VARs.
Acquiring
organizations
should align
with asset
inventories
for further
risk exposure
and
criticality
calculations.[5]
Thanks,
Dick Brooks
<image007.png>
<image008.png>
<image009.png>
Active Member of
the CISA
Critical
Manufacturing
Sector,
Sector
Coordinating
Council – A
Public-Private
Partnership
Risk always
exists, but
trust must be
earned and
awarded.™
Tel: +1
978-696-1788
Hi all,
look here for the CRA SReq (not yet published):
Mit den besten Grüßen,
Steffen Zimmermann
Industrial Security @ VDMA
Yes,
Felipe
mentioned the
OSR was due to
be published
today.
{Terse?
Mobile! Typo?
Dictated!}
A
representative
from the
commission
said at FOSDEM
yesterday that
they hope for
the final
request to be
published this
week.
I
think he
mentioned it
is on the
agenda today
but I might
misremember
that part.
Hi
Steffen,
everyone,
yes, that's
the latest
draft that was
circulated in
December which
could be
commented on
until January
20. It also
said "This is
a formal
step to
endorse the
draft
standardisation
request, and
as such
modifications
are not
expected
during this
process." so I
don't expect
any
differences
but the final
one has not
been published
as far as I
can tell.
Cheers,
Lars
On Mon, Jan
27, 2025 at
3:42 PM Steffen
Zimmermann via
open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx>
wrote:
>
> Hi,
>
>
>
> find the
SReq here
(published in
December):
>
>
>
> https://draftable.com/compare/CUdwceoGvyYS
>
>
>
> Mit den
besten Grüßen,
>
>
>
> Steffen
Zimmermann
>
>
Industrial
Security @
VDMA
>
>
>
>
>
> Von:
open-regulatory-compliance
<open-regulatory-compliance-bounces@xxxxxxxxxxx>
Im Auftrag von
Tobie Langel
via
open-regulatory-compliance
> Gesendet:
Samstag, 25.
Januar 2025
14:44
> An: Open
Regulatory
Compliance
Working Group
<open-regulatory-compliance@xxxxxxxxxxx>
> Cc: Tobie
Langel <tobie@xxxxxxxxxxxxxx>
> Betreff:
Re:
[open-regulatory-compliance]
CRA
Standardisation
request
>
>
>
> Thanks
Lars,
>
>
>
> That
matches my
understanding
too: afaik,
things are
moving forward
but an updated
draft hasn't
been made
publicly
available nor
has the
finalized text
been
published.
>
>
>
> --tobie
>
>
>
> On Sat,
Jan 25, 2025
at 2:36 PM Lars
Francke via
open-regulatory-compliance
<open-regulatory-compliance@xxxxxxxxxxx>
wrote:
>
> I don't
have time to
go to all the
meetings and
read all the
documents but
from my
understanding
we (ESOs) had
until 20
January to
comment/vote
on the last
draft item.
>
> Some work
has already
been
distributed
between CEN
and ETSI, not
all of it is
clear yet as
far as I know.
Some experts
are still
missing for
some of the
vertical
standards I
think.
>
> But we
got to vote on
a few NWIs
already (New
Work Items): https://boss.cen.eu/reference-material/guidancedoc/pages/tcnewwi/
>
>
>
> I
honestly have
trouble
navigating the
whole process
still but the
summary is: No
final "SReq"
yet but it's
all going
according to
plan.
>
>
>
> Simon
Phipps via
open-regulatory-compliance
<open-regulatory-compliance@xxxxxxxxxxx>
schrieb am
Sa., 25. Jan.
2025, 14:17:
>
> As far as
I am aware it
has still not
actually been
finalised and
issued to the
ESOs, but
someone may
know better
than me.
>
>
>
> S.
>
>
>
>
>
> On Sat,
Jan 25, 2025
at 1:11 PM Andrew
Katz via
open-regulatory-compliance
<open-regulatory-compliance@xxxxxxxxxxx>
wrote:
>
> Hi All
>
>
>
> A quick
question: I’ve
managed to the
find the draft
standardisation request from the European Commission for the 41 (?)
standards
under the CRA.
Presumably
this text was
finalised at
around the
same time as
the Act was
published in
the OJ. I’ve
tried looking,
but have yet
to find it.
Does anyone
have a copy or
a link?
>
>
>
> This is
all I have: https://ec.europa.eu/docsroom/documents/58974
>
>
>
> All the
best
>
>
>
>
>
> Andrew
>
>
>
>
>
>
>
>
> Andrew
Katz
> Orcro
Limited
> +44 20
7170 5943
> +44 7970
835001
> orcro.co.uk
>
> 86-90 Paul Street, London, EC2A 4NE, UK
>
>
> Orcro
Limited is a
limited
company
registered in
England and
Wales under
Number
11173406.
Registered
office is c/o
Saffery, St
John’s Court,
Easton Street,
High Wycombe,
Buckinghamshire, England, HP11 1JX. VAT number: GB 289 7831 32. Orcro
Limited is not
regulated as a
law firm and
does not
provide legal
advice.
Individuals’
qualifications
are as set out
in their bio
page.
Reference to
an individual
as a lawyer,
solicitor or
paralegal does
not mean that
they are
acting in that
capacity as an
Orcro staff
member.
>
> Data
protection: we
process your
personal data
to keep in
touch with
you, to carry
out work for
you or your
organisation,
for internal
administration
(including
employment)
for regulatory
purposes and
for limited
marketing
purposes (for
which you can
require us to
stop at any
time). For
more
information
see https://orcro.co.uk/privacy-summary/ or
contact team@xxxxxxxxxxx
>
>
>
>
_______________________________________________
>
open-regulatory-compliance
mailing list
> open-regulatory-compliance@xxxxxxxxxxx
> To
unsubscribe
from this
list, visit https://accounts.eclipse.org
>
>
>
>
> --
>
> Simon
Phipps
>
>
Supporting
Software
Heritage at
ORC
>
> Meshed
Insights Ltd.
>
>
_______________________________________________
>
open-regulatory-compliance
mailing list
> open-regulatory-compliance@xxxxxxxxxxx
> To
unsubscribe
from this
list, visit https://accounts.eclipse.org
>
>
_______________________________________________
>
open-regulatory-compliance
mailing list
> open-regulatory-compliance@xxxxxxxxxxx
> To
unsubscribe
from this
list, visit https://accounts.eclipse.org
>
>
_______________________________________________
>
open-regulatory-compliance
mailing list
> open-regulatory-compliance@xxxxxxxxxxx
> To
unsubscribe
from this
list, visit https://accounts.eclipse.org
_______________________________________________
open-regulatory-compliance
mailing list
open-regulatory-compliance@xxxxxxxxxxx
To
unsubscribe
from this
list, visit https://accounts.eclipse.org
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from
this list, visit
https://accounts.eclipse.org
_______________________________________________
open-regulatory-compliance mailing
list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit
https://accounts.eclipse.org
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org