sbomify · vpetersson · Sep 1, 2026 · Sep 1, 2026 · Sep 1, 2026
diff --git a/content/sbomify-action/_index.md b/content/sbomify-action/_index.md
@@ -63,17 +63,19 @@ The core tool behaves identically everywhere. What differs is how you invoke it,
 | [GitHub Actions](/sbomify-action/runtimes/github-actions/) | Native action   | OIDC or token | Yes             | Generates workflow | Yes         |
 | [GitLab CI](/sbomify-action/runtimes/gitlab-ci/)           | Container image | Token         | Yes             | No                 | No          |
 | [Bitbucket](/sbomify-action/runtimes/bitbucket/)           | Container image | Token         | Yes             | No                 | No          |
-| [Jenkins](/sbomify-action/runtimes/jenkins/)               | Container image | Token         | Manual          | No                 | No          |
-| [CircleCI](/sbomify-action/runtimes/circleci/)             | Container image | Token         | Manual          | No                 | No          |
-| [Azure DevOps](/sbomify-action/runtimes/azure-devops/)     | Container image | Token         | Manual          | No                 | No          |
-| [Any container runner](/sbomify-action/runtimes/docker/)   | Container image | Token         | Manual          | No                 | No          |
+| [Jenkins](/sbomify-action/runtimes/jenkins/)               | Container image | Token         | From git        | No                 | No          |
+| [CircleCI](/sbomify-action/runtimes/circleci/)             | Container image | Token         | From git        | No                 | No          |
+| [Azure DevOps](/sbomify-action/runtimes/azure-devops/)     | Container image | Token         | From git        | No                 | No          |
+| [Any container runner](/sbomify-action/runtimes/docker/)   | Container image | Token         | From git        | No                 | No          |
 | [TeamCity](/sbomify-action/runtimes/teamcity/)             | Container image | Token         | Git roots       | No                 | No          |
-| [Local machine](/sbomify-action/runtimes/local/)           | `uvx` or `pipx` | Token         | Manual          | Yes                | No          |
+| [Local machine](/sbomify-action/runtimes/local/)           | `uvx` or `pipx` | Token         | Opt-in          | Yes                | No          |
 
