Example properties to be checked for due diligence - #12
Conversation
Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
CsatariGergely
left a comment
CsatariGergely
left a comment
There was a problem hiding this comment.
Change "due diligence" to "13(5) due diligence".
Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
| ### Vulnerability handling | ||
|
|
||
| Naturally it is a critical factor of due diligence how the projects handle vulnerabilities. | ||
|
|
There was a problem hiding this comment.
Existing Vulnerabilities Due diligence should include a check for any existing unpatched vulnerabilities.
There was a problem hiding this comment.
In the due diligence I would rather check if the vulnerabilities are not neglected and not just the existence of the vulnerabilities. I think the important factor here is if the vulnerabilities are addressed and not if they exist in the moment of integration.
There was a problem hiding this comment.
This is addressed in the Vulnerability handling: section.
As requested on the meeting on 2026.08.27 Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
Fixed in 3967ef4 |
Co-authored-by: Georg Kunz <georg.kunz@ericsson.com> Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
gkunz
left a comment
gkunz
left a comment
There was a problem hiding this comment.
Thanks for addressing my previous comments. Looks good. Let's get this in and iterate from there.
| the risk of introducing vulnerabilities. | ||
|
|
||
| **Regular releases:** The project should have regular releases. In this way the vulnerability fixes of | ||
| the project are consumable by the products integrating the project. |
There was a problem hiding this comment.
Looking for regular releases may be a project health indicator, but could be misleading in the cases where the project is done. In those cases, any lacking releases of the software isn't really indicative of the project health.
There was a problem hiding this comment.
Correct, thanks. I've tried to clarify this in 83612fb
Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
sjn
left a comment
sjn
left a comment
There was a problem hiding this comment.
Shared a few more perspectives inline. Hope this helps!
| This chapter collects a selection of example properties what can be checked as the [article 13(5)][article-13] due | ||
| diligence. |
There was a problem hiding this comment.
Maybe expand a little on this?
This list is by no means complete. Performing sufficient due diligence is very likely to require additional considerations taking into account the specific circumstances and ways of working of the particular FOSS project. Furthermore, due diligence of open source projects should also include considerations of how the manufacturer can contribute to address any issues discovered in this process.
| The CRA introduces the concept of a voluntary security attestation as a way for open source communities to support the | ||
| due diligence of the projects. Such a voluntary attestation could provide the necessary data about the | ||
| project properties identified in this chapter to carry out [article 13(5)][article-13] due diligence. Currently, the | ||
| concept is still under development, therefore requiring manufacturers to assess individual properties | ||
| and characteristics of open source projects, as exemplified in the following sections. |
There was a problem hiding this comment.
My reading is that the voluntary security attestations are meant to support the manufacturer's due diligence obligations, by offering them a an option to procure these attestations in lieu of performing the due diligence process themselves. VSAs are therefore a cost-saving measure for manufacturers.
Not entirely sure how to get this point across here, though.
The CRA introduces the concept of a voluntary security attestation as a way for open source communities to support the manufacturer's due diligence
of the projectsobligations. Such a voluntary attestation could provide the necessary data and assurances about the project properties identified in this chapter to carry out [article 13(5)][article-13] due diligence. Currently, the concept is still under development, therefore requiring manufacturers to assess individual properties and characteristics of open source projects, as exemplified in the following sections.
| and gitlab.com). Another reason can be that a developer or a set of developers just would like to | ||
| drive the project to a different direction or would like to experiment with the technology. When | ||
| integrating open source components the source of these components should be always the major upstream | ||
| and not an undermaintained fork. |
There was a problem hiding this comment.
This may be a reasonable "base" recommendation, though maybe a little misleading. The circumstances of a fork may be also be due to governance or licensing issues, and depending on the technical and legal needs of the manufacturer may follow along with the forked community.
As for "Project identity and authenticity" - the project's supporting Steward organization should be a good entity to turn to in cases where the is a question about identity.
| ### Development practices | ||
|
|
||
| Development practices of the integrated components are a critial part of [article 13(5)][article-13] due diligence. The | ||
| correct development practices ensure that the code of the component is always peer reviewed and tested. |
There was a problem hiding this comment.
Assessing secure development practices are a good basis for a conversation about how to improve these, but a manufacturer may quickly find out that they are not in a position to impose any specific ones, or to decide what is the "correct" one for each project. Furthermore, good secure development practices don't just consider whether peer review and testing has been performed, but also considers secure design, access to necessary competence and resources, and takes steps that these are sufficiently taken care of before any security incidents or vulnerabilities happen.
| Naturally it is a critical factor of [article 13(5)][article-13] due diligence how the projects handle vulnerabilities. | ||
|
|
||
| **SECURITY.md:** The project should have a `SECURITY.md` or similar file which describes the security | ||
| and vulnerability handling policy of the project, including for instance how users can report vulnerabilities |
There was a problem hiding this comment.
…report vulnerabilities in confidence.
Being able to report vulnerabilities privately is a very important basic requirement, as any public mention (including in comments in a public issue tracker, or in a pull request) is considered a publication of the vulnerability. In coordinated vulnerability disclosure processes, any public mention of a vulnerability is a signal that there disclosure process is not coordinated any more, triggering a full publication.
| and which branches and releases are supported (i.e., receive fixes). | ||
|
|
||
| **Vulnerability handling:** The project should not neglect vulnerabilities. The reported | ||
| vulnerabilities should be addressed in a timely manner. |
There was a problem hiding this comment.
In a coordinated vulnerability disclosure process, any considerations about whether a vulnerability has been handled, is not evident until after publication. This may imply that certain vulnerabilities aren't made public for some reason (e.g. the reported vulnerability is actually a configuration error), or the vulnerability may not be possible to be addressed in a "timely manner" due to a combination of the complexity and severity of the issue.
Can we add at least a simple caveat here? E.g.
On a long-term perspective, the project should not […]
5 participants
Adding the seed for chapter 1.2 about a set of example properties what could be checked for due diligence.