Message ID | 1086822b-1cd7-4424-a1d3-5ae0ce8371ad@siemens.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [isar-cip-core,RFC] Add security policy | expand |
On 15.01.25 19:21, Jan Kiszka wrote: > From: Jan Kiszka <jan.kiszka@siemens.com> > > Try to define isar-cip-core's security context and what is considered in > scope. Furthermore define the reporting process options and our handling > of reports. > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > --- > > Kazu, are you fine with being a second direct contact? At least as long > as we do not know your successor as WG chair. > > There is one TODO left: reference to a reporting procedure for our CIP > kernel. The kernel WG will discuss this soon. > We discussed that yesterday in the IRC meeting, and a possibly common solution for all CIP subprojects could be to create a private security@lists.cip-project.org list, provided we can configure it to permit postings from non-members. To be discussed in the next TCP meeting, I would say. Jan > @all: Please provide feedback if this is accurate and sufficient. I > won't merge this soon, at least not before the next CIP Core WG and TSC > meetings. > > SECURITY.md | 47 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 47 insertions(+) > create mode 100644 SECURITY.md > > diff --git a/SECURITY.md b/SECURITY.md > new file mode 100644 > index 00000000..60619a7d > --- /dev/null > +++ b/SECURITY.md > @@ -0,0 +1,47 @@ > +# Security Policy > + > +The Civil Infrastructure Project takes the security of its code seriously. If > +you think you have found a security vulnerability, please read the next > +sections and follow the instructions to report your finding. > + > +## Security Context > + > +Open source software can be used in various contexts that may go far beyond > +what it was originally designed and also secured for. Therefore, we describe > +here how the CIP Core integration layer is currently expected to be used in > +security-sensitive scenarios and what aspects are covered elsewhere. > + > +The isar-cip-core layer provides several recipes and configurations to build > +Debian packages, and to install and configure them to create bootable images. > +Not all configurations have security in scope, and downstream integrations may > +further modify the security properties of isar-cip-core deliverables. The CIP > +project considers security bugs in scope for addressing via isar-cip-core: > + > + - issues in on-device logic generated by recipes or scripts > + (e.g. initramfs hooks) > + - issues imported via hard-coded versions of external dependencies > + (e.g. SWUpdate) > + - incomplete, incorrect or misleading integration guidelines for > + security-sensitive recipes and configurations > + > +Not in scope are: > + > + - issues of upstream Debian packages (please report to Debian directly) > + - issues of CIP kernels (handled via the CIP kernel process, TODO:reference!) > + > +However as there remain grey areas, do not hesitate to open a report for > +isar-cip-core if you are unsure whether a finding is or is not in scope for > +this project. CIP maintainers will help clarifying the situation then. > + > +## Reporting a Vulnerability > + > +Please DO NOT report any potential security vulnerability via a public channel > +(mailing list, gitlab issue etc.). Instead, create a **confidential** issue via > +https://gitlab.com/cip-project/cip-core/isar-cip-core/-/issues/new?issue[confidential]=true > +or contact jan.kiszka@siemens.com and kazuhiro3.hayashi@toshiba.co.jp via email > +directly. Please provide a detailed description of the issue, the steps to > +reproduce it, the affected versions and, if already available, a proposal for a > +fix. You should receive a response within 5 working days. If the issue is > +confirmed as a vulnerability by us, we will request a CVE for it, publish a > +security advisory via the project's channels and give credits for your report > +if desired. This project follows a 90 day disclosure timeline.
Hello Jan, Sorry for my late reply. > > Kazu, are you fine with being a second direct contact? At least as long > > as we do not know your successor as WG chair. Yes, it's OK if needed. In that case, I'll propose to change it once the WG chair migration will be completed :) but... > We discussed that yesterday in the IRC meeting, and a possibly common > solution for all CIP subprojects could be to create a private > security@lists.cip-project.org list, provided we can configure it to > permit postings from non-members. To be discussed in the next TCP > meeting, I would say. now you prefer to use this common list if possible? I also agree on using such common recipient to share the information with members immediately. Kazu
diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 00000000..60619a7d --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,47 @@ +# Security Policy + +The Civil Infrastructure Project takes the security of its code seriously. If +you think you have found a security vulnerability, please read the next +sections and follow the instructions to report your finding. + +## Security Context + +Open source software can be used in various contexts that may go far beyond +what it was originally designed and also secured for. Therefore, we describe +here how the CIP Core integration layer is currently expected to be used in +security-sensitive scenarios and what aspects are covered elsewhere. + +The isar-cip-core layer provides several recipes and configurations to build +Debian packages, and to install and configure them to create bootable images. +Not all configurations have security in scope, and downstream integrations may +further modify the security properties of isar-cip-core deliverables. The CIP +project considers security bugs in scope for addressing via isar-cip-core: + + - issues in on-device logic generated by recipes or scripts + (e.g. initramfs hooks) + - issues imported via hard-coded versions of external dependencies + (e.g. SWUpdate) + - incomplete, incorrect or misleading integration guidelines for + security-sensitive recipes and configurations + +Not in scope are: + + - issues of upstream Debian packages (please report to Debian directly) + - issues of CIP kernels (handled via the CIP kernel process, TODO:reference!) + +However as there remain grey areas, do not hesitate to open a report for +isar-cip-core if you are unsure whether a finding is or is not in scope for +this project. CIP maintainers will help clarifying the situation then. + +## Reporting a Vulnerability + +Please DO NOT report any potential security vulnerability via a public channel +(mailing list, gitlab issue etc.). Instead, create a **confidential** issue via +https://gitlab.com/cip-project/cip-core/isar-cip-core/-/issues/new?issue[confidential]=true +or contact jan.kiszka@siemens.com and kazuhiro3.hayashi@toshiba.co.jp via email +directly. Please provide a detailed description of the issue, the steps to +reproduce it, the affected versions and, if already available, a proposal for a +fix. You should receive a response within 5 working days. If the issue is +confirmed as a vulnerability by us, we will request a CVE for it, publish a +security advisory via the project's channels and give credits for your report +if desired. This project follows a 90 day disclosure timeline.