03.md -> Adding a proposal to how due diligence can be implemented - #18
03.md -> Adding a proposal to how due diligence can be implemented#18jrico-eclipse wants to merge 1 commit into
Conversation
First proposal, if the community agrees with it, I'll propose to go frther and start discussing the key assets that can help as well as the role of voluntary security attestations. Signed-off-by: Juan <137221298+jrico-eclipse@users.noreply.github.com>
jrico-eclipse
changed the title
openrefactorymunawar
left a comment
openrefactorymunawar
left a comment
There was a problem hiding this comment.
A few suggestions and minor typos.
| | Evaluation Criteria | Due Diligence Check | | ||
| | :--- | :--- | | ||
| | **Cybersecurity Policy** | The declared cybersecurity policy of a project and the fact sustaining the project execution of the policy is a key resource to understand the support manufacturers will get to comply with the CRA obligatinos. Reviewing repository history for security contact response times, CVD compliance and checking the `SECURITY.md` deliver useful insights that helps to evaluate the suitability of a component. | | ||
| | **Governance & Health** | The cybersecurity policy is a key element, but it is not enough to asses a component. The governance, how decisions are made and by whom as well as the contribution policy, usually set in the `CONTRIBUTING.md`, are also relevant to decide what responsibilities and role will be taken by the manufacturers. | |
| ## What has to be checked No newline at end of file | ||
| | Evaluation Criteria | Due Diligence Check | | ||
| | :--- | :--- | | ||
| | **Cybersecurity Policy** | The declared cybersecurity policy of a project and the fact sustaining the project execution of the policy is a key resource to understand the support manufacturers will get to comply with the CRA obligatinos. Reviewing repository history for security contact response times, CVD compliance and checking the `SECURITY.md` deliver useful insights that helps to evaluate the suitability of a component. | |
There was a problem hiding this comment.
obligatinos -> obligations
| Because open source components vary widely in both architectural impact and system privileges, due diligence under the Cyber Resilience Act cannot be executed as a uniform, one-size-fits-all audit. Article 13(5) expects manufacturers to establish a risk-proportional evaluation model that scales scrutiny based on the component's exposure, access level, and the risk classification of the parent product. By categorizing dependencies into distinct operational tiers, organizations can strategically deploy deep technical resources where risk is highest. | ||
|
|
||
| ```text | ||
| ┌─────────────────────────────────────┐ |
There was a problem hiding this comment.
Since the section is titled "Levels of die diligence", perhaps we need to add to the table how the levels ramp up from Level 1 to Level 3. Now we are only listing components that fall in each category. Having the definition of what extra things need to be checked help us appreciate better how the levels work.
| # What and how to record due diligence, evidence | ||
|
|
||
| Article 13(5) mandates that due diligence be **risk-proportional**. Integrating components with active **Article 25 Voluntary Security Attestations** allows manufacturers to accelerate evaluation by establishing an immediate baseline of trust, shifting internal audit resources toward high-risk or un-attested dependencies. | ||
| ## Levels of due diligence |
There was a problem hiding this comment.
This is not about the recordation requirement. We should merge this content to #12 , move to Chapter 1 and remove from here (that is Chapter 3 - What and how to record due diligence, evidence )
There was a problem hiding this comment.
Totally fine with this, I just wanted to mention that attestations are part of the evidences.
|
|
||
| Article 13(5) mandates that due diligence be **risk-proportional**. Integrating components with active **Article 25 Voluntary Security Attestations** allows manufacturers to accelerate evaluation by establishing an immediate baseline of trust, shifting internal audit resources toward high-risk or un-attested dependencies. | ||
| ## Levels of due diligence | ||
| Because open source components vary widely in both architectural impact and system privileges, due diligence under the Cyber Resilience Act cannot be executed as a uniform, one-size-fits-all audit. Article 13(5) expects manufacturers to establish a risk-proportional evaluation model that scales scrutiny based on the component's exposure, access level, and the risk classification of the parent product. By categorizing dependencies into distinct operational tiers, organizations can strategically deploy deep technical resources where risk is highest. |
There was a problem hiding this comment.
I do not think that due diligence will scale if there are different levels based on the product criticality and how the components are integrated to the product. All of these require manual evaluation.
There was a problem hiding this comment.
@CsatariGergely I think this is a good point to discuss in the meeting, WDYT?
There was a problem hiding this comment.
Uh-oh, sorry I've just seen this. Let's put this topic to the agenda of the next meeting.
| When evaluating a third-party open source component prior to integration and continuously throughout its lifecycle, manufacturers must audit four core criteria. The table below illustrates how to satisfy or streamline these requirements: | ||
|
|
||
| ## What has to be checked No newline at end of file | ||
| | Evaluation Criteria | Due Diligence Check | |
There was a problem hiding this comment.
#12 is already about this. We should merge this content to there.
| Article 13(5) mandates that due diligence be **risk-proportional**. Integrating components with active **Article 25 Voluntary Security Attestations** allows manufacturers to accelerate evaluation by establishing an immediate baseline of trust, shifting internal audit resources toward high-risk or un-attested dependencies. | ||
| ## Levels of due diligence | ||
| Because open source components vary widely in both architectural impact and system privileges, due diligence under the Cyber Resilience Act cannot be executed as a uniform, one-size-fits-all audit. Article 13(5) expects manufacturers to establish a risk-proportional evaluation model that scales scrutiny based on the component's exposure, access level, and the risk classification of the parent product. By categorizing dependencies into distinct operational tiers, organizations can strategically deploy deep technical resources where risk is highest. | ||
|
|
There was a problem hiding this comment.
Given that the security levels as they are depend on "use case" and a product/assessment specific, with verticals following a few distinct structures for them even, I'm not sure three strict security levels here are a great idea?
I might be better to note that level of due diligence is a general function of the use case - meaning the likelihood and potential impact of threats to the product. One could of course use the examples in the table below, but I would be careful about being too formal with them and breaking them up into risk levels that may vary by use case as well as type of component.
|
@jrico-eclipse will create a pr against chapter one with the same content. |
4 participants
First proposal, if the community agrees with it, I'll propose to go further and start discussing the key assets that can help as well as the role of voluntary security attestations.