5 posts tagged with "security"

Overview​

• Add @logStream = "waf" to your CloudWatch Logs Insights query to view log events where the WAF blocked a request.
• Logs are counted and rolled up by IP address.
• Provider information is also included in the log for enhanced debugging.

Overview​

Alpine 3.21 and above have changed the default mysql client to the mariadb client. As part of this change, the client now verifies the connection certificates by default.

When deploying to a preview environment or on a local development environment (depending on your configuration) mysql server is signed with a self-signed certificate causing the connection to fail. This change does not affect Skpr cluster environments.

Solution​

The solution is to disable the certificate verification using the MYSQL_ATTR_SSL_VERIFY_SERVER_CERT PDO setting for development (local and preview) environments. This alone will fix the web server connection issues, but does not fix the Drush CLI connection unless you're using version 13.7.2 and above.

if ($cert_path = $skpr->get('mysql.default.ca.crt')) {
  $databases['default']['default']['pdo'][\PDO::MYSQL_ATTR_SSL_CA] = $cert_path;
}
else {
  $databases['default']['default']['pdo'][\PDO::MYSQL_ATTR_SSL_VERIFY_SERVER_CERT] = FALSE;
}

See this change in context

We have worked with Drush to include a change that will disable the peer verification for the CLI when the above is set and this change was released in Drush 13.7.2. You will need to upgrade to Drush 13.7.2 to fix the issue for the CLI.

If for some reason you can't upgrade to Drush 13.7.2, please contact a Skpr Platform Team member as there are workarounds for connecting, but they are not as seamless as Drush sql:cli or similar.

Testing​

You can test your changes by switching to the latest image tag for your PHP containers (fpm and cli). These are located in .skpr/package/cli/Dockerfile and .skpr/package/fpm/Dockerfile.

Once the container is deployed you can confirm Alpine version with cat /etc/issue (3.21).

You can use drush version to check Drush version (13.7.2)

Finally a drush sql:cli command should work without certificate errors on a preview environment.

Timeline​

We will roll the alpine upgrade out to stable images on Monday, 30th March 2026.

Links​

• Code example in context
• Drush pull request

Overview​

The PGP key for the Skpr APT repository has been rotated.

Ubuntu users who rely on this repository must update their local PGP key to continue receiving package updates.

Updating the repository key​

Run the following commands to download and install the latest PGP key, then verify the update by upgrading your Skpr CLI:

# Update the key
wget -q https://packages.skpr.io/apt/packages.skpr.io.pub -O- | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/packages.skpr.io.pub > /dev/null

# Upgrade the CLI
sudo apt update
sudo apt upgrade skpr

These commands are also documented in the official installation guide:

https://docs.skpr.io/install/linux

Overview​

In light of the recent Shai-Hulud worm attack, we believe it’s important to offer our customers a more secure alternative to the npm package manager.

Why move away from npm?​

By design, npm executes arbitrary scripts across all dependencies—including transitive ones (the dependencies of your dependencies). This creates a risky environment where malicious code can execute unnoticed.

Enter pnpm​

First released in 2016, pnpm has matured into a battle-tested package manager trusted by teams of all sizes. It combines speed, efficiency, and strict dependency management, making it especially well-suited for organisations managing multiple projects and large monorepos.

Key benefits of pnpm include:

• Fast – Up to 2x faster than other package managers (see benchmark).
• Efficient – Uses content-addressable storage; all projects share a single source of truth.
• Strict – Enforces dependency boundaries from package.json.
• Deterministic – Ensures reproducible installs with pnpm-lock.yaml.
• Flexible – Doubles as a Node.js version manager via pnpm env use.
• Cross-platform – Runs seamlessly on Windows, Linux, and macOS.
• Battle-tested – In production use since 2016.

(Adapted from the official project README.md)

Why this matters now​

For the context of this changelog, the most important feature is script execution control. Unlike npm, pnpm does not automatically run install scripts from dependencies. Instead, it notifies development teams, giving them the choice to explicitly allow or deny execution.

This default safeguard significantly reduces the attack surface for supply-chain exploits like the Shai-Hulud worm.

╭ Warning ─────────────────────────────────────────────────────────────────────╮
│                                                                              │
│   Ignored build scripts: @tailwindcss/oxide, esbuild.                        │
│   Run "pnpm approve-builds" to pick which dependencies should be allowed     │
│   to run scripts.                                                            │
│                                                                              │
╰──────────────────────────────────────────────────────────────────────────────╯

With this in mind, we strongly recommend development teams evaluate pnpm for their development workflows as a replacement for npm.

Available in all base images​

pnpm is now available in all our Node base images.

See here for the full list of images.

Overview​

We have disabled NPM scripts in our Skpr container base images as a security measure in response to the Shai-Hulud worm attack.

For more information on the attack see this blog post from Socket.

Changes Applied​

We have added the following environment variables to our Node images.

• YARN_ENABLE_SCRIPTS=false
• NPM_CONFIG_IGNORE_SCRIPTS=true

Recommended Local Development Configuration​

To ensure local development environments are not compromised, we also recommend teams add the following to their .npmrc file:

ignore-scripts=true

Checking Blocked Scripts​

You can identify which scripts are now blocked with:

npm query ":attr(scripts, [postinstall])" | jq 'map(.name)'

Example output:

[
  "esbuild" 👈️ Flagging a dependency that has a postinstall script
]

To see what a blocked script would have executed:

npm view esbuild scripts.postinstall

Example output:

node install.js

You can then manually run the script by pointing to the full path:

node ./node_modules/esbuild/install.js

Include these manual execution steps in your build process where required.

Further Recommendations​

We encourage teams to evaluate alternative Node package managers that have built-in ignore-scripts workflows. For example, pnpm blocks scripts by default and provides a subcommand for approving projects when needed.