cli/security: dlp add-custom --re is matched as a glob, not a regular expression
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 72/100
Research direction
Start at cli/security/dlp.go:20 and trace how dlp add-custom --re stores and evaluates its pattern. Check the matching path and its tests, then verify that valid regular expressions match intended inputs and invalid patterns produce a clear add-time error. Done means the flag uses regex matching consistently.
Written by the indexing model from the issue text.
Description
Problem
In packages/cli/security/dlp.go:20, the --re flag for dlp add-custom is documented/intended as a regular expression for custom DLP pattern matching, but the value is actually matched using glob semantics (e.g. via filepath.Match or a similar glob matcher) rather than being compiled and evaluated as a regular expression.
Impact
Users supplying a regex pattern via --re (e.g. ^sk-[a-zA-Z0-9]{32}$) get glob-style matching instead, where characters like ^, $, {, }, and + do not behave as regex metacharacters. This silently produces a custom DLP pattern that matches different (and likely far fewer, or entirely wrong) inputs than the user intended, weakening the custom detection rule without any error being surfaced.
Repro
- Add a custom DLP pattern via
dlp add-custom --re '^sk-[a-zA-Z0-9]{32}$'. - Trigger DLP scanning on a string that matches the intended regex (e.g. a 32-character token starting with
sk-) and observe it is not detected because the value is being matched as a glob pattern, not compiled as a regex.
Suggested fix
Compile the --re value with regexp.Compile and use Regexp.MatchString for evaluation, surfacing a clear error at add-time if the pattern fails to compile as a valid regular expression, instead of passing it to glob-matching logic.
- Dominant language
- Go
- Stars
- 157
- Forks
- 19
- Avg merge
- 4h 28m
- Merged PRs (30d)
- 88
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from solongate/agent-security
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
solongate/agent-security#227 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 91/100
solongate/agent-security#226 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 88/100
solongate/agent-security#225 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
solongate/agent-security#224 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
solongate/agent-security#223 ·
Maintainers usually reply within 1 day
All issues in solongate/agent-security
Similar issues
-
VLAgent `spec.k8sCollector.includePodLabels: false` has no effectPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
VictoriaMetrics/operator#2772 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Gaurav-Gosain/tuios#1316 ·
Maintainers usually reply within 1 day
-
needs: investigation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
area:auth documentation priority:low
Difficulty 1/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
Mend: dependency security vulnerability
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
kube-tarian/sigrun#203 ·