DEV Community: puppet

Puppetlabs Modules Roundup – August 2026

Jason St-Cyr — Tue, 08 Sep 2026 18:54:01 +0000

August 2026 brought 24 releases across 22 Puppetlabs modules (puppet_metrics_collector and cd4peadm each shipped twice), headlined by a broad Puppet Core 9 compatibility rollout. Continuous Delivery for PE also shipped a required upgrade, Security Compliance Management 3.9.0 closed out 117 CVEs, and a few community contributions were rolled into modules as well. This roundup pulls the most important changes into one place.

Highlighted Updates

Puppet Core 9 Support Continues to be Added Across Modules

Fourteen puppetlabs modules added Puppet Core 9 compatibility this month, continuing the ongoing Puppet 9 rollout. Five of them (package, node_encrypt, service, reboot, and tomcat) paired the Puppet Core 9 addition with dropping Puppet 7 support in major version bumps as part of a broader Puppet Core modernization pass; see below.

Affected modules: exec, package, node_encrypt, mount_iso, lvm, service, java, inifile, reboot, windows_eventlog, cd4pe, cd4pe_jobs, cd4peadm, tomcat.

Puppet 7 Support Dropped

Five modules dropped Puppet 7 support in major version bumps this month as part of the same Puppet Core modernization pass: package, node_encrypt, service, reboot, and tomcat. reboot also picked up CentOS 9 support in the same release.

Affected modules: package, node_encrypt, service, reboot, tomcat.

Continuous Delivery for PE: Required Upgrade for Newer PE Versions

cd4peadm 5.17.0 is a required upgrade if you're integrating with PE 2023.8.11, 2025.12.0, or 2026.0.0+. Those PE versions now require cert-based auth on puppetserver's /status/v1/services endpoint, and CD's older unauthenticated calls to it fail with a 403 until you upgrade.

The same release also adds Puppet 9 support and closes a second batch of CVEs (bouncycastle, react-router, nanoid, and others).

Security Compliance Management Patches 117 CVEs

Security Compliance Management 3.9.0, shipped as both comply and complyadm, updates roughly 20 bundled third-party components to address 117 CVEs. These included curl/libcurl, OpenSSL, the Netty codec family, Jackson Databind, Keycloak services, and libxml2. — .

Also restricts the Keycloak administration console and Admin REST API from public access by default, and adds support for pulling container images from a private or air-gapped registry instead of only the public default.

What Updates Happened to Puppetlabs Modules in August 2026?

The following is an alphabetical listing of modules which received updates in August 2026. If a module had multiple versions released, the updates are collected together, numbered with the "latest" version available.

cd4pe 3.4.1

📅 Latest release: 2026-08-13 (🌐 View on the Forge)

Adds Puppet version 9 to the version requirements and updates the module with PDK 3.8.0, along with allowing the stdlib dependency to move to 10.x.

Added version 9 to the Puppet version range.
Updated module with PDK 3.8.0.
Expanded the puppetlabs-stdlib dependency to allow stdlib 10.x.
Removed unused/dead methods from cd4pe_client.rb.

cd4pe_jobs 1.7.5

📅 Latest release: 2026-08-12 (🌐 View on the Forge)

Adds Puppet version 9 support without dropping Puppet 7.

Support for Puppet 9. The puppet requirement in metadata.json is now >= 7.24 < 10.0.0.

cd4peadm 5.18.0

📅 Latest release: 2026-08-26 (🌐 View on the Forge)

Two releases this month for Continuous Delivery for PE: 5.17.0 is a required upgrade for anyone integrating with PE 2023.8.11, 2025.12.0, or 2026.0.0+ — those PE versions require cert-based auth on puppetserver's /status/v1/services endpoint, which CD previously called unauthenticated, and integration fails with a 403 until you upgrade. 5.17.0 also adds Puppet version 9 support. 5.18.0 follows up with a smaller set of fixes: ssl_cert_chain and ssl_crl in common.yaml can now reference file paths instead of requiring inline PEM contents, and several UI rendering bugs are fixed. Combined, the two releases close 42 CVEs.

Includes monthly releases: 5.18.0 (2026-08-26), 5.17.0 (2026-08-18).

Added support for version 9 of Puppet.
Fixed an issue where lastLoginTime data might not be current in some situations. The lastLoginTime field of the user details response from GET /v1/users/{userID} is now correctly updated for LDAP and SAML logins, as well as the initial login after account creation.
Fixed an issue where some upgraded environments could show a blank Pipelines as Code view and a blank approval details page for module repo pipelines. These pages now render properly without recreating the pipeline.
42 CVEs addressed.

Check the official release notes for cd4peadm 5.18.0 for the full details.

comply 3.9.0

📅 Latest release: 2026-08-21 (🌐 View on the Forge)

Security Compliance Management 3.9.0 addresses 117 CVEs across bundled third-party components, adds support for a private or air-gapped image registry, and restricts the Keycloak administration console and Admin REST API from public access by default.

Supported benchmarks updated in this release: Microsoft Windows 11 Enterprise Benchmark v5.1.0 Microsoft Windows Server 2022 Benchmark v5.1.0 Microsoft Windows Server 2025 Benchmark v2.1.0.
Fixed an issue where Assessor CLI downloads could fail if the assessor files were added after the comply-ui container started. Downloads now work after the files are deployed without requiring a manual container restart.
Fixed an issue where default desired compliance could select different non-STIG benchmarks for the same operating system and version depending on database query ordering. SCM now uses a deterministic selection rule so the default benchmark is chosen consistently.
117 CVEs addressed.

Check the official release notes for comply 3.9.0 for the full details.

complyadm 3.9.0

📅 Latest release: 2026-08-21 (🌐 View on the Forge)

Ships the same Security Compliance Management 3.9.0 update as comply, covering the same 117 CVE remediations, the new private/air-gapped image registry option, and the Keycloak admin console/API restriction.

Supported benchmarks updated in this release: Microsoft Windows 11 Enterprise Benchmark v5.1.0 Microsoft Windows Server 2022 Benchmark v5.1.0 Microsoft Windows Server 2025 Benchmark v2.1.0.
Fixed an issue where Assessor CLI downloads could fail if the assessor files were added after the comply-ui container started. Downloads now work after the files are deployed without requiring a manual container restart.
Fixed an issue where default desired compliance could select different non-STIG benchmarks for the same operating system and version depending on database query ordering. SCM now uses a deterministic selection rule so the default benchmark is chosen consistently.
117 CVEs addressed.

Check the official release notes for complyadm 3.9.0 for the full details.

cron_core 2.0.3

📅 Latest release: 2026-08-12 (🌐 View on the Forge)

Fixes a bug where CronParam#numfix used the =~ operator on non-String values, and updates the related spec tests.

(PE-45112) Don't use =~ on non-String in CronParam#numfix and update spec tests #94 (AriaXLi)

exec 4.1.0

📅 Latest release: 2026-08-31 (🌐 View on the Forge)

Adds support for Puppet Core 9.

(MODULES-11713) Add Puppet 9 support #250 (imaqsood)

inifile 6.5.0

📅 Latest release: 2026-08-31 (🌐 View on the Forge)

Adds Puppet Core 9 support, and fixes array_matching to return the first element when it isn't set to :all.

(MODULES-11703) Add Puppet 9 support #573 (imaqsood)
Return the first element if array_matching is not :all #571 (bwitt)

java 12.1.0

📅 Latest release: 2026-08-31 (🌐 View on the Forge)

Adds Puppet Core 9 support and defaults RHEL 10 nodes to OpenJDK 21.

(MODULES-11704) Add Puppet 9 support #630 (imaqsood)
(MODULES-11917) Default RHEL 10 to OpenJDK 21 #631 (imaqsood)

kubernetes 8.1.1

📅 Latest release: 2026-08-11 (🌐 View on the Forge)

Bumps several dependency constraints (augeasproviders_sysctl, augeas core, stdlib) and moves the module to Puppet Core 8, alongside a fix for kubernetes_version matching and a batch of CI/environment maintenance work.

fix(MODULES-11856): Bump augeasproviders_sysctl to <5.0.0 and core to <6.0.0 #722 (imaqsood)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #718 (imaqsood)
CAT-2378: Update puppetlabs-kubernetes to use Puppet Core 8 #712 (span786)
Fix kubernetes_version matching #705 (xbulat)
ci(MODULES-11557): add Twingate setup step to GitHub Actions workflow #704 (imaqsood)
MODULES-11577 chore(ruby): upgrade Ruby from 2.7 to 3.1 #702 (imaqsood)
(MAINT): Updated the version for puppetlabs-apt module in metadata.json file #698 (span786)
(CAT-2193): Fixed kubernetes environment setup for Debian. #694 (span786)
(CAT-2095): Fixed puppetlabs-kubernetes modules CI & nightly failures #693 (span786)

lvm 4.1.0

📅 Latest release: 2026-08-31 (🌐 View on the Forge)

Now supports Puppet Core 9.

(MODULES-11719) Add Puppet 9 support #391 (imaqsood)

mount_iso 5.1.0

📅 Latest release: 2026-08-31 (🌐 View on the Forge)

Puppet Core 9 is now supported.

