<user_query>
Run bash .github/scripts/gss-detect-secrets.sh
  bash .github/scripts/gss-detect-secrets.sh
  shell: /usr/bin/bash -e {0}
  env:
    GSS_QUALITY_GATE: true
GSS: scanning repository (docker.art.lmru.tech/python:3.12-slim-bookworm)...
GSS: detect-secrets failed (exit 1):
Unable to find image 'docker.art.lmru.tech/python:3.12-slim-bookworm' locally
3.12-slim-bookworm: Pulling from python
6db0909c4473: Pulling fs layer
6022a808df72: Pulling fs layer
848e9844b9c8: Pulling fs layer
df3a362e1759: Pulling fs layer
df3a362e1759: Waiting
6db0909c4473: Verifying Checksum
6db0909c4473: Download complete
6022a808df72: Download complete
df3a362e1759: Verifying Checksum
df3a362e1759: Download complete
848e9844b9c8: Verifying Checksum
848e9844b9c8: Download complete
6db0909c4473: Pull complete
6022a808df72: Pull complete
848e9844b9c8: Pull complete
df3a362e1759: Pull complete
Digest: sha256:31c0807da611e2e377a2e9b566ad4eb038ac5a5838cbbbe6f2262259b5dc77a0
Status: Downloaded newer image for docker.art.lmru.tech/python:3.12-slim-bookworm
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager, possibly rendering your system unusable. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv. Use the --root-user-action option if you know what you are doing and want to suppress this warning.
Traceback (most recent call last):
  File "/usr/local/bin/detect-secrets", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/usr/local/lib/python3.12/site-packages/detect_secrets/main.py", line 30, in main
    handle_scan_action(args)
  File "/usr/local/lib/python3.12/site-packages/detect_secrets/main.py", line 70, in handle_scan_action
    secrets = baseline.create(
              ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/detect_secrets/core/baseline.py", line 34, in create
    secrets.scan_files(
  File "/usr/local/lib/python3.12/site-packages/detect_secrets/core/scan.py", line 72, in get_files_to_scan
    valid_paths = git.get_tracked_files(git.get_root_directory(root))
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/detect_secrets/util/git.py", line 18, in get_root_directory
    return subprocess.check_output(command).decode('utf-8').strip()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/subprocess.py", line 466, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/subprocess.py", line 548, in run
    with Popen(*popenargs, **kwargs) as process:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/subprocess.py", line 1026, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/lib/python3.12/subprocess.py", line 1955, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'git'
Error: Process completed with exit code 1.

Run bash .github/scripts/iac-kics.sh
  bash .github/scripts/iac-kics.sh
  shell: /usr/bin/bash -e {0}
  env:
    IAC_QUALITY_GATE: true
IaC (KICS): scanning .helm with docker.art.lmru.tech/checkmarx/kics:latest...
Unable to find image 'docker.art.lmru.tech/checkmarx/kics:latest' locally
latest: Pulling from checkmarx/kics
02fc55a9c757: Pulling fs layer
174181e727b5: Pulling fs layer
3f02fc482423: Pulling fs layer
1d53393b78f0: Pulling fs layer
2a4da0691147: Pulling fs layer
7c6e71c1fdfd: Pulling fs layer
a45907cabfcb: Pulling fs layer
83aaad0499db: Pulling fs layer
b287abf0b515: Pulling fs layer
cdea145aa115: Pulling fs layer
8f59897653b5: Pulling fs layer
7ad0b01d93ed: Pulling fs layer
e9095f580f42: Pulling fs layer
9f56cec7f259: Pulling fs layer
8e5d4bb15359: Pulling fs layer
aae0cd2bed42: Pulling fs layer
970b42807d4b: Pulling fs layer
ec1edc00c3f9: Pulling fs layer
4f4fb700ef54: Pulling fs layer
7c6e71c1fdfd: Waiting
a45907cabfcb: Waiting
83aaad0499db: Waiting
b287abf0b515: Waiting
1d53393b78f0: Waiting
cdea145aa115: Waiting
8f59897653b5: Waiting
7ad0b01d93ed: Waiting
e9095f580f42: Waiting
ec1edc00c3f9: Waiting
4f4fb700ef54: Waiting
970b42807d4b: Waiting
9f56cec7f259: Waiting
2a4da0691147: Waiting
8e5d4bb15359: Waiting
aae0cd2bed42: Waiting
3f02fc482423: Verifying Checksum
3f02fc482423: Download complete
174181e727b5: Verifying Checksum
174181e727b5: Download complete
02fc55a9c757: Verifying Checksum
02fc55a9c757: Download complete
1d53393b78f0: Download complete
2a4da0691147: Download complete
7c6e71c1fdfd: Verifying Checksum
7c6e71c1fdfd: Download complete
a45907cabfcb: Verifying Checksum
a45907cabfcb: Download complete
02fc55a9c757: Pull complete
b287abf0b515: Download complete
83aaad0499db: Verifying Checksum
83aaad0499db: Download complete
cdea145aa115: Verifying Checksum
cdea145aa115: Download complete
8f59897653b5: Verifying Checksum
8f59897653b5: Download complete
e9095f580f42: Verifying Checksum
e9095f580f42: Download complete
174181e727b5: Pull complete
8e5d4bb15359: Verifying Checksum
8e5d4bb15359: Download complete
3f02fc482423: Pull complete
aae0cd2bed42: Download complete
1d53393b78f0: Pull complete
970b42807d4b: Verifying Checksum
970b42807d4b: Download complete
2a4da0691147: Pull complete
ec1edc00c3f9: Verifying Checksum
ec1edc00c3f9: Download complete
7c6e71c1fdfd: Pull complete
4f4fb700ef54: Verifying Checksum
4f4fb700ef54: Download complete
9f56cec7f259: Verifying Checksum
9f56cec7f259: Download complete
a45907cabfcb: Pull complete
7ad0b01d93ed: Verifying Checksum
7ad0b01d93ed: Download complete
83aaad0499db: Pull complete
b287abf0b515: Pull complete
cdea145aa115: Pull complete
8f59897653b5: Pull complete
7ad0b01d93ed: Pull complete
e9095f580f42: Pull complete
9f56cec7f259: Pull complete
8e5d4bb15359: Pull complete
aae0cd2bed42: Pull complete
970b42807d4b: Pull complete
ec1edc00c3f9: Pull complete
4f4fb700ef54: Pull complete
Digest: sha256:3e5a268eb8adda2e5a483c9359ddfc4cd520ab856a7076dc0b1d8784a37e2602
Status: Downloaded newer image for docker.art.lmru.tech/checkmarx/kics:latest

   MLLLLLM             MLLLLLLLLL   LLLLLLL             KLLLLLLLLLLLLLLLL       LLLLLLLLLLLLLLLLLLLLLLL
   MMMMMMM           MMMMMMMMMML    MMMMMMMK       LMMMMMMMMMMMMMMMMMMMML   KLMMMMMMMMMMMMMMMMMMMMMMMMM
   MMMMMMM         MMMMMMMMML       MMMMMMMK     LMMMMMMMMMMMMMMMMMMMMMML  LMMMMMMMMMMMMMMMMMMMMMMMMMMM
   MMMMMMM      MMMMMMMMMML         MMMMMMMK   LMMMMMMMMMMMMMMMMMMMMMMMML LMMMMMMMMMMMMMMMMMMMMMMMMMMMM
   MMMMMMM    LMMMMMMMMML           MMMMMMMK  LMMMMMMMMMLLMLLLLLLLLLLLLLL LMMMMMMMLLLLLLLLLLLLLLLLLLLLM
   MMMMMMM  MMMMMMMMMLM             MMMMMMMK LMMMMMMMM                    LMMMMMML
   MMMMMMMLMMMMMMMML                MMMMMMMK MMMMMMML                     LMMMMMMMMLLLLLLLLLLLLLMLL
   MMMMMMMMMMMMMMMM                 MMMMMMMK MMMMMML                       LMMMMMMMMMMMMMMMMMMMMMMMMML
   MMMMMMMMMMMMMMMMMM               MMMMMMMK MMMMMMM                         LMMMMMMMMMMMMMMMMMMMMMMMML
   MMMMMMM KLMMMMMMMMML             MMMMMMMK LMMMMMMM                                          MMMMMMMML
   MMMMMMM    LMMMMMMMMMM           MMMMMMMK LMMMMMMMMLL                                        MMMMMMML
   MMMMMMM      LMMMMMMMMMLL        MMMMMMMK  LMMMMMMMMMMMMMMMMMMMMMMMMML LLLLLLLLLLLLLLLLLLLLMMMMMMMMMM
   MMMMMMM        MMMMMMMMMMML      MMMMMMMK   MMMMMMMMMMMMMMMMMMMMMMMMML LMMMMMMMMMMMMMMMMMMMMMMMMMMMM
   MMMMMMM          LLMMMMMMMMML    MMMMMMMK     LLMMMMMMMMMMMMMMMMMMMMML LMMMMMMMMMMMMMMMMMMMMMMMMMML
   MMMMMMM             MMMMMMMMMML  MMMMMMMK         KLMMMMMMMMMMMMMMMMML LMMMMMMMMMMMMMMMMMMMMMMMLK

Scanning with Keeping Infrastructure as Code Secure v2.1.20

Using Kubernetes Native Secret Management, Severity: INFO, Results: 1
Description: Kubernetes External Secret Storage and Management System usage should be considered if you have more complex secret management needs, rather than using Kubernetes Secrets directly. Additionally, ensure that access to secrets is carefully limited
Platform: Kubernetes
CWE: 311
Risk Score: 0.0
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/b9c83569-459b-4110-8f79-6305aa33cb37

	[1]: .helm/templates/secrets.yaml:5

		004: metadata:
		005:   name: "{{ .Values.app.name }}-secret"
		006: data:

Secrets As Environment Variables, Severity: LOW, Results: 8
Description: Container should not use secrets as environment variables
Platform: Kubernetes
CWE: 526
Risk Score: 3.8
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/3d658f8b-d988-41a0-a841-40043121de1e

	[1]: .helm/templates/cronjob.yaml:18

		017:               imagePullPolicy: {{ .Values.app.image.pullPolicy }}
		018:               env:
		019:                 - name: JENKINS_URL

	[2]: .helm/templates/cronjob.yaml:18

		017:               imagePullPolicy: {{ .Values.app.image.pullPolicy }}
		018:               env:
		019:                 - name: JENKINS_URL

	[3]: .helm/templates/cronjob.yaml:18

		017:               imagePullPolicy: {{ .Values.app.image.pullPolicy }}
		018:               env:
		019:                 - name: JENKINS_URL

	[4]: .helm/templates/cronjob.yaml:18

		017:               imagePullPolicy: {{ .Values.app.image.pullPolicy }}
		018:               env:
		019:                 - name: JENKINS_URL

	[5]: .helm/templates/cronjob.yaml:18

		017:               imagePullPolicy: {{ .Values.app.image.pullPolicy }}
		018:               env:
		019:                 - name: JENKINS_URL

	[6]: .helm/templates/cronjob.yaml:18

		017:               imagePullPolicy: {{ .Values.app.image.pullPolicy }}
		018:               env:
		019:                 - name: JENKINS_URL

	[7]: .helm/templates/cronjob.yaml:18

		017:               imagePullPolicy: {{ .Values.app.image.pullPolicy }}
		018:               env:
		019:                 - name: JENKINS_URL

	[8]: .helm/templates/cronjob.yaml:18

		017:               imagePullPolicy: {{ .Values.app.image.pullPolicy }}
		018:               env:
		019:                 - name: JENKINS_URL

Root Container Not Mounted Read-only, Severity: LOW, Results: 1
Description: Check if the root container filesystem is not being mounted as read-only.
Platform: Kubernetes
CWE: 668
Risk Score: 3.6
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/a9c2f49d-0671-4fc9-9ece-f4e261e128d0

	[1]: .helm/templates/cronjob.yaml:14

		013:           restartPolicy: Never
		014:           containers:
		015:             - name: {{ .Values.app.name }}

Pod or Container Without Security Context, Severity: LOW, Results: 1
Description: A security context defines privilege and access control settings for a Pod or Container
Platform: Kubernetes
CWE: 285
Risk Score: 3.6
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/a97a340a-0063-418e-b3a1-3028941d0995

	[1]: .helm/templates/cronjob.yaml:14

		013:           restartPolicy: Never
		014:           containers:
		015:             - name: {{ .Values.app.name }}

Pod or Container Without ResourceQuota, Severity: LOW, Results: 1
Description: Each namespace should have a ResourceQuota policy associated to limit the total amount of resources Pods, Containers and PersistentVolumeClaims can consume
Platform: Kubernetes
CWE: 400
Risk Score: 2.8
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/48a5beba-e4c0-4584-a2aa-e6894e4cf424

	[1]: .helm/templates/cronjob.yaml:3

		002: kind: CronJob
		003: metadata:
		004:   name: {{ .Values.app.name }}

Pod or Container Without LimitRange, Severity: LOW, Results: 1
Description: Each namespace should have a LimitRange policy associated to ensure that resource allocations of Pods, Containers and PersistentVolumeClaims do not exceed the defined boundaries
Platform: Kubernetes
CWE: 400
Risk Score: 2.8
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/4a20ebac-1060-4c81-95d1-1f7f620e983b

	[1]: .helm/templates/cronjob.yaml:3

		002: kind: CronJob
		003: metadata:
		004:   name: {{ .Values.app.name }}

No Drop Capabilities for Containers, Severity: LOW, Results: 1
Description: Sees if Kubernetes Drop Capabilities exists to ensure containers security context
Platform: Kubernetes
CWE: 754
Risk Score: 3.6
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/268ca686-7fb7-4ae9-b129-955a2a89064e

	[1]: .helm/templates/cronjob.yaml:14

		013:           restartPolicy: Never
		014:           containers:
		015:             - name: {{ .Values.app.name }}

Missing AppArmor Profile, Severity: LOW, Results: 1
Description: Containers should be configured with an AppArmor profile to enforce fine-grained access control over low-level system resources
Platform: Kubernetes
CWE: 284
Risk Score: 3.3
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/8b36775e-183d-4d46-b0f7-96a6f34a723f

	[1]: .helm/templates/cronjob.yaml:3

		002: kind: CronJob
		003: metadata:
		004:   name: {{ .Values.app.name }}

Image Without Digest, Severity: LOW, Results: 1
Description: Images should be specified together with their digests to ensure integrity
Platform: Kubernetes
CWE: 665
Risk Score: 4.1
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/7c81d34c-8e5a-402b-9798-9f442630e678

	[1]: .helm/templates/cronjob.yaml:14

		013:           restartPolicy: Never
		014:           containers:
		015:             - name: {{ .Values.app.name }}

CronJob Deadline Not Configured, Severity: LOW, Results: 1
Description: Cronjobs must have a configured deadline, which means the attribute 'startingDeadlineSeconds' must be defined
Platform: Kubernetes
CWE: 400
Risk Score: 2.9
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/192fe40b-b1c3-448a-aba2-6cc19a300fe3

	[1]: .helm/templates/cronjob.yaml:3

		002: kind: CronJob
		003: metadata:
		004:   name: {{ .Values.app.name }}

CPU Requests Not Set, Severity: LOW, Results: 1
Description: CPU requests should be set to ensure the sum of the resource requests of the scheduled Containers is less than the capacity of the node
Platform: Kubernetes
CWE: 400
Risk Score: 2.9
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/ca469dd4-c736-448f-8ac1-30a642705e0a

	[1]: .helm/templates/cronjob.yaml:14

		013:           restartPolicy: Never
		014:           containers:
		015:             - name: {{ .Values.app.name }}

CPU Limits Not Set, Severity: LOW, Results: 1
Description: CPU limits should be set because if the system has CPU time free, a container is guaranteed to be allocated as much CPU as it requests
Platform: Kubernetes
CWE: 400
Risk Score: 2.9
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/4ac0e2b7-d2d2-4af7-8799-e8de6721ccda

	[1]: .helm/templates/cronjob.yaml:14

		013:           restartPolicy: Never
		014:           containers:
		015:             - name: {{ .Values.app.name }}

Using Unrecommended Namespace, Severity: MEDIUM, Results: 2
Description: Namespaces like 'default', 'kube-system' or 'kube-public' should not be used
Platform: Kubernetes
CWE: 665
Risk Score: 5.5
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/611ab018-c4aa-4ba2-b0f6-a448337509a6

	[1]: .helm/templates/secrets.yaml:5

		004: metadata:
		005:   name: "{{ .Values.app.name }}-secret"
		006: data:

	[2]: .helm/templates/cronjob.yaml:3

		002: kind: CronJob
		003: metadata:
		004:   name: {{ .Values.app.name }}

Service Account Token Automount Not Disabled, Severity: MEDIUM, Results: 1
Description: Service Account Tokens are automatically mounted even if not necessary
Platform: Kubernetes
CWE: 665
Risk Score: 6.8
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/48471392-d4d0-47c0-b135-cdec95eb3eef

	[1]: .helm/templates/cronjob.yaml:12

		011:       template:
		012:         spec:
		013:           restartPolicy: Never

Seccomp Profile Is Not Configured, Severity: MEDIUM, Results: 1
Description: Containers should be configured with a secure Seccomp profile to restrict potentially dangerous syscalls
Platform: Kubernetes
CWE: 665
Risk Score: 6.8
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/f377b83e-bd07-4f48-a591-60c82b14a78b

	[1]: .helm/templates/cronjob.yaml:14

		013:           restartPolicy: Never
		014:           containers:
		015:             - name: {{ .Values.app.name }}

NET_RAW Capabilities Not Being Dropped, Severity: MEDIUM, Results: 1
Description: Containers should drop 'ALL' or at least 'NET_RAW' capabilities
Platform: Kubernetes
CWE: 269
Risk Score: 6.2
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/dbbc6705-d541-43b0-b166-dd4be8208b54

	[1]: .helm/templates/cronjob.yaml:14

		013:           restartPolicy: Never
		014:           containers:
		015:             - name: {{ .Values.app.name }}

Memory Requests Not Defined, Severity: MEDIUM, Results: 1
Description: Memory requests should be defined for each container. This allows the kubelet to reserve the requested amount of system resources and prevents over-provisioning on individual nodes
Platform: Kubernetes
CWE: 400
Risk Score: 5.5
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/229588ef-8fde-40c8-8756-f4f2b5825ded

	[1]: .helm/templates/cronjob.yaml:14

		013:           restartPolicy: Never
		014:           containers:
		015:             - name: {{ .Values.app.name }}

Memory Limits Not Defined, Severity: MEDIUM, Results: 1
Description: Memory limits should be defined for each container. This prevents potential resource exhaustion by ensuring that containers consume not more than the designated amount of memory
Platform: Kubernetes
CWE: 400
Risk Score: 5.5
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/b14d1bc4-a208-45db-92f0-e21f8e2588e9

	[1]: .helm/templates/cronjob.yaml:14

		013:           restartPolicy: Never
		014:           containers:
		015:             - name: {{ .Values.app.name }}

Container Running With Low UID, Severity: MEDIUM, Results: 1
Description: Check if containers are running with low UID, which might cause conflicts with the host's user table.
Platform: Kubernetes
CWE: 1188
Risk Score: 4.9
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/02323c00-cdc3-4fdc-a310-4f2b3e7a1660

	[1]: .helm/templates/cronjob.yaml:14

		013:           restartPolicy: Never
		014:           containers:
		015:             - name: {{ .Values.app.name }}

Container Running As Root, Severity: MEDIUM, Results: 1
Description: Containers should only run as non-root user. This limits the exploitability of security misconfigurations and restricts an attacker's possibilities in case of compromise
Platform: Kubernetes
CWE: 1188
Risk Score: 5.8
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/cf34805e-3872-4c08-bf92-6ff7bb0cfadb

	[1]: .helm/templates/cronjob.yaml:14

		013:           restartPolicy: Never
		014:           containers:
		015:             - name: {{ .Values.app.name }}

Privilege Escalation Allowed, Severity: HIGH, Results: 1
Description: Containers should not run with allowPrivilegeEscalation in order to prevent them from gaining more privileges than their parent process
Platform: Kubernetes
CWE: 269
Risk Score: 7.7
Learn more about this vulnerability: https://docs.kics.io/latest/queries/kubernetes-queries/5572cc5e-1e4c-4113-92a6-7a8a3bd25e6d

	[1]: .helm/templates/cronjob.yaml:14

		013:           restartPolicy: Never
		014:           containers:
		015:             - name: {{ .Values.app.name }}

Results Summary:
CRITICAL: 0
HIGH: 1
MEDIUM: 9
LOW: 18
INFO: 1
TOTAL: 29

Preparing Scan Assets: DoneExecuting queries: [---------------------->_________________________________________________] 31.56%Executing queries: [--------------------------->____________________________________________] 38.27%Executing queries: [-------------------------------->_______________________________________] 45.53%Executing queries: [--------------------------------------->________________________________] 55.31%Executing queries: [--------------------------------------------->__________________________] 62.85%Executing queries: [---------------------------------------------------->___________________] 72.35%Executing queries: [----------------------------------------------------------->____________] 82.40%Executing queries: [------------------------------------------------------------------>_____] 92.18%Executing queries: [----------------------------------------------------------------------->] 98.88%Executing queries: [-----------------------------------------------------------------------] 100.00%Generating Reports: Done
Error: Process completed with exit code 50.

Run actions/upload-artifact@v4
  with:
    name: iac-kics
    if-no-files-found: ignore
    path: IaC/**

    compression-level: 6
    overwrite: false
    include-hidden-files: false
  env:
    IAC_QUALITY_GATE: true
With the provided path, there will be 2 files uploaded
Warning: Artifact upload failed with error: GHESNotSupportedError: @actions/artifact v2.0.0+, upload-artifact@v4+ and download-artifact@v4+ are not currently supported on GHES..

Errors can be temporary, so please try again and optionally run the action with debug mode enabled for more information.

If the error persists, please check whether Actions is operating normally at [https://githubstatus.com](https://www.githubstatus.com).
Error: @actions/artifact v2.0.0+, upload-artifact@v4+ and download-artifact@v4+ are not currently supported on GHES.

Run actions/upload-artifact@v4
  with:
    name: checkmarx-sast
    if-no-files-found: ignore
    path: checkmarx_report.pdf
    compression-level: 6
    overwrite: false
    include-hidden-files: false
  env:
    SAST_QUALITY_GATE: true
With the provided path, there will be 1 file uploaded
Warning: Artifact upload failed with error: GHESNotSupportedError: @actions/artifact v2.0.0+, upload-artifact@v4+ and download-artifact@v4+ are not currently supported on GHES..

Errors can be temporary, so please try again and optionally run the action with debug mode enabled for more information.

If the error persists, please check whether Actions is operating normally at [https://githubstatus.com](https://www.githubstatus.com).
Error: @actions/artifact v2.0.0+, upload-artifact@v4+ and download-artifact@v4+ are not currently supported on GHES.
</user_query>


Исправляем три проблемы: 1) в образе Python нет `git` — устанавливаем `git` в контейнере перед `detect-secrets`. 2) `upload-artifact@v4` не поддерживается на GHES — переходим на `v3`. 3) KICS завершился с кодом 50 из‑за findings при включённом gate — по желанию можно ослабить gate; сначала исправляем GSS и артефакты.


Сделано следующее.

### 1. `gss-detect-secrets.sh`
В slim-образе нет **`git`**, а `detect-secrets` без `--all-files` дергает git для списка отслеживаемых файлов. Перед `pip install` и запуском скана в контейнере выполняется **`apt-get install git`** (через `DEBIAN_FRONTEND=noninteractive`).

### 2. `.github/workflows/ci.yaml`
Все **`actions/upload-artifact@v4`** заменены на **`@v3`**, чтобы не падать на **GHES** (в логе: *upload-artifact v4+ are not currently supported on GHES*).

---

**Про KICS (exit code 50):** при **`IAC_QUALITY_GATE: true`** и **`--fail-on critical,high`** шаг падает, если есть находки уровня high/critical. У тебя в отчёте есть **HIGH** (например, *Privilege Escalation Allowed*). Это ожидаемое поведение gate: либо правите манифесты/настройки Helm, либо временно ставите **`IAC_QUALITY_GATE: "false"`** в workflow, пока не приведёте чарт в порядок.

**Про артефакты на GHES:** если **`@v3`** всё ещё ругается, напиши версию GHES — под неё можно зафиксировать конкретный тег экшена.


<user_query>
Run bash .github/scripts/gss-detect-secrets.sh
  bash .github/scripts/gss-detect-secrets.sh
  shell: /usr/bin/bash -e {0}
  env:
    GSS_QUALITY_GATE: true
GSS: scanning repository (docker.art.lmru.tech/python:3.12-slim-bookworm)...
GSS: invalid JSON from detect-secrets: Expecting value: line 1 column 1 (char 0)
Error: Process completed with exit code 2.
</user_query>


Смешивание вывода apt/pip с JSON в одном потоке ломает разбор. Пишем вывод `detect-secrets` только в файл в смонтированном каталоге.


Вот что было не так: в переменную попадал **весь вывод контейнера** (`$(...) 2>&1`), туда же уходили **apt/pip** и служебные строки, поэтому в начале не было чистого JSON → `Expecting value: line 1 column 1`.

**Что сделано:**
- После установки git и `detect-secrets` результат скана пишется **только** в файл **`${WORKDIR}/.gss-scan-output.json`** внутри смонтированного `/work` (`exec "$@" > /work/.gss-scan-output.json`).
- **apt-get** и **pip** перенаправлены в **`/dev/null`**, чтобы не мешать.
- Разбор и отчёт идут с **`run_report < .gss-scan-output.json`**.
- В **`trap EXIT`** файл удаляется; имя добавлено в **`.gitignore`**.

Перезапусти job — JSON должен парситься нормально.


<user_query>
Run bash .github/scripts/gss-detect-secrets.sh
  bash .github/scripts/gss-detect-secrets.sh
  shell: /usr/bin/bash -e {0}
  env:
    GSS_QUALITY_GATE: true
GSS: scanning repository (docker.art.lmru.tech/python:3.12-slim-bookworm)...
Unable to find image 'docker.art.lmru.tech/python:3.12-slim-bookworm' locally
3.12-slim-bookworm: Pulling from python
6db0909c4473: Pulling fs layer
6022a808df72: Pulling fs layer
848e9844b9c8: Pulling fs layer
df3a362e1759: Pulling fs layer
df3a362e1759: Waiting
6022a808df72: Verifying Checksum
6022a808df72: Download complete
df3a362e1759: Verifying Checksum
df3a362e1759: Download complete
848e9844b9c8: Verifying Checksum
848e9844b9c8: Download complete
6db0909c4473: Verifying Checksum
6db0909c4473: Download complete
6db0909c4473: Pull complete
6022a808df72: Pull complete
848e9844b9c8: Pull complete
df3a362e1759: Pull complete
Digest: sha256:31c0807da611e2e377a2e9b566ad4eb038ac5a5838cbbbe6f2262259b5dc77a0
Status: Downloaded newer image for docker.art.lmru.tech/python:3.12-slim-bookworm
fatal: detected dubious ownership in repository at '/work'
To add an exception for this directory, call:

	git config --global --add safe.directory /work
GSS: no secret findings.

/home/ruslanpi/Documents/results.json тут результаты кикс, давай закроем нужное типо секьюрити контекста и т.д.
</user_query>


Исправляем: 1) добавляем `git config safe.directory /work` в контейнере GSS. 2) Усиливаем Helm-манифесты по результатам KICS (securityContext и т.д.).


Добавляем `git safe.directory` в GSS; усиливаем Helm и Dockerfile под KICS (securityContext, ресурсы, deadline, namespace).


Кратко, что сделано:

### 1. `gss-detect-secrets.sh`
После установки `git` добавлено:
`git config --global --add safe.directory /work` — чтобы не было **dubious ownership** при монтировании репозитория в контейнер.

### 2. `Dockerfile`
- Пользователь **`appuser` (uid/gid 1000)** и `chown` на `/app`.
- **`USER 1000:1000`** — контейнер не под root (в паре с pod `securityContext`).

### 3. `.helm/templates/cronjob.yaml`
- **`namespace: {{ .Release.Namespace }}`**
- **`startingDeadlineSeconds: 600`**, **`activeDeadlineSeconds: 3600`**
- **`automountServiceAccountToken: false`**
- **Pod `securityContext`**: `runAsNonRoot`, `runAsUser`/`runAsGroup`/`fsGroup` **1000**, **`seccompProfile: RuntimeDefault`**
- **Container `securityContext`**: **`allowPrivilegeEscalation: false`**, **`readOnlyRootFilesystem: true`**, **`capabilities.drop: [ALL]`**
- **`resources`** из `values.yaml`
- **`emptyDir`** на **`/tmp`** (при `readOnlyRootFilesystem` без этого Python часто падает)

### 4. `.helm/templates/secrets.yaml`
- **`namespace: {{ .Release.Namespace }}`**

### 5. `.helm/values.yaml`
- Блок **`app.resources`** (requests/limits).

---

Часть предупреждений KICS остаётся по смыслу: **секреты через `env`** (лучше тогда External Secrets), **ResourceQuota/LimitRange** на уровне namespace, **digest образа** — это уже политика кластера/реестра. После деплоя нового образа с non-root перезапусти KICS; если что-то ещё режет gate — пришли свежий `results.json` или фрагмент отчёта.

`helm template` без `--set app.name=...` даёт пустые имена — у вас они задаются в CI через `--set`, это ожидаемо.


<attached_files>

<code_selection path="/home/ruslanpi/Documents/repos/lmru--devsecops-vuln-scanner-1/.helm/values.yaml" lines="15-21">
resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
    20|      cpu: "1"
      memory: 512Mi
</code_selection>

</attached_files>
<user_query>
@values.yaml (15-21) ресурсы великоваты
</user_query>


Поставил меньше: **requests** `50m` CPU / `64Mi` RAM, **limits** `200m` CPU / `256Mi` RAM. Если CronJob начнёт упираться в OOM при NVD или больших ответах — подними `memory` в `limits` или `requests`.


<user_query>
The image contains 1 high vulnerabilityDocker DX (docker-language-server)critical_high_vulnerabilities
Ctrl+click to open in new tab
Set the baseImage to use for subsequent instructions. FROM must be the first instruction in a Dockerfile.

FROM baseImage
FROM baseImage:tag
FROM baseImage@digest

плюс аспользовать корпоративный прокси
</user_query>


<git_status>
This is the git status at the start of the conversation. Note that this status is a snapshot in time, and will not update during the conversation.

Git repo: /home/ruslanpi/Documents/repos/lmru--devsecops-vuln-scanner-1

## master...origin/master
</git_status>

<agent_transcripts>
Agent transcripts (past chats) live in /home/ruslanpi/.cursor/projects/home-ruslanpi-Documents-repos-lmru-devsecops-vuln-scanner-1/agent-transcripts. They have names like <uuid>.jsonl, cite them to the user as [<title for chat <=6 words>](<uuid excluding .jsonl>). NEVER cite subagent transcripts/IDs; you can only cite parent uuids. Don't discuss the folder structure.
</agent_transcripts>

<agent_skills>
When users ask you to perform tasks, check if any of the available skills below can help complete the task more effectively. Skills provide specialized capabilities and domain knowledge. To use a skill, read the skill file at the provided absolute path using the Read tool, then follow the instructions within. When a skill is relevant, read and follow it IMMEDIATELY as your first action. NEVER just announce or mention a skill without actually reading and following it. Only use skills listed below.

<available_skills description="Skills the agent can use. Use the Read tool with the provided absolute path to fetch full contents.">
<agent_skill fullPath="/home/ruslanpi/.cursor/skills-cursor/canvas/SKILL.md">You MUST use a Cursor Canvas for chats involving dashboards, charts, timelines, interactive explorations, repeatable tools, etc. Use when the topic is complex enough that a plain markdown response would be inadequate, or when the user asks for something reusable or interactive.</agent_skill>

<agent_skill fullPath="/home/ruslanpi/.cursor/skills-cursor/create-rule/SKILL.md">Create Cursor rules for persistent AI guidance. Use when you want to create a rule, add coding standards, set up project conventions, configure file-specific patterns, create RULE.md files, or asks about .cursor/rules/ or AGENTS.md.</agent_skill>

<agent_skill fullPath="/home/ruslanpi/.cursor/skills-cursor/create-skill/SKILL.md">Guides users through creating effective Agent Skills for Cursor. Use when you want to create, write, or author a new skill, or asks about skill structure, best practices, or SKILL.md format.</agent_skill>

<agent_skill fullPath="/home/ruslanpi/.cursor/skills-cursor/update-cursor-settings/SKILL.md">Modify Cursor/VSCode user settings in settings.json. Use when you want to change editor settings, preferences, configuration, themes, font size, tab size, format on save, auto save, keybindings, or any settings.json values.</agent_skill>
</available_skills>
</agent_skills>


Переключаем базовый образ на корпоративное зеркало (как в `gss-detect-secrets.sh`) и добавляем передачу прокси только на этапе `pip install`, без сохранения прокси в финальном слое.


Кратко, что сделано:

### `Dockerfile`
- **`FROM docker.art.lmru.tech/python:3.12-slim-bookworm`** — тот же источник, что и в `gss-detect-secrets.sh`, вместо публичного `python:3.12-slim` (это убирает предупреждение Docker DX про «не заданный» корпоративный базовый образ и снижает расхождение с вашим реестром).
- **`ARG HTTP_PROXY` / `HTTPS_PROXY` / `NO_PROXY`** и **`export` только в `RUN` с `pip`** — прокси нужен при сборке, в финальный образ не попадает.

### `.github/workflows/ci.yaml`
- В шагах **Docker build** и **Docker push** в `customArgsList` добавлены
  `--build-arg HTTP_PROXY=…`, `--build-arg HTTPS_PROXY=…`, `--build-arg NO_PROXY=…` из **repository/organization variables** `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY`.

В GitHub: **Settings → Secrets and variables → Actions → Variables** — задать эти три переменные (для `NO_PROXY` обычно указывают внутренние хосты и `localhost`). Если переменных нет, подставятся пустые значения, сборка без прокси остаётся рабочей.

**Локально:**
`docker build --build-arg HTTP_PROXY=... --build-arg HTTPS_PROXY=... --build-arg NO_PROXY=... .`

**Фиксация базы по digest** (когда в Artifactory известен digest слоя):
`FROM docker.art.lmru.tech/python@sha256:<digest>`
или
`FROM docker.art.lmru.tech/python:3.12-slim-bookworm@sha256:<digest>` — так Docker DX и воспроизводимость сборки опираются на точный слой.

`yamllint` по этому файлу всё ещё ругается на **старые** длинные строки (в т.ч. `SCA_IMAGE` на ~166-й строке); новые блоки с `customArgsList` укладываются в лимит по строкам. Если нужно, могу пройтись и уложить весь workflow в 80 символов.


<attached_files>

<code_selection path="/home/ruslanpi/Documents/repos/lmru--devsecops-vuln-scanner-1/Dockerfile" lines="1-17">
FROM docker.art.lmru.tech/python:3.12-slim-bookworm

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY ./app /app

    10|RUN groupadd --gid 1000 appuser && \
    useradd --uid 1000 --gid appuser --no-create-home --shell /usr/sbin/nologin appuser && \
    chown -R appuser:appuser /app

USER 1000:1000

CMD ["/usr/local/bin/python", "main.py"]

</code_selection>

</attached_files>
<user_query>
@Dockerfile:1-17 в таком виде докерфайл рабочий?
</user_query>


Да, в таком виде **Dockerfile логически рабочий**: стандартная схема `WORKDIR` → `COPY requirements` → `pip install` → копирование кода → непривилегированный пользователь.

Что должно выполняться снаружи:

1. **Доступ к реестру** — образ `docker.art.lmru.tech/python:3.12-slim-bookworm` должен успешно **pull**-иться (при необходимости — `docker login` к Artifactory до `docker build`).

2. **Сеть для `pip`** — если из среды сборки PyPI доступен только через корпоративный прокси, текущий вариант **без** `ARG`/`ENV` для прокси на шаге `RUN pip install` может **падать по таймауту**. Тогда нужно снова добавить прокси только на этап `pip` (или `--build-arg` + `export` в том же `RUN`).

3. **Приложение** — в образе должен быть `main.py` в `/app` (у вас `WORKDIR /app` и `COPY ./app /app`, значит ожидается `app/main.py` в репозитории).

Итого: для открытого доступа к реестру и к PyPI — **да, рабочий**; за жёстким прокси — допишите прокси для `pip`.


<user_query>
Run bash .github/scripts/sca-trivy-image.sh
  bash .github/scripts/sca-trivy-image.sh
  shell: /usr/bin/bash -e {0}
  env:
    SCA_QUALITY_GATE: true
    APP_NAME: devsecops-vuln-scanner
    K8S_NAMESPACE: devsecops-vuln-scanner
    VAULT_ADDR: https://vault.lmru.tech
    VAULT_NAMESPACE: devsecops
    JFROG_CLI_ENV_EXCLUDE: *password*;*secret*;*key*;*token*;*auth*;JF_ARTIFACTORY_*;JF_ENV_*;JF_URL;JF_USER;JF_PASSWORD;JF_ACCESS_TOKEN
    JFROG_CLI_OFFER_CONFIG: false
    JFROG_CLI_AVOID_NEW_VERSION_WARNING: true
    JFROG_CLI_SOURCECODE_REPOSITORY: adeo/lmru--devsecops-vuln-scanner
    JFROG_CLI_CI_JOB_ID: ci
    JFROG_CLI_CI_RUN_ID: 354454
    JFROG_CLI_GITHUB_TOKEN:
    JFROG_CLI_CI_VCS_REVISION: 18008bf68be71149c5aaf3d6bcd8a6771bab657b
    JFROG_CLI_CI_BRANCH: master
    JFROG_CLI_CI_VCS_URL: https://github.lmru.tech/adeo/lmru--devsecops-vuln-scanner
    JFROG_CLI_BUILD_NAME: ci
    JFROG_CLI_BUILD_NUMBER: 31
    JFROG_CLI_BUILD_URL: https://github.lmru.tech/adeo/lmru--devsecops-vuln-scanner/actions/runs/354454
    JFROG_CLI_USER_AGENT: setup-jfrog-cli-github-action/5.0.0
    JFROG_CLI_COMMAND_SUMMARY_OUTPUT_DIR: /home/runner/_work/_temp
    JFROG_CLI_USAGE_GH_TOKEN_FOR_CODE_SCANNING_ALERTS_PROVIDED:
    SETUP_JFROG_CLI_SERVER_IDS: setup-jfrog-cli-server
    SCA_IMAGE: docker-local-devsecops.art.lmru.tech/devsecops-vuln-scanner:v0.1.1
SCA: scanning image docker-local-devsecops.art.lmru.tech/devsecops-vuln-scanner:v0.1.1 with Trivy (docker-security.art.lmru.tech/secapps/trivy-bundle:stable)...
Unable to find image 'docker-security.art.lmru.tech/secapps/trivy-bundle:stable' locally
stable: Pulling from secapps/trivy-bundle
589002ba0eae: Pulling fs layer
b416555f4d2b: Pulling fs layer
06b3d4e016af: Pulling fs layer
0272f312a3f5: Pulling fs layer
4f4fb700ef54: Pulling fs layer
c81d95487562: Pulling fs layer
5104ffed14dc: Pulling fs layer
0272f312a3f5: Waiting
4f4fb700ef54: Waiting
5104ffed14dc: Waiting
c81d95487562: Waiting
589002ba0eae: Verifying Checksum
589002ba0eae: Download complete
0272f312a3f5: Verifying Checksum
0272f312a3f5: Download complete
589002ba0eae: Pull complete
4f4fb700ef54: Verifying Checksum
4f4fb700ef54: Download complete
b416555f4d2b: Verifying Checksum
b416555f4d2b: Download complete
c81d95487562: Verifying Checksum
c81d95487562: Download complete
b416555f4d2b: Pull complete
06b3d4e016af: Verifying Checksum
06b3d4e016af: Download complete
06b3d4e016af: Pull complete
0272f312a3f5: Pull complete
4f4fb700ef54: Pull complete
c81d95487562: Pull complete
5104ffed14dc: Verifying Checksum
5104ffed14dc: Download complete
5104ffed14dc: Pull complete
Digest: sha256:725f501be153c05406b2f6d4814eb4ac3efe7351bb15b43b046367b35b4b7e71
Status: Downloaded newer image for docker-security.art.lmru.tech/secapps/trivy-bundle:stable
{"Version":"0.69.3","VulnerabilityDB":{"Version":2,"NextUpdate":"2026-03-20T12:35:06.232779285Z","UpdatedAt":"2026-03-19T12:35:06.232779536Z","DownloadedAt":"2026-03-30T08:08:25.498059183Z"},"JavaDB":{"Version":1,"NextUpdate":"2026-03-22T01:17:54.39581332Z","UpdatedAt":"2026-03-19T01:17:54.395813642Z","DownloadedAt":"2026-03-30T08:08:54.726741671Z"}}
2026-03-31T13:54:39Z	INFO	[vuln] Vulnerability scanning is enabled
2026-03-31T13:54:39Z	INFO	[secret] Secret scanning is enabled
2026-03-31T13:54:39Z	INFO	[secret] If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2026-03-31T13:54:39Z	INFO	[secret] Please see https://trivy.dev/docs/v0.69/guide/scanner/secret#recommendation for faster secret detection
2026-03-31T13:54:39Z	FATAL	Fatal error	run error: image scan error: scan error: unable to initialize a scan service: unable to initialize artifact: unable to initialize container image: unable to find the specified image "docker-local-devsecops.art.lmru.tech/devsecops-vuln-scanner:v0.1.1" in ["docker" "containerd" "podman" "remote"]: 4 errors occurred:
	* docker error: unable to inspect the image (docker-local-devsecops.art.lmru.tech/devsecops-vuln-scanner:v0.1.1): permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.51/images/docker-local-devsecops.art.lmru.tech/devsecops-vuln-scanner:v0.1.1/json": dial unix /var/run/docker.sock: connect: permission denied
	* containerd error: containerd socket not found: /run/containerd/containerd.sock
	* podman error: unable to initialize Podman client: no podman socket found: stat podman/podman.sock: no such file or directory
	* remote error: GET https://docker-local-devsecops.art.lmru.tech/v2/devsecops-vuln-scanner/manifests/v0.1.1: MANIFEST_UNKNOWN: The named manifest is not known to the registry.; map[manifest:devsecops-vuln-scanner/v0.1.1/manifest.json]
</user_query>


Разбираемся: Trivy не находит образ — нет доступа к Docker socket и образ не в реестре. Просматриваю скрипт и порядок шагов в CI.


Проблема: образ собирается с `skipPushImage: true`, но SCA ожидает его в реестре или в локальном Docker. У шага `bash` нет доступа к `/var/run/docker.sock`, а образ ещё не запушен — `MANIFEST_UNKNOWN`. Убираем зависимость от Docker socket в скрипте, передаём учётные данные для pull из реестра и переносим push перед SCA.


Удаляю длинный комментарий в скрипте. Причина сбоя: образ не был в реестре (`skipPush` до SCA) и Trivy через socket не мог достучаться до локального Docker; после push и сканирования по реестру это устраняется.


Добавляем шаг экспорта `SCA_IMAGE` в `GITHUB_ENV`, чтобы не раздувать длинные строки и обойти ограничение yamllint.


Вот что было не так и что сделано.

### Почему падало
1. **`MANIFEST_UNKNOWN`** — образ `docker-local-.../devsecops-vuln-scanner:v0.1.1` в реестре **ещё не был**: шаг **Docker push** шёл **после** SCA, а при `skipPushImage: true` после build в реестре тега не было.
2. **Docker socket** — скрипт подключал `/var/run/docker.sock` к Trivy, и при недоступном сокету на раннере сканирование через локальный Docker не работало. Для образа уже в **частном** реестре это не нужно: Trivy может тянуть слои **напрямую из реестра**.

### Что изменено
1. **`ci.yaml`** — порядок шагов: **Docker push → Export SCA image ref → SCA → Upload Trivy reports**. Так образ гарантированно есть в Artifactory до сканирования.
2. **`sca-trivy-image.sh`** — убраны `docker image inspect` / `docker pull` на хосте и **mount** `docker.sock`; в контейнер Trivy при необходимости передаются **`TRIVY_USERNAME`** / **`TRIVY_PASSWORD`** (для pull из private registry).
3. **`Export SCA image ref`** — задаёт `SCA_IMAGE` через `GITHUB_ENV` (и укладывает строки в лимит yamllint).

В шаге SCA в `env` должны быть **`TRIVY_USERNAME`** / **`TRIVY_PASSWORD`** (у вас — те же `LM_SA_*`, что и для Docker push).

Если после merge **quality gate** снова упадёт из‑за HIGH/CRITICAL в отчёте — это уже другая история (содержимое образа), а не отсутствие образа в реестре.


<user_query>
TRIVY_USERNAME / TRIVY_PASSWORD (для pull из private registry) на пулл не нужны доступы, только на пуш
</user_query>


Убираем передачу `TRIVY_USERNAME` / `TRIVY_PASSWORD` из CI и упрощаем скрипт.


Сделано.

- **`ci.yaml`**: у шага SCA убран блок `env` с `TRIVY_USERNAME` / `TRIVY_PASSWORD`.
- **`sca-trivy-image.sh`**: снова один вызов `docker run` без передачи учётки в Trivy.

Публичный/anonymous pull из `docker-local-*.art.lmru.tech` для сканирования Trivy остаётся достаточным; пуш по-прежнему идёт через `dockerUtils` с `LM_SA_*`. Если когда‑нибудь понадобится pull с логином (другой реестр), можно снова добавить опциональные `TRIVY_*` только в окружениях, где это требуется.


[Image]
<image_files>
The following images were provdied by the user and saved to the workspace for future use:
1. /home/ruslanpi/.cursor/projects/home-ruslanpi-Documents-repos-lmru-devsecops-vuln-scanner-1/assets/image-886cf602-c710-4ae3-b6bd-fc208b7ecc2b.png

These images can be copied for use in other locations.
</image_files>
<user_query>
надо как-то все же воркфлоу расположить шаги так, чтобы был виден SCA
</user_query>


Выносим SCA в отдельный job, чтобы в графе GitHub Actions отображался отдельный шаг. Просматриваю полный workflow:


Разделяем pipeline: отдельный job `sca` будет виден в графе. Job `docker_release` — версия, Chart, build и push; `deploy` — checkout с `git pull`, Vault и Helm. Проверяю имя output у `semanticVersionBump`:


Внося правки: после `git push` Chart.yaml обновляется в новом коммите — в job `deploy` добавляем `git pull`, чтобы подтянуть актуальный чарт.


Кратко, что сделано:

### Граф в GitHub Actions
Теперь на `master` цепочка такая:

1. **`secret_scan`**, **`iac_scan`**, **`sast`** — параллельно
2. **`docker_release`** — бамп версии, правка `Chart.yaml`, commit/push, Docker build + push
3. **`sca`** — отдельный job, в интерфейсе будет отдельный блок **SCA**
4. **`deploy`** — только после успешного **`docker_release`** и **`sca`** (`needs: [docker_release, sca]`)

### Зачем `git pull` в `deploy`
После шага с bump версии в репозиторий уходит **новый коммит**. Новый job делает `checkout` на старый SHA, поэтому перед Vault/Helm добавлен шаг **`Sync repo after version bump commit`** с `git pull --ff-only`, чтобы подтянуть актуальный `.helm/Chart.yaml` и остальные файлы.

### Версия образа в Helm
В `deploy` используется `needs.docker_release.outputs.newVersion` вместо `steps.newVersion.outputs.newVersion`.

### Окружение `stage`
`environment: stage` оставлен только у **`deploy`**. Если секреты вроде `LM_SA_*` привязаны **только** к environment и без него **`docker_release`** не видит их — добавьте `environment: stage` и в **`docker_release`** (учтите, что в GitHub могут появиться **две** точки согласования, если для environment включены ручные approvals).


<user_query>
26s
Run bash .github/scripts/sca-trivy-image.sh
SCA: scanning image docker-local-devsecops.art.lmru.tech/devsecops-vuln-scanner:v0.1.1 with Trivy (docker-security.art.lmru.tech/secapps/trivy-bundle:stable)...
Unable to find image 'docker-security.art.lmru.tech/secapps/trivy-bundle:stable' locally
stable: Pulling from secapps/trivy-bundle
589002ba0eae: Pulling fs layer
b416555f4d2b: Pulling fs layer
06b3d4e016af: Pulling fs layer
0272f312a3f5: Pulling fs layer
4f4fb700ef54: Pulling fs layer
c81d95487562: Pulling fs layer
5104ffed14dc: Pulling fs layer
0272f312a3f5: Waiting
4f4fb700ef54: Waiting
c81d95487562: Waiting
5104ffed14dc: Waiting
b416555f4d2b: Verifying Checksum
b416555f4d2b: Download complete
589002ba0eae: Verifying Checksum
589002ba0eae: Download complete
0272f312a3f5: Download complete
4f4fb700ef54: Verifying Checksum
4f4fb700ef54: Download complete
c81d95487562: Verifying Checksum
c81d95487562: Download complete
589002ba0eae: Pull complete
06b3d4e016af: Verifying Checksum
06b3d4e016af: Download complete
b416555f4d2b: Pull complete
06b3d4e016af: Pull complete
0272f312a3f5: Pull complete
4f4fb700ef54: Pull complete
c81d95487562: Pull complete
5104ffed14dc: Verifying Checksum
5104ffed14dc: Download complete
5104ffed14dc: Pull complete
Digest: sha256:725f501be153c05406b2f6d4814eb4ac3efe7351bb15b43b046367b35b4b7e71
Status: Downloaded newer image for docker-security.art.lmru.tech/secapps/trivy-bundle:stable
{"Version":"0.69.3","VulnerabilityDB":{"Version":2,"NextUpdate":"2026-03-20T12:35:06.232779285Z","UpdatedAt":"2026-03-19T12:35:06.232779536Z","DownloadedAt":"2026-03-30T08:08:25.498059183Z"},"JavaDB":{"Version":1,"NextUpdate":"2026-03-22T01:17:54.39581332Z","UpdatedAt":"2026-03-19T01:17:54.395813642Z","DownloadedAt":"2026-03-30T08:08:54.726741671Z"}}
2026-03-31T14:28:40Z	INFO	[vuln] Vulnerability scanning is enabled
2026-03-31T14:28:40Z	INFO	[secret] Secret scanning is enabled
2026-03-31T14:28:40Z	INFO	[secret] If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2026-03-31T14:28:40Z	INFO	[secret] Please see https://trivy.dev/docs/v0.69/guide/scanner/secret#recommendation for faster secret detection
2026-03-31T14:28:40Z	FATAL	Fatal error	run error: image scan error: scan error: unable to initialize a scan service: unable to initialize artifact: unable to initialize container image: unable to find the specified image "docker-local-devsecops.art.lmru.tech/devsecops-vuln-scanner:v0.1.1" in ["docker" "containerd" "podman" "remote"]: 4 errors occurred:
	* docker error: unable to inspect the image (docker-local-devsecops.art.lmru.tech/devsecops-vuln-scanner:v0.1.1): Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
	* containerd error: containerd socket not found: /run/containerd/containerd.sock
	* podman error: unable to initialize Podman client: no podman socket found: stat podman/podman.sock: no such file or directory
	* remote error: GET https://docker-local-devsecops.art.lmru.tech/v2/devsecops-vuln-scanner/manifests/v0.1.1: MANIFEST_UNKNOWN: The named manifest is not known to the registry.; map[manifest:devsecops-vuln-scanner/v0.1.1/manifest.json]

</user_query>


Проверяю соответствие пути образа в SCA и того, куда `dockerUtils` пушит образ.


Обнаружено несоответствие: Helm и деплой используют `docker-${VAULT_NAMESPACE}.art.lmru.tech` (т.е. `docker-devsecops.art.lmru.tech`), а SCA сканирует `docker-local-devsecops.art.lmru.tech` — это другой репозиторий; образ после push оказывается в `docker-devsecops`, поэтому Trivy получает `MANIFEST_UNKNOWN`.


### В чём была ошибка

В шаге **Deploy** образ задаётся так:

`docker-${{ env.VAULT_NAMESPACE }}.art.lmru.tech/...` → **`docker-devsecops.art.lmru.tech/...`**

А для SCA использовался префикс **`docker-local-devsecops`** — это **другой** реестр/репозиторий в Artifactory. Туда образ после `dockerUtils` не попадает (или попадает иначе), поэтому Trivy по OCI получал **`MANIFEST_UNKNOWN`**.

### Что сделано

В **Export SCA image ref** префикс приведён к тому же, что и в Helm:

`docker-${VAULT_NAMESPACE}.art.lmru.tech/${APP_NAME}` — как в `app.image.repository` при деплое.

После этого SCA сканирует **тот же** тег, что и кластер.

Сообщение про **`Cannot connect to the Docker daemon`** — это про попытки Trivy сходить в локальный Docker; при успешном pull из реестра сканирование идёт по **remote**, без демона.


<user_query>
Run bash .github/scripts/sca-trivy-image.sh
  bash .github/scripts/sca-trivy-image.sh
  shell: /usr/bin/bash -e {0}
  env:
    SCA_QUALITY_GATE: true
    APP_NAME: devsecops-vuln-scanner
    VAULT_NAMESPACE: devsecops
    SCA_IMAGE: docker-devsecops.art.lmru.tech/devsecops-vuln-scanner:v0.1.1
SCA: scanning image docker-devsecops.art.lmru.tech/devsecops-vuln-scanner:v0.1.1 with Trivy (docker-security.art.lmru.tech/secapps/trivy-bundle:stable)...
Unable to find image 'docker-security.art.lmru.tech/secapps/trivy-bundle:stable' locally
stable: Pulling from secapps/trivy-bundle
589002ba0eae: Pulling fs layer
b416555f4d2b: Pulling fs layer
06b3d4e016af: Pulling fs layer
0272f312a3f5: Pulling fs layer
4f4fb700ef54: Pulling fs layer
c81d95487562: Pulling fs layer
5104ffed14dc: Pulling fs layer
0272f312a3f5: Waiting
4f4fb700ef54: Waiting
c81d95487562: Waiting
5104ffed14dc: Waiting
b416555f4d2b: Verifying Checksum
b416555f4d2b: Download complete
589002ba0eae: Verifying Checksum
589002ba0eae: Download complete
0272f312a3f5: Verifying Checksum
0272f312a3f5: Download complete
4f4fb700ef54: Verifying Checksum
4f4fb700ef54: Download complete
c81d95487562: Verifying Checksum
c81d95487562: Download complete
589002ba0eae: Pull complete
06b3d4e016af: Verifying Checksum
06b3d4e016af: Download complete
b416555f4d2b: Pull complete
06b3d4e016af: Pull complete
0272f312a3f5: Pull complete
4f4fb700ef54: Pull complete
c81d95487562: Pull complete
5104ffed14dc: Verifying Checksum
5104ffed14dc: Download complete
5104ffed14dc: Pull complete
Digest: sha256:725f501be153c05406b2f6d4814eb4ac3efe7351bb15b43b046367b35b4b7e71
Status: Downloaded newer image for docker-security.art.lmru.tech/secapps/trivy-bundle:stable
{"Version":"0.69.3","VulnerabilityDB":{"Version":2,"NextUpdate":"2026-03-20T12:35:06.232779285Z","UpdatedAt":"2026-03-19T12:35:06.232779536Z","DownloadedAt":"2026-03-30T08:08:25.498059183Z"},"JavaDB":{"Version":1,"NextUpdate":"2026-03-22T01:17:54.39581332Z","UpdatedAt":"2026-03-19T01:17:54.395813642Z","DownloadedAt":"2026-03-30T08:08:54.726741671Z"}}
2026-03-31T14:36:53Z	INFO	[vuln] Vulnerability scanning is enabled
2026-03-31T14:36:53Z	INFO	[secret] Secret scanning is enabled
2026-03-31T14:36:53Z	INFO	[secret] If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2026-03-31T14:36:53Z	INFO	[secret] Please see https://trivy.dev/docs/v0.69/guide/scanner/secret#recommendation for faster secret detection
2026-03-31T14:36:54Z	INFO	[python] Licenses acquired from one or more METADATA files may be subject to additional terms. Use `--debug` flag to see all affected packages.
2026-03-31T14:36:54Z	INFO	Detected OS	family="debian" version="12.13"
2026-03-31T14:36:54Z	INFO	[debian] Detecting vulnerabilities...	os_version="12" pkg_num=105
2026-03-31T14:36:54Z	INFO	Number of language-specific files	num=1
2026-03-31T14:36:54Z	INFO	[python-pkg] Detecting vulnerabilities...
2026-03-31T14:36:54Z	WARN	Using severities from other vendors for some vulnerabilities. Read https://trivy.dev/docs/v0.69/guide/scanner/vulnerability#severity-selection for details.
2026-03-31T14:36:54Z	FATAL	Fatal error	run error: report error: unable to write results: failed to create a file: failed to create output file: open report.json: permission denied
</user_query>


Процесс внутри `trivy-bundle` не может писать в смонтированный `$GITHUB_WORKSPACE` из‑за несовпадения UID/GID. Добавляем `docker run --user "$(id -u):$(id -g)"`.


Trivy в образе, вероятно, запускается не от root; смонтированный workspace принадлежит пользователю раннера — из‑за этого запись в `/work` запрещена. Запускаем контейнер с `--user "$(id -u):$(id -g)"` и переносим `TRIVY_CACHE_DIR` в `/tmp`, чтобы кэш был доступен при несовпадении с `/home/trivy`.


Сделано.

**Почему падало:** в контейнере Trivy шёл не под тем UID/GID, что владелец `$GITHUB_WORKSPACE` на раннере, поэтому создание `report.json` в `/work` давало `permission denied`.

**Что изменено:**
- `--user "$(id -u):$(id -g)"` — процесс в контейнере совпадает с пользователем раннера, файлы в репозитории создаются с нужными правами.
- `TRIVY_CACHE_DIR=/tmp/trivy-cache` вместо `/home/trivy/.cache/...` — при «чужом» UID домашний каталог `trivy` в образе для кэша не подходит.

Локально скрипт по-прежнему работает: `id` берёт вашего пользователя.


<user_query>
Что изменено:

--user "$(id -u):$(id -g)" — процесс в контейнере совпадает с пользователем раннера, файлы в репозитории создаются с нужными правами.
TRIVY_CACHE_DIR=/tmp/trivy-cache вместо /home/trivy/.cache/... — при «чужом» UID домашний каталог trivy в образе для кэша не подходит.
Локально скрипт по-прежнему работает: id берёт вашего пользователя.

а так безопасно?
</user_query>


Да, для CI это нормальная и привычная схема.

**`--user "$(id -u):$(id -g)"`**
- Контейнер **не** работает от root на хосте и **не** пишет в смонтированный репозиторий от имени root — как раз так избегают «чужих» прав на файлах.
- Процесс получает те же UID/GID, что и job на раннере — ровно то, что нужно для записи в `$GITHUB_WORKSPACE`.
- Риски те же, что и у любого шага CI с доступом к репо: Trivy по-прежнему только сканирует образ и пишет отчёты; вы не даёте ему лишних привилегий по сравнению с обычным `run:` в том же job.

**`TRIVY_CACHE_DIR=/tmp/trivy-cache`**
- Кэш БД уязвимостей лежит во **временной** ФС контейнера; после `docker run` он исчезает.
- Там нет секретов приложения — только то, что Trivy скачал для сканирования (как и при стандартном пути в `/home/trivy/.cache`).

**Итог:** с точки зрения «не запускать сканер под root на смонтированный каталог» так даже **строже**, чем дефолт образа, который ломал права. Для продакшен-рантайма приложения это не относится — это только изолированный шаг пайплайна на агенте CI.


<user_query>
Digest: sha256:725f501be153c05406b2f6d4814eb4ac3efe7351bb15b43b046367b35b4b7e71
Status: Downloaded newer image for docker-security.art.lmru.tech/secapps/trivy-bundle:stable
{"Version":"0.69.3"}
2026-03-31T14:47:34Z	ERROR	[vulndb] The first run cannot skip downloading DB
2026-03-31T14:47:34Z	FATAL	Fatal error	run error: init error: DB error: database error: --skip-db-update cannot be specified on the first run
</user_query>


Кэш перенесён в `/tmp/trivy-cache` — при каждом `docker run` он пустой, поэтому для Trivy это всегда «первый запуск», и `--skip-db-update` недопустим. Удаляем эти флаги (или предварительно загружаем БД без `--skip-db-update`).


Удаляю `--skip-db-update` и `--skip-java-db-update`. При пустом кэше (`/tmp` в каждом контейнере новый) Trivy обязан скачать БД.


Кратко, что было не так:

**`--skip-db-update`** имеет смысл только если кэш Trivy уже есть (например, повторный запуск на той же машине). У вас кэш в **`/tmp/trivy-cache`** внутри контейнера — при каждом `docker run` каталог **пустой**, для Trivy это всегда первый запуск, и флаг `--skip-db-update` запрещён.

Флаги убраны: при сканировании при необходимости подтянется vuln DB (и при необходимости Java DB). Первый прогон станет чуть дольше из‑за скачивания БД.

Если позже понадобится ускорить повторные прогоны, можно задать **постоянный** кэш в workspace, например `TRIVY_CACHE_DIR=/work/.trivy-cache`, создать каталог до `docker run` и при желании снова включить `--skip-db-update` только когда кэш уже заполнен (отдельная проверка в скрипте).