bompage 1.2.2__tar.gz → 1.3.0__tar.gz

{bompage-1.2.2 → bompage-1.3.0}/.gitignore

@@ -31,4 +31,5 @@ wheels/
 /docs/superpowers/
 /styles/
 /Taskfile.d/
+AGENTS.md
 CLAUDE.md

{bompage-1.2.2 → bompage-1.3.0}/.gitlab-ci.yml

@@ -12,9 +12,9 @@ workflow:
         # semantic-release created the tag. On the tag pipeline only the release
         # jobs matter, and none of them gate on lint/test anyway (each has an
         # explicit `needs:`). DISABLE_JOBS switches off every op_so lint/test
-        # job; the four jobs the release needs re-enable themselves below
-        # (prepare-uv:sync, publish-pypi-uv, pages, push-sbom). build-web has no
-        # DISABLE_JOBS guard, so it survives as-is.
+        # job; the jobs the release needs re-enable themselves below
+        # (prepare-uv:sync, publish-pypi-uv, pages, generate-sbom, bompage-push).
+        # build-web has no DISABLE_JOBS guard, so it survives as-is.
         DISABLE_JOBS: "true"
     - if: $CI_COMMIT_BRANCH
   # Superseded pipelines abandon their still-running interruptible jobs when a
@@ -45,11 +45,11 @@ variables:
   TASK_VERSION: "v3.53.1"
   IMAGE_UV: ghcr.io/astral-sh/uv:python${PYTHON_VERSION}-trixie-slim
   IMAGE_NODE: node:24-trixie-slim
-  # Trivy generates bompage's own release SBOM in the `push-sbom` job. Pinned so
-  # re-running an old tag is reproducible; Renovate bumps it (custom manager in
-  # renovate.json).
+  # Trivy generates bompage's own release SBOM in the `generate-sbom` job. Pinned
+  # so re-running an old tag is reproducible; Renovate bumps it (custom manager
+  # in renovate.json).
   TRIVY_VERSION: "0.74.0"
-  # Node binary installed directly in the `push-sbom` job (a Python-image job):
+  # Node binary installed directly in the `generate-sbom` job (a Python-image job):
   # Trivy's pnpm analyzer only reads license data from an installed
   # `node_modules`, not from `pnpm-lock.yaml` alone. Pinned like TRIVY_VERSION
   # above; Renovate bumps it (custom manager in renovate.json). pnpm itself
@@ -94,6 +94,26 @@ include:
     inputs:
       publish_pypi_uv_python_version: "3.14"
       publish_pypi_uv_stage: pypi-release
+  # Only the `bompage-push` job is used here: `bompage_pages_enabled`/
+  # `bompage_prune_enabled` are turned off because the component unconditionally
+  # also defines a `pages` job (this repo already has its own, for the mkdocs
+  # docs site -- a same-name collision) and a `bompage-prune` job (which would
+  # otherwise fire on this repo's own scheduled Renovate pipeline and try to
+  # prune "$CI_PROJECT_URL.git", the wrong repository). Both belong only to the
+  # central sbom-bompage repo's own inclusion (deploy/.gitlab-ci.yml).
+  #
+  # `bompage_push_repo` is a literal, not `${VARIABLE}`: like the
+  # `*_python_version` inputs above, `include: inputs:` cannot reference this
+  # file's own `variables:` block (see the note on `include:` above).
+  - component: gitlab.com/op_so/components/pages/bompage@v1.0.0
+    inputs:
+      bompage_push_stage: sbom-release
+      bompage_push_repo: "https://gitlab.com/op_so/pages/sbom-bompage.git"
+      bompage_push_component: bompage
+      bompage_push_sbom: sbom.cdx.json
+      bompage_push_sbom_format: cyclonedx
+      bompage_pages_enabled: false
+      bompage_prune_enabled: false
 
 stages:
   - prepare-uv
@@ -104,6 +124,10 @@ stages:
   - pypi-release
   - pages-release
   - sbom-release
