Add organisation-wide security policy - #3
Conversation
This link is not accessible to the public, so I don't see much value in including it.
I believe we should more align with ORT's new AI policy and use an An you as a human being still need to add a |
sschuberth
left a comment
sschuberth
left a comment
There was a problem hiding this comment.
Regarding formatting, I'd prefer to stick to the "one sentence per line" rule for Markdown, as it avoids diff noise to due re-wrapping when making chances.
Also, shouldn't we also say something about about AI-generated security reports?
| ## 2. Definitions | ||
|
|
||
| * **Vulnerability**: a weakness in software or a service that can be | ||
| exploited to compromise confidentiality, integrity, or availability. |
There was a problem hiding this comment.
Is this supposed to be a generic definition, or a definition in the scope of this document? Because I believe vulnerabilities are not exploitable by definition.
There was a problem hiding this comment.
We don't necessarily fix vulnerabilities which cannot be exploited in our context. So the "can be exploited" is for that. In general, my understanding is that the CVD process, for which this stands for, is about vulnerabilities which can be exploited in the context, or potential context. Not sure, though: I'm thinking that there could be a theoretical new vulnerability, which cannot be now exploited, but could perhaps be exploited in the future. Thoughts?
There was a problem hiding this comment.
Maybe simply define another term here? Like "security issue" instead of "(exploitable) vulnerability"?
There was a problem hiding this comment.
I investigated this a bit. This definition comes from an ISO standard, but we don't follow it and its not public. I'm proposing a CRA definition that's essentially the same but can be publicly referred. I'll address this and your other comments in a force-push in a moment.
78a7cb9 to
4052d44
Compare
|
@sschuberth I tried to address all your comments |
Add the default SECURITY.md that GitHub shows on every repository in the organization without its own, and the detailed vulnerability handling policy it links to. Reports go to security@doubleopen.io. Assisted-by: Anthropic Claude Fable 5.1 Signed-off-by: Martin von Willebrand <martin.vonwillebrand@doubleopen.io>
4052d44 to
ec160db
Compare
2 participants
Adds the default SECURITY.md shown on every repository in the organisation without its own, and the detailed vulnerability handling policy it links to. Reports go to security@doubleopen.io.
These roughly follow the Eclipse Apoapsis examples: https://github.com/eclipse-apoapsis/.github/blob/main/SECURITY.md
The security policy is a bit different for sections 6 and 7, since we are a company running services and not a foundation hosting open source projects. Section 5 has the outside commitments.
Follow-ups: