GitHub Actions and DigitalOcean lessons from Claude

Dave Johnson — Tue, 2 Jun 2026 21:30:00 +0000

I would say that 99% of the code in the Investor Ping's backend and iOS app was written by LLMs, but I did not vibe code it. My definition of vibe coding is when you use an LLM to write code that you do not review or even read. Nope, I ran the project like I always do with design docs, issue tracking, pull requests and CI/CD sandbox and production deploys (in this case to DigitalOcean). I review all code and try to enforce some architectural constraints, mostly about separation of concerns, configuration and secrets management; but maybe less so in the iOS app because I am new to iOS and Swift.

Despite that, I ended up with some poor security practices baked into my codebase. I knew that would happen given the volume of code I was generating and my desire to move fast.

So, I worked with Claude Code to create a comprehensive security review and Claude found eighteen issues that should be fixed; most were in GitHub Actions workflows and secrets; the rest were vulnerable NPM dependencies and application level problems. The review created is an impressive document that explains each problem and how to fix it. Claude made a list of the top five things to fix and three of them were good lessons to learn.

📍 Pin third-party GitHub Actions to a commit SHA

The first item is to pin the third-party GitHub Actions used in my workflows to specific commit SHAs to reduce the chance of a supply chain attack. This seems reasonable and easy to do.

# Before — tag reference, mutable
- uses: actions/checkout@v4

# After — immutable SHA, version tag in comment for humans
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

🔐 Lock-down SSH with StrictHostKeyChecking=yes and ForceCommand

The second item is about how CI/CD accesses the production servers via SSH using a 3rd party GitHub Action and StrictHostKeyChecking=no. The workflow uses SSH to do deployment: to write config and secrets to a Docker Compose file and start up my containers. I think this is the most serious issue found. We don't want CI/CD to have the keys to the kingdom.

The fix is to add StrictHostKeyChecking=yes and use an SSH feature called ForceCommand to lock the SSH key down so that it can only run one specific script on the remote host, and to get the secrets to the hosts via a diferent route: a script I run on my laptop and a different SSH key.

On the host, restrict the CI key in ~/.ssh/authorized_keys to just the deploy script:

command="/usr/local/bin/deploy.sh",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-ed25519 AAAA...ci-key... ci-deploy@github

In the workflow, drop the third-party SSH action and pin the host key:

- name: Deploy
  env:
    DEPLOY_HOST: ${{ secrets.DEPLOY_HOST }}
    SSH_KEY:     ${{ secrets.DEPLOY_SSH_KEY }}
    KNOWN_HOSTS: ${{ secrets.DEPLOY_KNOWN_HOSTS }}
  run: |
    install -d -m 700 ~/.ssh
    printf '%s\n' "$SSH_KEY"     > ~/.ssh/id_ed25519  && chmod 600 ~/.ssh/id_ed25519
    printf '%s\n' "$KNOWN_HOSTS" > ~/.ssh/known_hosts && chmod 600 ~/.ssh/known_hosts
    ssh -o StrictHostKeyChecking=yes -i ~/.ssh/id_ed25519 \
        deploy@"$DEPLOY_HOST" deploy

🪖 Use least-privilege DigitalOcean access keys

Third, CI/CD runs Terraform with an all-powerful DigitalOcean API access token when some workflows only need a couple of permissions.

DO supports custom-scoped tokens (Control Panel → API → Generate New Token → Custom Scopes). Create one per workflow, stored as a separate GitHub secret, e.g. a token just for registry management:

jobs:
  tf-registry:
    environment: prod              # required reviewer before apply
    env:
      # token scopes: registry:read, registry:create, registry:delete
      DIGITALOCEAN_TOKEN: ${{ secrets.DO_TOKEN_REGISTRY }}
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
      - uses: hashicorp/setup-terraform@b9cd47afb6f8aabd99b34a4673bf25b95f6d4d0d # v3.1.2
      - run: terraform -chdir=terraform/registry apply -auto-approve

The fourth and fifth items were NPM dependencies with critical vulnerabilities that need an update. I feel like I need to learn some lessons in this area.

It took me maybe three Claude Code sessions, a couple of afternoons, to deploy fixes for those five problems plus two others. In the end it was nine pull requests and ~2,200 added / ~630 deleted lines of code.

The overall lesson: rapidly producing code with LLMs leads to security and other problems, because try as you may, you can't review every line. But a great LLM harness like Claude Code can search and probe your codebase from every angle and help you find and fix those problems quickly.

Windows security

Dave Johnson — Sat, 3 Feb 2007 23:34:15 +0000

Usually I find a couple of contradictory stories every time I read the feeds. Here's a pair from today's session. First via John Gruber.

Bll Gates in Newsweek: Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine.

And next, via John Robb, I found:

Spencer Kelly, BBC: We set up a poor Windows XP machine with no firewall or anti-virus software. Connecting it to the internet would be like throwing it into a lion pen with raw meat strapped to its hard drive. How long would it be before we were hit by something nasty on the net? Hours, minutes? As it turned out - eight seconds!

Of course Bill may have been talking about Vista, even though he did not qualify. Maybe Vista is better, but I wouldn't count on it. Initial reports don't sound so good (Vista users: keep your speakers and microphones turned off).

Blogging Roller

GitHub Actions and DigitalOcean lessons from Claude

📍 Pin third-party GitHub Actions to a commit SHA

🔐 Lock-down SSH with StrictHostKeyChecking=yes and ForceCommand

🪖 Use least-privilege DigitalOcean access keys

Windows security