+  # The bompage component always declares `bompage-prune` in this stage, even
+  # with `bompage_prune_enabled: false`; the stage must exist or the whole
+  # pipeline is rejected. The job itself never runs here.
+  - prune
   - renovate
 
 # Shared pnpm setup for the dashboard sources (web-src/). corepack reads the
@@ -239,7 +263,7 @@ test-e2e:
   rules: *skip-when-jobs-disabled
   before_script:
     # Pinned uv release tarball, same reasoning and shape as the Trivy / Node
-    # installs in `push-sbom`: `curl … | sh` returns 0 when the download fails
+    # installs in `generate-sbom`: `curl … | sh` returns 0 when the download fails
     # (the installer just gets an empty script) and the job then dies later on a
     # confusing "uv: not found".
     - |
@@ -303,7 +327,7 @@ test-e2e:
     policy: pull
   interruptible: true
 
-# Required by publish-pypi-uv / pages / push-sbom, so it must survive the
+# Required by publish-pypi-uv / pages / generate-sbom, so it must survive the
 # DISABLE_JOBS switch the tag pipeline sets in `workflow:` above (the component
 # ships `- if: $DISABLE_JOBS == "true" when: never` as its first rule).
 prepare-uv:sync:
@@ -400,47 +424,23 @@ pages:
   rules:
     - if: $CI_COMMIT_TAG
 
-# Dogfooding: on a release tag, generate bompage's own SBOM with Trivy and
-# publish it into the central SBOM repository via `bompage push` (spec sections 5
-# and 9). The released version is carried two ways: `uv lock` restamps it into
-# uv.lock so Trivy records it as the SBOM's root component version, and
-# `--sbom-version` puts it in the snapshot name
-# (reports/bompage/sbom-YYYYMMDD-<version>.json) and the commit message.
-# `push_report`'s anti-noise filter skips the commit when the dependency set is
-# byte-identical to the previous snapshot.
-#
-# Requires a masked CI/CD variable BOMPAGE_TOKEN: a project/group access token
-# scoped to write_repository on gitlab.com/op_so/pages/sbom-bompage only (spec
-# section 5.3). `bompage push` reads it from that variable.
-#
-# Signed (attestation spec section 6.3): a masked, protected CI/CD variable
-# BOMPAGE_SIGN_KEY on this project holds the private ed25519 key (see
-# deploy/README.md's "Attestation" section for how it was generated and how
-# its public half was added to `trust/allowed_signers` in the central
-# gitlab.com/op_so/pages/sbom-bompage repository). `bompage push` picks it up
-# on its own (`--sign-key` reads the BOMPAGE_SIGN_KEY env var by default, same
-# mechanism as BOMPAGE_TOKEN above) -- but it shells out to `ssh-keygen` to do
-# the signing (attest.py), so `openssh-client` must be installed below like
-# every other job in this file that touches git/signing.
-push-sbom:
+# Dogfooding: on a release tag, generate bompage's own SBOM with Trivy (spec
+# sections 5 and 9). The released version is carried two ways: `uv lock`
+# restamps it into uv.lock so Trivy records it as the SBOM's root component
+# version, and the `bompage-push` job below (from the
+# gitlab.com/op_so/components/pages/bompage component) puts it in the snapshot
+# name (reports/bompage/sbom-YYYYMMDD-<version>.json) and the commit message via
+# its own `--sbom-version`. `push_report`'s anti-noise filter skips the commit
+# when the dependency set is byte-identical to the previous snapshot.
+generate-sbom:
   extends: .abstract-uv
   stage: sbom-release
-  # Pushes to an external repository: not interruptible.
-  interruptible: false
   needs:
     - job: "prepare-uv:sync"
       artifacts: true
-    # Only publish the SBOM once the release itself has shipped to PyPI.
-    # `optional` keeps non-tag pipelines (where neither job runs) valid.
-    - job: publish-pypi-uv
-      artifacts: false
-      optional: true
-  variables:
-    # Central repository that hosts bompage's SBOM history.
-    BOMPAGE_REPO: "https://gitlab.com/op_so/pages/sbom-bompage.git"
   before_script:
     - *install-task  # curl + ca-certificates + task
