[isar-cip-core v1 0/3] Enable CVE check in isar-cip-core CI

[isar-cip-core v1 0/3] Enable CVE check in isar-cip-core CI

[Sai.Sathujoda]

From: Sai Sathujoda <Sai.Sathujoda@toshiba-tsip.com>

This series of patches enables CVE check in isar-cip-core CI by extracting
the latest dpkg-status files of deployed targets in aws s3 bucket. A weekly
scheduled pipeline runs a cve-checks job which generates CVE reports of respective
targets by using the cve_checker.py script in debian-cve-checker repository [1].

[1] https://gitlab.com/cip-playground/debian-cve-checker

Sai Sathujoda (3):
  .gitlab-ci.yml: Add cve-check stage in CI
  scripts/deploy-cip-core.sh: Upload dpkg-status file to aws s3 bucket
  scripts/run-cve-checks.sh: Add script to generate CVE report

 .gitlab-ci.yml             | 12 +++++++++++-
 scripts/deploy-cip-core.sh | 15 ++++++++++++++
 scripts/run-cve-checks.sh  | 40 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 66 insertions(+), 1 deletion(-)
 create mode 100755 scripts/run-cve-checks.sh

-- 
2.30.2

[isar-cip-core v1 1/3] .gitlab-ci.yml: Add cve-check stage in CI

[Sai.Sathujoda]

From: Sai Sathujoda <Sai.Sathujoda@toshiba-tsip.com>

The cve-check uses the dpkg-status file to get the latest CVE
report using the cve_checker.py script in debian-cve-checker
container. The dpkg-status file will also be deployed to aws s3
bucket along with the targets whose deployment is enabled.

Signed-off-by: Sai Sathujoda <Sai.Sathujoda@toshiba-tsip.com>
---
 .gitlab-ci.yml | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 1de6570..c838a81 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -29,6 +29,7 @@ variables:
 stages:
   - build
   - test
+  - cve-check
 
 default:
   before_script:
@@ -48,6 +49,7 @@ default:
     - large
   variables:
     base_yaml: "kas-cip.yml:kas/board/${target}.yml"
+    dpkg_status: "cip-core-image-*.dpkg_status"
   script:
     - if [ "${use_rt}" = "enable" ]; then base_yaml="${base_yaml}:kas/opt/rt.yml"; fi
     - if [ "${extension}" != "none" ]; then base_yaml="${base_yaml}:kas/opt/${extension}.yml"; fi
@@ -60,9 +62,17 @@ default:
     - if [ "${encrypt}" = "enable" ]; then base_yaml="${base_yaml}:kas/opt/encrypt-partitions.yml"; fi
     - echo "Building ${base_yaml}"
     - kas build ${base_yaml}
-    - if [ "${deploy}" = "enable" ]; then scripts/deploy-cip-core.sh ${release} ${target} ${extension} ${dtb} ${CI_COMMIT_REF_SLUG}; fi
+    - if [ "${deploy}" = "enable" ]; then scripts/deploy-cip-core.sh ${release} ${target} ${extension} ${dtb} ${CI_COMMIT_REF_SLUG} ${dpkg_status}; fi
     - if [ "${deploy_kernelci}" = "enable" ]; then scripts/deploy-kernelci.py ${release} ${target} ${extension} ${dtb}; fi
 
+cve-checks:
+  stage: cve-check
+  image: registry.gitlab.com/cip-playground/debian-cve-checker:latest
+  script:
+    - scripts/run-cve-checks.sh
+  rules:
+    - if: $CI_PIPELINE_SOURCE == "schedule" && $CI_JOB_NAME == "cve-checks"
+
 # base image
 build:simatic-ipc227e-base:
   extends:
-- 
2.30.2

[isar-cip-core v1 2/3] scripts/deploy-cip-core.sh: Upload dpkg-status file to aws s3 bucket

[Sai.Sathujoda]

From: Sai Sathujoda <Sai.Sathujoda@toshiba-tsip.com>

For every build job executed in CI, the dpkg-status file shall be uploaded
to a respective directory in aws s3 bucket.

Signed-off-by: Sai Sathujoda <Sai.Sathujoda@toshiba-tsip.com>
---
 scripts/deploy-cip-core.sh | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/scripts/deploy-cip-core.sh b/scripts/deploy-cip-core.sh
index 5855acb..834ba8e 100755
--- a/scripts/deploy-cip-core.sh
+++ b/scripts/deploy-cip-core.sh
@@ -15,6 +15,7 @@ TARGET=$2
 EXTENSION=$3
 DTB=$4
 REF=$5
+DPKG_STATUS=$6
 
 BASE_FILENAME=cip-core-image-cip-core-$RELEASE-$TARGET
 if [ "${EXTENSION}" != "none" ]; then
