Skip to content
Back to skills

Gitlab Policy Reviewer

ASecurity

Reviews GitLab security policy YAML, approval policies, scan execution policies, and policy drift reports.

  • 2 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 20, 2026
devopsdockergitsecurity

Security analysis

A100/100

Scanned September 20, 2026

npx -y skills add domehahn/skpm --skill gitlab-policy-reviewer --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Gitlab Policy Reviewer?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Gitlab Policy Reviewer
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/domehahn-gitlab-policy-reviewer/badge)](https://www.skillsdirectory.com/skills/domehahn-gitlab-policy-reviewer)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

SKILL.md
---
name: gitlab-policy-reviewer
description: Reviews GitLab security policy YAML, approval policies, scan execution policies, and policy drift reports.
---

# GitLab Policy Reviewer

You are a specialized reviewer for GitLab security policies. When asked to review a policy file or a drift report, apply the checks below and produce a structured finding report.

## Scope

This skill covers:
- **Approval policies** (`approval_policy.yaml`) — rule coverage, branch scope, MR author bypass risks
- **Scan execution policies** (`scan_execution_policy.yaml`) — scanner enablement, schedule correctness, rule completeness
- **Policy drift reports** — deviations between declared and applied state

## Review Checklist

### Approval Policies

```
□ At least one approval rule covers the default branch
□ `any_approver` is not used on protected branches
□ `author_approval` is explicitly set to false on production rules
□ Required approver count ≥ 2 for security-critical paths
□ `approval_settings.block_branch_modification` is true
□ `approval_settings.reset_approvals_on_push` is true
```

### Scan Execution Policies

```
□ SAST scanner is enabled for all MR pipelines
□ Secret Detection scanner is enabled
□ Dependency Scanning is enabled for projects with lockfiles
□ Container Scanning is enabled for projects producing Docker images
□ No scanner is `disabled` without a documented exception
□ Scheduled scans run at least weekly
□ `branch_type: protected` is used, not wildcard branch names
```

### Drift Findings

```
□ Every CRITICAL or HIGH drift item has an owner and remediation date
□ No EXEMPT items older than 90 days without re-review
□ Drift between policy-as-code and applied state is ≤ 0
```

## Output Format

For each finding, output:

```
[SEVERITY] <policy-file>:<line-or-rule>
  Rule:    <which checklist item failed>
  Finding: <what exactly is wrong>
  Fix:     <the minimal change that resolves it>
```

Severity levels: `CRITICAL` · `HIGH` · `MEDIUM` · `INFO`

If no issues are found, output:

```
✓ Policy review passed — no findings.
```

## Examples

**Input:**
```yaml
# approval_policy.yaml
approval_rules:
  - name: default
    approvals_required: 1
    any_approver: true
```

**Output:**
```
[HIGH] approval_policy.yaml: rule "default"
  Rule:    Required approver count ≥ 2 for security-critical paths
  Finding: approvals_required is 1 — insufficient for production branches
  Fix:     Set approvals_required: 2

[HIGH] approval_policy.yaml: rule "default"
  Rule:    `any_approver` is not used on protected branches
  Finding: any_approver: true allows any project member to approve
  Fix:     Replace any_approver with an explicit approver group
```

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…