-    - DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends git xz-utils openssh-client
+    - DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends xz-utils
     # Pinned Trivy release tarball (no `curl | sh`): reproducible, fails loudly.
     # Asset suffix is Linux-64bit (amd64) or Linux-ARM64 depending on the runner.
     - |
@@ -484,7 +484,6 @@ push-sbom:
     - PNPM_VERSION="$(node -e "console.log(require('./package.json').packageManager.split('@')[1])")"
     - npm install --global "pnpm@${PNPM_VERSION}"
     - pnpm install --frozen-lockfile --prod
-    - 'test -n "$BOMPAGE_TOKEN" || { echo "ERROR: CI/CD variable BOMPAGE_TOKEN is unset or empty" >&2; exit 1; }'
     # `.venv` (bompage installed editable) matches the committed 0.0.0 lock here;
     # stamp the real version afterwards and relock so uv.lock carries it before
     # Trivy reads it as the SBOM's root component version.
@@ -509,19 +508,38 @@ push-sbom:
     # `licenses` fields, by purl, for packages the `fs` scan above already kept.
     - trivy rootfs --quiet --format cyclonedx --scanners license --offline-scan --output sbom-rootfs.cdx.json .
     - uv run --no-sync python scripts/merge_sbom_licenses.py sbom-fs.cdx.json sbom-rootfs.cdx.json --output sbom.cdx.json
-    - >
-      uv run --no-sync bompage push
-      --component bompage
-      --sbom sbom.cdx.json
-      --repo "$BOMPAGE_REPO"
-      --branch main
-      --sbom-version "${CI_COMMIT_TAG#v}"
-      --sbom-format cyclonedx
-      --source-project "$CI_PROJECT_URL"
-      --source-commit "$CI_COMMIT_SHA"
-      --source-ref "$CI_COMMIT_TAG"
-      --ci-job-url "$CI_JOB_URL"
+  artifacts:
+    paths:
+      - sbom.cdx.json
+    expire_in: 1 day
   # No $DISABLE_JOBS guard: the tag pipeline sets DISABLE_JOBS to switch off
-  # lint/test (see `workflow:`), and the SBOM push must still run.
+  # lint/test (see `workflow:`), and the SBOM generation must still run so
+  # `bompage-push` below has something to push.
+  rules:
+    - if: $CI_COMMIT_TAG
+
+# `bompage-push` is defined by the gitlab.com/op_so/components/pages/bompage
+# component included above. Its default `rules:` skip the job when
+# $DISABLE_JOBS == "true" -- but that variable is set to "true" exactly on the
+# tag pipeline (see `workflow:` at the top of this file), i.e. exactly when the
+# push must run. Overridden here the same way `publish-pypi-uv`/`pages` already
+# override the same component-supplied guard elsewhere in this file.
+#
+# Signing (attestation spec section 6.3): a masked, protected CI/CD variable
+# BOMPAGE_SIGN_KEY on this project holds the private ed25519 key (see
+# deploy/README.md's "Attestation" section for how it was generated and how
+# its public half was added to `trust/allowed_signers` in the central
+# gitlab.com/op_so/pages/sbom-bompage repository). `bompage push` picks it up
+# on its own from the environment -- the component does not need to know about
+# it, same as BOMPAGE_TOKEN.
+bompage-push:
+  needs:
+    - job: generate-sbom
+      artifacts: true
+    # Only publish the SBOM once the release itself has shipped to PyPI.
+    # `optional` keeps non-tag pipelines (where neither job runs) valid.
+    - job: publish-pypi-uv
+      artifacts: false
+      optional: true
   rules:
     - if: $CI_COMMIT_TAG