@@ -53,3 +54,17 @@ else
 		aws s3 cp --no-progress --acl public-read build/tmp/deploy/images/*/"$DTB" "${S3_TARGET}"
 	fi
 fi
+
+# Deploy the dpkg status file (/var/lib/dpkg/status) to AWS for the CIP CVE checker (cip-core-sec)
+# to periodically extract and report pending CVEs.
+# * CI builds will override the previous dpkg status file
+# * Released images will contain the commit_id in the file name, and will not be automatically overriden
+#   * they have to be signed and released separately from the CI
+# * CVE checks will only scan the latest builds, and the released images
+# * AWS S3 bucket structure
+#   * download.cip-project.org/cip-core/cve-checks/
+#     * dpkg-status: folder to store the dpkg status files generated by the CI and released images
+#     * cve-reports: folder to store the cve-reports generated from the dpkg status files
+#       * they can be linked from the release website
+DPKG_STATUS_FILENAME=${CI_JOB_NAME#build:}.dpkg_status
+aws s3 cp --no-progress build/tmp/deploy/images/$TARGET/$DPKG_STATUS s3://download.cip-project.org/cip-core/cve-checks/dpkg-status/$DPKG_STATUS_FILENAME
-- 
2.30.2

[isar-cip-core v1 3/3] scripts/run-cve-checks.sh: Add script to generate CVE report

[Sai.Sathujoda]

From: Sai Sathujoda <Sai.Sathujoda@toshiba-tsip.com>

This script will extract latest dpkg-status files for all the deployed
targets and generate their CVE reports using the cve_checker.py script in
[1] and these report shall be uploaded back to cve-reports sub-directory
under cip-project.org in the s3 bucket.

[1] https://gitlab.com/cip-playground/debian-cve-checker

Signed-off-by: Sai Sathujoda <Sai.Sathujoda@toshiba-tsip.com>
---
 scripts/run-cve-checks.sh | 40 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)
 create mode 100755 scripts/run-cve-checks.sh

diff --git a/scripts/run-cve-checks.sh b/scripts/run-cve-checks.sh
new file mode 100755
index 0000000..a655151
--- /dev/null
+++ b/scripts/run-cve-checks.sh
@@ -0,0 +1,40 @@
+#!/bin/sh
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Toshiba Corp., 2020
+#
+# Authors:
+#  Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
+#
+# SPDX-License-Identifier: MIT
+#
+
+# This script is used in .gitlab-ci.yml to create
+# CVE reports in CSV format for each build target.
+# It uses the dpkg status files generated during
+# the build stages and saved as gitlab-ci artifacts.
+
+set -e
+
+# Install AWS CLI
+if ! which aws 2>&1 >/dev/null; then
+	echo "Installing awscli..."
+	apt update
+	apt install -y python3-wheel
+	apt install -y awscli
+fi
+
+# Retrieve the latest dpkg status files from AWS
+aws s3 cp --no-progress --recursive s3://download.cip-project.org/cip-core/cve-checks/dpkg-status/ ./
+
+# Create new CVE reports
+mkdir cve-reports
+for i in *.dpkg_status; do
+	echo "Checking $i"
+	filename=${i%.dpkg_status}
+	cve_checker.py --status $i --output ./cve-reports/$filename.csv
+done
+
+# Synchronize the CVE reports to AWS (it will delete old reports)
+aws s3 sync --no-progress --delete --acl public-read cve-reports s3://download.cip-project.org/cip-core/cve-checks/cve-reports
-- 
2.30.2

Re: [isar-cip-core v1 0/3] Enable CVE check in isar-cip-core CI

[Jan Kiszka]

On 22.11.23 15:01, Sai.Sathujoda@toshiba-tsip.com wrote:
> From: Sai Sathujoda <Sai.Sathujoda@toshiba-tsip.com>
> 
> This series of patches enables CVE check in isar-cip-core CI by extracting
> the latest dpkg-status files of deployed targets in aws s3 bucket. A weekly
> scheduled pipeline runs a cve-checks job which generates CVE reports of respective
> targets by using the cve_checker.py script in debian-cve-checker repository [1].
> 

I understand the scripts and that they can be useful at the point where
you are actually instantiating an image. However, I'm not yet sure I'm
getting the idea behind doing that test for more or less random snapshot
every weekend. Can you elaborate on that?

BTW, patch ordering is then wrong because patch 1 uses scripts that are
only introduced by later patches.

Thanks,
Jan

-- 
Siemens AG, Technology
Linux Expert Center

RE: [cip-dev] [isar-cip-core v1 0/3] Enable CVE check in isar-cip-core CI

[Sai.Sathujoda]

Hi Jan,

Sorry for the delayed response.

The idea behind this series of patches is to maintain a latest copy of cve-reports for the deployed targets in an s3 location throughout the development cycle. Hence we are not focused on getting cve-reports for a particular snapshot. It is unknown when a new package will be added or existing ones will be removed during the development phase, so we are just generating and maintaining a copy of cve-reports for random snapshots on a weekly schedule.

Please confirm if you are convinced with my explanation. If you are OK with it, I will re-order the patches based on previous review comments and send it for review.

Thanks and Regards,
Sai Ashrith  

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Jan Kiszka via lists.cip-project.org
Sent: Friday, November 24, 2023 12:46 PM
To: ashrith sai(ＴＳＩＰ) <Sai.Sathujoda@toshiba-tsip.com>; cip-dev@lists.cip-project.org
Cc: dinesh kumar(ＴＳＩＰ TMIEC ODG Porting) <dinesh.kumar@toshiba-tsip.com>; hayashi kazuhiro(林 和宏 ＤＭＥ ○ＤＩＧ□ＭＰＳ○ＭＰ４) <kazuhiro3.hayashi@toshiba.co.jp>
Subject: Re: [cip-dev] [isar-cip-core v1 0/3] Enable CVE check in isar-cip-core CI

On 22.11.23 15:01, Sai.Sathujoda@toshiba-tsip.com wrote:
> From: Sai Sathujoda <Sai.Sathujoda@toshiba-tsip.com>
> 
> This series of patches enables CVE check in isar-cip-core CI by 
> extracting the latest dpkg-status files of deployed targets in aws s3 
> bucket. A weekly scheduled pipeline runs a cve-checks job which 
> generates CVE reports of respective targets by using the cve_checker.py script in debian-cve-checker repository [1].
> 

I understand the scripts and that they can be useful at the point where you are actually instantiating an image. However, I'm not yet sure I'm getting the idea behind doing that test for more or less random snapshot every weekend. Can you elaborate on that?

BTW, patch ordering is then wrong because patch 1 uses scripts that are only introduced by later patches.

Thanks,
Jan

--
Siemens AG, Technology
Linux Expert Center

Re: [cip-dev] [isar-cip-core v1 0/3] Enable CVE check in isar-cip-core CI

[Jan Kiszka]

Hi Sai Ashrith-san,

On 01.12.23 19:18, Sai.Sathujoda@toshiba-tsip.com wrote:
> Hi Jan,
> 
> Sorry for the delayed response.
> 
> The idea behind this series of patches is to maintain a latest copy of cve-reports for the deployed targets in an s3 location throughout the development cycle. Hence we are not focused on getting cve-reports for a particular snapshot. It is unknown when a new package will be added or existing ones will be removed during the development phase, so we are just generating and maintaining a copy of cve-reports for random snapshots on a weekly schedule.
> 

What is a development cycle in this context?

And who would use these reports, and how would that usage look like?

> Please confirm if you are convinced with my explanation. If you are OK with it, I will re-order the patches based on previous review comments and send it for review.

Sorry, I'm not yet getting the idea, but that may be my fault. I'd like
to understand how the reports can help to make sure we are including
them optimally - and can explain their usage to others as well.

Best regards,
Jan

> 
> Thanks and Regards,
> Sai Ashrith  
> 
> -----Original Message-----
> From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Jan Kiszka via lists.cip-project.org
> Sent: Friday, November 24, 2023 12:46 PM
> To: ashrith sai(ＴＳＩＰ) <Sai.Sathujoda@toshiba-tsip.com>; cip-dev@lists.cip-project.org
> Cc: dinesh kumar(ＴＳＩＰ TMIEC ODG Porting) <dinesh.kumar@toshiba-tsip.com>; hayashi kazuhiro(林 和宏 ＤＭＥ ○ＤＩＧ□ＭＰＳ○ＭＰ４) <kazuhiro3.hayashi@toshiba.co.jp>
> Subject: Re: [cip-dev] [isar-cip-core v1 0/3] Enable CVE check in isar-cip-core CI
> 
> On 22.11.23 15:01, Sai.Sathujoda@toshiba-tsip.com wrote:
>> From: Sai Sathujoda <Sai.Sathujoda@toshiba-tsip.com>
>>
>> This series of patches enables CVE check in isar-cip-core CI by 
>> extracting the latest dpkg-status files of deployed targets in aws s3 
>> bucket. A weekly scheduled pipeline runs a cve-checks job which 
>> generates CVE reports of respective targets by using the cve_checker.py script in debian-cve-checker repository [1].
>>
> 
> I understand the scripts and that they can be useful at the point where you are actually instantiating an image. However, I'm not yet sure I'm getting the idea behind doing that test for more or less random snapshot every weekend. Can you elaborate on that?
> 
> BTW, patch ordering is then wrong because patch 1 uses scripts that are only introduced by later patches.
> 
> Thanks,
> Jan
> 
> --
> Siemens AG, Technology
> Linux Expert Center
> 

-- 
Siemens AG, Technology
Linux Expert Center