kubescape / kubescape/github-action

entrypoint computes --use-artifacts-from and then discards it, so a pinned action still evaluates live rules

Open
#80 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Shell
Stars
24
Forks
26
PR merge metrics
No merged PRs in 30d

Description

### Summary

`entrypoint.sh` builds an `--use-artifacts-from` option and then leaves it out of the command it runs, so every scan downloads the rule library at run time. A workflow that pins this action by SHA still gets whatever rules the library serves that day.

### Where

`entrypoint.sh` computes the option:

```sh
artifacts_path="/home/ks/.kubescape"
artifacts_opt=$([ -n "${INPUT_ACCOUNT}" ] && echo "" || echo --use-artifacts-from "${artifacts_path}")
```

and then omits it:

```sh
# TODO: include artifacts_opt once https://github.com/kubescape/kubescape/issues/1040 is resolved
scan_command="kubescape scan ${image_subcmd} ${frameworks_cmd} ${controls_cmd} ${scan_input} ..."
```

Two things about that TODO:

1. **kubescape/kubescape#1040 has been closed since January 2023.** The blocker it waits on is long resolved. `--use-artifacts-from` works on the CLI this action ships: I ran `kubescape download artifacts` followed by `kubescape scan framework nsa,mitre --use-artifacts-from ` on v3.0.21 and it evaluated the same 30 controls with identical per-control results as the downloading path.
2. **The path it points at does not exist in the image.** `quay.io/kubescape/kubescape-cli:v3.0.21` has no `/home/ks`:

```
$ docker run --rm --entrypoint sh quay.io/kubescape/kubescape-cli:v3.0.21 -c 'ls -la /home/ks'
ls: /home/ks: No such file or directory
```

So even if the option were passed today it would point at nothing.

### Impact

A pipeline that gates on `complianceThreshold` or on the compliance score cannot distinguish a real posture regression from a rule change. Concretely, two scans of the same manifests three hours apart, same action SHA, same reported `kubescapeVersion`, disagreed: one control went from 1 failing resource to 64 as a rule gained a clause under an unchanged name. Nothing in the report records a rule-library version, so there is no way to attribute the change from the output alone.

### Suggested fix

Either pass `artifacts_opt` again now that #1040 is closed and ship the artifacts in the image at that path, or expose the artifacts directory as an action input so a caller can vendor its own.

### A related surprise, worth documenting either way

`--use-artifacts-from` reads exceptions from `/exceptions.json` and silently ignores `--exceptions`. Passing both makes a valid exceptions file look broken: the scan reports zero ignored resources and no error. If the option is reinstated, callers using the `exceptions` input will need this handled or documented.

Contributor guide

Open the contributing guide

Research direction

Start with entrypoint.sh, especially the artifacts_opt assignment and scan_command construction, then inspect the referenced Kubescape CLI behavior for --use-artifacts-from and exceptions.json. Verify the action image's artifact path and the existing exceptions input flow. Done means pinned scans use a defined artifact source consistently, with the interaction with exceptions handled or documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, shell
Domain
ci-cd, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.