{bompage-1.2.2 → bompage-1.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: bompage
-Version: 1.2.2
+Version: 1.3.0
 Summary: A generic, server-less system to track SBOM history of N components and publish a static dashboard
 Project-URL: Homepage, https://gitlab.com/op_so/pages/bompage
 Project-URL: Documentation, https://op_so.gitlab.io/pages/bompage/
@@ -163,17 +163,19 @@ a signed attestation sidecar (`.att` / `.att.sig`) beside the SBOM, which
 changes — signing is entirely opt-in.
 
 On GitLab you usually do not call it by hand — include the ready-made
-component instead:
+`bompage-push` job instead (signing, if `BOMPAGE_SIGN_KEY` is set in the
+project, is picked up automatically — see `deploy/README.md`):
 
 ```yaml
+stages:
+  - sbom-release # bompage_push_stage default; declare it or override the input
+
 include:
-  - component: gitlab.com/op_so/pages/bompage/push-report@v1
+  - component: gitlab.com/op_so/components/pages/bompage@v1.0.0
     inputs:
-      component: app-api
-      sbom_path: build/sbom.cdx.json
-      bompage_repo: https://gitlab.com/acme/bompage.git
-      bompage_version: "1.2.3"
-      bompage_sign_key_var: BOMPAGE_SIGN_KEY # optional, see deploy/README.md
+      bompage_push_repo: https://gitlab.com/acme/bompage.git
+      bompage_push_component: app-api
+      bompage_push_sbom: build/sbom.cdx.json
 ```
 
 ### `bompage prune` — keep the repository small

{bompage-1.2.2 → bompage-1.3.0}/README.md

@@ -134,17 +134,19 @@ a signed attestation sidecar (`.att` / `.att.sig`) beside the SBOM, which
 changes — signing is entirely opt-in.
 
 On GitLab you usually do not call it by hand — include the ready-made
-component instead:
+`bompage-push` job instead (signing, if `BOMPAGE_SIGN_KEY` is set in the
+project, is picked up automatically — see `deploy/README.md`):
 
 ```yaml
+stages:
+  - sbom-release # bompage_push_stage default; declare it or override the input
+
 include:
-  - component: gitlab.com/op_so/pages/bompage/push-report@v1
+  - component: gitlab.com/op_so/components/pages/bompage@v1.0.0
     inputs:
-      component: app-api
-      sbom_path: build/sbom.cdx.json
-      bompage_repo: https://gitlab.com/acme/bompage.git
-      bompage_version: "1.2.3"
-      bompage_sign_key_var: BOMPAGE_SIGN_KEY # optional, see deploy/README.md
+      bompage_push_repo: https://gitlab.com/acme/bompage.git
+      bompage_push_component: app-api
+      bompage_push_sbom: build/sbom.cdx.json
 ```
 
 ### `bompage prune` — keep the repository small

bompage-1.3.0/deploy/.gitlab-ci.yml

@@ -0,0 +1,55 @@
+---
+# CI for the CENTRAL bompage repository (not the Python package repo).
+#
+# - On a push to the default branch: rebuild and republish the static dashboard
+#   (spec-bompage.md sections 3 and 8).
+# - On a *scheduled* pipeline: run `bompage prune` to drop SBOM snapshots older
+#   than the retention depth (spec section 5.4). Its commit lands on the default
+#   branch and triggers a fresh pipeline whose `pages` job republishes.
+#
+# Both jobs come from the gitlab.com/op_so/components/pages/bompage CI/CD
+# component (its image bundles the bompage CLI, git and ssh-keygen -- no more
+# per-job `pip install bompage==...`).
+#
+# CI/CD variables:
+#   BOMPAGE_TOKEN  required by both jobs; scoped token with write_repository on
+#                  THIS repository. Must be a project/group access token or PAT
+#                  -- the prune commit is pushed with it, and only a real token
+#                  (not CI_JOB_TOKEN) makes that push start the follow-up
+#                  pipeline whose `pages` job republishes the dashboard.
+
+# Interruptible by default so superseded pipelines free their runners; the prune
+# job opts out because it commits and pushes. Retries cover only causes that are
+# never the code itself: infra hiccups plus transient GitLab API failures.
+default:
+  interruptible: true
+  retry:
+    max: 2
+    when:
+      - api_failure
+      - runner_system_failure
+      - stuck_or_timeout_failure
+      - scheduler_failure
+
+include:
+  - component: gitlab.com/op_so/components/pages/bompage@v1.0.0
+    inputs:
+      # `--metadata` rows fill the dashboard header. A value that is an http(s)
+      # URL is rendered as a link, so point readers at where the data comes
+      # from: this repository, the pipeline that built the page, and the tool
+      # itself. Drop or replace any of them -- they are an example, not a
+      # requirement. `--allowed-signers` is this repository's trust root
+      # (attestation spec section 5); passed explicitly even though it matches
+      # the default (`<reports>/../trust/allowed_signers`) so a reader does not
+      # have to know that default to see where verification gets its keys
+      # from. An empty or placeholder trust/allowed_signers (see that file)
+      # simply makes every verdict read `unknown` -- it never fails the build.
+      bompage_pages_metadata: >-
+        --allowed-signers trust/allowed_signers
+        --metadata "Repository=$CI_PROJECT_URL"
+        --metadata "Pipeline=$CI_PIPELINE_URL"
+        --metadata "Built with=https://gitlab.com/op_so/pages/bompage"
+
+stages:
+  - prune
+  - pages

{bompage-1.2.2 → bompage-1.3.0}/deploy/README.md

@@ -17,7 +17,7 @@ trust/
   allowed_signers                  # trust root for SBOM attestation verification (optional, see below)
 web/                               # optional: a full built page (index.html + assets/) that
                                    # replaces the packaged dashboard, via `bompage build --web-dir web`
-.gitlab-ci.yml                     # pages job: install bompage, run `bompage build`, publish public/
+.gitlab-ci.yml                     # includes the bompage CI/CD component: pages + prune jobs
 ```
 
 The dashboard page carries **no project data**: `bompage build` writes the
@@ -48,22 +48,28 @@ component's; reusing one is refused rather than shown twice.
 
 ## Ingesting SBOMs
 
-Each source pipeline pushes with the `push-report` GitLab CI/CD component
-published from `gitlab.com/op_so/pages/bompage`:
+Each source pipeline pushes with the `bompage-push` job from the
+`gitlab.com/op_so/components/pages/bompage` GitLab CI/CD component:
 
 ```yaml
+stages:
+  - sbom-release # bompage_push_stage default; declare it or override the input
+
 include:
-  - component: gitlab.com/op_so/pages/bompage/push-report@v1
+  - component: gitlab.com/op_so/components/pages/bompage@v1.0.0
     inputs:
-      component: my-service
-      sbom_path: artifacts/sbom.spdx.json
-      bompage_repo: https://gitlab.com/acme/bompage.git # this repo
-      bompage_version: "1.2.3" # pin the release
+      bompage_push_repo: https://gitlab.com/acme/bompage.git # this repo
+      bompage_push_component: my-service
+      bompage_push_sbom: artifacts/sbom.spdx.json
+      bompage_push_sbom_format: spdx
 ```
 
-The job `pip install`s the pinned `bompage` and runs `bompage push`: it clones
-this repo with the scoped token in `$BOMPAGE_TOKEN`, writes
-`reports/my-service/sbom-YYYYMMDD.json` and commits only if the content changed.
+The job's image bundles a pinned `bompage` release and runs `bompage push`: it
+clones this repo with the scoped token in `$BOMPAGE_TOKEN`, writes
+`reports/my-service/sbom-YYYYMMDD.json` and commits only if the content
+changed. By default it runs only on the tag pipeline, versioning the snapshot
+from the tag; set `bompage_push_on: branch` to instead run from the consumer's
+default branch, versioned `0.0.0-$CI_COMMIT_SHORT_SHA`.
 
 ## Attestation (optional signing)
 
@@ -88,8 +94,10 @@ this section for a deployment that does not need it, nothing else changes.
    ```
 
 3. Store the **private** key (`bompage-push`, no extension — never the `.pub`
-   file) as a **masked, protected** CI/CD variable, e.g. `BOMPAGE_SIGN_KEY`, in
-   every source project that should sign its pushes.
+   file) as a **masked, protected** CI/CD variable named exactly
+   `BOMPAGE_SIGN_KEY`, in every source project that should sign its pushes.
+   `bompage push` reads that variable from the job environment on its own —
+   the `bompage-push` component job needs no extra input to enable signing.
 
    Because GitLab CI masked variables strictly forbid whitespace and newlines,
    encode the private key as a single-line Base64 string before saving it
