Security scanning for GitLab CI, in one command

Add vulnerability scanning to any GitLab project. No complex setup, no dependencies to manage, no YAML to write by hand.

Installation

Run one of the commands below inside your Git repository. The installer detects your project state, configures scanning modules, and injects a single include line into your .gitlab-ci.yml. Pick the modules you want and whether findings should block your pipeline — the commands update as you choose.

Modules
Failure behavior

Linux / macOS

Bash
curl -fsSL https://trivy.galih.dev/install.sh | bash

Windows

PowerShell
irm https://trivy.galih.dev/install.ps1 | iex

Passing options manually

Prefer typing it yourself? Both one-liners accept flags through their respective shell conventions:

Bash — pass arguments with -s --
curl -fsSL https://trivy.galih.dev/install.sh | bash -s -- --modules trivy
PowerShell — wrap in a script block
& ([scriptblock]::Create((irm https://trivy.galih.dev/install.ps1))) --modules trivy

Replace trivy with a comma-separated list of module names, or use all to enable every implemented module.

Uninstallation

Run one of the commands below to remove SS GitLab CI AutoConfig from your repository. This deletes the .ss-security-check/ directory and removes the injected include entry and security stage from your .gitlab-ci.yml — nothing else in the file is touched.

Linux / macOS

Bash
curl -fsSL https://trivy.galih.dev/uninstall.sh | bash

Windows

PowerShell
irm https://trivy.galih.dev/uninstall.ps1 | iex

Previewing changes

Both uninstallers support --dry-run to report what would be removed without changing anything:

Bash — pass arguments with -s --
curl -fsSL https://trivy.galih.dev/uninstall.sh | bash -s -- --dry-run
PowerShell — wrap in a script block
& ([scriptblock]::Create((irm https://trivy.galih.dev/uninstall.ps1))) --dry-run

Handling Gitleaks False Positives

The gitleaks module occasionally flags content that isn't actually a secret — generated checksums, hashes, or high-entropy strings in manifest and lockfiles are common offenders for the generic-api-key rule. Say a scan reports a finding like this:

Example finding
Finding: a546c6071f62ee4298c7ecb2b4d52e90d5db82dd65ed6a870787b2d54c0f9204 Secret: a546c6071f62ee4298c7ecb2b4d52e90d5db82dd65ed6a870787b2d54c0f9204 RuleID: generic-api-key Entropy: 3.785692 File: _bmad/_config/files-manifest.csv Line: 49

That value is a SHA-256 checksum in a generated manifest, not a real secret. To suppress it, create a .gitleaks.toml file at your repository root and add the exact secret value to allowlist.regexes:

.gitleaks.toml
title = "gitleaks config" [extend] # Keep every built-in rule active — only exclude the values below. useDefault = true [allowlist] description = "Known false positives" regexes = [ '''a546c6071f62ee4298c7ecb2b4d52e90d5db82dd65ed6a870787b2d54c0f9204''', ]

Only that exact string is skipped — everything else in the file, and every other rule, is still scanned normally. If another false positive shows up later, add its value as a new entry to the same array:

.gitleaks.toml — ignoring another value
[allowlist] description = "Known false positives" regexes = [ '''a546c6071f62ee4298c7ecb2b4d52e90d5db82dd65ed6a870787b2d54c0f9204''', '''''', ]

Notes:

  • Copy the value from the Secret field of the scan output exactly — this stays valid across future commits since it doesn't depend on a commit hash or line number.
  • The gitleaks module already picks up .gitleaks.toml from the repository root automatically — no extra flags or install options needed.

FAQ

What does the installer actually do to my repository?

It creates a .ss-security-check/ directory containing module templates and a main.yml that ties them together. It then adds (at most) one include entry and one - security stage entry to your .gitlab-ci.yml. Nothing else in your pipeline file is modified — existing jobs, stages, rules, anchors, and extends references are left untouched.

Is it safe to re-run the installer?

Yes. The installer is idempotent. Running it again with the same module selection produces no duplicate entries and no extra files. If nothing changed, the summary will report your repository is already up to date. If the remote module templates have been updated since the last run, the local copies under .ss-security-check/modules/ will be refreshed to match. If you re-run with a smaller module selection than before, modules no longer selected are removed automatically — the installer always converges your repository to match exactly what you asked for.

How do I disable SoftwareSeni security checks temporarily?

Comment out the - local: .ss-security-check/main.yml line in your .gitlab-ci.yml. The installer's own comment block above that line tells you exactly which line to comment. Re-run the installer (or uncomment the line) to re-enable.

How do I remove SS GitLab CI AutoConfig entirely?

Run the uninstaller. It deletes .ss-security-check/ and removes the injected include entry and security stage from your .gitlab-ci.yml, leaving everything else in the file untouched.

Can I use both install.sh and install.ps1 in the same repository?

Yes. Both scripts produce identical results — the same .ss-security-check/ directory layout and the same .gitlab-ci.yml injection. Use whichever matches your local shell. They are interchangeable and can be run in any order.

Vulnerability Severity Levels

The Trivy module scans for vulnerabilities at HIGH and CRITICAL severity only. Here's what those levels mean:

CRITICAL

Vulnerabilities that allow remote code execution, data exfiltration, full system compromise, or privilege escalation without user interaction or special conditions. These are exploitable in default configurations and typically have public exploits available. A CRITICAL finding means an attacker can likely compromise your system with minimal effort.

HIGH

Vulnerabilities with significant impact — such as arbitrary code execution or data exposure — but which require some preconditions to exploit. This might mean specific configurations, user interaction, local access, or a particular network position. The damage potential is serious, but exploitation is not trivial or universal.

Why only these two levels?

Filtering to HIGH and CRITICAL keeps the signal actionable. MEDIUM and LOW findings often produce noise that teams learn to ignore, which defeats the purpose of automated scanning. By focusing on the vulnerabilities most likely to result in a real breach, the pipeline fails only when immediate attention is genuinely warranted.

Troubleshooting

Common error messages from the installer and how to resolve them:

Error Cause & Fix
Not a Git repository You need to run git init first, or cd into an existing Git repository before running the installer.
git: command not found Git is not installed or not on your PATH. Install Git from git-scm.com and try again.
Unrecognized option You passed a flag the installer doesn't support. Run with --help to see the available options.
Module not found / Module not yet implemented The module name is either misspelled or refers to a planned module that isn't available yet. Run with --list-modules to see which modules are currently implemented.
Unable to parse .gitlab-ci.yml The file contains tab indentation or duplicate top-level include:/stages: keys. Fix the YAML formatting (use spaces, not tabs) and remove any duplicate keys.
Directory not writable The installer cannot create or modify files in the repository directory. Check file permissions and ensure you have write access to the project root.
Template retrieval failed The installer couldn't download a module's template from the hosting server. Check your network connectivity and ensure the host is reachable.
File write failed A local file could not be written. Check available disk space and directory permissions for the .ss-security-check/ directory.