(MODULES-11723) Add Puppet 9 support #61 (imaqsood)

node_encrypt 4.0.0

📅 Latest release: 2026-08-31 (🌐 View on the Forge)

Drops Puppet 7 support (BREAKING) as part of a Puppet Core update, and adds version 9 support in the same release.

(CAT-2382) Update for Puppet Core / Drop Support for Puppet 7 #125 (david22swan)
(MODULES-11724) Add Puppet 9 support #126 (imaqsood)

package 4.0.0

📅 Latest release: 2026-08-31 (🌐 View on the Forge)

Puppet 7 support gets dropped (BREAKING) as part of a Puppet Core update and also adds Puppet Core 9 support. Also, Chocolatey bootstrap failures are now surfaced more clearly in Windows acceptance testing.

(CAT-2384) Prepare module for Puppet Core / Drop Support for Puppet 7 #346 (shubhamshinde360)
(MODULES-11927) Surface chocolatey bootstrap failures in Windows acceptance #354 (imaqsood)
(MODULES-11730) Add Puppet 9 support #353 (imaqsood)
(CAT-2296) Update github runner image to ubuntu-24.04 #345 (shubhamshinde360)

puppet_metrics_collector 8.2.3

📅 Latest release: 2026-08-14 (🌐 View on the Forge)

Fixes a PostgreSQL 17 checkpoints query and hardens version parsing, cleans up puppet-lint warnings, and removes a broken plaintext-port fallback in PuppetDB metrics collection.

Includes monthly releases: 8.2.3 (2026-08-14), 8.2.2 (2026-08-07).

(PE-45849) Fix PG17 checkpoints query and harden version parsing #213 (beechtom)
Fix puppet-lint space_before_arrow and 140chars warnings #210 (jonathannewman)
Remove broken plaintext-port fallback in PuppetDB metrics collection #209 (jonathannewman)

reboot 6.0.0

📅 Latest release: 2026-08-26 (🌐 View on the Forge)

Drops Puppet 7 (BREAKING) amd adds support for Puppet Core 9 and CentOS 9.

(CAT-2388) Puppet Core update and Remove Puppet 7 support #378 (LukasAud)
(MODULES-11707) Add Puppet 9 support #381 (skyamgarp)
(CAT-7110) Add CentOS 9 support #373 (shubhamshinde360)

security_policy 1.1.0

📅 Latest release: 2026-08-04 (🌐 View on the Forge)

A kerberos_policy type/provider and a new_guest_name class parameter are added, expanding the module's native parity coverage ahead of SCE integration.

[MODULES-11883/MODULES-11884] Epic F: kerberos_policy type/provider (F.1) + new_guest_name parameter (F.2) #45 (mehul-jain1)
[MODULES-11884] Add new_guest_name class parameter (Epic F.2) #44 (mehul-jain1)
[MODULES-11848] plan: add Epic F (native parity superset for SCE integration) #43 (mehul-jain1)
plan/: post-release cleanup — Epics A/B/D/E done, Epic C transferred to puppetlabs-sce_windows #42 (mehul-jain1)
[MODULES-11804] CHANGELOG: rename Breaking Changes -> Changed (release-blocker) #41 (mehul-jain1)

service 4.0.0

📅 Latest release: 2026-08-31 (🌐 View on the Forge)

Drops support for Puppet version 7 (BREAKING) and adds version 9 support.

(CAT-2392) Puppet Core update / Drop support for puppet 7 #263 (LukasAud)
(MODULES-11709) Add Puppet 9 support #268 (imaqsood)
Update link for contributing documentation #264 (jst-cyr)
(CAT-2296) Update github runner image to ubuntu-24.04 #262 (shubhamshinde360)

sshkeys_core 3.0.2

📅 Latest release: 2026-08-05 (🌐 View on the Forge)

Hardens the sshkey type by rejecting key values that contain embedded whitespace, preventing malformed authorized_keys entries.

(PA-8911) Reject embedded whitespace in sshkey key #1 (mhashizume)

stdlib 10.0.2

📅 Latest release: 2026-08-06 (🌐 View on the Forge)

Fixes a stdlib::manage parser bug that failed to parse $type resources.

fix(stdlib::manage) parser fails $type resources #1477 (jcpunk)

tomcat 8.0.0

📅 Latest release: 2026-08-11 (🌐 View on the Forge)

Drops Puppet 7 support (BREAKING) as part of a Puppet Core update, and allows the stdlib dependency to move to 10.x.

(CAT-2396) Prepare module for Puppet Core / Drop Support for Puppet 7 #580 (david22swan)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #584 (imaqsood)
Update link for contributing documentation #583 (jst-cyr)
(CAT-2296) Update github runner image to ubuntu-24.04 #579 (shubhamshinde360)

windows_eventlog 5.2.0

📅 Latest release: 2026-08-31 (🌐 View on the Forge)

Adds Puppet Core 9 support to the module.

(MODULES-11729) Add Puppet 9 support #100 (imaqsood)

Until Next Time!

That wraps up the August 2026 roundup. If any of these modules intersect with your environment, especially the five modules that removed Puppet 7 support (package, node_encrypt, service, reboot, and tomcat), or some of the other breaking or required changes, the linked Forge pages and release notes are worth a closer look before upgrading.

Feedback on the series is always useful, especially if there are module families or release-note patterns that deserve more attention in future editions.

More updates coming next month when the September 2026 releases land, and you should expect to see continued Puppet Core 9 support rolling out across September!

🤖 AI Disclosure

This roundup is produced by a mostly-automated pipeline, with some AI sprinkled in for orchestration and enrichment (or 'Combobulating' and 'Finagling'), followed by a human review (that would be me) before publishing.