@@ -98,21 +106,9 @@ this section for a deployment that does not need it, nothing else changes.
    - **Linux:** `base64 -w 0 bompage-push`
    - **macOS:** `base64 -i bompage-push | tr -d '\n'`
 
-4. Point each source pipeline's `push-report` include at it:
-
-   ```yaml
-   include:
-     - component: gitlab.com/op_so/pages/bompage/push-report@v1
-       inputs:
-         component: my-service
-         sbom_path: artifacts/sbom.spdx.json
-         bompage_repo: https://gitlab.com/acme/bompage.git
-         bompage_version: "1.2.3"
-         bompage_sign_key_var: BOMPAGE_SIGN_KEY
-   ```
-
-A source pipeline that omits `bompage_sign_key_var` keeps pushing unsigned —
-its snapshots simply verify as `unknown` here, never as a build failure.
+A source pipeline whose project never sets `BOMPAGE_SIGN_KEY` keeps pushing
+unsigned — its snapshots simply verify as `unknown` here, never as a build
+failure.
 
 ### Protecting `trust/`
 
@@ -175,8 +171,8 @@ bompage prune --repo <url> --token <token> --dry-run
   lexicographically. Every source pipeline must respect this, including those
   driven by a third-party provisioning tool.
 - Source pipelines push with a **scoped token** limited to this repository, and
