diff mbox series

[isar-cip-core,RFC] Add security policy

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

Commit Message

Jan Kiszka Jan. 15, 2025, 6:21 p.m. UTC
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.

@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

Comments

Jan Kiszka Jan. 17, 2025, 9:25 a.m. UTC | #1
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.
Kazuhiro Hayashi Jan. 27, 2025, 9:36 a.m. UTC | #2
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 mbox series

Patch

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.