Security vulnerabilities and automated fixes for devops security issues
6 posts found
A GitHub Actions workflow in `templates/devto/devto-readme.yml` referenced `actions/checkout@v4` and `actions/setup-node@v4` using mutable version tags instead of pinned commit SHAs. This pattern enables supply-chain attacks where a compromised action owner silently repoints a tag to malicious code. The fix pins both actions to their full 40-character commit SHAs while preserving version comments for maintainability.
A missing `trustPolicy` setting in `pnpm-workspace.yaml` left a Node.js workspace vulnerable to malicious packages silently downgrading security configurations. The fix adds `trustPolicy: no-downgrade` alongside `blockExoticSubdeps: true` and a stricter `minimumReleaseAge`, closing a supply-chain attack primitive before it could be chained with other weaknesses.
A GitHub Actions workflow was using `actions/checkout@v1`, a mutable tag reference that could be silently repointed by the action owner to inject malicious code. This supply-chain vulnerability was fixed by pinning the action to a specific commit SHA (`11bd71901bbe5b1630ceea73d27597364c9af683`), ensuring the workflow always executes verified, immutable code.
A GitHub Actions workflow in `reusable-workflow-input-must-declare-type.yaml` was directly interpolating `${{ inputs.constraints }}` inside a `run:` shell step, creating a shell injection vulnerability. An attacker who controls the workflow input could inject arbitrary shell commands into the runner, potentially stealing secrets and source code. The fix moves the untrusted value into an intermediate environment variable, breaking the injection path entirely.
A critical vulnerability in the DragonFly installation script allowed attackers to inject malicious packages by downloading and installing software without verifying integrity checksums. The fix adds SHA256 verification before installation, ensuring only legitimate packages are executed with elevated privileges.
A high-severity privilege escalation vulnerability was discovered in a Docker Compose configuration where the `nginx` service lacked the `no-new-privileges` security option and was running with a writable root filesystem. These misconfigurations could allow a compromised container process to gain elevated permissions or download and execute malicious payloads. The fix applies defense-in-depth by adding `no-new-privileges:true`, enforcing a read-only root filesystem, and redirecting writable path