-  commit only when the SBOM content actually changed — the `push-report`
-  component centralises this (anti-noise filter, spec sections 5.1 / 5.2 / 10).
+  commit only when the SBOM content actually changed — the `bompage-push`
+  component job centralises this (anti-noise filter, spec sections 5.1 / 5.2 / 10).
 - Hosts provisioned via IaC generate their SBOM on the target, fetch it back to
   the controller/runner, and the **controller** commits and pushes — never the
   host itself (spec section 3).

{bompage-1.2.2 → bompage-1.3.0}/deploy/trust/allowed_signers

@@ -16,9 +16,11 @@
 #   1. ssh-keygen -q -t ed25519 -N '' -C bompage-push -f bompage-push
 #   2. Add the line above with the contents of bompage-push.pub.
 #   3. Store the PRIVATE key (bompage-push, no extension) as a masked,
-#      protected CI/CD variable (e.g. BOMPAGE_SIGN_KEY) -- never commit it.
-#   4. Wire that variable name into push-report.yml's `bompage_sign_key_var`
-#      input from every source pipeline.
+#      protected CI/CD variable named exactly BOMPAGE_SIGN_KEY, in every
+#      source pipeline that should sign its pushes -- never commit it.
+#      `bompage push` (the `bompage-push` job of the
+#      gitlab.com/op_so/components/pages/bompage component) reads that
+#      variable from the environment on its own; no extra wiring needed.
 #
 # This file is the REAL trust root -- unlike its read-only copy the published
 # site may serve for convenience, it lives in the central repository and is

{bompage-1.2.2 → bompage-1.3.0}/docs/index.md

@@ -1,6 +1,6 @@
 # Overview
 
-Version: 1.2.2
+Version: 1.3.0
 
 A generic, server-less system to centralise the SBOM history of **N components**
 in a dedicated Git repository and publish a static

