chore(deps): bump soldevelo/infrascan from 1.2.0 to 1.2.2 in the github-actions-dependencies group

[dependabot]

Bumps the github-actions-dependencies group with 1 update: soldevelo/infrascan.

Updates soldevelo/infrascan from 1.2.0 to 1.2.2

Release notes

Sourced from soldevelo/infrascan's releases.

InfraScan v1.2.2

InfraScan 1.2.2 Release Notes

This release contains all changes since v1.2.1.

Highlights

• New fail-on thresholds that only count what a PR adds: new_high_critical, new_critical, new_any. The existing thresholds count every finding in the repository, so in a repo with even one existing HIGH finding fail-on: high_critical fails every PR, including ones that don't touch infrastructure. The new_* thresholds compare against the baseline (the same comparison the PR comment's "New findings" uses) and fail only on findings the PR introduces. With no baseline — a push to the default branch, or a PR whose base branch couldn't be scanned — they're skipped with a notice in the log instead of treating every existing finding as new. The examples now use new_high_critical.
• fail-on defaults to an explicit never in the GitHub Action and the Bitbucket pipe (same behaviour as before: no threshold, no failure).
• Variables in compose image names are expanded the way docker compose does. image: prom/prometheus:${PROMETHEUS_VERSION} used to be resolved only from the scanner's own environment, so in CI such images were reported as unscannable. InfraScan now reads the environment, then .env, then the committed .env.example / .env.sample (since .env is usually gitignored), looked for next to the compose file and in parent directories. Supports $VAR, ${VAR}, ${VAR:-default}, ${VAR-default}. Values are only used to expand image names and are never exported — a placeholder like SLACK_WEBHOOK_URL in .env.example has no effect. An image with a variable that still can't be resolved is reported as not scanned, naming the variable. The file list is configurable with CONTAINER_ENV_FILES / container-env-files (e.g. deploy/versions.env,.env.sample).
• Configurable per-image container scan timeout: CONTAINER_SCAN_TIMEOUT / container-scan-timeout, default 300 s (previously a fixed 240 s for Grype and 120 s for Docker Scout). The limit covers the pull and the analysis, and for large images the analysis dominates — e.g. grafana/grafana: ~40 s to pull, ~3 min in Syft's binary cataloger, so it didn't fit in 240 s. A timed-out image is reported as not scanned, with a hint to raise the limit.

Fixes

