Changelog

This page documents user-visible changes to fremforge: new features, breaking changes (rare), and the weekly runner-image rebuild manifest. Entries are added in reverse-chronological order.

Subscribe: RSS feed, one item per entry below, or product-update email in your notification settings. See Subscribing.

For the full firehose of operational changes, anchor cron runs, sub-processor announcements, edge-rule adjustments, see the trust page and the status page.

Conventions

Each release entry has five blocks:

• Version, the SemVer this change shipped under, e.g. v1.0.0. This is the version shown in the fremforge app footer (see below). Operational-only changes that don’t move the product version (e.g. a weekly runner-image rebuild) omit it.
• Date, the day the change went live to customers (UTC).
• Surface, runners, admin, api, ssh, docs, pricing, trust, etc., the customer-facing area affected.
• Change, what changed, in language a customer recognises.
• Action required, what (if anything) the customer must do. Omitted when none.

Breaking changes carry a ⚠ breaking tag. Customers with active subscriptions also receive an email a minimum of 14 days before any breaking change ships.

From July 2026, changes that ship without a version bump are collected into one entry per month, newest month first. Each change in it carries the date it went live, and the entry’s heading carries the date of its newest change. A change is listed only once it is live for customers; where it is opt-in or limited, the entry says so.

Versions and the app footer

The fremforge app footer shows a build stamp like v1.0.0 · a5c7733:

• v1.0.0 is the product SemVer. It maps to the entries on this page, and links here. We bump it deliberately at meaningful milestones, not on every deploy.
• a5c7733 is the exact source commit that’s currently deployed. fremforge deploys continuously, so this short hash changes on every release; it links to the source commit (which references the pull request it came from). Use it when reporting an issue so we know precisely what you were running.

In short: the version is the human-readable milestone you’ll find on this page; the commit hash is the machine-precise “what’s live right now”. A full per-commit technical changelog is generated from pull-request history and kept in the product repository.

Entries

2026-10-22 — The signature check in pull requests works

• Surface: security
• Change:
  • The fremforge/cosign-verify pull-request check and the Cosign column now verify signatures. This lifts the 2026-10-21 correction. For each image your repository pins by digest, the check reports signed (with the signer), not signed, or could not check (with the reason). It reads images through your organisation’s dependency proxy and frem.sh registry, and trusts your organisation’s own fremforge Actions workflows and the public Sigstore. The check is still informational and never blocks a merge. See Signature findings in pull requests.

v1.4.0 — 2026-10-14, Reachability, AutoFix, and organisation defaults that apply on save

• Version: v1.4.0
• Surface: security, admin, api, ai
• Change: The highlights since v1.3.0. Each one is described in full, with its date, in the October 2026 entry below.
  • Reachability: does your code reach the vulnerable code? Go findings get a verdict from the Go binaries in the images you publish to your registry. npm findings get one from your repository’s JavaScript and TypeScript, and PyPI and Maven findings get an import-level one from your Python, Java and Kotlin. Each verdict is reachable, no call path or unknown, with the evidence. Findings are ranked by it, and those with no call path are grouped as Probably unexploitable; nothing is hidden, dismissed or unblocked unless you choose to: an opt-in SLA multiplier and an opt-in “do not block on no call path” are available. See Reachability.
  • Known-exploited vulnerabilities come first. A vulnerability listed as exploited in the wild by ENISA’s EU Vulnerability Database or CISA’s KEV catalogue is marked, filterable in the console and the findings API, sent to your SIEM as security.finding.known_exploited, always keeps its full SLA and gets its AutoFix pull request first. See Findings API and AutoFix.
  • AutoFix pull requests. Fix on a dependency finding opens one pull request that bumps the package to the lowest version fixing every open advisory, for npm, Go, PyPI, Maven, Gradle, NuGet and Cargo, and bumps an image’s FROM base; Fix all asks for every fixable package in a repository at once. An owner can also turn on AI-generated fixes for a short list of SAST rules, using only your organisation’s own model provider; it is off by default. AutoFix pull requests are never merged automatically. See AutoFix.
  • Organisation branch-protection defaults apply when you save them. Saving the defaults on the Repos page applies them to existing repositories at once. Require a pull request (no direct pushes) is enforced, also on existing rules (except rules with a push allowlist), and Require review from code owners applies: with a CODEOWNERS file, a pull request cannot merge while a code owner’s review request is open. See Branch protection.
  • Two settings that did nothing are removed: the Default repository template and the SSH certificate authority’s Principal policy. Both were saved but never applied. See Branch protection and Authentication policy.
  • The fremforge Terraform and OpenTofu provider 0.1.1 marks principal_policy and default_template_repo deprecated and no longer sends them, so a configuration that still sets them keeps working and plans clean. See The fremforge provider.
• Action required: If an API call or your Terraform configuration sets default_template_repo or principal_policy, remove it: a non-empty default_template_repo is refused with removed-setting. If you use the fremforge provider, upgrade to 0.1.1 (tofu init -upgrade): with 0.1.0, a fremforge_ssh_ca block that sets only principal_policy now fails.

v1.3.0 — 2026-10-12, Dependency proxy for every organisation, MCP connectors

• Version: v1.3.0
• Surface: packages, runners, security, ai, api, admin
• Change: The highlights since v1.2.0, July to October 2026. Each one is described in full, with its date, in the October 2026 entry below or in the September, August and July entries.
  • Dependency proxy for every organisation. Packages from the public registries (npm, PyPI, Maven, NuGet, Go, Cargo, Helm and RPM) and container images, cached for your organisation, with known malware (OSV MAL-*) refused and your package policy applied. On by default; hosted runners install packages through it and pull images through it, and it keeps serving what you have cached through upstream outages and short fremforge outages. See Dependency proxy.
  • Remote MCP server and connectors with sign-in. AI assistants connect to https://frem.sh/_app/mcp, with a fremforge API token or, for claude.ai, ChatGPT and Mistral Le Chat, by signing you in to frem.sh. Every tool is read-only. See Remote MCP server.
  • Package policies are enforced, and known malware is refused. A policy set to Enforce refuses downloads that break it; packages and images matching an OSV MAL-* advisory are refused for every organisation. See Package policies.
  • Per-package access and protected package names, for every package type. See Package access.
  • Registry robots: registry logins owned by the organisation, for CI outside fremforge and image pull secrets, with GitHub Actions OIDC exchange. See Registry robots.
  • Configuration as code with Terraform and OpenTofu: a tested module, and the fremforge provider 0.1.0. See Terraform and OpenTofu and The fremforge provider.
  • Read-only Auditor role: auditors read every repository and the org admin settings and can change nothing; the first 5 are free. See Auditors.
  • Component inventory: every third-party component your organisation uses, where it is used, the vulnerable ones, and the package versions actually pulled. See Component inventory.
  • Immutable releases and release attestation, opt-in per organisation. See Immutable releases.
  • SIEM forwarding, alert webhooks and the registry access log: CEF and syslog over TLS, security alert webhooks with a ServiceNow format, and every package and container request logged. See SIEM, Security alert webhooks and Registry access log.
  • Build provenance and a public transparency log at log.frem.sh, verifiable locally with the CLI. See Transparency log.
• Action required: If your hosted-runner jobs pull images from Docker Hub, add your organisation’s Docker Hub credential under Build & deploy → Dependency proxy → Upstream credentials, or those pulls are subject to Docker Hub’s anonymous rate limits. If your package policy is set to Enforce, check Would have blocked before relying on it. Both are described in the October 2026 entry below.

2026-10-21 — October 2026 (1–21 October)