-**Manual** means the runtime does not expose enough environment information for automatic detection, so you set `vcs_url`, `vcs_commit_sha` and `vcs_ref` in [`sbomify.json`](/sbomify-action/augmentation/) instead. Everything else works the same.
+**Yes** means the runtime publishes repository URL, commit SHA and ref as environment variables and they are read from there. **From git** means it does not, so the action reads the checkout it is running in - no configuration either way, as long as the `.git` directory is present and the repository has a remote.
 
 **Git roots** means TeamCity, which is VCS-agnostic: detection runs only when the repository URL positively identifies Git, and stays silent otherwise rather than recording a Subversion revision as if it were a commit. See [TeamCity](/sbomify-action/runtimes/teamcity/#vcs-information).
 
+**Opt-in** means a local run reads the checkout only when you set `SBOMIFY_LOCAL_VCS=true`, so an internal remote does not end up in a document by accident. `vcs_url`, `vcs_commit_sha` and `vcs_ref` in [`sbomify.json`](/sbomify-action/augmentation/) override whatever is detected, on every runtime.
+
 OIDC trusted publishing and build provenance attestation are GitHub-only today because they depend on GitHub-issued identity tokens. Support for other runtimes will follow as those platforms expose equivalent primitives.
 
 ## Documentation

diff --git a/content/sbomify-action/advanced.md b/content/sbomify-action/advanced.md
@@ -99,6 +99,8 @@ Three outputs:
 
 Four categories are tracked: overrides from the CLI or environment, augmentation values and their source, per-component enrichment additions, and sanitization fixes such as PURL normalisation. Timestamps are UTC, ISO 8601.
 
+File paths in the trail are recorded relative to the working directory, and anything outside it is reduced to its file name. The trail is meant to be handed to someone who did not run the build, and the absolute path of your lock file tells them nothing while publishing the build machine's directory layout and username.
+
 Archive `audit_trail.txt` alongside your SBOM. Together they answer "where did every field in this document come from?" - which is the question that actually gets asked in an audit.
 
 ## Caching
@@ -147,9 +149,8 @@ generate-sbom:
 docker volume create sbomify-cache
 
 docker run --rm \
-  -v "$(pwd):/github/workspace" \
+  -v "$(pwd):/workspace" \
   -v sbomify-cache:/cache \
-  -w /github/workspace \
   -e SBOMIFY_CACHE_DIR=/cache/sbomify \
   -e SYFT_CACHE_DIR=/cache/syft \
   -e LOCK_FILE=requirements.txt \

diff --git a/content/sbomify-action/augmentation.md b/content/sbomify-action/augmentation.md
@@ -98,14 +98,20 @@ By default augmentation only fills fields that are empty. Set `OVERRIDE_SBOM_MET
 
 ## Automatic VCS detection
 
-When running in supported CI environments, repository URL, commit SHA and branch or tag are detected and added automatically. No configuration needed.
+Repository URL, commit SHA and branch or tag are detected and added automatically on every CI runtime. No configuration needed.
 
-| Runtime             | Detected                                  | Notes                                                |
-| ------------------- | ----------------------------------------- | ---------------------------------------------------- |
-| GitHub Actions      | Repository URL, commit SHA, branch or tag | Works with GitHub Enterprise Server                  |
-| GitLab CI           | Project URL, commit SHA, ref name         | Works with self-managed instances                    |
-| Bitbucket Pipelines | Repository URL, commit SHA, branch or tag |                                                      |
-| TeamCity            | Repository URL, commit SHA, branch or tag | Git roots only - see [below](#teamcity-is-different) |
+Where a vendor publishes those details as environment variables, they are read from there. Everywhere else the action reads them from the git checkout it is running in, which is why Jenkins, CircleCI, Azure Pipelines and any other container runner get provenance without you writing it out by hand.
+
+| Runtime                                                                                                | Source                                           | Notes                                                               |
+| ------------------------------------------------------------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------------------------- |
+| GitHub Actions                                                                                         | Runner environment                               | Works with GitHub Enterprise Server                                 |
+| GitLab CI                                                                                              | Job environment                                  | Works with self-managed instances                                   |
+| Bitbucket Pipelines                                                                                    | Step environment                                 | Bitbucket Cloud; Data Center needs `vcs_url` in `sbomify.json`      |
+| TeamCity                                                                                               | Build properties file                            | Git roots only - see [below](#teamcity-is-different)                |
+| Jenkins, CircleCI, Azure Pipelines, Buildkite, Drone, Travis CI, AppVeyor, AWS CodeBuild, any other CI | The git checkout (`git remote`, `git rev-parse`) | Needs the `.git` directory in the container and a configured remote |
+| Your own machine                                                                                       | The git checkout, opt-in                         | Set `SBOMIFY_LOCAL_VCS=true` - see [below](#local-runs-are-opt-in)  |
+
+Each records repository URL, commit SHA and branch or tag. A browsable commit URL is added as well for github.com, gitlab.com and bitbucket.org, plus self-hosted GitHub and GitLab, whose commit paths match their cloud products. Everything else - Bitbucket Data Center included, since it lays commit URLs out differently from Bitbucket Cloud - gets the repository URL and the SHA without a link, rather than a guessed one that 404s.
 
 What gets written:
 
@@ -120,9 +126,16 @@ TeamCity is VCS-agnostic, and a root can just as easily be Subversion, Perforce
 
 TeamCity exposes no parameter saying which VCS a root uses. Detection therefore runs only when the repository URL positively identifies Git, and emits nothing otherwise. A self-hosted Git server whose URL has neither a `.git` suffix nor a recognised host cannot be detected; set `SBOMIFY_VCS_URL` (and `SBOMIFY_VCS_REF`) and it is trusted as given. See the [TeamCity runtime guide](/sbomify-action/runtimes/teamcity/#vcs-information).
 
-### Other runtimes
+### Runtimes read from the checkout
+
+Jenkins, CircleCI, Azure Pipelines and any other container runner have no vendor integration, and none is needed: they check out a git repository and run a command in it, so the action asks `git` directly. Two conditions have to hold, and both are the default:
+
+- **The `.git` directory has to be there.** A shallow clone is fine; an exported tarball or a mount of only your lockfile is not.
+- **The repository needs a remote.** `origin` is used if present, otherwise the first remote. A checkout with no remote has no URL worth recording, so nothing is emitted.
 
-Jenkins, CircleCI, Azure DevOps and plain container runs do not expose enough standard environment information for reliable detection. Set the values yourself:
+A runner is recognised as CI when it sets `CI=true` or a vendor variable of its own (`JENKINS_URL`, `CIRCLECI`, `TF_BUILD`, `BUILDKITE`, `DRONE`, `TRAVIS`, `APPVEYOR`, `CODEBUILD_BUILD_ID`). Almost every runner sets one; a bare `docker run` from a shell script sets neither and is treated as a local run.
+
+If any of that does not hold, or the remote URL is not the one you want in the document, set the fields yourself:
 
 ```json
 {
@@ -132,7 +145,13 @@ Jenkins, CircleCI, Azure DevOps and plain container runs do not expose enough st
 }
 ```
 
-Most CI systems expose the commit SHA in some environment variable, so this is usually a small template change in your pipeline definition.
+`sbomify.json` takes priority over detection, so this is also how you replace an internal remote URL with the public one.
+
+### Local runs are opt-in
+
+On your own machine nothing is read from the checkout unless you ask for it. The same lock file would otherwise produce a different SBOM depending on whether a remote happened to be configured, and an internal remote would be written into a document that often leaves the company.
+
+Set `SBOMIFY_LOCAL_VCS=true` to opt in, or state the fields in `sbomify.json` as above. On CI it stays automatic - that is the point of it.
 
 ### Overriding or disabling
 

diff --git a/content/sbomify-action/configuration.md b/content/sbomify-action/configuration.md
@@ -58,9 +58,10 @@ Non-SBOM `BOM_TYPE` values are uploaded verbatim to sbomify: augmentation, enric
 | `COMPONENT_PURL`           | none                      | Add or override the component PURL.                                                                                                                                                                        |
 | `ADDITIONAL_PACKAGES`      | none                      | Inline PURLs to inject, comma or newline separated.                                                                                                                                                        |
 | `ADDITIONAL_PACKAGES_FILE` | `additional_packages.txt` | Path to a file of PURLs, one per line.                                                                                                                                                                     |
-| `DISABLE_VCS_AUGMENTATION` | `false`                   | Disable automatic VCS detection from the CI environment.                                                                                                                                                   |
+| `DISABLE_VCS_AUGMENTATION` | `false`                   | Disable automatic VCS detection, whether it comes from the CI environment or the git checkout.                                                                                                             |
+| `SBOMIFY_LOCAL_VCS`        | `false`                   | Read VCS details from the git checkout on a non-CI run. Detection is automatic on CI and opt-in locally.                                                                                                   |
 | `SUBMODULE_PATH`           | none                      | Treat the component as a git submodule pinned at this path. Resolves the pin to a version and reuses an existing SBOM at that version if there is one. Requires `LOCK_FILE` and the `sbomify` destination. |
-| `WORKING_DIR`              | none                      | Working directory. On GitHub Actions prefer the `working-dir` input.                                                                                                                                       |
+| `WORKING_DIR`              | none                      | Working directory. Relative paths resolve against the current directory, or against the runner workspace on GitHub Actions, where the path must also stay inside it. Prefer the `working-dir` input there. |
 
 ## Uploading
 
@@ -149,6 +150,7 @@ You do not set these. They are read from the environment to detect VCS informati
 - **GitLab CI** - `CI_PROJECT_URL`, `CI_PROJECT_PATH`, `CI_SERVER_URL`, `CI_COMMIT_SHA`, `CI_COMMIT_REF_NAME`, `CI_PIPELINE_ID`, `CI_PROJECT_VISIBILITY`
 - **Bitbucket** - `BITBUCKET_WORKSPACE`, `BITBUCKET_REPO_SLUG`, `BITBUCKET_COMMIT`, `BITBUCKET_BRANCH`, `BITBUCKET_TAG`, `BITBUCKET_GIT_HTTP_ORIGIN`
 - **TeamCity** - `TEAMCITY_VERSION`, `BUILD_VCS_NUMBER` (and `BUILD_VCS_NUMBER_<VcsRootId>` on multi-root builds), `TEAMCITY_BUILD_PROPERTIES_FILE`
+- **Every other CI system** - `CI`, plus the vendor marker it sets: `JENKINS_URL` or `JENKINS_HOME`, `CIRCLECI`, `TF_BUILD`, `BUILDKITE`, `DRONE`, `TRAVIS`, `APPVEYOR`, `CODEBUILD_BUILD_ID`. These only name the platform in logs and telemetry - the repository details come from the git checkout. The matching checkout-path variables (`WORKSPACE`, `CIRCLE_WORKING_DIRECTORY`, `BUILD_REPOSITORY_LOCALPATH`, `SYSTEM_DEFAULTWORKINGDIRECTORY`, `BUILDKITE_BUILD_CHECKOUT_PATH`, `DRONE_WORKSPACE`, `TRAVIS_BUILD_DIR`, `APPVEYOR_BUILD_FOLDER`, `CODEBUILD_SRC_DIR`) are used when they point at a directory that exists inside the container.
 
 The two OIDC request variables only exist when the workflow grants `permissions: id-token: write`.
 

diff --git a/content/sbomify-action/how-it-works.md b/content/sbomify-action/how-it-works.md
@@ -96,7 +96,7 @@ This matters for compliance: component hashes are a [CISA 2025](/compliance/cisa
 
 ## 2. Augmentation
 
-Adds organisational metadata - supplier, authors, licenses, lifecycle phase, security contact, support dates - and VCS information detected from the CI environment.
+Adds organisational metadata - supplier, authors, licenses, lifecycle phase, security contact, support dates - and VCS information detected from the CI environment, or from the git checkout on runtimes that publish none.
 
 Sources are consulted in priority order, and **local values always win**:
 

diff --git a/content/sbomify-action/quickstart.md b/content/sbomify-action/quickstart.md
@@ -19,8 +19,7 @@ Run it from the root of your repository:
 
 ```bash
 docker run --rm -it \
-  -v "$(pwd):/github/workspace" \
-  -w /github/workspace \
+  -v "$(pwd):/workspace" \
   ghcr.io/sbomify/sbomify-action \
   sbomify-action wizard
 ```
@@ -53,7 +52,7 @@ Either way there is nothing else to install - whatever generator your project ne
 
 ### Things worth knowing
 
-- The wizard is **interactive**, so the `-it` flags are required, and it refuses to launch in CI (it checks `$CI` and `$GITHUB_ACTIONS`). Run it on your machine and commit the result.
+- The wizard is **interactive**, so the `-it` flags are required, and it refuses to launch on any environment it recognises as CI - `CI=true`, or a vendor marker such as `GITHUB_ACTIONS`, `GITLAB_CI` or `JENKINS_URL`. Run it on your machine and commit the result.
 - The volume mount is what lets it write the generated workflow back into your repository. Without it, the wizard runs but produces nothing you keep.
 - It only manages `.github/workflows/sboms.yml`, and marks files it generated with a header. It will never overwrite a workflow you wrote by hand.
 - It pins the action to a specific commit SHA at generation time, which is the recommended practice.
@@ -82,8 +81,7 @@ On any runtime other than GitHub Actions, the same configuration is passed to th
 
 ```bash
 docker run --rm \
-  -v "$(pwd):/github/workspace" \
-  -w /github/workspace \
+  -v "$(pwd):/workspace" \
   -e LOCK_FILE=requirements.txt \
   -e OUTPUT_FILE=sbom.cdx.json \
   -e ENRICH=true \