Secrets Management
v1.0.0Securely store, manage, rotate, and integrate secrets (API keys, passwords, certificates) in CI/CD pipelines using Vault, AWS Secrets Manager, and native tools.
⭐ 0· 750·1 current·1 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
high confidencePurpose & Capability
The skill's name and description (Vault, AWS Secrets Manager, CI/CD integration) align with the instructions and snippets in SKILL.md. However, the declared metadata lists no required environment variables or binaries even though the instructions repeatedly reference Vault, AWS CLI, GitHub/GitLab CI secrets, kubectl/ExternalSecrets, Terraform, docker, jq, and other tools. The tool choices are appropriate for the stated purpose, but the metadata omission is a mismatch.
Instruction Scope
The runtime instructions explicitly reference and expect secret-bearing environment variables and credentials (e.g., VAULT_TOKEN, VAULT_ADDR, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, $GITHUB_ENV, GitHub/GitLab secrets). The SKILL.md also shows commands that read/write secrets (vault kv put/get, aws secretsmanager get-secret-value, echoing secrets into $GITHUB_ENV, using add-mask), and runs containers (trufflehog) and CLIs (vault, aws, docker, jq). The metadata does not declare these dependencies, and the instructions include risky examples such as starting Vault in dev mode with a root token, which is insecure if copied to production.
Install Mechanism
This is an instruction-only skill with no install spec, so nothing is written to disk by the skill itself. That lowers installation risk, but the guidance presumes availability of many external binaries/containers (vault, aws-cli, kubectl, terraform, docker, trufflesecurity/trufflehog image) without declaring them. Consumers must provision those tools separately; the omission is a documentation/metadata gap.
Credentials
Although the skill is about secrets, the declared registry metadata lists no required environment variables or primary credential. SKILL.md requires/uses multiple sensitive variables (VAULT_TOKEN, VAULT_ADDR, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, $VAULT_TOKEN in CI, etc.). The skill should have declared these expected env vars in metadata and explained least-privilege requirements. As-is, there's a mismatch between the sensitivity of what's used and what the package declares.
Persistence & Privilege
The skill does not request always:true and does not include install hooks or code that would persist in the agent. It is user-invocable and permits model invocation (the platform default), which is appropriate for this kind of guidance-only skill.
What to consider before installing
This skill's instructions are broadly consistent with a secrets-management guide, but the registry metadata is incomplete. Before installing or following the examples: (1) treat the SKILL.md examples as templates only — do not copy dev-mode Vault with a root token into production; (2) expect to need tools and credentials not listed in metadata (vault, aws-cli, docker, jq, kubectl, terraform, and CI provider secrets like VAULT_TOKEN, AWS_ACCESS_KEY_ID/SECRET); (3) ensure any credentials you supply use least-privilege IAM roles or short-lived tokens and never paste real secrets into examples; (4) verify the skill's publisher/source (homepage is missing) and prefer packages that explicitly declare required env vars and binaries; (5) if you need to trust this skill for automation, ask the author to update metadata to list required env vars/binaries and to replace insecure examples (vault -dev with root token) with safe, production-oriented instructions.Like a lobster shell, security has layers — review code before you run it.
latestvk97eqhk2b3bk4ttxa66ppqk7xd8190cs
License
MIT-0
Free to use, modify, and redistribute. No attribution required.