• GitHub Action: skip-if-no-match never skipped a scan. It diffed against origin/<base>, which actions/checkout's default shallow clone doesn't fetch, so the diff was always empty and the scan always ran. The action now fetches the PR's base commit (depth 1) and diffs against it. If that fetch fails, the scan still runs.
• Grype: one image timing out skipped the rest of Docker Hub. 1.2.1 skips the remaining images of a registry after it proves unreachable, but its own per-image timeout counted as "unreachable" — so one slow, large image on Docker Hub caused every later Docker Hub image to be skipped, even after earlier ones had been scanned. A registry that has already served an image in the run is no longer blocked, and the per-image timeout never blocks Docker Hub.
• Workflow examples (README, docs/GITHUB_ACTION.md, docs/PIPELINE_INTEGRATION.md): push runs only on the default branch (that run saves the baseline PRs compare against; on every branch it duplicated each PR's scan), and contents: read is included — once a workflow sets permissions:, everything unlisted is none, and actions/checkout then fails on private repositories.

Notes

• The application version has been updated to 1.2.2.
• Workflows that generated an env file before the scan just to expand compose image versions can drop that step — .env.example / .env.sample are picked up automatically. See "Container scanning" in docs/BITBUCKET_PIPELINE.md and the inputs table in docs/GITHUB_ACTION.md.

v1.2.1

InfraScan 1.2.1 Release Notes

This release contains all changes since v1.2.0.

Highlights

• Images that can't be scanned are now reported, not counted as clean. Previously, if Grype couldn't pull an image (private registry unreachable from the CI runner, missing credentials, tag that doesn't exist), the image silently contributed zero findings. Now each one is listed with its reason in the build log, the PR comment and the step summary / Code Insights report ("K of M container images could not be scanned"). After the first unreachable or unauthorized registry, its remaining images are skipped instead of each one waiting out a timeout.
• Grype is picked automatically when there are no Docker Hub credentials. Docker Scout needs a Docker login even on a free account, so without one every image first failed with Scout before falling back to Grype. Pass credentials to keep using Scout (fewer false positives): docker-hub-username / docker-hub-password inputs (GitHub Action) or DOCKER_HUB_USERNAME / DOCKER_HUB_PASSWORD (Bitbucket pipe). The pipe also gets CONTAINER_SCANNER to force either scanner.
• New container-ignore-images / CONTAINER_IGNORE_IMAGES: a regex of images to skip, e.g. -SNAPSHOT$ for images the repo builds itself and only publishes after merge — on a PR the registry only has the previous build, so scanning it is misleading.
• Grype vulnerability DB cache (saves a ~2.5 min download per run). GitHub Action: automatic, keyed on the date, so the DB is refreshed once a day. Bitbucket: opt-in infrascan-grype-db cache (added to all examples); when Anchore publishes a newer DB, the pipe replaces the cache through the step's local auth proxy, with BITBUCKET_ACCESS_TOKEN as a fallback. Scans always use a current DB either way — the cache only decides whether a download is needed.

Fixes

• Bitbucket: stale baseline gave wrong PR deltas. Bitbucket never overwrites an existing cache, so the baseline saved on the first default-branch run was reused for up to a week while the branch kept changing. The baseline now carries a fingerprint of the scanned files; when a PR's target branch has changed since, the pipe scans the target branch directly for that PR's delta.
• Bitbucket: the no-cache baseline fallback didn't work inside the pipe container (git "dubious ownership", the clone's origin proxy unreachable from the pipe, no write access to .git). It now reads and fetches the target branch without touching the clone.
• Bitbucket: a declared Grype DB cache without the chmod line scanned no images at all. The pipe now ignores a cache directory it can't write to (with a hint in the log) and downloads the DB as if no cache were declared. Pipelines without any caches work out of the box, just slower.
• GitHub Action: the baseline was rescanned on every PR. It was only ever saved by PR runs, and GitHub scopes a cache saved by a PR to that PR alone — no other PR could restore it. Pushes to the default branch now save their scan as the baseline for that commit, so PRs targeting it restore it instead of scanning the base branch again. A PR scan failing via fail-on also no longer skips saving the baseline or the step summary.
• GitHub Action: the baseline scan ignored directory, scanner and framework, so a PR scan with non-default settings was compared against a differently-scanned baseline and reported false "new" findings. Both scans now use the same settings.
• Findings tables showed only the file's basename, not its path — in a repo with many services each having their own docker-compose.yml/Dockerfile (common in a monorepo), every entry looked identical (e.g. docker-compose.yml:7) with no way to tell which service a finding actually belonged to. The step summary's findings/cost-savings tables and the PR comment's "New findings" table now show the full relative path.
• GitHub Actions inline annotations could be dropped non-deterministically. GitHub Actions caps annotations at 10 errors / 10 warnings / 10 notices per step, and silently keeps only "a random subset" beyond that with no indication anything was cut. A repo with more than 10 CRITICAL (or HIGH, or cost-delta) findings would get an arbitrary subset shown as inline annotations from run to run. Findings are already severity-sorted, so InfraScan now stops at 10 per level itself — the ones that do show up are deterministically the most severe, not whatever GitHub happened to keep. Doesn't affect grading, the PR comment, or the step summary, which already show the full set.

Notes

• The application version has been updated to 1.2.1.
• Bitbucket users can add the Grype DB cache to their pipeline — see "Grype DB cache" in docs/BITBUCKET_PIPELINE.md. No token permission changes are needed.

Changelog

Sourced from soldevelo/infrascan's changelog.

InfraScan 1.2.1 Release Notes

This release contains all changes since v1.2.0.

Highlights

• Images that can't be scanned are now reported, not counted as clean. Previously, if Grype couldn't pull an image (private registry unreachable from the CI runner, missing credentials, tag that doesn't exist), the image silently contributed zero findings. Now each one is listed with its reason in the build log, the PR comment and the step summary / Code Insights report ("K of M container images could not be scanned"). After the first unreachable or unauthorized registry, its remaining images are skipped instead of each one waiting out a timeout.
• Grype is picked automatically when there are no Docker Hub credentials. Docker Scout needs a Docker login even on a free account, so without one every image first failed with Scout before falling back to Grype. Pass credentials to keep using Scout (fewer false positives): docker-hub-username / docker-hub-password inputs (GitHub Action) or DOCKER_HUB_USERNAME / DOCKER_HUB_PASSWORD (Bitbucket pipe). The pipe also gets CONTAINER_SCANNER to force either scanner.
• New container-ignore-images / CONTAINER_IGNORE_IMAGES: a regex of images to skip, e.g. -SNAPSHOT$ for images the repo builds itself and only publishes after merge — on a PR the registry only has the previous build, so scanning it is misleading.
• Grype vulnerability DB cache (saves a ~2.5 min download per run). GitHub Action: automatic, keyed on the date, so the DB is refreshed once a day. Bitbucket: opt-in infrascan-grype-db cache (added to all examples); when Anchore publishes a newer DB, the pipe replaces the cache through the step's local auth proxy, with BITBUCKET_ACCESS_TOKEN as a fallback. Scans always use a current DB either way — the cache only decides whether a download is needed.

Fixes

• Bitbucket: stale baseline gave wrong PR deltas. Bitbucket never overwrites an existing cache, so the baseline saved on the first default-branch run was reused for up to a week while the branch kept changing. The baseline now carries a fingerprint of the scanned files; when a PR's target branch has changed since, the pipe scans the target branch directly for that PR's delta.
• Bitbucket: the no-cache baseline fallback didn't work inside the pipe container (git "dubious ownership", the clone's origin proxy unreachable from the pipe, no write access to .git). It now reads and fetches the target branch without touching the clone.
• Bitbucket: a declared Grype DB cache without the chmod line scanned no images at all. The pipe now ignores a cache directory it can't write to (with a hint in the log) and downloads the DB as if no cache were declared. Pipelines without any caches work out of the box, just slower.
• GitHub Action: the baseline was rescanned on every PR. It was only ever saved by PR runs, and GitHub scopes a cache saved by a PR to that PR alone — no other PR could restore it. Pushes to the default branch now save their scan as the baseline for that commit, so PRs targeting it restore it instead of scanning the base branch again. A PR scan failing via fail-on also no longer skips saving the baseline or the step summary.
• GitHub Action: the baseline scan ignored directory, scanner and framework, so a PR scan with non-default settings was compared against a differently-scanned baseline and reported false "new" findings. Both scans now use the same settings.
• Findings tables showed only the file's basename, not its path — in a repo with many services each having their own docker-compose.yml/Dockerfile (common in a monorepo), every entry looked identical (e.g. docker-compose.yml:7) with no way to tell which service a finding actually belonged to. The step summary's findings/cost-savings tables and the PR comment's "New findings" table now show the full relative path.
• GitHub Actions inline annotations could be dropped non-deterministically. GitHub Actions caps annotations at 10 errors / 10 warnings / 10 notices per step, and silently keeps only "a random subset" beyond that with no indication anything was cut. A repo with more than 10 CRITICAL (or HIGH, or cost-delta) findings would get an arbitrary subset shown as inline annotations from run to run. Findings are already severity-sorted, so InfraScan now stops at 10 per level itself — the ones that do show up are deterministically the most severe, not whatever GitHub happened to keep. Doesn't affect grading, the PR comment, or the step summary, which already show the full set.

Notes

• The application version has been updated to 1.2.1.
• Bitbucket users can add the Grype DB cache to their pipeline — see "Grype DB cache" in docs/BITBUCKET_PIPELINE.md. No token permission changes are needed.

Commits

• d014b41 chore: release v1.2.2
• 43dd49b Configurable container scan timeout and compose env files
• 23b7798 Expand compose image variables from .env / .env.example
• b7b184e Add new_* fail-on thresholds and make never the explicit default
• 60794a1 Fix skip-if-no-match and update workflow examples
• c2d8ed8 docs: use absolute link in 1.2.1 release notes
• b56fffa chore: release v1.2.1
• 1148700 Fix GitHub Action baseline and Grype DB cache
• 437d3be Report unscanned images, cache Grype DB, fix stale Bitbucket baseline
• 6d919cb Cap GitHub annotations at 10 per level and show full file paths in PR comment...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[github-actions]

Dependency Review

The following issues were found:

• ✅ 0 vulnerable package(s)
• ✅ 0 package(s) with incompatible licenses
• ✅ 0 package(s) with invalid SPDX license definitions
• ⚠️ 1 package(s) with unknown licenses.

See the Details below.

License Issues

.github/workflows/infrascan-security-audit.yml

Package	Version	License	Issue Type
soldevelo/infrascan	d014b41beb18257680965b5c07d9d53de53bc042	Null	Unknown License

OpenSSF Scorecard

Package	Version	Score	Details
actions/soldevelo/infrascan	d014b41beb18257680965b5c07d9d53de53bc042	Unknown	Unknown

Scanned Files

• .github/workflows/infrascan-security-audit.yml

[dependabot]

This pull request was built based on a group rule. Closing it will not ignore any of these versions in future pull requests.

To ignore these dependencies, configure ignore rules in dependabot.yml