SECOPS
Require named security approvers when GitLab MRs touch critical paths
On every GitLab MR change, detect whether protected paths are modified and, if so, assign the designated security reviewers and post a blocking checklist comment so the MR can't…
How it runs
The automated pipeline, trigger to output.
- TriggerGitLab MR opened or updatedGitLab
- ActionPull MR changed-file listGitLab
- LogicMatch paths to protected categories; exit if none
- ActionAssign mapped security reviewers + labelGitLab
- OutputPost category-specific review checklist commentGitLab
What it does
This workflow enforces human security review for the paths that matter. When an MR is opened or updated, it inspects the changed files; if any fall under your protected-path list (secrets handling, RBAC config, network policy), it assigns the named security reviewers, applies a `needs-security-approval` label, and leaves a comment with a review checklist tailored to which sensitive area was touched.
When to use it
Use it when GitLab's built-in CODEOWNERS isn't expressive enough and you want path-specific reviewer routing plus an audit trail of what was flagged and why. Good for teams running review SLAs on a fixed roster of security engineers.
How it works
- 1A GitLab MR webhook fires on open or update.
- 2The flow pulls the changed-file list for the MR.
- 3A filter checks paths against the protected-path config and returns the matched categories.
- 4If nothing matched, the flow exits quietly.
- 5Otherwise it assigns the mapped security reviewers and adds the `needs-security-approval` label.
- 6It posts a category-specific review checklist as an MR comment.
Set it up
What you configure once, before turning it on.
- 1Connect GitLabRepos, MRs, pipelines, registry.
- 2Set each agent's modelWe leave models unset so you pick the tier — fast + cheap, or top-quality.
- 3Tune it to your dataEdit the prompts, filters, and field mappings so it matches how your team works.
- 4Test, then turn it onRun once against a sample, confirm the output, then enable the trigger.
More SecOps workflows
Post-Revocation Verification and Audit Logging
After a key is revoked, it confirms the old credential actually fails, verifies the replacement works.
Page on-call when a WAF rule mass-blocks legitimate traffic
On demand or every few minutes, it detects a single Cloudflare WAF rule suddenly blocking a broad spread of ASNs and paths (a likely false-positive storm).
PII Content Scan on New Dropbox External Share
When a file gets an external Dropbox link, it reads the file content, uses an AI classifier to detect PII or secrets.
Compile a weekly WAF tuning review with trends to Confluence
Every week an agent rolls up Cloudflare WAF block clusters by rule and ASN, compares them to prior weeks for trend direction.
Sensitive Dropbox Link Owner Remediation Loop
When a newly created Dropbox shared link points to a sensitive file, this workflow DMs the file owner, gives them a deadline to justify or revoke it.
GitLab Push Secret Detection to Block and History Purge
On a GitLab push that contains a detected secret, it revokes the exposed credential, opens a tracking issue with git-history purge instructions.
Run it inside a business
This workflow drops into a full company template. Import the org, and this is one of the playbooks its agents run.
Run this workflow in your colony.
14-day trial. No DevOps. No Sales call. Provisioned in under a minute.