Deploydevnlu

Deploys the application to the SupplyWhy development EC2 server via SSH, updates image tag if provided, applies Kubernetes deployment, and verifies rollout s...

Security Scan

The skill mostly does what it says (SSH to a dev EC2 and run kubectl), but there are inconsistencies and sensitive operations (accessing a private SSH key, mismatched interfaces, and potential command-injection surface) that warrant caution before installing.

Purpose & Capability

The code and SKILL.md both describe deploying to the SupplyWhy EC2 via SSH and running kubectl, which is coherent with the name/description. However the SKILL.md expects an IMAGE_TAG argument ($ARGUMENTS) while the code instead parses a deployment environment (production/staging/dev) from Slack text and uses that value as the image tag — a mismatch in inputs. The skill also hardcodes an ECR repo/account in the sed command, which is specific but consistent with a deployment tool for this application.

Instruction Scope

The instructions and code tell the agent to add and use a local private SSH key (~/.ssh/supplywhy-dev-key.pem) and run multiple ssh commands on a host named supplywhy-dev-master. That requires access to the user's private key and the agent's ssh-agent. The code accepts NLP-parsed environment text and injects it into shell commands without explicit sanitization, which introduces a command-injection risk if the parsed value is unexpected. The SKILL.md and code differ about how an image tag is provided (ARGUMENTS vs parsed environment), creating ambiguity about what will actually be used.

Install Mechanism

There is no install spec and only a small index.js implementation; nothing is downloaded or written by an installer. This is lower risk from an installation perspective.

Credentials

No environment variables or credentials are declared in metadata, yet the skill requires and will use a specific SSH private key file in the user's home (~/.ssh/supplywhy-dev-key.pem). Requiring access to a private key is proportionate for a deploy tool, but the omission from declared requirements and the hardcoded key path means the skill implicitly expects access to sensitive local secrets. Additionally, the hardcoded ECR repo/account is specific and may not be appropriate for all users.

Persistence & Privilege

The skill is not always-enabled and does not request system-wide persistence or modify other skills. It runs when invoked (normal behavior) and does not declare elevated platform privileges.

What to consider before installing

Before installing, consider these precautions: - Treat this as potentially dangerous until you audit it: the skill will attempt to add and use a local SSH private key (~/.ssh/supplywhy-dev-key.pem). Only proceed if you trust the skill source and you have a dedicated deploy key (not your personal account key). - The SKILL.md and code disagree about how the image/tag is supplied. Test in a safe environment to confirm which input (an explicit tag argument vs. a parsed environment string) will be used. - The code injects the parsed environment directly into shell commands (sed/ssh). Malformed or unexpected NLP output could allow command injection. Prefer sanitizing inputs or restricting allowed values to {production,staging,dev} before running commands. - Verify the hardcoded ECR account (590183820143) and the target host name (supplywhy-dev-master) are appropriate for your org; otherwise the skill could target the wrong resources. - Use a limited-scope deploy key with restricted access and rotate it if the key is ever exposed. Run the deployment steps manually once from a machine with only the deploy key to confirm behavior before allowing the skill to run automatically. - If you cannot audit the code or don't trust the author, do not install the skill on a machine that holds other SSH keys or sensitive credentials. If you want to proceed but reduce risk: modify the code to validate/sanitize parsed environment values, require explicit configuration of the SSH key path in metadata, and use a dedicated, least-privilege deploy key.

Deploy the application to SupplyWhy via Slack natural language commands.

Instructions

Execute the following steps in order. Verify each step succeeds before proceeding to the next.

Step 1: Add SSH Key to Agent

Run the following command to add the SSH key:

ssh-add ~/.ssh/supplywhy-dev-key.pem

Verification: The command should output Identity added: ~/.ssh/supplywhy-dev-key.pem or similar. If you see "Could not open a connection to your authentication agent", the ssh-agent may not be running. If you see "No such file or directory", the key file is missing.

Stop and report to user if: The key cannot be added.

Step 2: Test SSH Connection

Before deploying, verify the SSH connection works:

ssh supplywhy-dev-master "echo 'SSH connection successful'"

Verification: Should output SSH connection successful. If you see connection timeout, permission denied, or host not found errors, the SSH connection is not working.

Stop and report to user if: SSH connection fails.

Step 3: Update Image Tag

If an IMAGE_TAG argument was provided ($ARGUMENTS), update the deployment.yaml with the new tag:

ssh supplywhy-dev-master "sed -i 's|590183820143.dkr.ecr.us-west-2.amazonaws.com/genie:.*|590183820143.dkr.ecr.us-west-2.amazonaws.com/genie:$ARGUMENTS|' genie/deployment.yaml"

Verification: Run a quick check to confirm the tag was updated:

ssh supplywhy-dev-master "grep 'image:' genie/deployment.yaml"

The output should show the new tag you provided.

Skip this step if: No IMAGE_TAG argument was provided (deploy with existing tag).

Stop and report to user if: The sed command fails.

Step 4: Deploy via kubectl

SSH into the EC2 server and run the kubectl deployment command:

ssh supplywhy-dev-master "cd genie && kubectl apply -f deployment.yaml"

Verification: The kubectl output should show resources being created, configured, or unchanged. Look for lines like:

• deployment.apps/xxx configured
• service/xxx unchanged

Stop and report to user if:

• kubectl returns errors (e.g., "error: the path does not exist", "connection refused")
• Any resource shows error status

Step 5: Verify Deployment Status

After applying, check that the deployment is rolling out successfully:

ssh supplywhy-dev-master "kubectl rollout status deployment -n default --timeout=60s"

Verification: Should show successfully rolled out for deployments. If it times out or shows errors, the deployment may have issues.

Report to user: The final status of all deployments, whether successful or failed.

Success Criteria

The deployment is successful when:

1. SSH key was added successfully
2. SSH connection to server works
3. Image tag was updated (if argument provided)
4. kubectl apply completed without errors
5. Deployment rollout status shows success

Troubleshooting

If the deployment fails at any step:

1. SSH key issues: Verify the key exists at ~/.ssh/supplywhy-dev-key.pem and has correct permissions (600)
2. SSH connection issues: Check network access and that your IP is allowed in security groups
3. kubectl apply errors: Verify deployment.yaml exists in the genie folder on the server
4. Rollout failures: Check pod logs with kubectl logs or describe the deployment with kubectl describe deployment