{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/gitlab-job-token-allowlist-user-permission-gates/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates/",
        "slug": "gitlab-job-token-allowlist-user-permission-gates",
        "url": "https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/gitlab-job-token-allowlist-user-permission-gates/"
        },
        "title": "Treat a GitLab job-token allowlist as a second gate, not a permission grant",
        "summary": "Cross-project job access requires an allowed source and an already-authorized triggering user.",
        "format": {
            "slug": "guide",
            "name": "Guide"
        },
        "priority": {
            "slug": "info",
            "name": "Information"
        },
        "featured": false,
        "image": {
            "theme": "cyber-defense",
            "label": "Cyber defense",
            "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "cybersecurity",
                "name": "Cybersecurity",
                "url": "https://update.dsesecurity.com/topic/cybersecurity/"
            },
            {
                "slug": "it",
                "name": "IT",
                "url": "https://update.dsesecurity.com/topic/it/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-10-15T13:33:39+00:00",
        "modified_at": "2026-10-15T13:36:17+00:00",
        "reviewed_on": "2026-10-15",
        "reading_minutes": 2,
        "word_count": 264,
        "potentially_affected": "This applies to GitLab CI/CD job-token access. Public or internal project features can have additional visibility behavior, and self-managed administrators can enforce stricter allowlist requirements.",
        "dse_recommendation": "DSE recommends reviewing the source project and triggering identity together when approving a cross-project pipeline.",
        "primary_source": {
            "name": "GitLab — CI/CD job token",
            "url": "https://docs.gitlab.com/ci/jobs/ci_job_token/",
            "published_on": null,
            "authority": "docs.gitlab.com"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<p>Cross-project job access requires an allowed source and an already-authorized triggering user.</p>\n<h2>Source facts</h2>\n<p>GitLab creates a CI_JOB_TOKEN for a running job and revokes its access when the job finishes. The token has access to fewer resources than a personal access token and is constrained by the triggering user’s permissions. For cross-project access, the target project’s allowlist normally must include the source project or group. Adding that source does not grant its users additional project privileges. A group entry includes projects in its subgroups and can also cover projects added to that group later.</p>\n<p>Source: <a href=\"https://docs.gitlab.com/ci/jobs/ci_job_token/\">GitLab — CI/CD job token</a>.</p>\n<h2>Applicability</h2>\n<p>This applies to GitLab CI/CD job-token access. Public or internal project features can have additional visibility behavior, and self-managed administrators can enforce stricter allowlist requirements.</p>\n<h2>DSE recommendation</h2>\n<p>DSE recommends reviewing the source project and triggering identity together when approving a cross-project pipeline. Prefer the narrowest practical source entry, especially where a group contains unrelated projects or can gain new descendants. Record which target resources the integration needs and why its users have permission. Keep a minimal test job for access verification, and review group membership changes as part of the trust relationship. Avoid disabling the allowlist to solve a missing user privilege or an incorrectly scoped integration.</p>\n<h2>Verification</h2>\n<p>Test the approved source with an authorized user, then compare an unlisted source and a triggering identity without the target privilege. Confirm the expected denials. Review the authentication log and ensure the token cannot be reused after the test job completes.</p>\n<h2>Official reference</h2>\n<p><a href=\"https://docs.gitlab.com/ci/jobs/ci_job_token/\">GitLab — CI/CD job token</a>. Reviewed October 15, 2026.</p>",
        "content_text": "Cross-project job access requires an allowed source and an already-authorized triggering user.\nSource facts\nGitLab creates a CI_JOB_TOKEN for a running job and revokes its access when the job finishes. The token has access to fewer resources than a personal access token and is constrained by the triggering user’s permissions. For cross-project access, the target project’s allowlist normally must include the source project or group. Adding that source does not grant its users additional project privileges. A group entry includes projects in its subgroups and can also cover projects added to that group later.\nSource: GitLab — CI/CD job token.\nApplicability\nThis applies to GitLab CI/CD job-token access. Public or internal project features can have additional visibility behavior, and self-managed administrators can enforce stricter allowlist requirements.\nDSE recommendation\nDSE recommends reviewing the source project and triggering identity together when approving a cross-project pipeline. Prefer the narrowest practical source entry, especially where a group contains unrelated projects or can gain new descendants. Record which target resources the integration needs and why its users have permission. Keep a minimal test job for access verification, and review group membership changes as part of the trust relationship. Avoid disabling the allowlist to solve a missing user privilege or an incorrectly scoped integration.\nVerification\nTest the approved source with an authorized user, then compare an unlisted source and a triggering identity without the target privilege. Confirm the expected denials. Review the authentication log and ensure the token cannot be reused after the test job completes.\nOfficial reference\nGitLab — CI/CD job token. Reviewed October 15, 2026.",
        "content_markdown": "Cross-project job access requires an allowed source and an already-authorized triggering user.\n\n## Source facts\n\nGitLab creates a CI_JOB_TOKEN for a running job and revokes its access when the job finishes. The token has access to fewer resources than a personal access token and is constrained by the triggering user’s permissions. For cross-project access, the target project’s allowlist normally must include the source project or group. Adding that source does not grant its users additional project privileges. A group entry includes projects in its subgroups and can also cover projects added to that group later.\n\nSource: [GitLab — CI/CD job token](https://docs.gitlab.com/ci/jobs/ci_job_token/).\n\n## Applicability\n\nThis applies to GitLab CI/CD job-token access. Public or internal project features can have additional visibility behavior, and self-managed administrators can enforce stricter allowlist requirements.\n\n## DSE recommendation\n\nDSE recommends reviewing the source project and triggering identity together when approving a cross-project pipeline. Prefer the narrowest practical source entry, especially where a group contains unrelated projects or can gain new descendants. Record which target resources the integration needs and why its users have permission. Keep a minimal test job for access verification, and review group membership changes as part of the trust relationship. Avoid disabling the allowlist to solve a missing user privilege or an incorrectly scoped integration.\n\n## Verification\n\nTest the approved source with an authorized user, then compare an unlisted source and a triggering identity without the target privilege. Confirm the expected denials. Review the authentication log and ensure the token cannot be reused after the test job completes.\n\n## Official reference\n\n[GitLab — CI/CD job token](https://docs.gitlab.com/ci/jobs/ci_job_token/). Reviewed October 15, 2026."
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates/",
                "url": "https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-10-15"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Treat a GitLab job-token allowlist as a second gate, not a permission grant",
                        "item": "https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates/#article",
                "identifier": "https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates/",
                "url": "https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates/",
                "headline": "Treat a GitLab job-token allowlist as a second gate, not a permission grant",
                "description": "Cross-project job access requires an allowed source and an already-authorized triggering user.",
                "abstract": "Cross-project job access requires an allowed source and an already-authorized triggering user.",
                "articleBody": "Cross-project job access requires an allowed source and an already-authorized triggering user.\nSource facts\nGitLab creates a CI_JOB_TOKEN for a running job and revokes its access when the job finishes. The token has access to fewer resources than a personal access token and is constrained by the triggering user’s permissions. For cross-project access, the target project’s allowlist normally must include the source project or group. Adding that source does not grant its users additional project privileges. A group entry includes projects in its subgroups and can also cover projects added to that group later.\nSource: GitLab — CI/CD job token.\nApplicability\nThis applies to GitLab CI/CD job-token access. Public or internal project features can have additional visibility behavior, and self-managed administrators can enforce stricter allowlist requirements.\nDSE recommendation\nDSE recommends reviewing the source project and triggering identity together when approving a cross-project pipeline. Prefer the narrowest practical source entry, especially where a group contains unrelated projects or can gain new descendants. Record which target resources the integration needs and why its users have permission. Keep a minimal test job for access verification, and review group membership changes as part of the trust relationship. Avoid disabling the allowlist to solve a missing user privilege or an incorrectly scoped integration.\nVerification\nTest the approved source with an authorized user, then compare an unlisted source and a triggering identity without the target privilege. Confirm the expected denials. Review the authentication log and ensure the token cannot be reused after the test job completes.\nOfficial reference\nGitLab — CI/CD job token. Reviewed October 15, 2026.",
                "datePublished": "2026-10-15T13:33:39+00:00",
                "dateModified": "2026-10-15T13:36:17+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Treat a GitLab job-token allowlist as a second gate, not a permission grant"
                },
                "articleSection": [
                    "Cybersecurity",
                    "IT"
                ],
                "keywords": [
                    "Cybersecurity",
                    "IT",
                    "Guide",
                    "Information priority"
                ],
                "genre": "Guide",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "Cybersecurity",
                        "url": "https://update.dsesecurity.com/topic/cybersecurity/"
                    },
                    {
                        "@type": "Thing",
                        "name": "IT",
                        "url": "https://update.dsesecurity.com/topic/it/"
                    }
                ],
                "wordCount": 264,
                "timeRequired": "PT2M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "GitLab — CI/CD job token",
                    "url": "https://docs.gitlab.com/ci/jobs/ci_job_token/"
                }
            }
        ]
    }
}