Developer tools
6 checks across GitHub, GitLab, Bitbucket, and Jira, verifying branch protection and account-level authentication and access-control settings.
github-branch-protection-enabled
Checks that a specific branch of a GitHub repository has branch protection enabled. Calls GET https://api.github.com/repos/{owner}/{repo}/branches/{branch}/protection, authenticated with a bearer token.
- owner, repo, branch
- the repository and branch to check. The target is
{owner}/{repo}@{branch}. - token
- a GitHub token with permission to read branch protection.
The full raw API response is always kept alongside a compact summary of each sub-setting, so no detail is lost for an auditor who wants the exact payload. A 401 or 403 response is reported as needs-review, never fail.
github-org-2fa-enforced
Checks whether a GitHub organization requires two-factor authentication for every member, billing manager, and outside collaborator. Calls GET https://api.github.com/orgs/{org} and reads two_factor_requirement_enabled.
- org
- the organization login, also used as the target.
- token
- an organization-owner GitHub token, required to read this field.
GitHub returns null for this field when it cannot determine the setting, distinct from false, which means the requirement is genuinely off. Both a null value and a 401 or 403 response are reported as needs-review, never fail.
gitlab-branch-protection-enabled
Checks that a specific branch of a GitLab project has a protected-branch rule enabled. Calls GET {baseUrl}/api/v4/projects/{projectPath}/protected_branches/{branch}, authenticated with a bearer token.
- projectPath, branch
- a numeric project ID or a URL-encoded namespace and project path, and the branch to check. The target is
{projectPath}@{branch}. - token
- a GitLab token with permission to read the project.
Only gitlab.com is used by default. A self-managed GitLab instance is supported by passing a different base URL. A 404 response specifically means no protected-branch rule exists for that branch, which GitLab also returns for a project or branch that does not exist at all, so the raw status and body are kept in evidence. A 401 or 403 response is reported as needs-review, never fail.
gitlab-instance-2fa-enforced
Checks whether a GitLab instance requires two-factor authentication for all users. Calls GET {baseUrl}/api/v4/application/settings and reads require_two_factor_authentication.
- token
- an administrator-level GitLab personal access token. A project- or group-scoped token cannot read this setting.
- baseUrl (optional)
- defaults to gitlab.com, and is also the target. This is an instance-wide setting with no per-project scope.
A 401 or 403 response is reported as needs-review, never fail.
bitbucket-branch-restrictions-enabled
Checks that a specific branch of a Bitbucket repository has at least one branch-restriction rule, push, merge checks, or required reviewers, configured. Calls the Bitbucket API v2 branch-restrictions endpoint, authenticated with a bearer token.
- workspace, repoSlug, branch
- the repository and branch to check. The target is
{workspace}/{repoSlug}@{branch}. - token
- a Bitbucket API token used as a bearer token.
A restriction matches the branch on an exact name or a full wildcard. Glob patterns such as release/* are not matched, so a glob-only setup reports as unprotected rather than guessed at. A 401 or 403 response is reported as needs-review, never fail.
jira-ip-allowlist-enforced
Checks whether an enabled IP-allowlist policy exists for an Atlassian organization. Calls GET https://api.atlassian.com/admin/v1/orgs/{orgId}/policies, paginated through an opaque cursor, authenticated with a bearer Organization API key.
- orgId
- the Atlassian organization identifier, also used as the target. This is an organization-wide setting covering every Atlassian product under it, including Jira and Confluence.
- apiKey
- an Organization API key generated at admin.atlassian.com, distinct from a normal Jira Cloud API token.
A policy counts when its type is ip-allowlist and its status is enabled. The Atlassian Organization Admin API has no endpoint exposing 2FA enforcement, so this check verifies IP allowlisting instead, a real, checkable access-control posture setting. A 401 or 403 response is reported as needs-review, never fail.