• Surface: issues, cli, packages, security, admin, billing, ssh, git, actions, runners, legal, docs, api, ai, dependency-updates
• Change:

  • 2026-10-21 — Correction: the signature check in pull requests is not yet operational. The fremforge/cosign-verify pull-request status and the Cosign column on the Container images page cannot reach the registries that hold image signatures, so they have shown images as not signed whether or not they are. Our pages said the check verifies signatures on every pull request; that was not true. Both are informational and never blocked a merge. The image signature policy at pull time is a separate check. See Signature findings in pull requests.

    • Action required: none. Updated 2026-10-22: the check is now operational; see the 2026-10-22 entry above.

  • 2026-10-21 — Quotas for Actions artifacts and attachments. Each organisation now has a cap of 5 GiB per seat for Actions artifacts and 5 GiB per seat for issue and release attachments (trial: 5 GiB each). Both are free and have no overage. Until now neither had a limit. An artifact upload over the cap fails with HTTP 413. See Actions artifacts and attachments.

    • Action required: none for most organisations. If a workflow keeps many large artifacts, set retention-days on upload-artifact so old ones expire.

  • 2026-10-21 — Artifact retention setting: default 30 days. The organisation’s artifact retention setting now defaults to 30 days (was 90), and organisations that never changed it moved to 30. The setting does not yet delete artifacts on its own: Forgejo expires them after the retention-days set at upload, or after 90 days. See Build artifact retention.

    • Action required: none. To keep artifacts for less than 90 days, set retention-days on the upload.

  • 2026-10-21 — The IaC check reads your Terraform and OpenTofu modules through fremforge’s module cache. A module from registry.terraform.io or registry.opentofu.org, or from github.com or gitlab.com at a tag or a commit, is fetched through the dependency proxy’s module cache and checked with your configuration. A misconfiguration inside a module is listed apart, under In modules on Security › Findings › IaC: it never blocks a pull request, has no fix-by SLA and sends no alert, because the fix is in your module call or its version, not in your files. Any other remote source (another host, a branch, an archive URL) is no longer fetched by the scanner itself: it is listed as not fetched, with its source, and its resources are not checked. Modules from your own organisation on frem.sh are fetched as before. See IaC scanning.

    • Action required: none. To have a module checked that is now listed as not fetched, pin it to a tag (?ref=v1.2.3) on github.com or gitlab.com, or use a registry module.

  • 2026-10-21 — Hosted runners run forgejo-runner 13: ::set-output, ::set-env and ::add-path no longer work. ⚠ breaking. The hosted runners moved from forgejo-runner 12 to 13.2.0 at about 04:30 UTC. Version 13 removed these three workflow commands: a step that prints one gets a warning in its log, and the output, environment variable or PATH entry is silently not set, so a later step or job reads an empty value while the run can still go green. GitHub still accepts ::set-output (deprecated), so a workflow ported from GitHub can lose its outputs without failing. Write to $GITHUB_OUTPUT, $GITHUB_ENV and $GITHUB_PATH instead; the same files are also available as $FORGEJO_OUTPUT, $FORGEJO_ENV and $FORGEJO_PATH. Two more changes in version 13: an expression that cannot be evaluated, or an invalid strategy.matrix (such as an exclude naming a value the matrix does not have), now fails the step or job instead of being ignored; and a step that writes a job summary ($GITHUB_STEP_SUMMARY) gets the warning This Forgejo instance does not support job summaries, and the summary is discarded. The runners also no longer set the GITEA_ACTIONS and GITEA_ACTIONS_RUNNER_VERSION environment variables: use FORGEJO_ACTIONS (or GITHUB_ACTIONS) and FORGEJO_ACTIONS_RUNNER_VERSION, and for the job token use ${{ secrets.FORGEJO_TOKEN }} or ${{ secrets.GITHUB_TOKEN }} rather than secrets.GITEA_TOKEN. See Outputs, environment variables and PATH.

    • Action required: search your workflows for the old commands (git grep -nE '::(set-output|set-env|add-path)') and replace each with a write to the matching file, for example echo "tag=v1.2.3" >> "$GITHUB_OUTPUT" instead of echo "::set-output name=tag::v1.2.3". Update any Marketplace action that still prints them. Fix any expression or matrix a run now fails on.

  • 2026-10-21 — Hosted runners: fixed pnpm and Yarn versions for projects that pin none. A job whose package.json has no packageManager now gets pnpm 12.14.0 and Yarn 4.18.1. Both are on the runner, so they need no download. Until now such a job got npm’s latest at the moment it ran: pnpm 12 recently, and Yarn Classic 1.22. Unpinned Yarn jobs therefore move from Yarn 1.22 to Yarn 4. A project that pins packageManager gets exactly that version, as before; pnpm 12.14.0 and 11.28.6 are now on the runner too, and any other pinned version is downloaded when the job starts. See pnpm and Yarn versions.

    • Action required: if a project relies on Yarn Classic without pinning it, add "packageManager": "yarn@1.22.22" to its package.json. Pinning packageManager is how you choose a pnpm or Yarn version.

  • 2026-10-20 — Daily alert summary: fewer security emails, on by default. Security alerts that need attention but not at once are now collected into one email per person a day at 07:00 (Copenhagen time), across all your organisations: new HIGH findings, and findings that became reachable at MEDIUM or LOW severity. New CRITICAL findings, findings that became known exploited, and findings that became reachable at HIGH or CRITICAL severity are still sent at once. This changes the default for existing customers: the summary is on for everyone, including members who already had security alerts on. Each person can switch it off in their notification settings to get every alert at once, as before. Webhooks, SIEM endpoints and the audit log still receive every event at once. See Security alerts and the daily alert summary.

    • Action required: none. To keep receiving every alert as it is found, switch off Daily alert summary in your notification settings.

  • 2026-10-20 — The weekly security digest is a trend report with counts only. It no longer lists individual findings (newly reachable and known-exploited findings, top fixable upgrades, packages needing migration); it counts them. Members get the counts without links into the owner-only console, and the Renovate section and the compliance report PDF go to owners only. The digest page also no longer says the digest is opt-in or sent every Monday: it is on by default for every member, and goes out seven days after a person’s previous one.

    • Action required: none.

  • 2026-10-20 — Security alerts in your language. The security alert for new HIGH and CRITICAL findings is now in the recipient’s language (English, Danish, German, French, Dutch or Swedish). In every security email, members who are not owners get counts only, with no repository, file or package names. Security emails go only to current members of an organisation, and none are sent for an organisation that has been cancelled or deleted. Turning off the finding alert email for an organisation no longer stops its audit events: those always reach your SIEM.

    • Action required: none.

  • 2026-10-19 — Open fix PR on secret and IaC findings, without AI. Open fix PR in the new Fix column of the secret and IaC findings pages opens a pull request that fixes the finding by a set rule, with no AI model and nothing sent outside fremforge. A hard-coded credential in Go, Python, JavaScript or TypeScript becomes an environment variable read. For six IaC checks (the S3 public access block, Azure storage HTTPS-only and minimum TLS 1.2), the property is set to its secure value. Every change is syntax-checked and re-scanned first, and the pull request is never merged automatically. When the credential was found live, the pull request starts with ROTATE NOW. See Rule-based fixes.

    • Action required: none. Rotate a credential before you merge its fix: it is still in the history.

  • 2026-10-19 — Secrets from European cloud providers are found. Secret scanning now finds Hetzner Cloud, Scaleway, OVHcloud, IONOS Cloud and T Cloud / Open Telekom Cloud credentials, in push protection, the pull request check and the history sweep. A rule matches only where the provider’s name or file format says what the value is, so a bare hash or UUID is not reported. See European cloud providers.

    • Action required: none. Push protection now blocks a push that adds one of these credentials.

  • 2026-10-19 — Seven more validity checks. Hetzner Cloud, Scaleway and IONOS Cloud (EU-operated) and npm, OpenAI, Anthropic and Hugging Face (US-operated) join the list of validity checks. Each one is off until you switch it on, and each makes one read-only request, which the table names.

    • Action required: none.

  • 2026-10-19 — Check a secret yourself, then mark it. A finding from a provider in that list has Check it yourself: the provider’s read-only request as a command for your own terminal, which reads the secret from the keyboard and never sends it to fremforge. Mark active and Mark rotated record what you found, per location. See Check it yourself, then mark it.

    • Action required: none.

  • 2026-10-19 — Rotate by default, and which to rotate first. Secret findings that no provider has answered are ordered by how likely the secret is still live, estimated from the code (still in the current code, removed later, only on another branch), the commit’s age and recent push-protection blocks, without the secret and without contacting anyone. The API returns it as likely_live. See Rotate by default.

    • Action required: none.

  • 2026-10-19 — A security fix counts only where every copy reaches the fixed version. A lockfile can hold an older copy of a package nested under another dependency, and a grouped fix can move a transitive copy to a version that is still vulnerable. fremforge now reads the lockfiles at the head of each security fix pull request (npm, pnpm, Yarn, Bun, uv, Poetry, Cargo, Go and NuGet) and checks every copy. A pull request that leaves an older copy stays open, says which copies are left, and shows Fix proposed only on the findings it fixes. A package with no copy at its fixed version is not counted as part of the pull request and goes to the transitive fix. See Security fixes.

    • Action required: none.

  • 2026-10-19 — Grouped security fixes. Under Security › Fix › Dependency updates › Security fixes, Grouped repositories lists the repositories where the fixes of one lockfile go in one pull request instead of one per package (npm, PyPI, Go, Cargo and NuGet, inside the installed major). A group counts as one pull request against the limits; a package that cannot be updated with the others keeps its own request and gets its own pull request or note. Off unless you list a repository. Also in the API (grouped_repos); the Terraform provider gets security_fixes.grouped_repos in its next release. See Grouped fixes.

    • Action required: none.

  • 2026-10-19 — Every validity check and AI provider says who operates it. Each secret validity provider under Security › Policies › Push protection › Validity checks, each AI vendor tile and each AI provider you have added now shows US-operated or EU-operated (a Custom AI endpoint shows Depends on endpoint). The API reports it as operator_jurisdiction. See Validity checks and AI integrations.

    • Action required: none.

  • 2026-10-19 — Adding an AI provider no longer switches any AI feature on. Until today, an AI feature with no saved default used your newest provider, so adding a provider switched every feature on, AI pull request review included. Now every feature is off until it is switched on under AI integrations (or by a per-repository override), and the console shows each feature as On or Off. AI fixes answer the new refusal autofix-feature-off when only the feature is missing, and the settings API reports ai_feature_on.

    • Action required: if you had added a provider and relied on a feature running without saving its default, switch that feature on under AI integrations.

  • 2026-10-19 — Contribute anonymous counts: an opt-in, off by default. Under Security › Reports › Remediation metrics, through the API (/orgs/{org}/security/anonymous-counts) or with Terraform, an organisation can contribute anonymous daily counts to the security metrics fremforge publishes: open findings by type and severity, reachability verdicts, security fix pull requests opened and merged, and time to fix. No names, code or people are shared, and every published number rests on at least five organisations. Switching it off deletes the stored days at once. See Anonymous counts, which also describes the method; no numbers are published yet.

    • Action required: none. Nothing is shared unless an org owner switches it on.

  • 2026-10-19 — New and migrated repositories are scanned when they are created. A repository created with content, migrated from another host, or set up as a pull-mirror now has its default branch scanned straight away, instead of waiting for its first push. Before, a migrated repository was scanned only if fremforge happened to commit to it; a mirror waited for its first sync. An empty repository is still scanned on its first push.

    • Action required: none. Expect findings on newly migrated repositories from their first minutes.

  • 2026-10-19 — The setup checklist says when a security fix pull request opens. The Security fix limits item on Security › Overview now says that a fix pull request opens only when someone clicks Open fix PR, unless automatic security fixes are on.

    • Action required: none.

  • 2026-10-19 — Go reachability: a package that needs cgo no longer stops the analysis. Go source mode analyses code as built for Linux without cgo. A package that only builds with cgo used to make every Go finding in the repository unknown (build_failed). That package is now left out and the rest is analysed; findings in modules it imports are unknown (build_constraints), never unreachable. See the reasons.

    • Action required: none.

  • 2026-10-19 — Go reachability: modules with capital letters in their path are analysed. Source mode could not load a module whose path has an upper-case letter (for example github.com/NYTimes/gziphandler or github.com/Azure/go-ntlmssp), so every Go finding in a repository that depends on one was unknown (build_failed). Such modules are now fetched like any other. The next scan of an affected repository gives its findings their real verdicts. See Go: your repository’s code.

    • Action required: none.

  • 2026-10-19 — Dependency proxy: a cached layer nobody scanned is scanned for your organisation. With malware scanning on, an image layer that another organisation cached without scanning is now scanned the first time your organisation pulls it, once, and its verdict holds for everyone. Until it is, it is served while it is scanned, or answered 503 with Retry-After if you set block_until_scanned. A layer found infected is refused to every organisation. Before, such a layer was served to you unscanned when you pulled it by digest. See Dependency proxy.

    • Action required: none.

  • 2026-10-19 — Go reachability from your own code, for every organisation. When a dependency scan finds vulnerable Go modules, fremforge now also analyses your repository’s Go code (govulncheck source mode) and shows the call path from a line in your repository to the affected function, even when no image was built from that commit. Nothing in your repository is run, modules come only through the dependency proxy, and private modules (under frem.sh, or matching your repository’s GOPRIVATE, GONOPROXY or GONOSUMDB patterns) are never requested. See Go: your repository’s code.

    • Action required: none.

  • 2026-10-19 — IaC scanning checks Bicep, and the full list of formats. fremforge/iac-scan now compiles every .bicep file to ARM, offline and without your bicepconfig.json, and checks it like the rest of the repository; findings are shown on the .bicep file. A file that cannot be compiled (for example one that uses a registry module) is listed under Files not checked instead of passing silently. The check’s formats, each proved with a positive and a clean pull request: Dockerfiles, Compose, Kubernetes, Helm, Terraform and OpenTofu (.tf and .tofu), CloudFormation (YAML and JSON), Azure ARM, Bicep and Ansible. See IaC scanning.

    • Action required: none.

  • 2026-10-19 — Your own SAST rules. Under Security › Policies › SAST rules, through the API, or as fremforge_sast_custom_rule (Terraform provider 0.5.0), an organisation can add up to 50 OpenGrep rules of its own, each with a test sample. The scanner runs each rule on its sample before it is used; fremforge/sast then runs it with the built-in rule sets on pull requests and default branches, and its findings are marked Custom and block by their severity. Rules are never fetched from a URL: the custom_rules_url setting, which the scanner never read, is retired. See Your own rules.

    • Action required: if an API call or a Terraform configuration sets custom_rules_url, remove it: a value other than null or "" is refused with custom-rules-url-removed.

  • 2026-10-19 — Base-image fixes know which repository built an image without labels. An image pushed to your registry by a fremforge Actions run of a repository in your organisation is now matched to that repository and commit, so Open base-image fix PR works without the OCI source and revision labels. Labels still win when present. Each image finding says which repository and Dockerfile built it and how fremforge knows, in the console and in the API (base_attribution). See Base-image bumps.

    • Action required: none.

  • 2026-10-19 — Maven: the dependencies your pom.xml pulls in are scanned. Dependency scanning now resolves each pom.xml through your organisation’s Maven proxy, without running Maven, and checks every package in the tree, not only the ones the pom names. Expect new dependency findings on Java repositories: they are transitive dependencies now being seen, not new vulnerabilities. A pull request that adds or raises a vulnerable one at or above your threshold is blocked, as before for direct ones. A pom that cannot be fully resolved is never reported clean: the status, the pull request comment, the findings and SBOM pages, the SBOM and GET /orgs/{org}/code-security/deps/coverage name it and the missing artifacts. Open fix PR on a transitive Maven finding pins it with <dependencyManagement>. See Maven dependency resolution, including its known limits.

    • Action required: none. If a pom is listed as not fully checked because your Maven proxy lacks an internal artifact, add the repository that holds it as an upstream of the proxy.

  • 2026-10-18 — The dependency proxy’s Go route no longer looks up frem.sh-hosted modules upstream. A request for a module under frem.sh (or a subdomain) is answered 404 with the decision private-module, before proxy.golang.org or sum.golang.org is contacted. The security scanners also never request a module under frem.sh, or one matching a GOPRIVATE, GONOPROXY or GONOSUMDB pattern your repository declares. See What reaches Google for public modules.

    • Action required: none. If a build fetches frem.sh-hosted Go modules, list frem.sh in GOPRIVATE so the go command fetches them from frem.sh directly.

  • 2026-10-18 — IaC scanning: required for new organisations, and manageable with Terraform. fremforge/iac-scan is a required check in every organisation created on or after 19 October 2026; older organisations get it one by one. Security › Policies › Scanners › IaC now says whether it is required in yours, so you can see why a pull request is or is not blocked by it. The fremforge Terraform and OpenTofu provider 0.4.0 manages the IaC check’s mode and threshold (fremforge_scan_policy with scanner = "iac_scan") and your own IaC checks (fremforge_iac_custom_check). See When it is a required check.

    • Action required: none. To manage these settings as code, upgrade the provider (tofu init -upgrade).

  • 2026-10-18 — Vulnerable CI action versions are found and fixed. The dependency scan now matches every uses: owner/repo@<version> in your workflow files (.forgejo/workflows/, .gitea/workflows/, .github/workflows/) against the GitHub Actions advisories, from fremforge’s own copy of the OSV database, with no call to GitHub. An action pinned to a commit is matched by the version comment beside it (@<sha> # v4.1.2). A vulnerable action is a dependency finding in fremforge/dep-scan, and Open fix PR moves it to the lowest fixed version, pinned to that tag’s commit. See CI action versions.

    • Action required: none. A pull request that adds a vulnerable action version at or above your dependency threshold is now blocked.

  • 2026-10-18 — IaC findings by CIS benchmark and NIS2 area. The compliance report has a new section, also in the PDF, the JSON and a CSV (section=iac_compliance): the open IaC findings grouped by the benchmark controls their checks test, from Trivy’s published compliance mappings (CIS Docker, Kubernetes, RKE2, EKS and AWS, NSA Kubernetes hardening, Pod Security Standards), and by NIS2 Article 21(2) area. The NIS2 grouping is fremforge’s own and does not state compliance.

    • Action required: none.

  • 2026-10-18 — Your own IaC checks. Under Security › Policies › IaC checks, or through the API, an organisation can add up to 25 checks of its own, written in Rego as Trivy custom checks. Each is verified with OPA in the scanner before it runs, and fremforge/iac-scan then runs it with the built-in checks on every repository. See Your own checks.

    • Action required: none.

  • 2026-10-18 — A fix request names a manifest it could not read. When Renovate cannot parse a manifest (invalid JSON, YAML, TOML or XML), the request now ends No PR: manifest unreadable and names the file, in the console and in the API (reason manifest_unparseable, unparseable_manifests). Until now it read as “not a direct dependency”. See Troubleshooting.

    • Action required: none.

  • 2026-10-18 — Security fixes for pub. Open fix PR now works for Dart and Flutter (pub) dependencies: the fix changes pubspec.yaml and refreshes pubspec.lock with dart pub upgrade in hosted Renovate’s sandbox. A pub package that pubspec.yaml does not name is not fixed yet. See Supported ecosystems.

    • Action required: none.

  • 2026-10-18 — Security fixes for Composer, Bun, RubyGems and Hex. Open fix PR now works for PHP (Composer), Bun (bun.lock), Ruby (RubyGems) and Elixir (Hex) dependencies. Composer and Bun fixes change the manifest and refresh the lock file in hosted Renovate’s sandbox, with no package scripts or plugins run. RubyGems and Hex fixes, and Composer packages composer.json does not name, change only the lock file (Gemfile.lock, mix.lock, composer.lock). That update runs in a job on your organisation’s own runner, because Bundler and Mix read the Gemfile and mix.exs, which are code fremforge does not run. fremforge checks that only locked versions changed before it opens the pull request. Bun’s binary bun.lockb is not supported: run bun install --save-text-lockfile once to switch to bun.lock. See Security fixes and Supported ecosystems.

    • Action required: none. A RubyGems, Hex or transitive Composer fix uses your organisation’s runner minutes for one short job.

  • 2026-10-18 — Pull requests that failed before their branch had a scan are scanned again by themselves. When a pull request’s scan finds no scan of the branch it merges into, every finding counts. Now, once that branch’s first scan is recorded, fremforge scans again the open pull requests into it whose check failed meanwhile (up to 20 per repository, per check). They turn green, or stay red only on what they add, with no re-run or new push needed. See Image scanning.

    • Action required: none.

  • 2026-10-18 — A proxied image keeps its findings while it is in use. The findings of an image your organisation pulls through the dependency proxy used to be removed as soon as the image left your cache. Now they stay while the image is still in use: pulled by your organisation, or named in one of your deployments, in the last 30 days. An image pulled again after its findings were removed gets them back at the next sweep. See Image scanning.

    • Action required: none.

  • 2026-10-18 — Downloads by fremforge-hosted runners no longer count toward package egress caps. Package-registry downloads made by CI jobs on fremforge’s hosted runners stay inside the platform: they are still counted, but no longer count toward your organisation’s package egress caps (100 GB per seat soft, 300 GB per seat hard) and are never throttled. The billing page now shows the month’s Downloads from outside fremforge, which count toward the caps, and Downloads by fremforge runners, which are not capped. Downloads by self-hosted runners and by every other client count as downloads from outside fremforge, as before. Downloads made before this change keep counting toward this month’s caps in full. This changes the 10 October entry below, which said hosted-runner downloads count toward the caps.

  • 2026-10-17 — IaC scanning is a check of its own. trivy config (Dockerfile, Compose, Kubernetes, Helm and Terraform misconfigurations) now posts its own status, fremforge/iac-scan, with its own mode (enforce, audit or off) and threshold under Security › Policies › Scanners and as iac_scan in the scan policy API. Its findings have their own tab, Security › Findings › IaC, and their own row on the Security overview. Like the other checks it blocks only on misconfigurations a pull request adds, compared with the branch it merges into, including protected release branches. fremforge/image-scan no longer reports misconfigurations. Existing findings, their dismissals and fix-by dates moved with them; your totals are unchanged. fremforge/iac-scan becomes a required branch-protection check organisation by organisation; until then it reports without blocking on its own. See IaC scanning.

  • 2026-10-16 — The images your Helm charts deploy are checked for vulnerabilities. The image scan now reads every Helm chart in a repository (values.yaml and literal image: lines in templates/, without rendering anything), fetches each image it names through your dependency proxy, or fremforge’s own if your organisation has none, and scans it with Trivy. The findings are reported on fremforge/image-scan with the chart file and the image as the target, for example chart/values.yaml: docker.io/library/alpine:3.12.0, and a pull request is blocked only by findings it adds. Images assembled by template logic, values overlays and dependency charts not in the repository are not covered. See Images your Helm charts deploy.

    • Action required: if your charts use Docker Hub images, add your organisation’s Docker Hub credential under Dependency proxy › Upstream credentials. Without it those images are not scanned, and the status and Security › Findings › Container images say so.

  • 2026-10-16 — Protected release branches are scanned, listed apart, and can get security fixes. Branches such as release/1.x that match your protected-branch patterns (or a repository’s own protection rules) are scanned by every scanner on push and at least weekly. Their findings are listed per branch on Security › Findings › All and in the findings API (?branch=), with a fix-by date, and are counted in none of your default branch’s numbers, SLA metrics or alerts; alerts and the weekly digest list them in a section of their own. A dismissal applies to that branch only and is an exception like any other. A dependency finding can get a security fix pull request into its release branch, and a pull request into a release branch is checked against that branch’s own last scan. See Release branches.

    • Action required: none. Where dismissals require approval, only an approver can dismiss on a release branch for now.

  • 2026-10-16 — Terraform and OpenTofu providers are checked for vulnerabilities. The dependency scan now reads .terraform.lock.hcl: each locked provider binary is scanned for the Go modules it was built from, and their advisories are reported as dependency findings of the repository (ecosystem Terraform, package the provider address), only when the lock’s hashes match the binary scanned. They count towards your dependency threshold like any other finding, so a pull request that adds a provider version with a finding at or above it is blocked. Providers built before Go 1.18, and Terraform modules, are not covered. See Terraform and OpenTofu providers.

    • Action required: none. A repository whose lock pins a provider with a finding at or above your threshold sees it on its next pull request.

  • 2026-10-16 — Console pages take no text from their URL. After you save a form, its message (“Secret saved”, “That pattern is already listed”, why a save was refused) now travels in a short-lived cookie for that one page and shows once, instead of in the page’s address, where it stayed in your browser history and could be forged: a link to a console page could make it say whatever the sender wrote. Links now carry only an id or a code. Pre-filled override forms (malware, push protection) are filled from your own finding or rejected push, not from the link. The SCIM token is shown once on the page that answers Enable SCIM or Rotate token and is never put in a URL. The language picker and sign-out only return to a page on frem.sh. Messages on Org › SSO that were never shown before (for example App label is required.) now show. See SCIM provisioning.

    • Action required: none. A bookmark that carried a message in its address opens the page without it.

  • 2026-10-16 — Security › Findings › All: every open finding in one list. Security › Findings now opens on All, one list of the open findings of every scanner (code, secrets, dependencies, container images, infrastructure as code, licences and malware), known exploited first, then by severity. Type and severity filters show their counts; a row links to the finding on its own tab, which keeps the details and actions. The type tabs stay. Over the API: GET /orgs/{org}/security/findings. See Where findings are listed and Every finding in one list.

    • Action required: none.

  • 2026-10-16 — Security › Reports › Notifications is the one place for security notifications; three new API endpoints. The page now holds the security digest, the switch for finding alerts (newly reachable or known exploited), which until now was only on the Overview’s setup checklist, with the last 7 days’ counts, and how many webhook destinations and SIEM endpoints receive security events. New over the API: GET/PUT /orgs/{org}/security/transition-alerts, GET/PUT /orgs/{org}/security/checklist and GET /orgs/{org}/security/recommendations. Hiding or showing the setup checklist is now audited as code-security.checklist.updated. See Finding alerts, Setup checklist and Recommendations.

    • Action required: none.

  • 2026-10-16 — One release age. How long a new version must have been published before your organisation takes it is now one setting, Security › Policies › Release age (0 to 14 days), for the fremforge/release-age pull request check, hosted Renovate’s version updates, security fixes and downloads from your registry. Until now the check and Renovate used a fixed 3 days, security fixes had their own Release age and the package policy its minimum age. Nothing changed on its own: where the four differ, the page shows each value and what a save would set, and nothing is written until an owner saves. Known-exploited fixes still do not wait. Over the API: GET/PUT /orgs/{org}/release-age and POST …/release-age/preview. See Release age.

    • Action required: none.

  • 2026-10-16 — Image signatures: one list of trusted signers. The image signature policy’s issuers and identities are now one list, Trusted signers: an issuer alone trusts every subject it certifies, an issuer with a subject regex only matching subjects. The console has one field for it, one signer per line, and a refused list comes back with the reason and what you typed. The API takes and returns signers; issuers and identities keep working, and the Terraform resource is unchanged. Nothing changed in which signatures are trusted. See The trust policy.

    • Action required: none.

  • 2026-10-15 — Findings tabs show findings first; scanner settings move to Security › Policies › Scanners. The settings that sat at the top of the SAST, Dependencies, Licences and Secret scanning tabs (whether the scanner runs, and the severity at which its pull request check fails) are now on Security › Policies › Scanners. Each findings tab keeps one line with the scanner’s state and a link. A finding’s actions are behind ⋯ at the end of its row, next to the one action the row offers, such as Propose fix or Pin as transitive. The filter rows (Dependencies views, known exploited, malware source and state) are one row of filters under the tab bar. Licence per-repository overrides moved to Licence policy. Nothing changed in what the settings do, and the API is unchanged. See Scanners.

  • 2026-10-15 — Security › Policies gains Image policies and Repository rules. The image pull gate and the image signature policy moved from Findings › Container images to Security › Policies › Image policies. Branch protection for new repositories, commit signing and Actions only on protected branches moved from Org › Repos and Build & deploy › Environments to Security › Policies › Repository rules; the old pages link there and _admin/repo-defaults redirects. Commit signing is now one setting: saving it also sets the signed-commits default for new repositories, and the page says when an older setting left the two out of step. Nothing else changed in what the settings do. See Security policies.

  • 2026-10-15 — One licence policy for pull requests and downloads. The licence rules that decide a pull request’s dependency licences and the ones that decide a download from your registry are now one policy, at Security › Policies › Licence policy: allowed, denied and warned licences, unknown and multiple licences, Downloads: allowed licences only, and the pull request threshold. Nothing changed on its own. If your two sets of rules differ, the page says so and proposes one policy in which the stricter rule wins for each scope. Before you save, it shows every setting that changes and every licence whose result changes, in pull requests and on download. The Licences tab and the Package policies page link there. Over the API: GET/PUT /orgs/{org}/licence-policy and POST …/licence-policy/preview. The older endpoints still work and change one scope. See Licence policy.

  • 2026-10-16 — The dependency, SAST, licence and secret checks block only on findings the pull request introduces. fremforge/dep-scan, fremforge/sast, fremforge/license-scan and fremforge/secret-scan used to fail on every finding in the repository, so one critical advisory, SAST hit, forbidden licence or committed secret on your default branch blocked every pull request, even a README change. Like the image check since 2026-10-15, each now compares the pull request’s findings with the latest scan of the branch it merges into: dependencies by package and advisory, SAST by rule, file and matched code (a moved line is not new), licences by package and licence, secrets by a keyed hash of the matched lines (never the secret). A new malicious package or known-exploited vulnerability always blocks. Existing findings still show, count towards your SLA and alert. Without a scan of that branch, every finding blocks as before. See Pull request checks: only new findings block.

    • Action required: none.

  • 2026-10-15 — The image-scan check on a pull request blocks only on findings the pull request introduces. fremforge/image-scan used to fail on every open high or critical finding in the repository, so a repository that already had one could not merge even a config-only change. It now compares the pull request’s findings with the latest scan of the branch it merges into, by advisory, package and file: a finding the branch already has no longer blocks, and a new one does. Existing findings still show, count towards your SLA and gate image pulls. Without a scan of that branch, every finding blocks as before. See Pull requests: only new findings block.

    • Action required: none.

  • 2026-10-15 — Transitive security fixes for pnpm, Yarn, Python and Gradle. The pins for transitive dependencies now cover more lockfiles, under the same rule as npm: the lock moves only when the fixed version declares the same dependencies as the version it replaces. pnpm (pnpm-lock.yaml 9.0): an overrides entry in pnpm-workspace.yaml, or package.json for pnpm 9, and the lock’s own overrides section. Yarn 1: a resolutions entry and the yarn.lock entry; Yarn 2 and later are refused, because their lock needs a checksum only Yarn computes. uv and Poetry: the package’s lock entry moves to the fixed version, files and hashes read through your PyPI dependency proxy, with no pin in pyproject.toml. Gradle (gradle.lockfile): a constraints entry in the build file and the lockfile line; refused when the build verifies dependencies. All of them start from Open fix PR when hosted Renovate finds nothing to bump. See Transitive dependencies.

    • Action required: none.

  • 2026-10-15 — Upstream images: the newer tag that fixes them, and a pull request that moves the reference. For an image your organisation pulls through the dependency proxy and does not build, fremforge now looks for the newest tag of the same line (for example 16.4 to 16.10, never another major or minor version), or the same tag rebuilt upstream, scans it, and shows on each finding Newer tag <tag> fixes N of this image’s findings, Rebuilt upstream: pulling <tag> again fixes N, or Upstream image, no newer fixed tag. It is also upstream_update in GET /orgs/{org}/code-security/images/findings. Open PR with <tag>, or POST /orgs/{org}/dependency-updates/security-fixes/image-ref-requests, opens one security fix pull request in each repository that references the image at the tag you pull, in docker compose, Kubernetes manifests, Helm values or CI image: entries. See Newer tags for upstream images.

    • Action required: none.

  • 2026-10-15 — Security fixes for transitive dependencies. A vulnerable package your repository does not declare itself now gets a security fix pull request too. npm (package-lock.json): when hosted Renovate finds nothing to bump, fremforge pins the package with an overrides entry in package.json and moves its lock entries to the fixed version, but only when that version declares the same dependencies, so npm ci accepts the lock unchanged otherwise. Maven packages seen in your SBOM get Pin as transitive on the finding, or POST /orgs/{org}/dependency-updates/security-fixes/transitive-requests, which adds a <dependencyManagement> entry to the root pom.xml. Go needs nothing new: the fix raises the // indirect line in go.mod. They are ordinary security fix pull requests, with the same branch, label, limits, Release age and merge setting. pnpm, Yarn, Python and Gradle followed the same day (see “Transitive security fixes for pnpm, Yarn, Python and Gradle” above). See Transitive dependencies.

    • Action required: none.

  • 2026-10-15 — “Needs migration” when a fix exists only under another package. A dependency finding whose advisory has no fix on the package you use, but is fixed under a successor the advisory names (a new module path or major version, such as Go github.com/docker/docker to github.com/moby/moby/v2 or github.com/pion/dtls/v2 to v3, or a renamed package, such as npm request to @cypress/request), now reads Needs migration to <package> (fixed in <version>) instead of “no fix yet”. It shows on Security › Findings › Dependencies (Findings and By package), as needs_migration in GET /orgs/{org}/code-security/deps/findings, and in a new Needs migration section of the weekly digest. No fix pull request is opened for these: moving to another package is a code change. See Needs migration.

    • Action required: none.

  • 2026-10-15 — Security fixes no longer follow a repository’s Renovate holds. A rule in a repository’s renovate.json that holds a package back from version updates (a packageRules entry with "enabled": false, ignoreDeps, ignorePaths, includePaths or enabledManagers) used to stop security fix pull requests for that package too. It no longer does: security fixes for that package now open like any other, by click or by your automatic mode. To keep a package out of security fixes, record an exception for its findings: it is visible, carries a reason and lapses on its expiry date. A top-level "enabled": false still turns Renovate off for the whole repository. See Your repository’s Renovate settings.

    • Action required: review repository hold rules. If a renovate.json holds a package back on purpose, and you do not want security fixes for it, dismiss its findings or request an exception.

  • 2026-10-15 — One list of exceptions: dismissals included. A dismissal is now an exception that needed no approval. Security › Findings › Exceptions has a new section, Accepted without approval, with every dismissal in force: one-finding dismissals, repo-wide dependency dismissals and image-wide ones, with a type filter. Each can now be revoked there, which reopens its findings at once; until now a dismissal could only lapse. Over the API, GET /orgs/{org}/exceptions?approval=none (or all for both kinds) lists them with "approval": "none" and scope finding, repo or image, and GET/POST …/exceptions/{id}/revoke take their ids. Revoking a repo-wide or image-wide one needs policy:write. Without the new parameter the list is unchanged, and nothing changes in what is dismissed, what blocks a pull request or when a dismissal lapses. See Exceptions without approval.

    • Action required: none.

  • 2026-10-14 — Security fixes without hosted Renovate, and merge when checks pass. Security fix pull requests no longer need Version updates: the first fix request, or choosing an automatic mode, sets up your organisation’s dependency bot with Version updates left off, and GET /orgs/{org}/dependency-updates reports it as security_fixes_bot. Merge when checks pass now applies to security fix pull requests too: they are armed once their required checks can pass, never for a fix that crosses a major version, never during a release freeze, outside your merge window only for a known-exploited fix, and never for a high-blast-radius package in an organisation that turns the setting on from now on. Organisations that were moved to Merge when checks pass on 2026-10-14 keep exactly what they had: their hosted Renovate security pull requests keep merging, and their security fix pull requests wait for review until their Security fixes take over from Renovate’s, a separate, audited switch; at the switch, fix pull requests follow When fixes merge. New organisations start on Wait for review. Release age (days) is applied to security fixes, known-exploited fixes excepted. New fix pull requests use branches security-fix/<package>-<version> and the label security-fix; open older ones get the label too. Archived and mirror repositories are refused with security-fix-repo-archived. An organisation can let the Security fixes lane take over from hosted Renovate’s own security pull requests (PUT /orgs/{org}/dependency-updates/security-fixes/lane, offered on request for customers); Renovate then opens version updates only. See Security fixes and Merging.

    • Action required: none. Nothing changes for an existing organisation until its Security fixes take over from hosted Renovate’s security pull requests.

  • 2026-10-14 — Dependency updates: Security fixes and Version updates on one page. Security › Fix › Dependency updates (also under Build & deploy) is now one page with two lanes, opened by one bot, <org>-fremforge-bot-deps: Security fixes, one pull request per vulnerable package or base image driven by your findings, and Version updates, hosted Renovate as before. The page also shows the repositories that take part and the recent activity. Security fixes have one set of settings: when fix pull requests are opened (Off, On click, Automatic for important findings, or the new Automatic for all high and critical), whether they wait for review or merge when checks pass, how many may be open per repository (now up to 10) and per day (up to 50), and which repositories they cover. The buttons are now Open fix PR, Fix all in this repository and Open base-image fix PR; the SAST button is AI fix, and “AutoFix” is no longer a product name. Nothing merges differently: organisations whose Renovate security pull requests merged themselves keep that, as Merge when checks pass, and fix pull requests opened from a finding still wait for review. Security fixes and AI fix now have separate limits. Remediation metrics now also count findings fixed by hosted Renovate’s own security pull requests. New API: GET/PUT /orgs/{org}/dependency-updates/security-fixes/settings, GET/POST .../security-fixes/requests, GET/PUT .../version-updates/settings (snake_case) and POST /orgs/{org}/code-security/sast/findings/{id}/ai-fix, with the scopes dependency-updates:read and dependency-updates:write. The older paths, fields and scopes keep working until 2027-10-15 and answer with Deprecation and Sunset headers: renovate:read/renovate:write (use dependency-updates:read/:write), PUT .../dependency-updates/settings and its security_automerge (use .../version-updates/settings and merge on .../security-fixes/settings), .../code-security/autofix/settings (use .../security-fixes/settings), .../code-security/autofix/requests and the three .../autofix request paths (use .../security-fixes/requests), and .../sast/findings/{id}/autofix (use .../ai-fix). See Dependency updates and Deprecated API.

    • Action required: none. If you automate the old fields or paths, move to the new ones before 2027-10-15.

  • 2026-10-14 — The Security console is reorganised. Security in the sidebar now has eight entries, in the order you handle a finding: Overview, Findings, Components, Prioritise (Fix-by SLA, Pull request checks), Fix (Dependency updates, Security fixes, AI fix, Workflow pinning), Reports (Compliance report, Control evidence, Vendor attestation, Remediation metrics, Notifications), Policies and Access (now also IP allowlist, Support access and AI connectors). The Edge policies page is gone: its settings moved to Prioritise, Access and Reports › Notifications. Supply chain is split into Fix › Workflow pinning and Components › Build attestations, and Control evidence and Vendor attestation moved from the Reports group into Security › Reports. Every old address redirects to its new page, and no setting, default or API path changed. One name per concept across the console and these docs: Fix-by SLA, not reachable, Security digest, Security fixes and AI fix. New pages: Supported ecosystems, SAST, Secret scanning, IaC and configuration scanning, Workflow pinning, Control evidence, Vendor attestation and Actions only on protected branches. Corrected: pages that described a “CVE policy” and a “Merge-block policy” switch that do not exist, custom SAST rules (not supported), push protection that “cannot be disabled” (it is always on, with a scanner failure mode), a scaffolded cosign workflow, fixes “for npm and Go” only, and the Renovate cadence (every night, not weekly).

    • Action required: none.

  • 2026-10-14 — Automatic security fixes (opt-in). An owner can let fremforge open security fix pull requests by itself, without a click, for high and critical findings that are reachable or known exploited, optionally only in listed repositories and optionally also for findings with unknown reachability. Off by default; the pull requests are never merged automatically and never use AI. See Automatic security fixes.

  • 2026-10-14 — Setup checklist, alerts when a finding becomes reachable or known exploited, and a fuller weekly digest. Security › Overview opens with a setup checklist computed from your organisation’s state: open known-exploited findings, images whose Go binaries were built without symbols (-ldflags=-s, so reachability cannot judge them), your AI provider for AI fixes (not set, set, or key rejected), your AutoFix limits and the reachability opt-ins. An owner can hide it and show it again. When an open dependency finding on a default branch becomes reachable or becomes known exploited, the organisation’s security contacts (members with Security alerts on) get one email per batch, at most one an hour, and your SIEM gets the audit events code-security.finding.became_reachable and code-security.finding.became_known_exploited; each finding alerts once per transition. It is on by default and an owner can switch it off for the organisation. See Finding alerts. The weekly digest now lists the week’s newly known-exploited and newly reachable findings and your AutoFix pull requests opened, merged and closed.

  • 2026-10-14 — The fremforge provider 0.1.1. principal_policy on fremforge_ssh_ca and default_template_repo on fremforge_branch_protection_defaults are deprecated: the provider no longer sends or reads them, and a configuration that still sets them plans clean, with a deprecation warning. With 0.1.0, a fremforge_ssh_ca block whose only argument is principal_policy fails, because the API has no other field to write. version = "~> 0.1" picks up 0.1.1 on tofu init -upgrade. See The fremforge provider.

    • Action required: run tofu init -upgrade (or terraform init -upgrade), then remove the two arguments from your configuration.

  • 2026-10-14 — Organisation branch-protection defaults apply when you save them, and two settings that did nothing are gone. Saving the defaults on the Repos page now applies them to the organisation’s existing repositories at once, instead of at the next hourly pass, and a new repository gets a rule for every protected branch pattern when it is created. Require a pull request (no direct pushes) is a checkbox on that form and is enforced: turning it on makes existing rules pull-request-only too, except rules with a push allowlist. Require review from code owners now applies: with a CODEOWNERS file, a pull request cannot merge while a code owner’s review request is open. Org-wide signed commits and the seat cap also take effect on save. The Default repository template and the SSH certificate authority’s Principal policy were removed: both were saved but never applied. See Branch protection and Authentication policy.

    • Action required: if an API call or your Terraform configuration sets default_template_repo or principal_policy, remove it. A non-empty default_template_repo is refused with removed-setting; principal_policy is ignored. See The fremforge provider.

  • 2026-10-14 — Hosted Renovate relocks compiled Python requirements. For a requirements*.txt written by uv pip compile or pip-compile, a dependency-update pull request now re-runs the command in the file’s header. It contains the whole relocked file: the bumped package, any other pin the bump moves (for example pydantic-core when pydantic moves), and their hashes. Before, it changed one line, and when another pin had to move, pip install --require-hashes refused it. The header must name its source file and use long options with = (--output-file=requirements.txt, --python-version=3.11); Renovate does not relock a header that uses -o or puts a space before a value. Hand-written requirements files are updated as before. See Compiled Python requirements.

    • Action required: if a compiled lock’s header uses -o or --option value, regenerate it once with the long, =-joined form.

  • 2026-10-13 — Opt-in: do not block pull requests on findings with no call path. An organisation owner can choose that a dependency finding whose reachability verdict is no call path does not fail fremforge/dep-scan, for every repository or a list of them. It is off by default. unknown, malware and known-exploited findings always block, nothing is hidden or dismissed, and the pull request comment lists what did not block and why. Read the risk on that page before turning it on.

  • 2026-10-13 — Reachability reads more of your dependencies. Java and Kotlin findings are followed through other packages’ compiled classes; PyPI releases published only as an sdist map to their import names; npm tarballs are streamed, so large packages are analysed like any other; and yarn.lock (classic and berry), bun.lock and pnpm-lock.yaml 5.x and 6 are read as well as package-lock.json. See Reachability.

  • 2026-10-13 — A refused AI key is shown. When your model provider refuses your organisation’s key on a real call, the provider row under AI integrations turns red and, with AI fixes on, the SAST page says so, instead of showing the key’s last successful test. Saving the provider tests it again.

  • 2026-10-13 — Known-exploited vulnerabilities: fixed first, filterable, and a SIEM event. A dependency or image vulnerability whose CVE is listed as exploited in the wild, by ENISA’s EU Vulnerability Database or CISA’s KEV catalogue, now gets its AutoFix pull request before every other queued request, first in Fix all, with known exploited in the title, the CVEs in the description and the label known-exploited. The findings API returns known_exploited (the listed CVEs and the lists) on dependency and image findings and takes ?known_exploited=true|false; the console’s Dependencies and Container images lists have a Known exploited only filter, and the Container images list now shows the Known exploited badge too. SIEM finding events gain security.finding.known_exploited, sent once when an open or dismissed finding becomes listed, and every finding event carries known_exploited. A known-exploited finding always keeps its full SLA, ranks before EPSS within its severity, and neither its AutoFix pull request nor a fixing version pulled through the dependency proxy waits for your minimum release age. See Findings API.

  • 2026-10-13 — AI inventory: licences from ModelPack, KitOps and Docker model metadata. A model file’s licence now also comes from the model artifact it belongs to, when you push it to your registry or pull it through the dependency proxy: the ModelPack config’s descriptor.licenses, the KitOps Kitfile’s part, model or package license, a Docker model’s GGUF general.license or its licence file, or the manifest annotation org.opencontainers.image.licenses. fremforge reads these from its own store and contacts no one; a Hugging Face model your CI pulls by name stays unknown. The API’s new licence_from says where a licence was declared. See Where licences come from.

  • 2026-10-13 — AI inventory: the models your organisation holds and the ones its CI pulls. Security → Components → AI inventory lists every model file found in your Git LFS, packages, container images, dependency-proxy pulls and Actions artifacts, with its format, scan verdict, the licence the file declares (GGUF general.license or a safetensors metadata licence; otherwise unknown) and what its header states (parameters, data types, architecture). It also lists the models your workflows pull, from the workflow files and the scripts they run: Hugging Face (from_pretrained, hf_hub_download, snapshot_download, huggingface-cli download, hf download), ollama pull, docker model pull, kit pull and modctl pull. A pull without a fixed revision (a 40-character commit sha for Hugging Face, an @sha256: digest otherwise) is a finding. Models are in the component inventory too, as pkg:generic/<file>@<sha256> and pkg:huggingface/<org>/<name>@<revision>. The inventory downloads as a CycloneDX 1.6 ML-BOM, and the compliance report has an AI inventory section. API: /orgs/{org}/ai/models, /ai/models/{sha256}, /ai/ml-bom, /ai/references (components:read). See AI inventory.

  • 2026-10-13 — Model scanning: an organisation policy, findings and enforcement. Model files (pickle, PyTorch, safetensors, GGUF, ONNX, Keras) in Git LFS, packages, the container registry and the dependency proxy are scanned for code that runs when the model is loaded, and the files your organisation holds that the policy blocks are listed under Security → Policies → Model scanning, with where each was seen. The policy has three modes: Shadow, the default for every organisation, lists findings and refuses nothing; Enforce refuses an upload of a blocked file with 422 and a container pull that would serve one with 403; Off lists nothing. An org owner can dismiss a finding for one file, with a reason and an expiry, and allow pickles of known ML frameworks. Model files in Actions artifacts are scanned after the run, as findings only. Above 4 GiB, a safetensors or GGUF file that passes its structure check is accepted in every mode, as since 2026-10-12. The same policy and findings are on the API (/orgs/{org}/security/model-policy, /orgs/{org}/security/model-findings), and changes are audited. See Model scanning.

  • 2026-10-13 — CI downloads served from the dependency proxy cache are counted in the pull census instead of the access log. When a Forgejo Actions job downloads a package file through the dependency proxy and the proxy serves it from its cache, allowed and without an error, the download is no longer stored as an event in the registry access log, its SIEM delivery or access-log.ndjson in the data export. It is counted in the pull census instead, per UTC day, package version and repository, with the ids of the Actions runs that pulled it: the census API gains a run_id filter and a run_ids list on each job consumer, and metadata/pulled-versions.ndjson gains run_ids. So which version entered which build stays answerable, per run. Not kept for these downloads: the file name, size, exact time of each pull, client address, user agent and request id. Every download fetched from the upstream registry, every download from your own registry, every refused, blocked, would-have-blocked or failed request, and every request by a person, a bot, a registry robot or an anonymous client is still one event. Events stored before this date are kept for their normal retention. See Registry access log.

    • Action required: if a SIEM rule or report counts registry.access.download events from CI jobs, read those counts from the pull census (GET /orgs/{org}/components/pulled) instead.

  • 2026-10-12 — Reachability for JavaScript, TypeScript, Python, Java and Kotlin, and what you can do with it. Pull request and default-branch dependency scans now check whether your code loads a vulnerable npm package (with Jelly) or imports a vulnerable PyPI or Maven package, directly or through other packages, and show the file and line. These verdicts are import level unless the advisory names the affected functions, and Python, Java and Kotlin findings are never marked no call path. On top: an opt-in SLA multiplier (1 to 4) for findings with no call path, never for known-exploited ones; a dismissal or exception that relied on no call path is revoked when a later scan finds a call path (reachability_changed); and SAST findings get deterministic triage signals (test or generated code, taint path, often dismissed here) with a collapsed Lower confidence group and ?sort=risk. See Reachability and Severity SLA.

  • 2026-10-12 — AutoFix for PyPI, Maven, Gradle, NuGet and Cargo, base images, and Fix all. AutoFix opens one pull request per vulnerable package in these ecosystems too, refreshing the lockfile (for Gradle, in a job on your own hosted runner), bumps an image’s FROM base when the newer base no longer has the vulnerability, and Fix all asks for every fixable package in a repository at once. AutoFix pull requests are never merged automatically.

  • 2026-10-12 — Issue due-date reminder emails. The day before an issue is due, its assignees (or, with nobody assigned, its author) get an email; while it is overdue the reminder repeats at most once a week, for up to four weeks. Everything due tomorrow and overdue arrives as one daily email, in your Forgejo language. It covers open issues in your organisations’ repositories, not pull requests and not personal namespaces. Turn it off per organisation in notification settings or with the unsubscribe link in the email. See Due-date reminders.

  • 2026-10-12 — Routine CI metadata reads leave the registry access log. An allowed metadata read (a package index or version list) that a Forgejo Actions job makes through the dependency proxy, answered without an error, is no longer stored in the access log, its SIEM delivery or the data export. One install makes hundreds of them, and the download that follows is what shows which version entered the build. Every download, every refused, blocked or would-have-blocked request, every failed request, and every request by a person, a bot or an anonymous client is still recorded, metadata reads included; the pull census is unchanged. Events stored before this date are kept for their normal retention. See Registry access log.

  • 2026-10-12 — Hosted runners pull container images through your dependency proxy. On fremforge-hosted runners, the images the job’s Docker daemon pulls (docker pull, docker run, job and service containers) come from ghcr.io, quay.io, mcr.microsoft.com, registry.k8s.io, public.ecr.aws and registry.access.redhat.com through your organisation’s dependency proxy, and are cached for your organisation. docker.io, registry.redhat.io and registry.connect.redhat.com go through the proxy only for an organisation that has added its own upstream credential for that registry, and not for pull requests from forks. It applies to jobs whose package installs go through the proxy (runner pull-through, below). The proxy is checked at the start of every job: if it cannot be reached, or a pull through it fails, the image is pulled from the registry directly, as before. On this path the proxy is a cache, not a gate: a pull your package policy or malware check refuses also falls through to the registry, so where a refusal must stop the pull, pull from frem.sh/<org>/dependency-proxy/<registry>/<image> explicitly. A docker buildx builder with the docker-container driver still pulls directly. See Dependency proxy.

  • 2026-10-12 — Retention keeps the base images your current builds use. A container image cached by your dependency proxy is no longer removed for not having been pulled within retention_days while one of your organisation’s current images is built on it, that is, while every layer of the cached image is also a layer of an image still published under a tag in your organisation’s registry. Its manifest, configuration and layers are kept together, so a pull of it keeps working, and so is a multi-platform index whose platform image you build on. It still counts toward your storage, and once no current image is built on it the last-pulled rule applies again. An image that only shares some layers with your builds, a base used only for a platform other than linux/amd64, and a build that recompresses the base image’s layers keep the last-pulled rule. See Retention.

  • 2026-10-11 — Reachability for Go, and AutoFix pull requests. Go binaries in the images in your registry are read with govulncheck, so a dependency or image finding is marked reachable, no call path or unknown, with the evidence. Findings lists are ranked by it, and findings with no call path move to a collapsed Probably unexploitable group; nothing is hidden, dismissed or unblocked. Fix on a dependency finding opens one pull request that bumps the package to the lowest version fixing every open advisory (npm and Go first). An owner can also turn on AI-generated fixes for a short list of SAST rules, using only the organisation’s own model provider; it is off by default. See Reachability and AutoFix.

  • 2026-10-11 — The dependency proxy is on by default for every organisation. The dependency proxy is available on every plan, customers’ organisations included, and is on for every organisation that has not saved its own dependency proxy settings. An organisation that has saved them keeps them, and an owner can turn the proxy off under Build & deploy → Dependency proxy. Runner pull-through is on for the same organisations: jobs on fremforge-hosted runners install npm and PyPI packages, and by default Go modules, Maven and NuGet packages and the Trivy vulnerability database, through the organisation’s proxy, so each install is cached for the organisation, passes its package policy and malware checks, and is in its access log. The proxy is checked when each job starts; if it cannot be reached, the job installs from the public registries instead. A trial organisation’s proxy cache is limited to 5 GB. See Hosted runners and Package caches.

  • 2026-10-11 — The shared Docker Hub mirror on hosted runners is retired. Hosted runners no longer pull Docker Hub images through a mirror shared by all organisations. A Docker Hub pull in a hosted-runner job now goes to Docker Hub through fremforge’s egress proxy, without credentials and therefore at Docker Hub’s anonymous rate limits, unless your organisation has added its own Docker Hub credential: then the pull goes through your dependency proxy and is cached for your organisation. See Docker Hub through the dependency proxy.

    • Action required: if your workflows pull images from Docker Hub, an organisation owner adds your Docker Hub credential in the org admin under Build & deploy → Dependency proxy → Upstream credentials (https://frem.sh/<org>/_admin/dependency-proxy#upstream-credentials). Without it, those pulls are subject to Docker Hub’s anonymous limits.

  • 2026-10-11 — The dependency proxy rides out short outages. If Forgejo or the fremforge API is briefly unavailable, the proxy keeps serving cached content to a caller it allowed the same read in the previous 15 minutes, instead of answering 503; a revoked credential or a refusal still takes effect at once. When an upstream registry is down, a public image tag your organisation has never pulled can be served from the last good copy another organisation cached without credentials; content fetched with an organisation’s own credential, and Docker Hub content, is never shared this way. Retention no longer removes a cached package version (npm, PyPI, Maven, NuGet, Go, Cargo, Helm or RPM) while it is a current component in your organisation’s component inventory; container images followed on 12 October (above). See Upstream outages and Retention.

  • 2026-10-11 — The fremforge Terraform and OpenTofu provider 0.1.0. A dedicated provider, source = "frem.sh/fremforge/fremforge", manages your organisation’s fremforge settings with typed resources: authentication and access policy, the IP allowlist, scan and scanner policy, immutable releases, image and package signature rules, the dependency proxy, package access and registry robots, with import by organisation slug and drift on every argument you set. tofu init or terraform init installs it from frem.sh and verifies its signature; builds exist for Linux, macOS and Windows. Repositories, teams and branch protection stay with the Forgejo provider. See The fremforge provider.

  • 2026-10-11 — Package policies are enforced, and known malware is refused for every organisation. A package policy set to Enforce now refuses, with 403, a download that breaks it, from your package registry and through the dependency proxy; before, Enforce only recorded what it would have refused. A policy in Shadow, the default, still only records. A file that bundles a package listed in an OSV MAL-* advisory is refused for every organisation, whatever its mode: registry files, packages fetched through the dependency proxy (npm, PyPI, Maven, NuGet, Go, Cargo; the version is also left out of the metadata the proxy serves) and images cached through the proxy with an open malware finding, as pushed images have been since 2026-10-04. An approved exception lets one registry file through. When the dependency proxy cannot get a policy answer, it now refuses the download with 503 rather than serve an unchecked version. Your package verdicts, Would have blocked, package findings and the package-policy API results are now shown to your organisation, with audit, SIEM and webhook events, alert mails and digest lines from that day on. Container images stay in shadow mode under the package policy. See Package policies.

    • Action required: if your package policy is already set to Enforce, check Security → Policies → Package policies → Would have blocked before relying on it, or set it to Shadow until you have.

  • 2026-10-11 — MCP connectors with sign-in. claude.ai, ChatGPT and Mistral Le Chat can connect to https://frem.sh/_app/mcp by signing you in to frem.sh, with no token to paste. A connected assistant can also read your repositories, pull requests, issues and Actions runs, and you can withdraw it at any time with DELETE /users/me/connector-grants/{id}. Organisation owners can block connectors under Security. The page has setup steps for each of the three apps, sign-in for Cursor, and the redirect rules for desktop apps. See Remote MCP server.

  • 2026-10-11 — npm audit and pnpm audit work through the dependency proxy. When npm or pnpm installs through your organisation’s dependency proxy (/_app/proxy/<org>/npm/), for example on runners with runner pull-through on, the proxy answers the bulk advisory request from fremforge’s own OSV-based advisory index, so an audit reports real advisories. Your dependency list is not forwarded to registry.npmjs.org or any other third-party advisory service. npm 7+ and pnpm 11+ are supported; npm 6 and pnpm 10 use an older endpoint the proxy answers with 404. pnpm 11 reads its registry from PNPM_CONFIG_REGISTRY or an .npmrc, not from NPM_CONFIG_REGISTRY. See Package caches.

  • 2026-10-10 — Remote MCP server. AI assistants that speak the Model Context Protocol can connect to https://frem.sh/_app/mcp with a fremforge API token: Claude Code, Cursor, Mistral Le Chat and the Mistral Agents API, among others. Its 41 read-only tools cover findings, components, deployments, package access, policies, runner usage and CI logs. Each tool is one REST API operation called with your token, so it has the token’s scopes and nothing more. OAuth sign-in for claude.ai and ChatGPT connectors is not available yet. See Remote MCP server.

  • 2026-10-10 — Correction: SAML single sign-on is not available. The SAML 2.0 page described a SAML service provider as live since 2026-05-17. It never was: an SSO source of type SAML could not be registered. Connect Microsoft Entra ID, ADFS or any other identity provider over OIDC; the OIDC guide now has an ADFS section. See SAML.

  • 2026-10-10 — Package publishes from hosted runners are scanned, and their downloads count toward package egress. A fremforge-hosted runner job’s package registry traffic for an organisation now goes through the same path as every other registry request: each publish is malware-scanned (an infected one is refused with 422, an upload over 4 GiB with 413), checked against package access, and recorded in the access and audit logs; its downloads count toward the organisation’s package egress caps (100 GB per seat soft, 300 GB per seat hard, then 1 Mbps). Changed 2026-10-18: downloads by fremforge-hosted runners no longer count toward the caps; see the 18 October entry above. Packages in a user’s personal namespace are not covered. See Malware scan.

  • 2026-10-10 — Correction: a push keeps auto-merge. The Auto-merge section said that pushing new commits to a pull request disables its auto-merge. It does not: the pull request stays scheduled and merges once the required checks pass on the new commit, with or without a merge queue. In a merge queue, a push takes the pull request out of the queue, and it rejoins once its checks pass. To stop a merge, cancel auto-merge. See Auto-merge.

  • 2026-10-09 — A queued pull request builds once. While a pull request is in the merge queue, its merge group’s run is its build: its own pull_request runs of workflows that also trigger on merge_group are cancelled when it enters the queue, and its required checks take the … (merge_group) result. Workflows without a merge_group trigger keep running on the pull request, and leaving the queue brings the normal pull_request checks back. See Merge queue.

  • 2026-10-09 — Pulled versions and Deployments in the console and the data export. Security → Components has two new tabs. Pulled versions lists the package versions your organisation’s consumers actually downloaded from its registry and through the dependency proxy, vulnerable ones first, with who pulled them, filters and a CSV download. Deployments lists what your CI/CD reported as deployed where, newest first. Every data export now contains the pull census as metadata/pulled-versions.ndjson, next to the reported deployments in metadata/deployments.ndjson. See Pulled package versions, Deployments and Export schema.

  • 2026-10-09 — Component inventory for every organisation. Every third-party component your organisation uses is now searchable in one place, built from the SBOMs fremforge already holds for your repositories, releases, container images and uploads. Find where a component is used by package URL, version or version range (vers:), list the vulnerable components in use with their open advisories, and classify uses as sandbox, development, test, staging or production, by rule, by the SBOM upload or by a deployment your CI/CD reports. It is in the org admin under Security → Components, on the API at GET /orgs/{slug}/components, /components/usages and /components/vulnerable (scope components:read), paged by cursor, and as CSV with format=csv. See Component inventory.

  • 2026-10-09 — Per-package access for every package type, and filtered package lists. Per-package access and protected names now cover every package type the registry serves, NuGet, Cargo, Go, Debian, RPM and the rest included. In an organisation that uses it, the API’s package list and the registry indexes (npm, Helm, NuGet, Composer, Cargo, Chef, Conda, RubyGems, CRAN, Conan and Swift) leave out the packages the caller cannot read. See Package access.

  • 2026-10-09 — Per-package access and protected package names. An owner can put a package, or every package of the organisation, on per-package access, as on GitHub: it inherits read, write and admin from its linked repository, and teams and other repositories’ Actions jobs can be granted access to that one package (a job of a granted repository can also publish a package linked elsewhere). Protected names limit who may publish or delete matching packages, as GitLab’s protected packages do. Nothing changes until an owner turns it on. Container, generic, Helm, Maven, npm and PyPI packages; console under Security → Access → Package access, the API under /orgs/{org}/packages/..., the configuration-as-code module, the audit log and the data export. See Package access.

  • 2026-10-09 — Enable and disable workflows through the API. PUT /api/v1/repos/{owner}/{repo}/actions/workflows/{workflow_id}/enable and /disable do what the Enable workflow / Disable workflow buttons do, for a repository admin with a token. GET /api/v1/repos/{owner}/{repo}/actions/workflows lists the default branch’s workflows with their state (active or disabled_manually), and GET .../workflows/{workflow_id} returns one. Paths and JSON are Gitea’s, so Gitea API clients work unchanged. See Enabling and disabling workflows.

  • 2026-10-08 — Data export files deleted after 7 days. An export’s archive file is now deleted 7 days after it was made, in both storage regions, as the Privacy notice states; it was kept up to 90 days (13 months in the disaster-recovery copy). Under a legal hold the file is kept. See Data export.

  • 2026-10-08 — Evidence retention per class, and a legal hold that suspends all of it. An owner now sets how long each kind of evidence is kept, under Reports → Evidence retention or with PATCH /orgs/{org}/evidence-retention: audit log content, the registry access log, resolved findings, SBOMs of unreleased builds, provenance attestations and data export downloads, each within stated bounds. The defaults are what every organisation had before, so nothing changes until you choose. A legal hold now suspends deletion of every class; before, audit content redaction and SBOM pruning did not check it. The settings are in the data export as policy/settings/retention.ndjson. See Evidence retention.

  • 2026-10-08 — Package tags, further files, refusals and CI jobs in the audit log. Every registry write is now an audit event with the package, its digest and who wrote it (a person, a registry robot, or a Forgejo Actions job with its repository and run): package.upload.accepted and .refused, package.delete.accepted and .refused, and for container tags package.tag.created, package.tag.moved (with the digest it pointed at before) and package.tag.deleted. Release events name the release, its target and its assets. See Package and release events.

  • 2026-10-08 — Read-only Auditor role. Every organisation has a new Auditors team, created by fremforge. Its members can read every repository and the org admin settings, including members, SSO, billing settings and the audit log, in the fremforge console, on the API and in Forgejo, and can change nothing: every write is refused, on the API with the auditor-read-only error. Data export, SBOM and billing downloads, CI logs, webhooks and Actions runner settings stay closed to auditors. The first 5 auditors in an organisation are free; a sixth or later auditor is a billable seat. Every auditor read is recorded in the audit log as tenant.auditor.read. An owner adds auditors from Org admin → Members. A team you had already named Auditors yourself is left unchanged. See Auditors.

  • 2026-10-07 — Registry robots, with GitHub Actions OIDC exchange. An organisation can create registry robots: registry logins that belong to the organisation rather than a person, for CI outside fremforge (such as GitHub Actions) and for image pull secrets (such as OpenShift). A robot reads, or reads and publishes, the packages of one organisation, holds no seat and expires within 365 days. A GitHub Actions job can exchange its own OIDC token for a robot token that lasts 1 hour, so no registry secret has to be stored in GitHub. See Registry robots.

  • 2026-10-07 — Registry robots publish but never delete. A registry robot (an organisation’s registry login for CI outside fremforge and for image pull secrets) can read, or read and publish, packages, and every delete it attempts (a package version, a file, a container tag or an image, on every registry API) is refused with 403 and recorded in the audit log as registry_robot.delete_refused. Deleting stays with an organisation admin. Robot usernames start with the organisation name, shortened when needed to fit 40 characters. See Registry robots.

  • 2026-10-07 — Data export carries your security data and SBOMs. The organisation export now includes scan findings with their dismissals, package-policy state, signed build and release attestations (since 2026-10-06), and the SBOMs of your repositories and container images (CycloneDX and SPDX). The data-export page now verifies the bundle’s signature with fremforge-slsa-builder-v2, the active key since 2026-09-12; it named the retired v1 key, under which a current bundle does not verify. See Data export.

  • 2026-10-07 — Image block threshold, and container pull-gate decisions in the audit log. The severity at which container-image findings block merges and pulls is now set per organisation, from critical only to every finding (default high and critical). Every refused container pull, and every pull a gate would have refused under your warn or in observation mode, is an audit event that reaches your SIEM, one per image digest per hour with a count. See Block threshold and Container pull gates.

  • 2026-10-07 — Product-update email, opt-in. Organisation owners can turn on Product updates in their notification settings to get significant changes from this page by email. Off unless you turn it on; one-click unsubscribe in every mail. See Subscribing.

  • 2026-10-07 — Package egress: a soft cap that informs and a hard cap that throttles. Package-registry downloads stay included with no per-GB charge. Past the soft cap of 100 GB per seat in a calendar month (UTC), the billing page says so and your operational alerts address gets one email that month; nothing slows down and nothing is charged. Past the hard cap of 300 GB per seat, downloads are throttled to 1 Mbps per connection until the 1st of the next month. The billing page shows the month’s usage against both caps.

  • 2026-10-07 — Malware scanning reaches inside packed uploads. Package uploads and container layers that the scanner could not open before are unpacked first and their contents scanned: npm and Cargo publish bodies, Debian (.deb) and RPM packages, Conda (.conda) packages, zst/zstd-compressed files and zstd-compressed container layers. See Malware scanning.

  • 2026-10-06 — Helm charts, as OCI artifacts and in a classic chart repository. Push charts with helm push to oci://frem.sh/<org> or upload them to the organisation’s classic Helm repository; a published chart version cannot be overwritten. See Helm.

  • 2026-10-07 — Changelog RSS feed. This page is available as an RSS feed at /reference/changelog/index.xml, one item per entry. See Subscribing.

  • 2026-10-05 — fremforge CLI 0.5.0. fremforge auth login --device signs in from a headless or SSH machine: the CLI shows a code that you approve in a browser at frem.sh/_app/device. fremforge auth configure docker|pip|npm|maven|gradle sets each tool up to use that sign-in for the frem.sh package registries, so no personal access token is needed. The CLI access token lives at most 1 hour and is refreshed automatically. fremforge release verify checks an immutable release. Keychain storage on macOS and Windows is new and has only been unit-tested; see the CLI page.

  • 2026-10-04 — Actions jobs publish packages with the job token. A workflow can publish to its own repository’s package registry with the job’s token instead of a stored PAT. See Packages.

  • 2026-10-04 — Package versions are immutable. A published package version can no longer be overwritten, in every organisation, unless the organisation lets a repository opt out. Refused overwrites are recorded in the audit log.

  • 2026-10-04 — Registry access log. Every package and container request is logged with its client identity, and the log can be forwarded to your SIEM. See Registry access log.

  • 2026-10-04 — Security alert webhooks, with a ServiceNow format. Outbound webhooks can carry security events, including a ServiceNow incident format, with a test-send button on the webhooks page. See Security alert webhooks.

  • 2026-10-04 — One IP allowlist for every HTTPS surface. The organisation’s IP allowlist now applies to the web admin, the fremforge API, the repository web interface, the Forgejo REST API, Git over HTTPS, Git LFS and the package registries. Git over SSH is not covered. See IP allowlist.

  • 2026-10-04 — “SSH off” also refuses clone and fetch. An organisation that has turned SSH off now refuses clone, fetch and LFS over SSH as well as push, and the refusal names the setting and the HTTPS clone URL.

  • 2026-10-04 — Malicious container images are refused at pull. A pull of an image whose packages match an OSV MAL-* malware advisory is refused. Container-image findings appear on the Malware tab. See Malicious packages.

  • 2026-10-04 — Scan comments lead with what is new. The sticky PR comment lists findings that are new relative to the default branch first.

  • 2026-10-03 — Data export can include package contents. On request, the organisation export includes every file of every package version as a separate signed archive, with an SBOM next to each file, and a real Git LFS manifest. See Data export.

  • 2026-10-03 — 90 days to export after termination. Customer content is now kept for 90 days after termination (was 60) so it can be exported (Terms 1.11 §16.5).

  • 2026-10-03 — Times shown in your own time zone. The fremforge console converts every time to the viewer’s time zone in the browser.

  • 2026-10-02 — Immutable releases and release attestation, opt-in per organisation. An organisation admin can make releases and version tags immutable once published, with a signed release attestation. Off until an admin turns it on. See Immutable releases.

  • 2026-10-02 — SIEM forwarding: CEF, syslog over TLS and custom auth headers. The SIEM stream can now be sent as CEF (over HTTPS or syslog) or RFC 5424 syslog over TLS, with a custom auth header per endpoint, batching, and replay without dropped events. See SIEM.

  • 2026-10-02 — Configuration as code with Terraform or OpenTofu. A tested module and provider setup to manage an organisation’s settings from HashiCorp Terraform or OpenTofu. See Terraform and OpenTofu.

  • 2026-10-02 — Cancelling a running job posts its final commit status, instead of leaving it pending.

  • 2026-10-01 — Default-branch malware matching for every organisation. fremforge builds an SBOM of each default branch and matches it against OSV MAL-* malware advisories daily. Findings are listed, dismissed and bulk-dismissed on a new Malware tab, with an alert. SBOMs are now generated in SPDX 2.3 as well as CycloneDX, and finding dismissals can be given an expiry date.

  • 2026-10-01 — Legal: Terms 1.9 to 1.12 are in force. The standard plan’s availability commitment is 99.9% per month (Terms 1.9, SLA 1.6, which also raises the service-credit bands); an amendment is judged adverse by its effect on you (Terms 1.10); the 90-day export window above (Terms 1.11); and you may use the Service across your group and move your subscription after a reorganisation (Terms 1.12, 2026-10-05). Runner minutes are counted per job, rounded up to the next whole minute (AUP 1.8).

  • 2026-10-04 to 2026-10-06 — Legal: published versions that take effect on 2026-11-03. DPA 1.40 and 1.41, SLA 1.12 and 1.13, AUP 1.9 and Privacy notice 1.20 are announced by notice and take effect on 2026-11-03. DPA 1.42 (package SBOMs in the package export) and DPA 1.43 (corrected email and CDN disclosures, more in the data export) widen what fremverk provides and take effect on 2026-11-03. Until then the earlier versions apply.

  • 2026-10-06 to 2026-10-07 — Legal: more published versions that take effect later. SLA 1.14 (one support-targets table with workaround and resolution targets per severity) and AUP 1.10 take effect on 2026-11-03. DPA 1.44 (how alerts reach on-call staff, stated as operated) and DPA 1.45 with Privacy notice 1.21 are announced by notice and take effect on 2026-11-06; DPA 1.46 and Privacy notice 1.22 and 1.23 widen what fremverk provides and take effect on 2026-11-06 too. AUP 1.10, DPA 1.45 and 1.46 and Privacy notice 1.21 and 1.23 describe the dependency proxy, which is not yet available. Until then the earlier versions apply.

  • 2026-10-07 — Documentation in Danish. The delivery documentation is now also in Danish at docs.frem.sh/da/: getting started and your first hour, SAML and OIDC single sign-on, SCIM, package registries and registry robots, data export and its schema, org administration and members, the IP allowlist, the authentication policy, the audit log, SIEM forwarding and support. Use the language switcher next to the search box. The English page stays authoritative, and a Danish page whose English original has changed since it was translated says so at the top. The Danish text has not yet been reviewed by a native speaker.

• Action required: If your organisation has SSH turned off and still clones over SSH, switch to the HTTPS clone URL. Workflows that publish packages with a stored PAT can move to the job token.

2026-09-30 — September 2026

• Surface: runners, security, actions, git, cli, dependency updates, benches, billing
• Change:
  • 2026-09-30 — More concurrent CI jobs. Hosted-runner concurrency is 2 jobs per seat, at least 10 and at most 60 per organisation, plus best-effort use of idle capacity up to 60 (AUP 1.6). The job start rate scales with it. See Runners.
  • 2026-09-30 — A job whose if: is certainly false is skipped by the server, without starting a runner VM.
  • 2026-09-29 — Wider licence and code scanning. Licence scanning reads dependency licences from every lockfile, including Go, Maven, NuGet and PyPI, and reports “lookup unavailable” instead of a false result during an outage. SAST runs a fremforge rule set with injection rules for JavaScript and TypeScript at error level and rules for six more languages, including C and C++. See Licence scanning.
  • 2026-09-29 — Container layers are malware-scanned at push, and a manifest pull waits for its layers’ scan result. See Malware scanning.
  • 2026-09-27 — fremforge/release-age is a required check. Automated dependency-update PRs are held until every version their lockfile resolves to is at least 3 days old, and hosted Renovate relocks resolve through a view that hides newer versions. See Dependency updates.
  • 2026-09-22 — Trials with a card on file convert to paid at expiry without further action.
  • 2026-09-21 — Scheduled workflows fire once per schedule, not once per Forgejo replica.
  • 2026-09-17 — Forgejo 15.0.9, after 15.0.7 (2026-09-04) and 15.0.8 (2026-09-13). All three are upstream security releases; 15.0.8 fixes CVE-2026-89094.
  • 2026-09-13 — CLI attest-verify. The CLI checks a build-provenance attestation and its transparency-log entry locally, without trusting fremforge’s own verdict (CLI 0.3.0).
  • 2026-09-12 — Public transparency log at log.frem.sh. Build-provenance attestations are appended to a C2SP tlog-tiles log. Its checkpoints are cosigned by an external witness since 2026-09-17. See Transparency log.
  • 2026-09-12 — CLI auth login --no-browser signs in on a machine without a browser (CLI 0.2.3).
  • 2026-09-11 — Build provenance for Actions builds. Container images that a workflow builds and pushes get a provenance attestation, retrievable by artifact digest, and release assets inherit the provenance of the build that produced them. See SBOMs.
  • 2026-09-04 — Secret scanning at PR time is enforced. A PR that adds a secret gets a failing fremforge/secret-scan check, and findings link to the commit and file. Findings have their own page and an overview tile. See Push protection.
  • 2026-09-01 — frembench dev benches. A paid add-on: a Linux machine you reach from the browser, with the same toolchain as the CI runners. €39 per bench seat per month with 200 hours included, €0,20 per hour beyond, capped at €99 per bench seat per month. Not available on trials. See frembench.
• Action required: None.

2026-08-29 — August 2026

• Surface: runners, actions, admin, security, cli, audit, partners, legal, console
• Change:
  • 2026-08-29 — Runner VMs run on Debian 13. See Runners.
  • 2026-08-27 — Environment-scoped variables and secrets reach the jobs that deploy to that environment.
  • 2026-08-26 — New accounts are notified on mention only, instead of on all activity. Existing accounts are unchanged.
  • 2026-08-26 — PR approval mail goes to the people a PR is waiting on.
  • 2026-08-22 — Go 1.27 added to the runner toolchain; Go 1.25 removed. Go 1.26 is updated to its latest patch. See Runner image.
  • 2026-08-22 — New repositories accept changes to main through pull requests only by default.
  • 2026-08-22 — v1.2.1. Dependency updates only; no change in behaviour.
  • 2026-08-20 — Organisation owners are no longer exempt from required approvals by default; an organisation can turn the exemption back on. Owners-only approvals can be required, so a member’s PR needs an owner’s approval. See Branch protection.
  • 2026-08-16 — OIDC tokens for Actions carry an immutable, environment-scoped subject per tenant. See OIDC.
  • 2026-08-16 — Partner programme. Partner portal and Partner API, for resellers. See Partners and the Partner API.
  • 2026-08-13 — Legal: Terms 1.8. The fremforge mark is a registered EU trade mark. Earlier in August: Terms 1.2 to 1.7, DPA 1.20 to 1.36, SLA 1.3 to 1.5 and AUP 1.3 to 1.5 corrected the documents against how the Service runs, added the EU Data Act switching terms and CLI terms, and made the security-patching targets contractual (Critical 48 h, High 72 h, Medium 7 days).
  • 2026-08-11 — Console in six languages. The fremforge console is available in English, Danish, German, French, Dutch and Swedish.
  • 2026-08-11 — Accessibility statement published, with automated keyboard and screen-reader checks behind it.
  • 2026-08-09 — In-VPC Maven and NuGet caches for hosted runners. See Package caches.
  • 2026-08-04 — Verify your own audit chain. The audit-log WORM anchor is signed, and the CLI’s audit-verify recomputes the chain locally. Each CLI release ships a CycloneDX SBOM inside its signed manifest. See Audit chain.
  • 2026-08-04 — AI-generated output carries the EU AI Act Article 50 machine-readable marking.
• Action required: Workflows that request Go 1.25 should move to 1.26 or 1.27, which are pre-installed.

2026-07-31 — July 2026 (8–31 July)

• Surface: git, actions, admin, billing, security, dependency updates, runners, docs
• Change:
  • 2026-07-31 — Forgejo 15.0.6, an upstream security release fixing CVE-2026-60004 (CVSS 9.8).
  • 2026-07-31 — on: workflow_run runs natively in Forgejo Actions.
  • 2026-07-31 — Guests and Collaborators. Every organisation has canonical Guests (free read on chosen repositories) and Collaborators (write on chosen repositories, billable) teams. A seat is billable when its holder can write somewhere; read-only access is free. See Members.
  • 2026-07-25 — API error reference. Every error type the fremforge API returns has its own page, and the security findings API is documented. See API reference.
  • 2026-07-23 — Python 3.14 in the runner toolchain.
  • 2026-07-20 — Security fix PRs from hosted Renovate. Hosted Renovate opens fix PRs driven by OSV advisories, groups related updates, and reaches private registries across your organisations. See Dependency updates.
  • 2026-07-16 — Re-run PR scans without a new commit. See Re-running scans.
  • 2026-07-10 — Signup signs you in after payment, without a temporary-password email.
  • 2026-07-08 — Scan policy per repository. Security scanning can be set to enforce, audit or off as an organisation default and per repository.
• Action required: None.

v1.2.0 — 2026-07-07, Forgejo 15.0.3 + out-of-band, EU-sovereign scanning

• Version: v1.2.0
• Surface: git, actions, security
• Change:
  • Forgejo upgraded to 15.0.3 — the latest upstream release, with its security hardening and stability fixes.
  • Faster pull requests. Security scanning (dependencies, code/SAST, licenses, containers, and SBOM) now runs out-of-band — off your CI pipeline’s critical path — so it no longer adds time to your workflows. Results still land as clear pass/fail fremforge/* checks on every PR.
  • EU-sovereign dependency scanning. Dependency-vulnerability checks now run entirely within our European infrastructure, with the vulnerability database refreshed daily — stronger data residency, always-current coverage.
  • More resilient at scale — the scanning service was hardened to absorb bursts of concurrent pull requests smoothly.
• Action required: None. Scanning is automatic; the pass/fail checks appear on each PR exactly as before.

v1.1.0 — 2026-07-02, Free cross-org readers + sign-in hardening

• Version: v1.1.0
• Surface: admin, billing, sso
• Change:
  • Free cross-organisation readers. Members can be granted read-only access across organisations without consuming a paid seat — auditors, collaborators, and stakeholders get the read access they need while paid seats stay reserved for contributors. Reader access is read-only (the Viewers team) and never grants write.
  • Cross-organisation sign-in hardening. Per-organisation sign-in can require a fresh identity-provider re-authentication when a session originates from a different organisation. Enforcement is automatic and capability-gated: it activates only once your IdP is confirmed to support step-up re-auth and never blocks sign-in for a provider that doesn’t — no configuration, no lock-out risk.
• Action required: None.

2026-06-24, Runners moved to ECS-per-job on Debian + Node 24

• Surface: runners, actions
• Change: The hosted Forgejo Actions runner pool is now ECS-per-job (a fresh Elastic Cloud Server VM per job, kernel-isolated) instead of the previous pod model. The hosted runner image moved to a Debian (glibc) base with Node 24 LTS. Docker is pre-installed and runs natively on the runner VM — docker build, docker run, and docker/build-push-action all work without Kaniko workarounds. Toolchains, git-lfs, jq, yq, gitleaks, trivy, skopeo, shellcheck, shfmt remain pre-installed; see docs.frem.sh/build/actions/runner-image/ for the current list.
• Action required: Workflows that previously called kaniko for image builds can switch to native docker build or docker/build-push-action@v5. The Kaniko path continues to work for the migration window.

v1.0.0 — 2026-06-19, SSO auth sources over the API

• Version: v1.0.0
• Surface: api, admin
• Change: You can now create and update an organisation’s OIDC single-sign-on source over the REST API (POST / PUT /_app/api/v1/orgs/{org}/sso), in addition to the admin UI wizard. This works with any standards-compliant OIDC provider, registers the group→team mapping, and enforces MFA verification on the resulting source by default. This release also introduces the version/commit build stamp in the app footer (see Versions and the app footer).
• Action required: None. The admin UI SSO wizard continues to work unchanged.

2026-05-08, Hosted CI runners online

• Surface: runners, actions
• Change: fremforge’s hosted Forgejo Actions runners are now live. Workflows targeting runs-on: fremforge execute inside our hosted runner image (Alpine 3.22 + bash, GNU coreutils, git + git-lfs, build-essentials, Node 22 LTS, jq, yq, gitleaks, trivy, kaniko, shellcheck, shfmt). See docs.frem.sh/build/actions/runner-image/ for the full tooling list and how to install language toolchains via standard setup-* actions. The image rebuilds weekly with a Trivy CVE gate; per-build manifests publish to the runner-image manifests linked below.
• Action required: None for now. The first sandbox-tenant onboarding flow uses the full path. Existing self-hosted (BYO) runner setups continue to work unchanged.

2026-05-06, Initial publication

• Surface: trust, infra
• Change: First publication of this changelog at docs.frem.sh/reference/changelog/. Referenced from docs/runners/ for the weekly runner-image manifest. Pre-launch operations changes from before this date are not back-published.
• Action required: None. Bookmark this page.

Subscribing

• Email (organisation owners): turn on Product updates in your notification settings. It is off unless you turn it on. fremverk then emails you an entry from this page when it covers a significant new feature or a change to the interface. Not every entry is mailed, and none is mailed on a schedule. It reaches you only while you are an owner of at least one organisation. Every mail has a one-click unsubscribe link, and turning the setting off stops it at once. The entry itself is in English; the rest of the mail follows your language setting.
• RSS: add https://docs.frem.sh/reference/changelog/index.xml to your feed reader. Each entry on this page is one item: a month entry, or a version entry. A month entry is updated in place as changes go live during that month, so its item can change after you first see it.
• Security mailing list: the security mailing list covers sub-processor changes (per DPA §10.2), security advisories, and upcoming breaking changes.

Runner image manifests

Each weekly hosted-runner image rebuild publishes its manifest under /changelog/runner-images/, that sub-section is auto-generated by the rebuild pipeline rather than hand-written, so the manifest never goes stale relative to the container image digest. The manifest includes:

• The hosted runner image digest + base image (Debian major.minor)
• Pre-installed tool versions (node, npm, jq, yq, git, gitleaks, trivy, kaniko, shellcheck, shfmt)
• CVE scan summary (HIGH/CRITICAL fail with --ignore-unfixed; MEDIUM disclosed)
• CycloneDX SBOM (linked from each manifest entry)
• Diff vs previous week’s manifest

The pipeline shipped 2026-05-08; the bootstrap image (20260508-142738-bootstrap) was the first push, its manifest entry will be backfilled before the first weekly auto-rebuild lands. Subsequent rebuilds (Mon 06:00 UTC) auto-publish.

Why docs.frem.sh/changelog and not www.frem.sh/changelog

The audience for release notes is operators and developers using fremforge, the same audience already reading docs.frem.sh. Marketing copy lives at www.frem.sh. Keeping the changelog colocated with the docs site means: (1) one Hugo build, one navigation surface; (2) the runner-image manifest sub-page can be auto-generated by the rebuild pipeline writing to the same content tree; (3) deep-links from runbooks and docs pages stay same-origin.

Related

• Trust page, sub-processors, audit posture, EU-only data residency
• Sub-processor list, every entity with potential access to Customer Personal Data, with notification policy
• Transparency report, annual government-access aggregate report
• Status page, current uptime + planned maintenance

Last updated: 2026-10-07.