From afc053424be6c7418c6a65200a75e7929839b5cb Mon Sep 17 00:00:00 2001 From: Brian DeHamer Date: Wed, 18 Mar 2026 09:16:37 -0700 Subject: [PATCH 1/2] Consolidate attestation action references to actions/attest (#60214) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .../kubernetes-admissions-controller.md | 2 +- .../enforce-artifact-attestations.md | 2 +- .../increase-security-rating.md | 2 +- .../manage-attestations.md | 4 ++-- .../use-artifact-attestations.md | 18 +++++++++--------- .../publish-packages/publish-docker-images.md | 2 +- .../upload-linked-artifacts.md | 4 ++-- .../actions/attestation-virtual-registry.md | 2 +- .../package_registry/publish-docker-image.md | 2 +- 9 files changed, 19 insertions(+), 19 deletions(-) diff --git a/content/actions/concepts/security/kubernetes-admissions-controller.md b/content/actions/concepts/security/kubernetes-admissions-controller.md index 470408ecc68b..36ce5a2645be 100644 --- a/content/actions/concepts/security/kubernetes-admissions-controller.md +++ b/content/actions/concepts/security/kubernetes-admissions-controller.md @@ -23,7 +23,7 @@ To [install the controller](/actions/how-tos/security-for-github-actions/using-a When the Policy Controller is installed, it will intercept all image pull requests and verify the attestation for the image. The attestation must be stored in the image registry as an [OCI attached artifact](https://oras.land/docs/concepts/reftypes/) containing a [Sigstore Bundle](https://docs.sigstore.dev/about/bundle/) which contains the attestation and cryptographic material (e.g. certificates and signatures) used to verify the attestation. A verification process is then performed that ensures the image was built with the specified build provenance and matches any policies enabled by the cluster administrator. -In order for an image to be verifiable, it must have a valid provenance attestation in the registry, which can be done by enabling the `push-to-registry: true` attribute in the `actions/attest-build-provenance` action. See [Generating build provenance for container images](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds#generating-build-provenance-for-container-images) for more details on how to generate attestations for container images. +In order for an image to be verifiable, it must have a valid provenance attestation in the registry, which can be done by enabling the `push-to-registry: true` attribute in the `actions/attest` action. See [Generating build provenance for container images](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds#generating-build-provenance-for-container-images) for more details on how to generate attestations for container images. ### About trust roots and policies diff --git a/content/actions/how-tos/secure-your-work/use-artifact-attestations/enforce-artifact-attestations.md b/content/actions/how-tos/secure-your-work/use-artifact-attestations/enforce-artifact-attestations.md index af91d218d35a..240583baf521 100644 --- a/content/actions/how-tos/secure-your-work/use-artifact-attestations/enforce-artifact-attestations.md +++ b/content/actions/how-tos/secure-your-work/use-artifact-attestations/enforce-artifact-attestations.md @@ -14,7 +14,7 @@ category: contentType: how-tos --- ->[!NOTE] Before proceeding, ensure you have enabled build provenance for container images, including setting the `push-to-registry` attribute in the [`attest-build-provenance` action](https://github.com/actions/attest-build-provenance) as documented in [Generating build provenance for container images](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds#generating-build-provenance-for-container-images). This is required for the Policy Controller to verify the attestation. +> [!NOTE] Before proceeding, ensure you have enabled build provenance for container images, including setting the `push-to-registry` attribute in the [`attest` action](https://github.com/actions/attest) as documented in [Generating build provenance for container images](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds#generating-build-provenance-for-container-images). This is required for the Policy Controller to verify the attestation. ## Getting started with Kubernetes admission controller diff --git a/content/actions/how-tos/secure-your-work/use-artifact-attestations/increase-security-rating.md b/content/actions/how-tos/secure-your-work/use-artifact-attestations/increase-security-rating.md index c3a98fefa7e4..4252a00c6f4e 100644 --- a/content/actions/how-tos/secure-your-work/use-artifact-attestations/increase-security-rating.md +++ b/content/actions/how-tos/secure-your-work/use-artifact-attestations/increase-security-rating.md @@ -51,7 +51,7 @@ To verify the artifact attestations generated with your builds, you can use [`gh The `gh attestation verify` command requires either `--owner` or `--repo` flags to be used with it. These flags do two things. * They tell `gh attestation verify` where to fetch the attestation from. This will always be your caller workflow. -* They tell `gh attestation verify` where the workflow that did the signing came from. This will always be the workflow that uses [`attest-build-provenance` action](https://github.com/actions/attest-build-provenance), which may be a reusable workflow. +* They tell `gh attestation verify` where the workflow that did the signing came from. This will always be the workflow that uses the [`attest` action](https://github.com/actions/attest), which may be a reusable workflow. You can use optional flags with the `gh attestation verify` command. diff --git a/content/actions/how-tos/secure-your-work/use-artifact-attestations/manage-attestations.md b/content/actions/how-tos/secure-your-work/use-artifact-attestations/manage-attestations.md index d3fea66ad99d..d6a7dc7c99f0 100644 --- a/content/actions/how-tos/secure-your-work/use-artifact-attestations/manage-attestations.md +++ b/content/actions/how-tos/secure-your-work/use-artifact-attestations/manage-attestations.md @@ -32,8 +32,8 @@ Use the `created` filter to filter by creation date. To enter a custom date rang Use the `predicate` filter to filter by the kind of attestation. A predicate is the type of claim that an attestation makes about an artifact, such as "this artifact was built during a particular workflow run and originates from this repository." -* Provenance attestations were created with the `attest-build-provenance` action. -* SBOM attestations were created with the `attest-sbom` action. +* Provenance attestations were created with the `attest` action. +* SBOM attestations were created with the `attest` action using the `sbom-path` input. * Custom predicate type patterns are **not** supported in the search field, but are supported by the API. ## Deleting attestations diff --git a/content/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations.md b/content/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations.md index 7f964eda7673..f385f9ab3643 100644 --- a/content/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations.md +++ b/content/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations.md @@ -26,9 +26,9 @@ You can use {% data variables.product.prodname_actions %} to generate artifact a To generate an artifact attestation, you must: * Ensure you have the appropriate permissions configured in your workflow. -* Include a step in your workflow that uses the [`attest-build-provenance` action](https://github.com/actions/attest-build-provenance). +* Include a step in your workflow that uses the [`attest` action](https://github.com/actions/attest). -When you run your updated workflows, they will build your artifacts and generate an artifact attestation that establishes build provenance. You can view attestations in your repository's **Actions** tab. For more information, see the [`attest-build-provenance`](https://github.com/actions/attest-build-provenance) repository. +When you run your updated workflows, they will build your artifacts and generate an artifact attestation that establishes build provenance. You can view attestations in your repository's **Actions** tab. For more information, see the [`attest`](https://github.com/actions/attest) repository. ### Generating build provenance for binaries @@ -45,7 +45,7 @@ When you run your updated workflows, they will build your artifacts and generate ```yaml - name: Generate artifact attestation - uses: actions/attest-build-provenance@v3 + uses: actions/attest@v4 with: subject-path: 'PATH/TO/ARTIFACT' ``` @@ -68,7 +68,7 @@ When you run your updated workflows, they will build your artifacts and generate ```yaml - name: Generate artifact attestation - uses: actions/attest-build-provenance@v3 + uses: actions/attest@v4 with: subject-name: {% raw %}${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}{% endraw %} subject-digest: 'sha256:fedcba0...' @@ -87,9 +87,9 @@ To generate an attestation for an SBOM, you must: * Ensure you have the appropriate permissions configured in your workflow. * Create an SBOM for your artifact. For more information, see [`anchore-sbom-action`](https://github.com/marketplace/actions/anchore-sbom-action) in the {% data variables.product.prodname_marketplace %}. -* Include a step in your workflow that uses the [`attest-sbom` action](https://github.com/actions/attest-sbom). +* Include a step in your workflow that uses the [`attest` action](https://github.com/actions/attest) with the `sbom-path` input. -When you run your updated workflows, they will build your artifacts and generate an SBOM attestation. You can view attestations in your repository's **Actions** tab. For more information, see the [`attest-sbom` action](https://github.com/actions/attest-sbom) repository. +When you run your updated workflows, they will build your artifacts and generate an SBOM attestation. You can view attestations in your repository's **Actions** tab. For more information, see the [`attest`](https://github.com/actions/attest) repository. ### Generating an SBOM attestation for binaries @@ -106,7 +106,7 @@ When you run your updated workflows, they will build your artifacts and generate ```yaml - name: Generate SBOM attestation - uses: actions/attest-sbom@v2 + uses: actions/attest@v4 with: subject-path: 'PATH/TO/ARTIFACT' sbom-path: 'PATH/TO/SBOM' @@ -130,7 +130,7 @@ When you run your updated workflows, they will build your artifacts and generate ```yaml - name: Generate SBOM attestation - uses: actions/attest-sbom@v2 + uses: actions/attest@v4 with: subject-name: {% raw %}${{ env.REGISTRY }}/PATH/TO/IMAGE{% endraw %} subject-digest: 'sha256:fedcba0...' @@ -180,7 +180,7 @@ gh attestation verify oci://ghcr.io/ORGANIZATION_NAME/IMAGE_NAME:test -R ORGANIZ To verify SBOM attestations, you have to provide the `--predicate-type` flag to reference a non-default predicate. For more information, see [Vetted predicates](https://github.com/in-toto/attestation/tree/main/spec/predicates#vetted-predicates) in the `in-toto/attestation` repository. -For example, the [`attest-sbom` action](https://github.com/actions/attest-sbom) currently supports either SPDX or CycloneDX SBOM predicates. To verify an SBOM attestation in the SPDX format, you can use the following {% data variables.product.prodname_cli %} command. +For example, the [`attest` action](https://github.com/actions/attest) currently supports either SPDX or CycloneDX SBOM predicates. To verify an SBOM attestation in the SPDX format, you can use the following {% data variables.product.prodname_cli %} command. ```bash copy gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY \ diff --git a/content/actions/tutorials/publish-packages/publish-docker-images.md b/content/actions/tutorials/publish-packages/publish-docker-images.md index ff02b5d14986..a883b44129b9 100644 --- a/content/actions/tutorials/publish-packages/publish-docker-images.md +++ b/content/actions/tutorials/publish-packages/publish-docker-images.md @@ -115,7 +115,7 @@ jobs: {% ifversion artifact-attestations %} - name: Generate artifact attestation - uses: actions/attest-build-provenance@v3 + uses: actions/attest@v4 with: subject-name: index.docker.io/my-docker-hub-namespace/my-docker-hub-repository subject-digest: {% raw %}${{ steps.push.outputs.digest }}{% endraw %} diff --git a/content/code-security/how-tos/secure-your-supply-chain/establish-provenance-and-integrity/upload-linked-artifacts.md b/content/code-security/how-tos/secure-your-supply-chain/establish-provenance-and-integrity/upload-linked-artifacts.md index ab12cff6c615..8741c985d928 100644 --- a/content/code-security/how-tos/secure-your-supply-chain/establish-provenance-and-integrity/upload-linked-artifacts.md +++ b/content/code-security/how-tos/secure-your-supply-chain/establish-provenance-and-integrity/upload-linked-artifacts.md @@ -77,7 +77,7 @@ You can upload data to the {% data variables.product.virtual_registry %} in the In the following example, we build and publish a Docker image, then use the `{% raw %}${{ steps.push.outputs.digest }}{% endraw %}` output in the next step to generate a provenance attestation. -The `attest-build-provenance` action automatically uploads a storage record to the {% data variables.product.virtual_registry %} when `push-to-registry: true` is set and the workflow includes the `artifact-metadata: write` permission. +The `attest` action automatically uploads a storage record to the {% data variables.product.virtual_registry %} when `push-to-registry: true` is set and the workflow includes the `artifact-metadata: write` permission. ``` yaml {% raw %} @@ -108,7 +108,7 @@ jobs: ${{ env.ACR_ENDPOINT }}/${{ env.IMAGE_NAME }}:${{ github.sha }} - name: Generate artifact attestation - uses: actions/attest-build-provenance@v3 + uses: actions/attest@v4 with: subject-name: ${{ env.ACR_ENDPOINT }}/${{ env.IMAGE_NAME }} subject-digest: ${{ steps.push.outputs.digest }} diff --git a/data/reusables/actions/attestation-virtual-registry.md b/data/reusables/actions/attestation-virtual-registry.md index 3f11358cec43..d91b8af66e9e 100644 --- a/data/reusables/actions/attestation-virtual-registry.md +++ b/data/reusables/actions/attestation-virtual-registry.md @@ -1,4 +1,4 @@ -The [attest](https://github.com/actions/attest) and [attest-build-provenance](https://github.com/actions/attest-build-provenance) actions automatically create storage records on the {% data variables.product.virtual_registry %} if both: +The [attest](https://github.com/actions/attest) action automatically creates storage records on the {% data variables.product.virtual_registry %} if both: * The `push-to-registry` option is set to `true` * The workflow that includes the action has the `artifact-metadata: write` permission diff --git a/data/reusables/package_registry/publish-docker-image.md b/data/reusables/package_registry/publish-docker-image.md index ae547a3a517a..4a969e573717 100644 --- a/data/reusables/package_registry/publish-docker-image.md +++ b/data/reusables/package_registry/publish-docker-image.md @@ -57,7 +57,7 @@ jobs: {% ifversion artifact-attestations %} # This step generates an artifact attestation for the image, which is an unforgeable statement about where and how it was built. It increases supply chain security for people who consume the image. For more information, see [Using artifact attestations to establish provenance for builds](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds). - name: Generate artifact attestation - uses: actions/attest-build-provenance@v3 + uses: actions/attest@v4 with: subject-name: {% raw %}${{ env.REGISTRY }}/${{ env.IMAGE_NAME}}{% endraw %} subject-digest: {% raw %}${{ steps.push.outputs.digest }}{% endraw %} From 33235b79208aeeca75c1ee178a306fa22b465b09 Mon Sep 17 00:00:00 2001 From: Sunbrye Ly <56200261+sunbrye@users.noreply.github.com> Date: Wed, 18 Mar 2026 10:22:39 -0700 Subject: [PATCH 2/2] Base and LTS models (#60013) --- .../concepts/fallback-and-lts-models.md | 49 +++++++++++++++++++ content/copilot/concepts/index.md | 1 + .../reference/ai-models/supported-models.md | 4 ++ 3 files changed, 54 insertions(+) create mode 100644 content/copilot/concepts/fallback-and-lts-models.md diff --git a/content/copilot/concepts/fallback-and-lts-models.md b/content/copilot/concepts/fallback-and-lts-models.md new file mode 100644 index 000000000000..2fe6cc2c96e4 --- /dev/null +++ b/content/copilot/concepts/fallback-and-lts-models.md @@ -0,0 +1,49 @@ +--- +title: Base and long-term support (LTS) models +shortTitle: Base and LTS models +intro: 'Learn about base models, long-term support (LTS) models, and how they affect model availability for enterprises using {% data variables.product.prodname_copilot %}.' +versions: + feature: copilot +allowTitleToDifferFromFilename: true +contentType: concepts +category: + - Manage Copilot for a team +--- + +## About base models + +> [!IMPORTANT] +> * On March 18, 2026, {% data variables.product.github %} designated {% data variables.copilot.copilot_gpt_53_codex %} as the base model. +> * Base models apply only to {% data variables.copilot.copilot_business_short %} and {% data variables.copilot.copilot_enterprise_short %}. + + A base model is the default AI model that {% data variables.product.prodname_copilot %} uses when no other models are enabled. The base model is automatically enabled for all {% data variables.copilot.copilot_business_short %} or {% data variables.copilot.copilot_enterprise_short %} accounts within 60 days after the model is designated as a base model. + +When a new model is designated a base model, the following timeline applies: + +| Phase | Timeline | What happens | +|--------------------|-------------------------------|----------------------------------------------------------------------------------------------------| +| Announcement | Day 0 | {% data variables.product.github %} announces the new base model. | +| Upgrade window | Day 0 to Day 60 | Customers have 60 days to upgrade their IDE extensions to versions that support the new model. | +| Enablement | Day 60 | The new model is automatically enabled on all organizations and enterprises as the base model. | + +> [!NOTE] +> The base model has a **1x premium request multiplier** on paid plans. For more information about multipliers, see [AUTOTITLE](/copilot/concepts/billing/copilot-requests#model-multipliers). + +## About long-term support (LTS) models + +> [!IMPORTANT] +> * On March 18, 2026, {% data variables.product.github %} designated {% data variables.copilot.copilot_gpt_53_codex %} as the LTS model. +> * LTS models apply only to {% data variables.copilot.copilot_business_short %} and {% data variables.copilot.copilot_enterprise_short %}. + +An LTS model is an AI model that {% data variables.product.github %} commits to supporting for an extended period of one year from its designation date. During that period, the model remains available, which allows users to build around the model without concern that it will be {% data variables.release-phases.closing_down %} unexpectedly. + +## Continuous access when premium requests are unavailable + +{% data variables.copilot.copilot_gpt_53_codex %} is available on paid plans with a 0x premium request multiplier, which means it does not consume premium requests. This ensures continuous access to {% data variables.product.prodname_copilot_short %} in situations such as: +* Premium request quota exhausted: If a user has used their monthly premium request allowance, they can continue working with {% data variables.copilot.copilot_gpt_53_codex %} at no additional cost. +* Overage controls disabled: If an organization or enterprise has disabled premium request overages and a user reaches their limit, {% data variables.copilot.copilot_gpt_53_codex %} remains available. + +## Further reading + +* [AUTOTITLE](/copilot/reference/ai-models/supported-models) +* [AUTOTITLE](/copilot/concepts/billing/copilot-requests) diff --git a/content/copilot/concepts/index.md b/content/copilot/concepts/index.md index 98e14679928a..91c51607850e 100644 --- a/content/copilot/concepts/index.md +++ b/content/copilot/concepts/index.md @@ -20,5 +20,6 @@ children: - /policies - /mcp-management - /network-settings + - /fallback-and-lts-models contentType: concepts --- diff --git a/content/copilot/reference/ai-models/supported-models.md b/content/copilot/reference/ai-models/supported-models.md index 44027b4c2ab6..beca331a0b98 100644 --- a/content/copilot/reference/ai-models/supported-models.md +++ b/content/copilot/reference/ai-models/supported-models.md @@ -102,6 +102,10 @@ For more information about premium requests, see [AUTOTITLE](/copilot/managing-c {% data reusables.copilot.model-multipliers %} +## Fallback and long-term support (LTS) models + +For more information about fallback and LTS models, see [AUTOTITLE](/copilot/concepts/fallback-and-lts-models). + ## Next steps * For task-based guidance on selecting a model, see [AUTOTITLE](/copilot/reference/ai-models/model-comparison).