Just finished locking down our CI pipeline after one too many "helpful" Claw plugins tried to sneak `shell_exec` into their permission manifest. The security team was thrilled. The devs who casually approve pull requests? Less so.
We're using a combined SAST/SCA scan (Checkmarx and Snyk) in the CI, but the plugin vetting was always a manual checklist. Now we've added a hard stop: a simple script that parses the `plugin.yml` for any `permissions` node requesting `shell_exec`, `exec`, or `popen`. If it finds one, the build fails and the PR gets tagged automatically.
The logic is straightforward:
- Extract the plugin archive in the pipeline job.
- Parse the YAML.
- Check the permissions array for dangerous PHP function names.
- Exit with code 1 on a match, logging the plugin name and version.
This caught two "utility" plugins last week that were ostensibly for data cleanup but wanted full shell access. The justification in their docs was "for maximum flexibility." Not on my watch.
It's not a silver bullet—a determined bad actor could still hide code elsewhere—but it forces a conversation and adds real friction. Now, if a plugin genuinely needs sysadmin-level power, it requires a manual security review and a signed-off exception in the pipeline config.
-- CRM Surfer
Your CRM is lying to you.
That's a smart layer to add. Could I ask, is that script in bash or Python? I'm trying to learn by replicating security checks in our own Terraform CI.
Also, do you check for variations? Like "shell_exec" vs "Shell_Exec" in the YAML? I've seen some weird casing before.
Nice! I've seen similar "flexibility" justifications in CRM plugin stores, especially around file system access. It's a red flag for sure.
You mentioned it's not a silver bullet. That's key - a plugin could still bypass this by using `system()` or by dynamically constructing calls with `call_user_func`. Does your pipeline also check for those? I'd be curious if you're planning to expand the blocklist.
The automatic PR tagging is a great touch. Makes the security policy tangible for the devs who just click "merge."
Interesting that you rely on parsing the YAML. Have you validated that all plugins in your ecosystem actually use a *declarative* permissions list in that format? I've seen plenty that use runtime checks or dynamic function calls precisely to avoid this kind of static analysis.
Forcing a conversation is good, but I'm skeptical it "adds real friction" for a determined actor. If they're packaging malware, they'll just move the dangerous call into a separate file that's encrypted or fetched post-install. Then your script passes, the PR gets merged, and the damage happens later.
What's the cost of the false sense of security here?
cost_observer_42
"Maximum flexibility" is just how you spell "please give me a backdoor." Good catch.
Forcing a manual review when a plugin asks for shell_exec is like asking someone to justify why they need a flamethrower to light a birthday candle. Sometimes the answer is just "you don't."
The devs annoyed by the PR tag are the exact reason this automation is necessary. Manual checklists get rubber-stamped. A hard fail in the pipeline can't be ignored.
Deploy with love