{bompage-1.2.2 → bompage-1.3.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "bompage"
-version = "1.2.2"
+version = "1.3.0"
 description = "A generic, server-less system to track SBOM history of N components and publish a static dashboard"
 authors = [
     { name = "FX Soubirou", email = "soubirou@yahoo.fr" }
@@ -91,9 +91,9 @@ show_missing = true
 fail_under = 100
 
 [tool.coverage.run]
-# `scripts/merge_sbom_licenses.py` runs in the release pipeline (the `push-sbom`
-# job), so it is held to the same bar as `src/`. The demo-data generator is a
-# local convenience with no CI role and is left out.
+# `scripts/merge_sbom_licenses.py` runs in the release pipeline (the
+# `generate-sbom` job), so it is held to the same bar as `src/`. The demo-data
+# generator is a local convenience with no CI role and is left out.
 source = ["src", "scripts"]
 omit = ["scripts/gen-demo-data.py"]
 

{bompage-1.2.2 → bompage-1.3.0}/renovate.json

@@ -10,7 +10,7 @@
   "customManagers": [
     {
       "customType": "regex",
-      "description": "Trivy version pinned in .gitlab-ci.yml (push-sbom job)",
+      "description": "Trivy version pinned in .gitlab-ci.yml (generate-sbom job)",
       "managerFilePatterns": ["/^\\.gitlab-ci\\.yml$/"],
       "matchStrings": ["TRIVY_VERSION:\\s*\"(?<currentValue>[^\"]+)\""],
       "datasourceTemplate": "github-releases",
@@ -19,7 +19,7 @@
     },
     {
       "customType": "regex",
-      "description": "Node version pinned in .gitlab-ci.yml (push-sbom job)",
+      "description": "Node version pinned in .gitlab-ci.yml (generate-sbom job)",
       "managerFilePatterns": ["/^\\.gitlab-ci\\.yml$/"],
       "matchStrings": ["NODE_VERSION:\\s*\"(?<currentValue>[^\"]+)\""],
       "datasourceTemplate": "github-tags",

bompage-1.3.0/src/bompage/_paths.py

@@ -0,0 +1,17 @@
+"""Path-segment safety shared by every module that turns untrusted input into
+a file name under ``reports/<component>/``.
+
+``push`` validates ``component`` / ``sbom_version`` before writing there
+(spec §4: one directory = one component); ``attest`` validates an
+attestation's own ``prev.file`` before joining it onto the same tree
+(SECURITY.md: an input that escapes ``reports/<component>/`` is a
+vulnerability regardless of what leaks). Both need the identical rule --
+reject separators and ``.`` / ``..`` -- so it lives here once rather than as
+two copies that could silently drift apart.
+"""
+
+from __future__ import annotations
+
+import re
+
+SAFE_SEGMENT = re.compile(r"[A-Za-z0-9][A-Za-z0-9._-]*")

{bompage-1.2.2 → bompage-1.3.0}/src/bompage/analysis/drift.py

@@ -12,6 +12,7 @@ from __future__ import annotations
 
 from datetime import date
 
+from bompage.analysis.timeline import highest_by_name
 from bompage.models import ComponentReport, Drift, PackageOccurrence
 
 # A drift needs the package on at least this many components, at this many
@@ -25,22 +26,22 @@ def build_package_index(
     """Map each package name to one occurrence per component that carries it.
 
     A component may list the same name at several versions (spec section 7.3
-    speaks of "the version detected on each", singular); keep the highest so a
-    within-component duplicate is not mistaken for a cross-component drift.
+    speaks of "the version detected on each", singular); keep the highest --
+    via the same tie-break :func:`bompage.analysis.timeline.highest_by_name`
+    applies -- so a within-component duplicate is not mistaken for a
+    cross-component drift, and the drift list can never disagree with the
+    timeline about which version a component is "really" on.
     """
     index: dict[str, list[PackageOccurrence]] = {}
     for component in sorted(components, key=lambda c: c.name):
-        best: dict[str, PackageOccurrence] = {}
-        for pkg in component.packages:
-            current = best.get(pkg.name)
-            if current is None or (pkg.version or "") > (current.version or ""):
-                best[pkg.name] = PackageOccurrence(
+        for name, pkg in highest_by_name(component.packages).items():
+            index.setdefault(name, []).append(
+                PackageOccurrence(
                     component=component.name,
                     version=pkg.version,
                     ecosystem=pkg.ecosystem,
                 )
-        for name, occurrence in best.items():
-            index.setdefault(name, []).append(occurrence)
+            )
     return index
 
 

{bompage-1.2.2 → bompage-1.3.0}/src/bompage/analysis/inventory.py

@@ -70,11 +70,23 @@ def _is_strong_copyleft(license_id: str | None) -> bool:
 
 
 def build_inventory(packages: list[Package]) -> list[Package]:
-    """Return the deduplicated, ecosystem-enriched inventory, sorted by name."""
+    """Return the deduplicated, ecosystem-enriched inventory, sorted by name.
+
+    A duplicate (name, version, purl) is merged, not dropped: one occurrence
+    of the same package can legitimately carry a license the other lacks
+    (e.g. a manifest with no license metadata vs. a lockfile-resolved entry
+    for the exact same package), and keeping only whichever happened to be
+    seen first would silently lose that license -- and with it, a copyleft
+    flag the dashboard depends on.
+    """
     seen: dict[tuple[str, str | None, str | None], Package] = {}
     for pkg in packages:
         key = (pkg.name, pkg.version, pkg.purl)
-        if key in seen:
+        existing = seen.get(key)
+        if existing is not None and (existing.license or not pkg.license):
+            # Already captured a license (skip a duplicate lacking one), or
+            # this duplicate has none either (nothing would change) -- either
+            # way, no need to re-enrich and overwrite the entry already held.
             continue
         seen[key] = pkg.model_copy(
             update={

{bompage-1.2.2 → bompage-1.3.0}/src/bompage/analysis/timeline.py

@@ -24,7 +24,7 @@ from bompage.models import Change, Package, Snapshot, TimelineEntry
 _MIN_SNAPSHOTS_FOR_DIFF = 2
 
 
-def _highest_by_name(packages: list[Package]) -> dict[str, Package]:
+def highest_by_name(packages: list[Package]) -> dict[str, Package]:
     """One representative package per name: the highest ``version or ""``.
 
     A name may legitimately appear more than once in one snapshot (e.g. an npm
@@ -34,7 +34,9 @@ def _highest_by_name(packages: list[Package]) -> dict[str, Package]:
     ``diffSnapshots`` apply -- or the timeline, the deltas and the drift list
     quietly disagree about which version a component is on. Building the map by
     plain assignment would instead be last-wins, i.e. dependent on the order the
-    scanner happened to emit.
+    scanner happened to emit. Public (not `_`-prefixed): shared with
+    ``drift.build_package_index``, which applies the exact same tie-break to a
+    component's packages -- see that module's docstring.
     """
     best: dict[str, Package] = {}
     for pkg in packages:
@@ -49,10 +51,10 @@ def snapshot_versions(snapshot: Snapshot) -> dict[str, str | None]:
 
     Keeps the highest version of a name listed more than once, so the timeline
     and the added/removed deltas stay deterministic instead of depending on
-    package order (see :func:`_highest_by_name`).
+    package order (see :func:`highest_by_name`).
     """
     return {
-        name: pkg.version for name, pkg in _highest_by_name(snapshot.packages).items()
+        name: pkg.version for name, pkg in highest_by_name(snapshot.packages).items()
     }
 
 
@@ -99,7 +101,7 @@ def diff_last_two(
         return [], []
     per_snapshot = _resolve(snapshots, versions)
     previous = per_snapshot[-2]
-    current = _highest_by_name(snapshots[-1].packages)
+    current = highest_by_name(snapshots[-1].packages)
     added = [pkg for name, pkg in current.items() if name not in previous]
     removed = [name for name in previous if name not in current]
     return added, sorted(removed)