<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=606528) </details> <!--IssueSummary end--> # Release notes Increase the default `ci_max_artifact_size_cyclonedx` limit from 1 MiB to 5 MiB for Self-Managed and GitLab Dedicated instances, to reduce 413 errors when uploading CycloneDX SBOM artifacts. # Problem to solve The current default limit for CycloneDX artifacts, `ci_max_artifact_size_cyclonedx`, is 1 MiB in the database for self-managed and Dedicated instances. (see https://gitlab.com/gitlab-org/gitlab/-/raw/v19.2.0-ee/db/structure.sql?ref_type=tags) The low default limit causes Dependency Scanning using CycloneDX SBOM artifact uploads to fail with `413 Request Entity Too Large` for non-trivial projects. This has led to several Support tickets, and presents a particularly bad pain point for Dedicated customers. Specific pain points: - **Multiple customers have hit the CycloneDX-specific 1 MiB limit despite high general artifact and NGINX limits**, resulting in `413 Request Entity Too Large` errors when uploading `cyclonedx` artifacts in Dependency Scanning jobs. Several customers have opened Support tickets due to this low limit. See for example Zendesk tickets [#503235](https://gitlab.zendesk.com/agent/tickets/503235), [#564285](https://gitlab.zendesk.com/agent/tickets/564285), [#584573](https://gitlab.zendesk.com/agent/tickets/584573), [#646621](https://gitlab.zendesk.com/agent/tickets/646621), and [#730444](https://gitlab.zendesk.com/agent/tickets/730444). - **The limit is enforced for SBOM artifact uploads, and there is no path to change the setting on Dedicated.** The `cyclonedx` job artifact upload process uses `ci_max_artifact_size_cyclonedx`. On GitLab Dedicated, the only known way to change the setting is [via the Rails console](https://docs.gitlab.com/administration/cicd/limits/#maximum-file-size-per-type-of-artifact:~:text=For%20example%2C%20to%20set%20the%20ci_max_artifact_size_junit%20limit%20to%2010%20MB%20on%20GitLab%20Self%2DManaged%2C%20run%20the%20following%20in%20the%20GitLab%20Rails%20console%3A) (not a supported configuration surface for Dedicated), so affected tenants are blocked. A higher default setting would be helpful for Dedicated customers. - **GitLab.com already runs with this limit raised to 5 MiB**, via infrastructure changes that increased `ci_max_artifact_size_cyclonedx` from 1 MiB to 5 MiB for all plans after a Scalability review concluded the risk was minimal; see for example [gitlab-com/gl-infra/production#17908](https://gitlab.com/gitlab-com/gl-infra/production/-/work_items/17908) and Scalability issue [gitlab-com/gl-infra/scalability#3413](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/3413). We should assess for any potential downstream impacts of raising the default value and document those trade-offs, but the current 1 MiB default is probably too restrictive given real-world SBOM sizes and customer feedback we've. # Proposal - Confirm there are no major concerns with raising the limit to 5 MiB in terms of: - Memory and CPU usage when parsing and storing CycloneDX reports. - Storage growth and retention characteristics for CycloneDX artifacts. - SBOM Scan API latency and rate limits when processing larger SBOMs. - If investigation doesn't reveal any substantial risks/downsides, increase the product-wide default limit for `ci_max_artifact_size_cyclonedx` from 1 MB to 5 MB, so new and existing instances that rely on default limits inherit the higher threshold. - Concretely, update the default value used when seeding or migrating `Plan.default.actual_limits.ci_max_artifact_size_cyclonedx`, and ensure any plan-specific overrides are either maintained at or raised to at least 5 MiB where appropriate. - Align and clarify documentation: - Once the underlying default is changed, update both CI/CD limits and instance limits docs so they consistently state that the default `ci_max_artifact_size_cyclonedx` is 5 MiB, and clearly explain how this interacts with: - The project-level “Maximum artifacts size” setting. - SBOM Scan API limits for Dependency Scanning using SBOM. # Intended users - Application security engineers and developers using **Dependency Scanning using SBOM** with CycloneDX artifacts, especially on large monorepos or multi-module builds. - Instance administrators on **GitLab Self-Managed** and **GitLab Dedicated** responsible for configuring CI/CD limits and ensuring security scans run reliably. # Does this feature require an audit event? No. This proposal adjusts a global artifact size limit used by CI/CD and the SBOM Scan API, but does not introduce new user-visible actions or security-sensitive operations that must be individually audited beyond existing admin-configuration and CI/CD activity logs. Examples: -->