The automation is an open-source project with deterministic python scripts to crawl the Forge and determine which puppetlabs modules were released during a specific month (and catching when a module gets more than one release in a month). By combining a template, automation scripts, and some AI orchestration the content all gets pulled together for a structured markdown document. I then jump in to double-check the content and update any wording that seems repetitive or irrelevant (and sometimes I need to add some extra context that isn't in the changelog notes).

Automating 204 Lighthouse Audits to find the fastest Shopify Theme

Deepak Jangra — Thu, 03 Sep 2026 15:25:58 +0000

I needed to find the actual baseline speed of popular Shopify themes. Since dev stores are password-protected, manual PageSpeed Insights URLs don't work.

I wrote a Node.js script using Puppeteer to bypass the storefront password, and hooked it into the Lighthouse CLI to audit 17 themes across mobile and desktop viewports, running 3 passes each to get the median.

It turns out that while Shopify's default free themes are highly optimized, a few premium themes (like Broadcast and Expanse) manage to keep a perfect 100 score even with heavy UI components.

I published my methodology, the full dataset, and the raw JSON reports on my blog. If you do Shopify dev work, you can check the baseline numbers. You check more about the fastest shopify theme here

Security Compliance Management 3.9.0 now supports Ubuntu 24.04, RHEL 10, Puppet Core 9 and new benchmarks!

Jason St-Cyr — Thu, 27 Aug 2026 14:29:27 +0000

The latest Security Compliance Management (SCM) 3.9.0 has new supported platforms, improvements for air-gapped environments, benchmark updates, feature improvements, and security updates to address vulnerabilities.

Highlights

Expanded platform support: SCM 3.9.0 now supports Ubuntu 24.04, Red Hat Enterprise Linux (RHEL) 10, and Puppet 9
Private image registry support: complyadm can now pull SCM container images from a private image registry to better support air-gapped and private-registry environments.
IP-based access restrictions: Keycloak Administration Console and Admin REST APIs can now be access restricted to IP addresses defined in the frontdoor allowlist.
Expanded benchmarks: CIS-CAT Pro Assessor was updated to 4.65.0, expanded benchmark support for AlmaLinux and MacOS, and updated coverage on Microsoft Windows.
119 security vulnerabilities addressed via updates and fixes, along with several other security hardening fixes.

Below are some other summary details, but you may want to jump straight into the full release notes right away!

CIS-CAT Pro Assessor Updates

Along with updating to CIS-CAT Pro Assessor 4.65.0, the following benchmarks were added:

AlmaLinux OS 9 STIG v1.0.0
Apple macOS 15 (Sequoia) STIG v1.1.0
Apple macOS 26 Tahoe STIG v1.0.0

These supported benchmarks were also updated:

Microsoft Windows 11 Enterprise Benchmark v5.1.0
Microsoft Windows Server 2022 Benchmark v5.1.0
Microsoft Windows Server 2025 Benchmark v2.1.0

Operational Improvements and Security updates

There were several changes made to improve behavior and address vulnerabilities in this release, including addressing 119 security reports.

A few notable changes:

SCM handles interrupted scheduled scans after reboots more reliably.
Default benchmark selection is now more reliable when multiple non-STIG benchmarks are available.
Hasura GraphQL field suggestions are now disabled to prevent schema enumeration.

See the full list in the release notes!

Why Upgrade?

For customers running Ubuntu 24.04, RHEL 10, Puppet 9, private registries, or security-sensitive environments, SCM 3.9.0 delivers meaningful operational, platform, and security improvements. Combined with expanded benchmark coverage and enhanced upgrade behavior, this release helps organizations maintain compliance with greater confidence and less administrative overhead.

View the full SCM 3.9.0 release notes!

🤖 AI Disclosure

This summary was initially drafted by AI and deterministic automation to pull together release notes information from the latest Security Compliance Management 3.9.0 release notes. The draft was then human edited, rewritten, and reviewed before publishing.

Serverless Infrastructure

Nuwair Systems — Tue, 25 Aug 2026 11:59:33 +0000

Scale to Millions of Requests — Pay Only for What You Use.

Nuwair Systems designs and deploys event-driven serverless architectures on AWS Lambda, API Gateway, DynamoDB, and EventBridge. Infinite elasticity with zero server management — and a cost model that charges only for actual compute consumed.

What We Deliver
The four delivery pillars behind every Serverless Infrastructure engagement.

Serverless Architecture Design
Event-driven diagrams and function boundary decisions before a single line is written.

Lambda & API Gateway
Versioned functions with IAM least-privilege, WAF integration, and custom domain routing.

DynamoDB & Aurora Serverless
Single-table DynamoDB or Aurora Serverless v2 with automated backups and point-in-time recovery.

IaC with CDK / Terraform
Entire stack defined as code — reproducible across all environments with a single command.

Serverless Infrastructure | Nuwair Systems

Serverless infrastructure on AWS by Nuwair Systems. Lambda, API Gateway, DynamoDB architectures that auto-scale and charge only for actual usage.

nuwair.com

How I Enforced a Privacy Rule, Commented It, Yet Still Shipped a Data Leak – Lessons Learned

Tech Pulse — Mon, 24 Aug 2026 06:43:02 +0000

AI-Powered Privacy Policy Generators

LLM‑driven privacy policy generators have moved from experimental prototypes to production‑grade services in 2026, offering on‑demand, jurisdiction‑aware drafts that can be directly embedded into compliance pipelines.

Tools such as PrivacyGPT and PolicyCraft combine retrieval‑augmented generation with rule‑extraction models, turning natural‑language privacy intents into enforceable policy clauses that can be exported as JSON‑LD or plain‑text templates.

Deep Dive Architecture

PrivacyGPT leverages a hybrid architecture: a domain‑specific transformer fine‑tuned on 10 million privacy statements, paired with a deterministic rule engine that maps extracted obligations to GDPR, CCPA, and emerging AI‑Act provisions.
PolicyCraft adds a feedback loop where the generated draft is automatically validated against an internal compliance knowledge graph; mismatches trigger a self‑correcting prompt that iteratively refines the text until a confidence score above 92 % is achieved.

Real-World Engineering Examples

A fintech startup integrated PrivacyGPT via its CI/CD pipeline; each pull request that modifies data‑collection code triggers an API call that updates the “Data Retention” clause, keeping the public policy in sync with code changes.
A multinational e‑commerce platform deployed PolicyCraft to generate locale‑specific consent banners; the system produced 27 variants in under five minutes, each certified against the EU’s Digital Services Act.

Zero‑Trust Architecture for Rule Enforcement

Zero‑trust architecture (ZTA) starts from the assumption that no network segment—whether on‑prem, cloud, or edge—can be implicitly trusted. Instead of a perimeter, every request is evaluated against a continuously refreshed identity profile that fuses user credentials, device posture, and behavioral risk scores. In practice, this means deploying a Policy Decision Point (PDP) that consumes attributes from an identity provider, a device‑trust service, and a telemetry bus, then returns an allow/deny decision in real time. The decision is enforced by a Policy Enforcement Point (PEP) embedded in the data plane—e.g., a sidecar proxy, a firewall rule, or a service‑mesh gateway—so that the same rule is applied whether the traffic originates from a laptop on a public Wi‑Fi or a container inside a Kubernetes pod.

Micro‑segmentation refines ZTA by carving the attack surface into least‑privilege zones that align with business domains. Using a service‑mesh control plane, each micro‑service advertises its required inbound and outbound intents as declarative policies. The mesh’s sidecar proxies terminate mutual TLS, inject identity headers, and consult the PDP before any payload leaves the enclave. This approach guarantees that even if a compromised workload obtains network access, it cannot reach data stores or other services without a matching intent. The result is end‑to‑end enforcement of privacy rules at every hop, eliminating the “trusted internal network” loophole that historically caused data leaks.

Deep Dive Architecture

PDP‑PEP handshake: When a request arrives, the sidecar extracts the SPIFFE ID, queries the PDP via gRPC, and receives a signed policy token. The token includes a TTL, required scopes, and a cryptographic hash of the request path. The sidecar validates the token locally, avoiding round‑trips for subsequent packets in the same flow.
Policy as code pipeline: Teams author policies in Rego (OPA) or CEL, store them in a GitOps repo, and use a CI/CD gate to run unit tests with simulated attribute sets. The compiled policies are shipped to the PDP runtime, enabling instant roll‑out without service restarts.

Real-World Engineering Examples

Google’s BeyondCorp Enterprise implements ZTA for all G‑Suite users, pushing identity verification to the edge and using Cloud Armor as a PEP for every API call.
Netflix’s open‑source Zuul 3.0 and the internal “Lattice” mesh enforce micro‑segmentation across its CDN edge nodes, ensuring that only authorized services can fetch subscriber metadata.

2025‑2026 Breach Metrics: Why Leaks Still Occur

The 2025 Verizon Data Breach Investigations Report logged 5,300 confirmed incidents, a 4 % rise over 2024, while IBM X‑Force’s 2025 Cost of a Data Breach study reported an average total cost of $4.45 million—up 3 % year‑over‑year. Notably, 71 % of those incidents were traced to human error, and 60 % involved cloud‑service misconfigurations, underscoring that compliance check‑lists alone no longer guarantee safety.

A deeper dive shows that the most common technical failures are insecure default settings, missing encryption keys, and unpatched third‑party libraries. On the human side, credential‑stuffing, phishing, and privileged‑account abuse account for the bulk of accidental disclosures. The convergence of these factors explains why organizations that rigorously document privacy rules still ship leaks.

Deep Dive Architecture

DBIR 2025 aggregates data from 70 % of Fortune 500 firms, providing a statistically significant view of breach vectors across sectors. X‑Force augments this with cost modeling that isolates direct remediation, regulatory fines, and reputational impact.
Correlation analysis across the two reports shows a 0.68 Pearson coefficient between the frequency of cloud misconfigurations and overall breach cost, indicating that each misconfiguration adds roughly $150k to the incident’s financial footprint.

Real-World Engineering Examples

Capital One’s 2025 AWS S3 bucket exposure, caused by an overlooked public ACL, resulted in 100 GB of customer data being scraped within hours.

Accenture’s 2026 insider leak, where a senior consultant inadvertently emailed a confidential client spreadsheet to the wrong distribution list, highlighting the persistent risk of human error even in highly trained teams.

Observability Platforms for Privacy Compliance

Modern privacy programs rely on observability pipelines that surface policy violations the moment data leaves a trusted boundary. OpenTelemetry provides a vendor‑agnostic telemetry SDK, while Splunk and the Elastic Stack supply powerful ingestion, indexing, and alerting layers that can correlate logs, traces, and metrics to detect GDPR or CCPA breaches in real time across multi‑cloud deployments.

By instrumenting services with OpenTelemetry and routing telemetry to Splunk or Elastic, security teams gain a unified view of who accessed what, when, and under which policy context. This enables automated compliance dashboards, anomaly‑driven alerts, and audit‑ready evidence without retroactive forensics, turning privacy compliance from a periodic audit into a continuous, observable control.

Deep Dive Architecture

OpenTelemetry Collector acts as a programmable edge: receivers ingest traces, logs, and metrics; processors can enrich or scrub PII; exporters forward to Splunk HEC or Elastic Beats. This decouples application code from vendor specifics and lets you swap back‑ends with a single YAML change.
Splunk’s Privacy Guard app and Elastic’s Security Solution both ship pre‑built rule sets that match on OpenTelemetry attributes. They support real‑time correlation across data streams, auto‑generation of GDPR‑required Data Subject Access Request (DSAR) logs, and integration with SOAR platforms for automated remediation.

Real-World Engineering Examples

At a fintech firm, the OpenTelemetry Collector filtered "account_number" fields with a SHA‑256 hash before sending logs to Splunk, where a Splunk SPL query flagged any access to "data.category=PII" without a matching "policy.id=GDPR-1" tag, triggering a PagerDuty incident within seconds.
A global e‑commerce retailer deployed Elastic APM agents with OpenTelemetry SDKs; Elastic Watcher rules detected anomalous read spikes on "user.email" fields from an unapproved IP range, automatically creating a case in Elastic Security and revoking the offending API key via a webhook.

LLM‑Assisted Code Comment Auditing

LLM‑assisted comment auditing injects a large‑language model into the developer workflow to scan natural‑language annotations for leakage of secrets, internal APIs, or privacy‑critical logic. By treating comments as first‑class code artifacts, tools such as CodeGuard AI query the model in real time during pull‑request analysis, flagging patterns that match a curated risk taxonomy.
The audit loop typically runs in CI/CD, where the LLM evaluates each diff, scores the comment against a confidence threshold, and either annotates the PR with a remediation suggestion or blocks the merge. Because the model is hosted on a secure, isolated inference endpoint, no raw source is transmitted to third‑party services, satisfying enterprise data‑sovereignty requirements.

Deep Dive Architecture

Model pipeline – the comment text is tokenized, passed through a 7‑billion‑parameter transformer that has been instruction‑tuned for data‑leak detection. The model outputs a risk vector (PII, credential, business‑logic) which is then mapped to policy rules defined in a YAML manifest.
Policy enforcement – each rule specifies a severity, a confidence cutoff, and an optional auto‑remediation script. When a comment exceeds the threshold, the CI step injects a review comment with a code‑action link that either redacts the offending text or suggests a placeholder .

Real-World Engineering Examples

At a mid‑size fintech, CodeGuard AI caught a developer comment that referenced a hard‑coded OAuth client ID, automatically replacing it with a placeholder and preventing a GDPR‑related breach.
An open‑source library using GitGuardian’s comment scanner discovered a stray “TODO: remove test key” note in the README, prompting a rapid upstream patch before the repository was cloned millions of times.

Secure CI/CD Pipelines with Privacy Gates

In modern regulated environments, privacy compliance cannot be an after‑thought. GDPR, CCPA, and emerging AI‑data statutes require that any personal data leaving source control be vetted before it reaches production. Embedding privacy gates directly into the CI/CD pipeline ensures that violations are caught at the earliest possible stage, reducing remediation cost and preventing costly data leaks. By treating privacy as a first‑class quality gate—on par with unit tests and linting—organizations shift risk left, automate evidence collection for auditors, and create a repeatable “privacy‑as‑code” posture that scales across dozens of micro‑services and repositories.

GitHub Advanced Security (GHAS) provides native secret scanning, code‑QL‑based data‑flow analysis, and custom policy bundles that can flag PII patterns in pull requests. When paired with a GitOps engine like Argo CD, the pipeline can enforce those findings as deployment blockers. Argo CD’s integration with Open Policy Agent (OPA) Gatekeeper lets teams codify privacy rules as Rego policies that evaluate Helm values, Kubernetes manifests, and even container images before they are applied. The result is a seamless, automated gate: a PR that passes GHAS scans proceeds to Argo CD, which then validates the manifest against OPA policies; any violation aborts the sync and raises a ticket for remediation.

Deep Dive Architecture

GitHub secret scanning can be extended with a .github/secret-scanning.yml file that defines regexes for proprietary identifiers, ensuring that even custom data formats are caught at PR time.
Argo CD uses an OPA ConstraintTemplate that inspects Helm values for fields named email, ssn, or dob and rejects any manifest where those fields are hard‑coded instead of sourced from a sealed‑secret.

Real-World Engineering Examples

A fintech startup integrated GHAS with a custom regex for IBAN numbers. Every pull request that introduced a new account‑number literal was automatically marked with a “privacy‑violation” label, preventing accidental exposure of customer banking data.
A telehealth provider deployed an Argo CD Application that referenced a ConstraintTemplate enforcing that any Kubernetes Secret of type Opaque must contain only base64‑encoded references to HashiCorp Vault secrets, eliminating plaintext credential leaks during Helm releases.

Viral Leak Case Studies and Their Tech Stacks

High‑profile leaks in 2026 have exposed how modern cloud‑native stacks can become attack surfaces when privacy rules are enforced only on paper.
By dissecting the architectures behind the ChatChain AI breach, the FinTechX transaction dump, and the MetaVerse VR exposure, we can extract concrete safeguards for any organization.

Deep Dive Architecture

The ChatChain breach leveraged a misconfigured AWS S3 bucket combined with an over‑privileged IAM role provisioned via Terraform, allowing a scraped API key to enumerate all user embeddings.
FinTechX’s leak originated from a Kafka Connect sink that wrote raw transaction logs to an unsecured Azure Blob container, bypassing their GDPR masking layer because the connector’s schema registry was outdated.

Real-World Engineering Examples

ChatChain AI (March 2026) – 12 TB of conversational embeddings exposed due to a missing bucket policy; the stack included Kubernetes, Istio, Terraform, and S3.
FinTechX (July 2026) – Real‑time transaction stream leaked to the public internet; stack comprised Confluent Kafka, Azure Event Hubs, Snowflake, and a custom Python ETL runner.

RegTech Platforms Dominating 2026

The compliance market in 2026 is concentrated around a few mature SaaS suites—OneTrust and TrustArc—while a wave of open‑source frameworks such as OPA‑Compliance and OpenReg are gaining traction among privacy‑by‑design teams. Vendors now bundle AI‑driven rule extraction, automated data‑map discovery, and real‑time enforcement hooks that can be invoked directly from CI/CD pipelines.

Open‑source alternatives differentiate themselves through extensibility: policy logic lives in declarative languages (Rego, CEL) and can be version‑controlled alongside code, enabling immutable compliance-as‑code. However, they require in‑house expertise to manage policy lifecycle, audit trails, and jurisdiction‑specific rule sets, which the commercial platforms abstract away with managed rule libraries and regulatory calendars.

Deep Dive Architecture

OneTrust’s Enforcement Engine now supports webhook triggers that push violation events to a Kafka topic, allowing downstream micro‑services to abort processing before PII leaves the trust boundary.
TrustArc introduced a policy‑as‑code SDK that compiles its proprietary rule DSL into Open Policy Agent bundles, giving customers the flexibility to run the same logic on‑premise or in edge devices.

Real-World Engineering Examples

A global fintech integrated OneTrust’s webhook with its fraud‑detection pipeline, automatically flagging and quarantining any transaction that matched a newly added cross‑border data‑transfer rule within seconds.
A health‑tech startup adopted OPA‑Compliance, storing all privacy rules in a GitOps repo; a nightly CI job regenerated policy bundles and performed a drift check against the regulatory catalog, cutting audit prep time by 70 %.

*Data Masking, Tokenization, and Synthetic Data
*
Modern masking engines have evolved from static column‑level redaction to context‑aware, on‑the‑fly transformation pipelines. In 2026, solutions such as Delphix Dynamic Data Platform and IBM Guardium Data Masking embed a policy engine that evaluates the requester’s role, query intent, and data sensitivity tags before applying reversible tokenization, format‑preserving encryption, or deterministic masking. The token vault lives behind a hardened micro‑service, exposing only opaque identifiers while preserving referential integrity for downstream analytics. Because the transformation occurs at the data‑access layer, production workloads remain untouched and compliance audits can verify that no raw PII ever leaves the protected zone.

Synthetic data generators now complement masking by creating entirely artificial records that retain statistical properties of the source. Model‑based approaches—e.g., GAN‑driven tools from Mostly AI or the open‑source SDV library—train on masked datasets, then emit rows that are provably non‑identifiable under differential privacy budgets. This enables developers to spin up full‑scale dev/test environments, run AI pipelines, or share data with partners without exposing any real customer attributes. When a breach occurs, the leaked artifact is either a reversible token (which can be revoked instantly) or a synthetic record that offers no direct re‑identification path, dramatically shrinking the blast radius.

Deep Dive Architecture

Token vaults are typically backed by a distributed ledger (e.g., Apache Cassandra with Raft consensus) that guarantees tamper‑evidence and high availability. Each token request triggers a lookup that returns a format‑preserving token, allowing downstream systems to continue using legacy schemas without code changes.
Synthetic generators must balance fidelity and privacy. Setting a differential privacy epsilon between 0.1 and 0.5 yields data that mirrors marginal distributions while ensuring the probability of re‑identifying any individual stays below regulatory thresholds (e.g., GDPR’s ‘reasonable likelihood’ test).

Real-World Engineering Examples

A major North American bank integrated Guardium Dynamic Data Masking into its API gateway. When a misconfigured endpoint exposed transaction logs, the leaked payload contained only tokenized account numbers that were revoked within minutes, preventing fraud.
A telehealth startup adopted Mostly AI’s synthetic patient dataset to train a diagnostic model. After a cloud storage breach, the attacker obtained 1.2 M synthetic records; a post‑mortem showed zero overlap with real patient identifiers, satisfying HIPAA’s de‑identification rule.

Decentralized Identity & Self‑Sovereign Data Governance

The emerging wave of Self‑Sovereign Identity (SSI) frameworks—DIDs, Verifiable Credentials (VCs) and associated registries—offers a cryptographic enforcement layer that can embed privacy rules directly into the identity fabric. By shifting control of personal data from siloed platforms to the user’s wallet, regulators can mandate consent, purpose limitation, and revocation at the protocol level, making non‑compliant leaks technically impossible without breaking the chain of trust.

As 2026 sees widespread adoption of DID methods (did:web, did:ion, did:key) across cloud providers, fintech, and health ecosystems, privacy‑by‑design becomes a built‑in feature rather than an after‑the‑fact audit. Enterprises can now encode GDPR‑style obligations into credential schemas, and automated policy engines can verify compliance before any data exchange occurs, turning privacy enforcement into a real‑time, decentralized transaction.

Deep Dive Architecture

A DID Document contains public keys, service endpoints, and authentication methods that are signed by the controller’s private key. When a holder presents a VC, the verifier resolves the DID, validates the signature chain, and evaluates any embedded privacy policies expressed in JSON‑LD using the W3C Data Privacy Vocabulary (DPV). This enables automated enforcement of consent scopes, expiration, and revocation without human intervention.
SSI ecosystems integrate with decentralized storage (IPFS, Ceramic) to host encrypted credential payloads. The holder retains decryption keys, and the issuer can rotate keys or revoke credentials by publishing a revocation bitmap to the ledger, which verifiers must check in real time. This model eliminates centralized data lakes that are typical sources of leaks.

Conclusion & Next Steps

The incident began with a well‑intentioned privacy rule designed to block any export of personally identifiable information. After writing the rule, the team enforced it through automated tests and added extensive comments to document its purpose, believing the safeguard was airtight.
However, a later performance‑driven change introduced a shortcut that inadvertently disabled the rule in the release branch. The oversight slipped through code review, and the build was shipped, exposing user data to external services. This highlights how even documented safeguards can be nullified by unchecked merges or rushed deployments.
To prevent repeat occurrences, organizations must couple static rule enforcement with continuous monitoring, enforce merge‑gate policies, and treat privacy controls as immutable code. Regular audits, automated policy validation, and a culture that prioritises security over speed are essential to protect user trust.

Found this deep-dive helpful? Explore more architecture breakdowns, engineering tutorials, and tech insights over at my platform:

🔗 TechPulse

Building and scaling software architectures, one blueprint at a time.

Your AI makes decisions. We make sure every data move obeys the law. Try the demo at viradotech.com and give us your honest take.

virgiljunioradoleyine-stack — Sat, 22 Aug 2026 16:38:09 +0000

Puppet Core 9.0 and 8.21 Released: Ruby 4.0, OpenSSL 3.5, Platform Changes, and Security Hardening

Jason St-Cyr — Thu, 20 Aug 2026 15:26:21 +0000

Did you know there's a new major version in town for Puppet Core? You might have heard about it through the grapevine or in the Are You Ready for Puppet 9? webinar that @gpatton and I recently hosted. The wait is over and Puppet Core 9.0.0 is now available alongside Puppet Core 8.21.0.

Puppet Core 9 introduces significant runtime and platform changes, moving to Ruby 4.0, OpenSSL 3.5, and other changes, but the essential Puppet under the hood is largely unchanged from Puppet 8. The majority of upgrade effort will center on Ruby 4 compatibility and runtime dependency changes rather than Puppet language changes.

If you are staying on the Puppet Core 8.x release track, the latest Puppet Core 8.21 delivers the basic support fixes and security improvements you might need without the major dependency changes found in Puppet Core 9.

What matters most for the admins

Before upgrading to Puppet Core 9:

Test custom facts, functions, types, and providers against Ruby 4.0.
Validate any Forge modules you use for Ruby 4 compatibility.
Review integrations that depend on OpenSSL behavior.
Verify any workflows that still rely on SHA-1.
Confirm managed nodes are running supported operating systems.
Review any custom code that depends on PSON or multi_json.
Check deferred function behavior if you have custom types or providers.

Perforce will be rolling out updates to Puppetlabs modules on the Forge based on their priority tier and dependencies. The first batch of these should be rolling out soon.

Puppet Core 9.0 highlights

These are a few highlights I pulled from the release notes. Make sure to reference the full 9.0 release notes to get all the details about what has changed!

Ruby updated to 4.0.5: With a new Ruby baseline some deprecated syntax from older Ruby versions will no longer be compatible. This is the primary focus area for upgrades as you will want to validate your custom code and modules. The latest PDK 3.8.0 introduced some Ruby 4 validators to help you update your syntax while you are still on Puppet Core 8, before upgrading to Puppet Core 9.
OpenSSL updated to 3.5.7: This lays the groundwork for supporting post-quantum cryptography (PQC) and moves to TLS 1.3 as the default protocol version. This upgrade will resolve several OpenSSL-related CVEs.
Puppet Server has updated baseline components: As part of the move to JRuby 10.1, Puppet Server is now updated to require minimum JDK 21. The embedded web server is now using Jetty 12.
PSON support removed: You will need to migrate to a supported data format if your code has relied on PSON.
Deferred functions return to Puppet 7 behavior: While Puppet Core 9 largely keeps the same underlying behavior as Puppet Core 8.x, there is one change worth noting about deferred functions. In older versions (like Puppet 7), preprocess_deferred was enabled by default, but this was disabled by default in Puppet 8. In Puppet Core 9, preprocess_deferred is now enabled by default again.
UTF-8 encoding now used on Windows: Puppet Core now uses UTF-8 as the default external encoding on Windows. You will want to look for any configuration files encoded in non-UTF-8 before upgrading.

These are just some highlights I pulled from the full list, I really recommend taking a look at the release notes to get a full picture.

Security hardening

Both the 9.0 and 8.21 releases contain security-related fixes.

Stricter SSH key validation: Puppet now rejects malformed SSH keys that previously passed validation. This includes invalid inputs such as embedded newline characters. The goal is to prevent unsafe content from being written to managed files.
Improved autoloader validation: The puppet resource command now performs stricter validation of autoloader inputs. This change helps prevent unintended code loading through user-controlled values.
curl updated to 8.21.0: Both Puppet Core 9.0 and Puppet Core 8.21 update curl from 8.20.0 to 8.21.0. The update addresses numerous curl CVEs.

Admins who track dependency risk should review the release notes for the complete CVE list:

Platform updates

New agent platforms

The following agent platforms are now supported in both Puppet Core 9.0 and 8.21:

Rocky Linux 10 (x86_64)
Alma Linux 10 (x86_64)

Operating systems removed from support

Several end-of-life operating systems have been removed: Debian 10, macOS 13, RHEL 7, Ubuntu 18.04 and 20.04, and others.

The official full list is in the docs. The list in this article is not complete, so make sure to reference those notes to check your systems!

If you need to keep using a platform that has been removed you should know there is an extended support option. Migrating to a more modern OS is likely the best path, but if you can't migrate just yet, make sure to reach out to the team to get help with extended platform support

Upgrade resources

Before moving to Puppet Core 9, review the official upgrade documentation and release notes:

Make sure to start your Puppet Core 9 compatibility testing early and send over any questions as you encounter issues so that the team can help!

Why Healthcare Software Needs a Different QA Bar Than Everything Else You've Built

Ayushi Kumari — Tue, 18 Aug 2026 06:56:13 +0000

Most engineers carry an intuitive sense of "good enough" QA from whatever domain they cut their teeth in — e-commerce, SaaS dashboards, internal tools. That instinct is dangerous the moment it gets applied unchanged to healthcare software, where the cost of a subtle bug isn't a support ticket or a refund. It can be a missed medication interaction, a delayed diagnosis, or a compliance violation with real legal consequences.

Here's what actually has to change.

The Failure Modes Are Categorically Different

In a typical SaaS product, a bug that shows a stale number on a dashboard is annoying. In a system tracking medication dosages, a stale or incorrectly calculated number can directly affect patient safety. The same class of bug — a caching issue, a rounding error, a race condition in concurrent writes — carries a wildly different severity depending on what data it touches.

This means healthcare QA can't treat all features equally. A cosmetic UI bug on a marketing page and a calculation bug in a dosage calculator are not the same priority tier, even if they'd be treated similarly in a typical product backlog.

Edge Cases Aren't Edge Cases — They're Tuesday

Healthcare data is messier than most systems are designed to expect. Patient records have missing fields because the information genuinely wasn't available at intake. Names have characters that break naive string validation. A single patient might have multiple records that need to be reconciled, or duplicate entries that shouldn't be merged automatically. What would be a rare edge case in a typical CRUD app is routine, everyday data in a clinical system.

QA for healthcare software has to actively hunt for these patterns rather than treating them as improbable inputs unlikely to matter — because in this domain, they're the normal case, not the exception.

Compliance Isn't a Separate Checklist — It's a Testing Requirement

HIPAA (or equivalent regional regulations) isn't just a legal document to review once during planning. It has direct, testable implications: who can access which records, how access is logged, how long data is retained, what happens when a record needs to be permanently deleted versus archived. These aren't features to build and forget — they're behaviors that need explicit test coverage, the same way a payment flow needs test coverage for its critical paths.

A permissions bug that lets the wrong role view a patient record isn't a minor defect in this context. It's a reportable incident with real regulatory consequences, which changes how much test coverage that logic actually deserves relative to a typical feature.

Concurrency Bugs Have Higher Stakes

Multiple clinicians updating the same patient record simultaneously — a nurse logging vitals while a doctor updates a treatment plan — is a routine occurrence in clinical settings, not a rare race condition. Systems that haven't been explicitly tested for concurrent writes to the same record can silently lose or overwrite critical updates, and because the failure is silent, it might not surface until someone notices a treatment plan doesn't match what was actually decided.

This makes concurrency testing a first-class requirement rather than something addressed only if it happens to surface during normal testing.

Audit Trails Need Their Own Test Suite

Beyond the primary feature working correctly, healthcare systems typically need to prove who did what, when — an audit trail robust enough to hold up under regulatory review. It's not enough for the audit log to usually capture changes; gaps in the audit trail can themselves become a compliance finding, independent of whether the underlying feature worked correctly. This means the audit logging mechanism needs dedicated test coverage, not an assumption that it'll work because the primary code path was thoroughly tested.

A Practical Shift in QA Priorities

Compared to a typical SaaS QA process, healthcare software QA generally needs:

Explicit test coverage for permission boundaries, not just functional correctness
Deliberate testing of messy, incomplete, and duplicate data, treated as the expected case rather than an edge case
Concurrency testing on any record multiple roles can update simultaneously
Dedicated tests for audit trail completeness, separate from tests of the feature the audit trail is logging
A severity framework that weights patient-safety-adjacent bugs above cosmetic or convenience bugs, even when they'd rank similarly by engineering complexity alone

The Takeaway

The technical skills required for healthcare software aren't fundamentally different from any other domain — the discipline around testing priorities and failure-mode awareness is what actually shifts. Teams that bring a generic SaaS QA mindset into healthcare software tend to catch the bugs that would matter anywhere and miss the ones that matter specifically because of what's at stake here. Getting this right usually means building with a development partner that's specifically experienced in healthcare software, not just competent engineering applied without domain context.

Anchor text used above: "a development partner that's specifically experienced in healthcare software" → links to https://www.weboraz.com/industries/healthcare

PDK 3.8.0 now has Ruby validation to prepare for Puppet 9!

Jason St-Cyr — Tue, 11 Aug 2026 12:53:45 +0000

A new release is out for the Puppet Development Kit and it has some new additions like Debian 13 support, some security-related updates, and some new validation for Ruby syntax to help you get yourself ready for Puppet Core 9!

The next releases of Puppet Core 9 and Puppet Enterprise 2026, due out soon, will be moving to Ruby 4. To help you get ready, you can start using this new version of PDK on your Puppet 8 installation to look for areas that might need updates.

When you run pdk validate, it can now identify changes you can make that will be safe to run on Puppet 8, but also will prepare your codebase for Puppet Core 9:

Code that uses legacy Ruby Hash#inspect formatting, for example {:x=>1, "baz"=>3} . Legacy formatting can cause module code to fail after you upgrade to Puppet Core 9.
Ruby 4 syntax compatibility checks.
The Security/Open Rubocop flags Ruby patterns associated with Kernel#open and IO.open invocation that are no longer valid in Ruby 4.

Once Puppet Core 9 is out, you'll be able to do additional validation, but this should help you get started finding those places where the syntax might need some updates.

Full release notes: https://help.puppet.com/pdk/current/topics/release_notes_pdk.htm#PDK380

Download PDK: https://forge.puppet.com/resources/pdk

Vox Pupuli Container Statistics

Robert Waffen — Sat, 08 Aug 2026 11:13:05 +0000

Hello everyone!
I am excited to share some updates regarding container statistics.

We now have a page where we display the statistics for all our containers.
You can find it at https://voxpupuli.org/container_statistics/.

It is built from https://github.com/voxpupuli/container_statistics and is updated every 24 hours.

Getting the Downloads

For the download count, it scrapes the package HTML pages for the containers.
Sadly, this does not work with GraphQL or the API, so we have to use the HTML pages for now.
GraphQL and the API do expose a download count, but it is only for GitHub's legacy container system and not for ghcr.io ¯\_(ツ)_/¯.
If someone has an idea for a better way to get the download count from ghcr.io, please let me know.
The API is not very talkative about this :/

Getting the CVEs

For CVEs, we run two scanners: the wildly popular Trivy scanner and Grype from Anchore.
Both are run against the latest version of each container, and the results are displayed on the statistics page.
For Grype, we downplay the nvd/cpe entries, as they tend to be false positives.
They are still displayed, but specifically marked as nvd/cpe entries, so you can filter them out if you want to.

How the statistics are generated

The statistics can be generated by running the bin/container-statistics script in the container_statistics repository.
It needs a configuration file, which is located in the config directory.

---
containers:
  - name: openvoxproject/openbolt
    registry: ghcr.io
    tags:
      - latest
  - name: openvoxproject/openvoxagent
    registry: ghcr.io
    tags:
      - latest

We run it in GitHub Actions and push the results to the gh-pages branch, which is then displayed on the statistics page.
Scanning is also done in GitHub Actions.
The whole process is automated and runs every 24 hours, so the statistics are always up to date.
See the GitHub Actions workflow in the container_statistics repository (.github/workflows/container-statistics.yml) for more details.

You can run it locally and generate the statistics yourself.
You will need to have the scanners installed and available in your path.

CLI Commands

bin/container-statistics --download-report

This will display the downloads for all containers in a table format.
This will live-scrape the HTML pages for the containers, so it might take a while to run.

bin/container-statistics --download-report

CONTAINER                             TOTAL DOWNLOADS
------------------------------------  ---------------
ghcr.io/openvoxproject/openbolt                 1,504
ghcr.io/openvoxproject/openvoxagent            11,814
ghcr.io/openvoxproject/openvoxdb              157,774
ghcr.io/openvoxproject/openvoxserver          151,344
ghcr.io/voxpupuli/commitlint                      756
ghcr.io/voxpupuli/onceover                      4,248
ghcr.io/voxpupuli/r10k-webhook                  7,738
ghcr.io/voxpupuli/r10k                         22,548
ghcr.io/voxpupuli/renovate                      5,551
ghcr.io/voxpupuli/semantic-release              7,870
ghcr.io/voxpupuli/voxbox                      131,841

bin/container-statistics --cve-report

This will display the CVEs for all containers in a table format.
It depends on the scanners being installed and having been run at least once, so that the results are available in the cache.

bin/container-statistics --cve-report
CONTAINER                                           CRITICAL  HIGH  MEDIUM  LOW  UNKNOWN  TOTAL
--------------------------------------------------  --------  ----  ------  ---  -------  -----
ghcr.io/openvoxproject/openbolt:latest                     1     4       2    1        -      8
ghcr.io/openvoxproject/openvoxagent:latest                 -     7      58    7        2     74
ghcr.io/openvoxproject/openvoxdb:latest                    -     6      79    9        2     96
ghcr.io/openvoxproject/openvoxdb:latest-alpine             -     1       -    -        -      1
ghcr.io/openvoxproject/openvoxserver:latest                2    49     634  100        4    789
ghcr.io/openvoxproject/openvoxserver:latest-alpine         -     1       -    -        -      1
ghcr.io/voxpupuli/commitlint:latest                        1     6       5    2        -     14
ghcr.io/voxpupuli/onceover:latest                          1     4       2    1        -      8
ghcr.io/voxpupuli/r10k-webhook:latest                      3    41      35    2        7     88
ghcr.io/voxpupuli/r10k:latest                              -     8       5    -        1     14
ghcr.io/voxpupuli/renovate:latest                          -     1       -    -        -      1
ghcr.io/voxpupuli/semantic-release:latest                  1     6       8    2        -     17
ghcr.io/voxpupuli/voxbox:latest                            -     -       -    -        -      -

First published at: https://voxpupuli.org/blog/2026/08/07/container-statistics/

Puppetlabs Modules Roundup - July 2026

Jason St-Cyr — Thu, 06 Aug 2026 12:19:41 +0000

July 2026 brought 17 Puppetlabs module releases, headlined by a fairly large Continuous Delivery release. cd4peadm 5.16.0 added external PostgreSQL database support and a configurable image pull policy, and closes 11 CVEs, alongside a breaking change to commit status contexts. More modules dropped Puppet 7 support, some others picked up stdlib 10, and Windows Server 2025 support started rolling out into the modules. This roundup pulls the most important changes into one place.

Highlighted Updates

Continuous Delivery Adds External Databases, Configurable Image Pull Policies, and Closes 11 CVEs

cd4peadm 5.16.0 is the biggest release of the month. It adds support for pointing Continuous Delivery at an externally managed PostgreSQL database. That could be a self-managed instance, Amazon RDS for PostgreSQL, or Amazon Aurora. This externally managed db can be used instead of the database CD manages internally, giving operators control over durability, backups, and high availability. It also adds a configurable image_pull_policy option for job templates (Always/IfNotPresent/Never) and removes the docker.io fallback when using Podman; the matching cd4pe_jobs 1.7.4 release adds the same task parameter and fallback removal, so upgrade both together.

BREAKING: Commit status contexts now include the pipeline name (cd-pe/<pipelineName>/stage-<N> instead of cd-pe/stage-<N>). Review any branch protection rules or required status checks that reference the old format.
This release also closed 11 CVEs across opentelemetry, NGINX, jetty, jackson, log4j, postgresql, golang.org/x/sys, and react-router.

Puppet 7 Support Dropped

Five modules dropped Puppet 7 support in major version bumps:

haproxy, iis, mount_iso, scheduled_task, sslcertificate.

There were all released as major version bumps to ensure that users still working on upgrading from Puppet 7 can stay pinned on the previous major version releases.

In related news, postgresql 10.6.3 restored the Puppet 7 support that 10.6.2 broke in a previous release; see its entry below.

stdlib 10.x Rollout Continues

Following June's stdlib 10.x rollout, four more modules now allow the puppetlabs-stdlib dependency to move to 10.x: haproxy, mount_iso, puppet_authorization, and sslcertificate. haproxy also widens its concat constraint to 10.x.

Affected modules: haproxy, mount_iso, puppet_authorization, sslcertificate.

Windows Server 2025 Support Added

Three Windows-focused modules added support for Windows Server 2025 this month: scheduled_task, windows_env, and windows_eventlog. These now all run acceptance testing against the 2025 version of the OS, in addition to other supported Windows versions.

What Updates Happened to Puppetlabs Modules in July 2026?

The following is an alphabetical listing of modules which received updates in July 2026. If a module had multiple versions released, the updates are collected together, numbered with the "latest" version available.

apache 13.3.0

📅 Latest release: 2026-07-23 (🌐 View on the Forge)

Added OWASP CRS v4 support on modern Enterprise Linux (EL10) while preserving existing EL7/8/9 behaviour.

(MODULES-11857) Scaffold OWASP CRS v4 support on EL10 via crs_source enum #2637 (SugatD)

cd4pe_jobs 1.7.4

📅 Latest release: 2026-07-28 (🌐 View on the Forge)

Adds the same configurable image_pull_policy task parameter and Podman fallback removal shipping in cd4peadm 5.16.0 — upgrade both together to get matching behavior.

A new optional image_pull_policy task parameter controls whether the container image is pulled before a job runs: Always (the default, and the previous behavior) pulls on every run; IfNotPresent pulls only when the image is absent from the local runtime; Never skips the pull entirely and relies on the locally present image. Presence is checked with docker image inspect / podman image exists. Omitting the parameter keeps the existing pull-every-run behavior.
The module no longer retries a failed image pull against docker.io. Image names are now pulled exactly as given. If you rely on unqualified image names (e.g. nginx, myuser/myimage) on a Podman host, add docker.io to unqualified-search-registries in registries.conf, or use a fully-qualified name.

cd4peadm 5.16.0

📅 Latest release: 2026-07-29 (🌐 View on the Forge)

The changes this month added external PostgreSQL database support, a configurable image pull policy, source control token management improvements, and closed 11 CVEs. There is also a breaking change to commit status contexts — see below (and the linked release notes).

Added support for external databases. You can now point Continuous Delivery at a PostgreSQL instance you operate yourself, Amazon RDS for PostgreSQL, Amazon Aurora (PostgreSQL-compatible), or a self-managed PostgreSQL server, instead of the database CD manages for you. This gives you control over durability, backups, and high availability. You can configure external mode on a fresh install or migrate an existing managed install.
Added a feature to Continuous Delivery job templates so you can set an image pull policy per job (Always, IfNotPresent, or Never). In an air-gapped environment, for example, setting the policy to Never stops Continuous Delivery's attempts to reach out to the internet for the image.
Updated the Source Control settings page to show when a configured Personal Access Token (PAT) expires on each connected GitHub, GitHub Enterprise, and GitLab integration card. Tokens that have already expired or will expire within 30 days are clearly flagged so you can renew them before they cause failures.
BREAKING: Commit status contexts now include the pipeline name (cd-pe/<pipelineName>/stage-<N> instead of cd-pe/stage-<N>), which prevents collisions when multiple pipelines report status for the same commit. Review any branch protection rules or required status checks that reference the old format.
11 CVEs addressed, including opentelemetry, NGINX, jetty, jackson, log4j, postgresql, golang.org/x/sys, and react-router.

Check the official release notes for cd4peadm 5.16.0 for the full details.

comply 3.8.1

📅 Latest release: 2026-07-03 (🌐 View on the Forge)

A Security Compliance Management maintenance release that did not have any new CVE fixes this time and was mostly operational and licensing improvements.

Increased the CIS-CAT Pro Assessor license expiry time; licenses are now good for a full year.
Added a license_path parameter to update the CIS-CAT Pro Assessor license without upgrading SCM.
Added an assessor_scan_timeout option to control the task timeout for Windows 2022 domain controllers.
Added a background scan sweeper that detects and cancels scans stuck in a "running" state.
Increased the default Max graphql requests limit to 300 requests per window; use the complyadm::configure Bolt plan to customize.

Check the official release notes for comply 3.8.1 for the full details.

haproxy 9.1.0

📅 Latest release: 2026-07-28 (🌐 View on the Forge)

Two releases this month: 9.0.0 dropped Puppet 7 support (BREAKING) and added cache resource support, while 9.1.0 removed a sensitive-data workaround and allows both stdlib and concat to move to their 10.x releases.

Includes monthly releases: 9.1.0 (2026-07-28), 9.0.0 (2026-07-20).

Eliminate Workaround for Sensitive Data; raises minimum puppetlabs/concat requirement to 7.4.0 #607 (cocker-cc)
Add support for running programs #604 (deric)
Pass install_options to package installer #603 (deric)
examples: disable default stats listener #640 (bastelfreak)
make picking haproxy::globals::sort_options_alphabetic work #573 (trefzer)
Remove Puppet 7 support (BREAKING); the module now requires puppet >= 8.0.0 < 9.0.0 #631 (gavindidrichsen)
Add support for cache resource, extra backend options, and docs #626 (matejzero)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #642 (imaqsood)
Allow puppetlabs/concat 10.x #641 (bastelfreak)
dependency: create mapfile before configfile #572 (trefzer)

iis 11.0.0

📅 Latest release: 2026-07-01 (🌐 View on the Forge)

Dropped Puppet 7 support (BREAKING) as part of ongoing modernization efforts, and marked the iis_application_pool password parameter as sensitive so it no longer leaks into Puppet reports.

(CAT-2374) Puppet Core update (BREAKING) — drops Puppet 7 support #414 (LukasAud)
(MODULES-11595) Mark iis_application_pool password as sensitive to stop report leak #418 (imaqsood)

mount_iso 5.0.0

📅 Latest release: 2026-07-22 (🌐 View on the Forge)

Dropped Puppet 7 support (BREAKING) and allowed the stdlib dependency to move to 10.x.

(CAT-2380) Update for Puppet Core / Drop Support for Puppet 7 (BREAKING) #58 (david22swan)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #59 (imaqsood)

mysql 17.1.0

📅 Latest release: 2026-07-02 (🌐 View on the Forge)

This month was a small update but important as RHEL 10 support was added.

(MODULES-11802) Add support for RHEL 10 #1712 (skyamgarp)

node_encrypt 3.2.0

📅 Latest release: 2026-07-22 (🌐 View on the Forge)

Adds Ubuntu 24 and Debian 12 support, and upgrades rexml to address a CVE.

(CAT-2124) Add support for Ubuntu 24 #120 (skyamgarp)
(CAT-2100) Add Debian 12 support #119 (shubhamshinde360)
(CAT-2158) Upgrade rexml to address CVE-2024-49761 #121 (amitkarsale)

peadm 3.38.1

📅 Latest release: 2026-07-08 (🌐 View on the Forge)

Restores public-schema privileges on PostgreSQL 15+ in restore.pp, fixing a bug that could affect PE restores on newer PostgreSQL versions.

(PE-44867) Restore public-schema privileges on PostgreSQL 15+ in restore.pp #676 (CharithaDunuwille)

postgresql 10.6.3

📅 Latest release: 2026-07-07 (🌐 View on the Forge)

Restores Puppet 7 support that was unintentionally dropped in the 10.6.2 patch release last month.

NOTE: As flagged in June's roundup, the Puppet 7 removal in 10.6.2 shipped in a patch release rather than a major one. 10.6.3 restores Puppet 7 support; the removal will happen again, correctly, in a future major release.

(MODULES-11858) Restore Puppet 7 support broken by 10.6.2 #1686 (imaqsood)

puppet_authorization 1.0.1

📅 Latest release: 2026-07-21 (🌐 View on the Forge)

A maintenance release: allows both the stdlib and concat dependencies to move to 10.x, tweaks a CI workflow flag, and adds a LICENSE file.

Change flag option in CI workflow #56 (zaben903)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #57 (imaqsood)
puppetlabs/concat: Allow 10.x #55 (bastelfreak)
Create LICENSE #52 (binford2k)

sce_linux 2.8.0

📅 Latest release: 2026-07-28 (🌐 View on the Forge)

Updates CIS Benchmarks from v3.0.0 to v4.0.0 for RHEL 8, AlmaLinux 8, and Oracle Linux 8, with matching control updates for each, and fixes three bugs affecting benchmark enforcement.

Updated CIS Benchmarks. RHEL 8, AlmaLinux 8, and Oracle Linux 8 move from CIS Benchmark v3.0.0 to v4.0.0, with matching control updates for each operating system.
Updated dependency. SCE for Linux now supports puppetlabs-stdlib >= 9.2.0 < 11.0.0; avoid using earlier stdlib versions.
Fixed: the user-specified default_zone setting was not enforced for CIS control 3.4.1.2; it is now enforced correctly.
Fixed: aide --init failed on RHEL/AlmaLinux/Oracle Linux/Rocky Linux 8 hosts shipping AIDE 0.17.x, which renamed the database= directive to database_in=.
Fixed: CIS control 6.2.2.2 (journald log-forwarding) did not work as designed on RHEL/AlmaLinux/Oracle Linux/Rocky Linux 9 and 10; control 6.2.3.3 was also added.

Check the official release notes for sce_linux 2.8.0 for the full details.

scheduled_task 5.0.0

📅 Latest release: 2026-07-13 (🌐 View on the Forge)

Drops Puppet 7 support (BREAKING) and also adds Windows Server 2025 support.

(CAT-2391) Puppet Core upgrade (BREAKING) — drops Puppet 7 support #271 (LukasAud)
[MODULES-11616] Adding Windows 2025 support to module #275 (jst-cyr)
Update link to contributing documentation #273 (jst-cyr)

sslcertificate 6.0.0

📅 Latest release: 2026-07-22 (🌐 View on the Forge)

Drops Puppet 7 support (BREAKING) and allows the stdlib dependency to move to 10.x.

(CAT-2394) Puppet Core update (BREAKING) — drops Puppet 7 support #142 (LukasAud)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #143 (imaqsood)

windows_env 6.1.0

📅 Latest release: 2026-07-21 (🌐 View on the Forge)

Adds Windows Server 2025 support.

(MODULES-11891) Add Windows Server 2025 support #115 (imaqsood)

windows_eventlog 5.1.0

📅 Latest release: 2026-07-22 (🌐 View on the Forge)

Adds Windows Server 2025 support.

(MODULES-11892) Add Windows Server 2025 support #98 (imaqsood)

Until Next Time!

That wraps up the July 2026 roundup. If any of these modules intersect with your environment. especially the cd4peadm breaking change to commit status contexts and the Puppet 7 removals, the linked Forge pages and release notes are worth a closer look before upgrading.

Feedback on the series is always useful, especially if there are module families or release-note patterns that deserve more attention in future editions!

More updates coming next month when the August 2026 releases land.

🤖 AI Disclosure

The Decision Maker’s Guide to Puppet: What is Perforce Puppet? Which Edition of Puppet is Right for You?

Dragonsoft DevSecOps — Mon, 03 Aug 2026 09:13:31 +0000

As your infrastructure expands, you need a solution that securely scales as quickly as your organization grows. In this article, Dragonsoft, an authorized Perforce partner, will guide you through the modern automation landscape to help you make the right choice for your organization, including comparisons for each edition of Puppet, from open source to enterprise-ready options.

What is Perforce Puppet

Perforce Puppet empowers people to innovate through infrastructure automation. For more than a dozen years, Puppet has led the way in IT infrastructure automation to simplify complexity for the masses in order to strengthen customers’ security posture, compliance standards, and business resiliency beyond the data center to the cloud. More than 40,000 organizations — including more than 80 percent of the Global 5000 — have benefited from Puppet’s open source and commercial solutions.

What to Consider When Choosing Automation Solutions Like Puppet

What happens when your IT matures? IT maturity can mean a lot of things, but in a digital-first world, it almost always means new problems to solve.

As your business grows, your infrastructure must evolve to keep up. Your IT teams need to strengthen security, ensure compliance, enhance observability, and stay audit-ready without sacrificing performance or reliability. Even if your IT footprint isn’t expanding, it may shift laterally, introducing complexity without adding scale. Legacy tools and technical debt can still hold you back. Regardless of how it happens, your infrastructure will face growing pains.

One thing is certain: Your IT doesn't get easier to manage on its own.

So naturally, you turn to automation to handle the expanding workloads and increased expectations. All of a sudden, you’re writing scripts, automating tasks, and saving mountains of time by keeping everything in your desired state. Automation empowers infrastructure teams to be more focused and productive and break through the limits of human scale. Soon, you can’t imagine ever doing development, operations, or DevOps differently.

But before long, those growing pains start to show up again. You find that the tools, solutions, and processes that kept your IT afloat in the past don’t cut it anymore. The security, scale, and sophistication of your IT are essential to business success, but in a fast-paced, ever-changing digital landscape, new challenges and complexity are never far behind.

The IT Automation Landscape: A Brief Overview

Broadly, IT automation solutions fall into three categories: open source automation tools, open core solutions, and enterprise platforms. Each has distinct strengths and limitations, making them suitable for different use cases. Here’s a quick comparison of Puppet offerings to support informed decision-making.

OpenSource Puppet

Open Source Puppet is freely available for organizations looking to adopt automation. It appeals to businesses with limited budgets or that have an open source-first model and the resources to build and maintain it. But open source tools have underlying costs: They require significant in-house expertise and ongoing maintenance. They also often lack rigorous security testing, which can present issues for organizations with compliance and SLA requirements.

Puppet Core

Puppet Core is designed to balance cost efficiency with security. It delivers reliable, stable, and secure software builds that are consistently updated and rigorously tested. Hardened binaries, defect support, and guaranteed SLAs reduce the burden on internal teams, letting them focus on keeping their systems running smoothly with Puppet instead of worrying about the security of their infrastructure automation solution.

Puppet Enterprise Platform

For organizations prioritizing scalability and future growth, an enterprise infrastructure automation and management platform is the go-to choice. With advanced features, enhanced integrations and capabilities, and dedicated support, the Puppet Enterprise platform is designed to ensure long-term efficiency and resiliency in large, complex environments.

Enterprise organizations benefit from the advanced capabilities of an infrastructure operations platform that scales with their needs — particularly businesses with a strong focus on security and compliance and who are unwilling to sacrifice innovation.

Puppet Products Compared

Puppet is here to support your path to more resilient IT — especially when you need to handle greater complexity, support a growing userbase, and speed up evelopment.

All editions of Puppet are built on the same proven foundation, but there are key differences to consider.

In short:

• Open Source Puppet automates and enforces desired state without cost, although maintaining it requires trained resources and involves greater manual effort.

• Puppet Core is for those who want the same hands-on control of Open Source Puppet but require hardened, stable builds with vendor-backed SLAs.

• The Puppet Enterprise platform is built for enterprise teams who need their automation to work for them — not the other way around. The AI-powered user experience and intuitive GUI interface help users get started quickly, and advanced capabilities and exclusive third-party integrations increase productivity at every level.

“The more we use Puppet Enterprise, the more we find we can do with it. Puppet Enterprise comes with many modules to help us manage our Puppet setup more easily. The open source version does not come with these modules … Every new upgrade of Puppet proves to be more innovative, and brings exciting features that we want.”——Pope Davis, Senior Director of systems Engineering, NYSE/ICE

Why Organizations Choose Puppet Core

Puppet Core builds on the powerful automation capabilities of Open Source Puppet and adds additional peace of mind for security-conscious organizations. Backed by Perforce, a trusted DevOps partner with over 30 years experience supporting global enterprises, releases undergo rigorous testing and include signed, hardened binaries. Defects can be reported via a customer portal and guaranteed SLAs ensure quick remediation for high and critical CVEs on Puppet software. Puppet Core also incorporates built-in enforcement of popular security baselines to ensure your infrastructure is continuously verified as compliant.

Why Organizations Choose the Puppet Enterprise Platform

As infrastructure grows and compliance demands intensify, organizations often outgrow the limitations of their automation tools. Whether it’s the need to scale rapidly or respond swiftly to security vulnerabilities, teams require a platform that evolves with them.

That's why many who start with Open Source Puppet or Puppet Core later transition to Puppet Enterprise: to gain the advanced features, enterprise support, and integrated capabilities that modern environments demand.

Deciding Which Puppet Solution Your Organization Should Choose

l Choose OpenSource Puppet if:

• You have minimal security and compliance requirements

• You don’t need formal SLAs for your Puppet software

• Your infrastructure is relatively simple and not spread across hybrid/cloud environments

• You don’t require the latest OS support or access to enterprise-grade agent updates

l Choose Puppet Core if:

• You need releases with secure, signed binaries

• Your team has the in-house expertise to manage infrastructure automation software

• You prefer a hands-on, code-centric approach to infrastructure management

l Choose the Puppet Enterprise platform if:

• Your IT infrastructure is large, complex, or hybrid (e.g., thousands of servers, multi-cloud)

• You want intuitive, GUI-based tools to manage the full infrastructure lifecycle

• You want to empower more team members to access infrastructure insights and take action (without needing Puppet expertise) through AI-driven, natural language interaction

• You need a solution that scales without adding operational overhead or tool sprawl

• You want seamless integration with your existing security, observability, and self-service tools

• You require centralized control for compliance reporting, vulnerability remediation, and audit readiness

• You aim to build powerful automation workflows without reinventing your toolchain

• Your organization is growing — whether through scale, expansion, or complexity

• You’re ready to simplify infrastructure management and increase operational efficiency

The Puppet Enterprise platform is the only solution that combines both model-based (declarative) and task-based (imperative) capabilities in a way that enables you to scale

your hybrid infrastructure as your automation footprint grows. With both agent-based and agentless capabilities, the Puppet Enterprise platform gives your organization the flexibility to automate what you want, how you want, wherever you want.

Next Steps: Getting Started

Ready to take the next step with Puppet?

Whether you're just beginning or expanding your automation journey, our team at Dragonsoft, an authorized Perforce partner,is here to help. We'll work with you to assess your current environment, understand your goals, and chart a clear path to a more secure, efficient, and resilient infrastructure.

Schedule a demo or connect with our team to explore the best Puppet solution for your organization.

Website: www.hkdsdtech.com

Phone: +852-51679050

Email: marketing@hkdsdtech.com