forked from yoctoproject/cve-cna-open-letter
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathcve-cna-open-letter.txt
195 lines (101 loc) · 4.99 KB
/
cve-cna-open-letter.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
An open letter to the CVE Project and CNAs
==========================================
Security and vulnerability handling in software is of ever increasing
importance. Recent events have adversely affected many project's ability
to identify and ensure these issues are addressed in a timely manner.
This is extremely worrying.
Most realistic ways of using CVE data involve a machine readable way of
knowing which software component is affected and which versions. Until
recently many of us were relying not on the CVE project's data but on
the NVD data that added that information.
The CVE JSON version 5 format
(https://cveproject.github.io/cve-schema/schema/v5.0/docs/) is a significant
improvement as it includes product and vendor names directly, and supports
version constraints although they are not mandatory.
We would like to ask that:
* machine readable affected version ranges become strongly encouraged
(ideally mandatory) for new CVEs
* it becomes easy for CNAs to update older CVEs to include the machine
readable product and vendor names and add version information
* CNAs make sure they follow the same format when entering the machine
readable data, so that consumers can create programs handling this
data in an unified way
Current collection forms do not require version information and the
importance of it is easily overlooked. They could warn if it isn’t present
for example.
For older CVEs in particular there is a wealth of version information in
NIST’s NVD. Finding a way to extend older CVE entries with this (and other)
information would help everyone.
Processes/tooling to easily allow CNAs to adopt enhancements to CVEs would
also encourage improving the data, ideally as easy as something like a
GitHub pull request.
We, as projects that need to respond to security issues, could all do things
in our own ways. Many of us have open source backgrounds and realise the
power of collaboration and would much prefer to work together and build
something none of us alone could achieve. We need the tools, processes
and core support from the CVE project to make it happen.
In order to show the level of support for this, this 'open letter' is being
shared around between projects and we're accepting pull requests to add
signatures from both individuals and suitable project/company representatives.
Signed:
Richard Purdie <[email protected]>
(Yocto Project Architect, TSC Chair and Linux Foundation Fellow)
on behalf of Yocto Project and OpenEmbedded
Ross Burton <[email protected]>
Yocto Project TSC member, Arm Ltd
Marta Rybczynska <[email protected]>
Yocto Project Security Team Member
also signed "An Open Letter from Cybersecurity Professionals to the U.S. Congress and Secretary of Commerce
A cybersecurity crisis in waiting: On the Need to Restore and Enhance Operations with the National Vulnerability Database"
https://docs.google.com/document/d/1y6JXhh52b1OMxLMQyl_WH0R2-85iYEBzjSm_fhv8-GY/edit
Alex Stewart <[email protected]>
Lead Distro Maintainer, NI LinuxRT
NI, Emerson Electric
Jerome Oufella <[email protected]>
VP Technologies, Savoir-faire Linux, Inc.
Maxin John <[email protected]>
Software Engineer, GE Healthcare Finland Oy
Thomas Roos <[email protected]>
meta-aws, yocto, embedded linux @ AWS
Ricardo Salveti <[email protected]>
Principal Engineer, Foundries.io
Thomas Rini <[email protected]>
Chief Custodian of Das U-Boot, VP of Engineering at Konsulko Group
Esben Haabendal <[email protected]>
Director, Geanix ApS
Jose Quaresma <[email protected]>
Embedded Linux Engineer, Foundries.io
Alexander Kanavin <[email protected]>
Yocto contributor, openembedded-core maintainer (one of)
Trevor Gamblin <[email protected]>
Yocto contributor, Patchtest maintainer
Louis Rannou <[email protected]>
Yocto Project contributor, Syslinbit
Leonardo Held <[email protected]>
Embedded Linux Engineer, Toradex
Yoann Congal <[email protected]>
Yocto Project contributor, Tech expert @ Smile ECS
Thomas Perrot <[email protected]>
Embedded Linux Engineer, Bootlin
Adrian Freihofer <[email protected]>
Embedded Linux Engineer, Siemens
Matthias Klein <[email protected]>
Embedded Linux Engineer, optiMEAS
Fabien Lehoussel <[email protected]>
Tech Manager @ Smile ECS
Vincent Jourdon <[email protected]>
COO Embedded Software @ Smile ECS
Piotr Buliński <[email protected]>
Security Solutions Architect, C89
Paul Goulpié <[email protected]>
Tech expert @ Smile ECS
Ayoub Zaki <[email protected]>
Principal Consultant Owner, Embetrix Embedded Systems Solutions
Daiane Angolini <[email protected]>
Embedded Linux Engineer, Foundries.io
Sreejith Naarakathil <[email protected]>
Chief Evangelist, GNUSFAAS AB
Fabien Thomas <[email protected]>
Tech Manager @ Smile ECS
[please separate signatures with 3 empty lines and leave 3 empty lines above this
text after the signature to make git merge conflicts easier]