DEV Community: Jason St-Cyr

RHEL 10 support now available in Puppet SCE for Linux

Jason St-Cyr — Thu, 18 Jun 2026 16:16:41 +0000

Version 2.7.0 of Security Compliance Enforcement (SCE) for Linux is now available for download from the Forge!

Support for the RHEL 10 family

This release adds Red Hat Enterprise Linux (RHEL) 10 CIS benchmarks (v1.0.1, Server Levels 1 and 2). Teams adopting RHEL 10 or a compatible platform can bring those systems into compliance using the same trusted standards already in place across earlier RHEL versions.

Other improvements

Some other issues were also addressed, including logging issues with the rsyslog configuration file and intrusion detection on RHEL 9.

For all the details, make sure to read the full release notes

SCE Module on Puppet Forge

Security Compliance Management 3.8.0 Is Now Available

Jason St-Cyr — Tue, 16 Jun 2026 13:31:38 +0000

Security Compliance Management (SCM) 3.8.0 is here, with updates focused on keeping compliance scans running reliably with less manual intervention and an important license update.

This release introduces automatic cleanup for stuck scans, improved control over scan behavior with configurable timeouts, extended CIS-CAT® Pro Assessor license support, and updated benchmark content. It also includes important security fixes across core components.

⚠️ We recommend upgrading to SCM 3.8.0 before June 21, 2026 to avoid disruption, as the CIS-CAT Pro Assessor license included in SCM 3.7.1 expires on that date.

What’s changing in SCM 3.8.0

CIS-CAT Pro Assessor licensing and version

SCM 3.8.0 now contains CIS-CAT Pro Assessor v4.63.0
The bundled CIS-CAT® Pro Assessor license is now valid for one year
- The license shipped with SCM 3.8.0 is valid until June 2027
- The license included in SCM 3.7.1 expires on June 21, 2026

You can now also update the license without upgrading SCM:

New license_path parameter
- Allows updating the CIS-CAT Pro Assessor license independently
- Documentation: https://help.puppet.com/scm/current/Content/UserGuide/SCM/update_assessor_license.htm

Scan management, configuration, and reliability

Added a background scan sweeper to detect and cancel scans stuck in a "running" state
Fixed a race condition where timed-out Puppet Enterprise job status polls could leave scans permanently stuck
New assessor_scan_timeout option controls task timeout for Windows Server 2022 domain controllers (Note: this isn't set by default)
Increased default Max GraphQL requests limit to 300 requests

Benchmark coverage updates

New benchmarks added for Amazon Linux 2023 STIG, Microsoft Windows 11 STIG, Oracle Linux 9 STIG, RHEL 10 STIG, and SUSE 16
Updated benchmarks for: Amazon Linux 2, macOS, Debian, Windows, and Ubuntu (see the release notes for specific benchmark updates)
Removed benchmarks for:
- Azure Compute Windows Server 2019 v1.0.1
- Azure Compute Windows Server 2022 v1.0.0

Security fixes

This release includes updates to address 40 vulnerabilities across several components. The following components were updated to address the vulnerabilities:

Gorm.io
Keycloak
netty-codec
netty-codec-http
netty-codec-http2
netty-codec-haproxy
netty-handler
Protobuf
react-router

Refer to the full release notes for the complete list of CVEs.

Upgrade guidance

To avoid scan interruptions, upgrade to SCM 3.8.0 before June 21, 2026. This ensures continued use of the CIS-CAT Pro Assessor, access to updated benchmark content, improved security posture, and improvements in scan processing.

Learn more

Full release notes: https://help.puppet.com/scm/current/Content/UserGuide/SCM/Release_notes/release_notes.htm#SecurityComplianceManagement380

If you have questions or need assistance upgrading, reach out to Puppet Support.

🤖 AI Disclosure

This article was written and reviewed by the author, with the help of AI to assist in pulling together the details from multiple sources and general brand voice alignment.

How did I do that? For this particular article, I provided Microsoft 365 Copilot with the original release notes, my previous release announcement for 3.7.0, our company brand voice guidelines, and the official product release announcement that went out to customers. The LLM can then pull together the list of things that were updated and create a skeleton of an article. I then rewrite the content as needed to meet with my own tone of voice and get rid of the over-list-based approach that LLMs often take. It's also important to actually check back against the original release notes because sometimes the LLM will change certain words or remove words that change the meaning of what was in the release. I hope this helps if you are also writing with LLMs!

Remediating 18 OpenSSL CVEs at Scale with Puppet

Jason St-Cyr — Mon, 15 Jun 2026 14:10:21 +0000

Written by Paul Reed.

The June 2026 OpenSSL advisory is a big one. 18 vulnerabilities, one rated high severity with remote code execution potential, and a disclosure credited in part to Anthropic's Mythos model working alongside researcher Alex Gaynor. Six of those CVEs trace back to that collaboration.

When an advisory like the OpenSSL one lands, the first question is always the same: where are we exposed? If you run Puppet, you can answer that question across the entire fleet right now, patch it through one mechanism that handles every platform for you, and have it stay patched without anyone watching afterwards. The rest of this article is how.

The Vulnerability: What CVE-2026-45447 Actually Does

CVE-2026-45447 is a heap use-after-free in PKCS7_verify(). The bug fires when OpenSSL processes a PKCS#7 or S/MIME signed message where the SignedData.digestAlgorithms field is an empty ASN.1 SET.

When OpenSSL encounters this condition, OpenSSL frees a BIO object that was passed in by the calling application and is still expected to be valid. The calling application then uses the freed pointer. Depending on heap layout, that results in heap corruption, a process crash, or with a controlled heap grooming primitive, code execution.

Affected ranges:

OpenSSL 3.0.x through 3.3.x (patch to 3.5.1)
OpenSSL 1.1.1x (patch to corresponding 1.1.1 update)

The other 17 CVEs in the advisory cover authentication bypass via forged certificates (moderate, roughly a 1-in-256 success rate), ciphertext forgery, private key recovery, root CA replacement, and several DoS vectors. None are trivial in regulated environments.

Step 1: Query Your Actual Exposure

Knowing where you're exposed is where Puppet earns its keep on day zero. There's no scanner to stand up and no spreadsheet to chase round the teams. The data is already sitting in PuppetDB.

Package inventory is fed by Puppet's resource abstraction layer, the same machinery behind puppet resource package. It enumerates every package provider Puppet Enterprise supports. This means package inventory sees well beyond the system package manager: OS packages across apt, dnf/yum and zypper, and language managers like gem and pip alongside them. One query, every node:

puppet query 'package_inventory[certname, package_name, version, provider] {
  package_name ~ "(?i)openssl$|libssl$|libcrypto$"
  and
  version ~ "^(3\\.[0-3]\\.|1\\.[0-1]\\.)"
}'

Run the query against a live environment to review the results. On one fleet:

system libraries across multiple providers (libopenssl3/libopenssl1_1 via zypper, openssl and openssl-libs via dnf/yum, openssl via apt)
the Ruby openssl gem at several versions
openssl via puppet_gem on every agent node, because Puppet's own Ruby ships it
pyOpenSSL and python3-openssl via pip and the OS package manager

Most tools miss the bulk of that, because they only ever look at the system package manager. Here, anything a package manager put on the box is in scope, system libraries and language bindings together.

Scope the query to an environment by filtering against the inventory endpoint:

puppet query 'package_inventory[certname, package_name, version, provider] {
  package_name ~ "(?i)openssl$|libssl$|libcrypto$"
  and
  version ~ "^(3\\.[0-3]\\.|1\\.[0-1]\\.)"
  and
  certname in inventory[certname] { environment = "production" }
}'

Step 2: Patch It (recommended for the actual remediation)

You don't hand-write a package resource per platform, and you shouldn't. The package name varies (openssl-libs on RHEL, libssl3 on Debian, libopenssl3 on SUSE), the versions differ again, and the openssl CLI isn't even the vulnerable piece, the runtime library is. Let the tooling that already models your estate carry that.

Use the patching framework: pe_patch on Puppet Enterprise, os_patching for open source and Bolt. Classify the class and each node reports its pending updates, including which are security updates. You patch through the PE console or a task, scoped to security updates only if you want the change tight.

The OS package manager applies the vendor's security update, so the correct library package and version are chosen per platform without you encoding any of it. Reboots, update ordering, and patch and blackout windows are the framework's job. A box that can't be touched in business hours is a blackout window in config, not a workaround.

The exposure query doubles as your target list. The orchestrator takes PQL directly with -q, so there's no glue script to write. You hand the orchestrator the query and let it resolve the nodes:

puppet task run pe_patch::patch_server -q 'package_inventory[certname]{
  package_name ~ "(?i)openssl$|libssl$|libcrypto$"
  and version ~ "^(3\\.[0-3]\\.|1\\.[0-1]\\.)"
}'

That's pe_patch::patch_server on Puppet Enterprise, os_patching::patch_server for open source and Bolt. The orchestration runs the task against exactly the nodes the query returned and nothing else. Add security_only=true to keep the run tight, so a node that's already current is a no-op. If you'd rather not touch the command line, wire the same query into a node group in the PE console and drive it from there.

Step 3: Enforce It In Code

If you'd rather declare the state and have Puppet hold the state on every run, use the openssl module's class. The module knows the package names per platform:

class { 'openssl':
  package_ensure         => latest,
  ca_certificates_ensure => latest,
}

Using latest keeps the library current; set package_ensure to a specific version from Hiera if you want a pinned, auditable rollout.

This enforcement step is something a one-off script and a scanner both miss. A patch run fixes the issue once; declaring the state is what makes it stay fixed. The agent runs on a schedule, every 30 minutes by default, and enforces desired state each time. So when a node drifts back to a vulnerable version, a VM reprovisioned off a stale image, say, or a change someone made by hand and forgot, the next run quietly puts the desired state back. A scanner would notice that regression on its next sweep and open you a ticket. Enforcement just doesn't let the gap stay open that long.

The two paths aren't either/or. The patching framework is the quicker way to clear the initial backlog; enforcement is what keeps the backlog cleared. Run both and the framework does the first sweep while the module holds the line from then on.

Step 4: Restart Processes That Link the Library

Patching the package is only half the job. A running process keeps the old .so mapped until the process restarts, and a library swap under a live OpenSSL is exactly the case where that bites.

If you patched with the framework, it already tracks this for you. pe_patch reports the processes that require a restart in the node's fact, so you don't go hunting:

"reboots" : {
    "app_restart_required" : true,
    "apps_needing_restart" : {
        "1" : "/usr/lib/systemd/systemd --switched-root --system --deserialize 31",
        "586" : "/usr/lib/systemd/systemd-journald",
        "601" : "/usr/lib/systemd/systemd-udevd",
        "657" : "/sbin/auditd",
        "691" : "/usr/bin/python3 -s /usr/sbin/firewalld --nofork --nopid",
        "694" : "/usr/sbin/rngd -f --fill-watermark=0 -x pkcs11 -x nist -x qrypt -x namedpipe -x jitter -D daemon:daemon",
        "696" : "/usr/lib/systemd/systemd-logind",
        "766" : "/usr/sbin/NetworkManager --no-daemon",
        "863" : "sshd: /usr/sbin/sshd -D [listener] 0 of 10-60 startups"
    },
    "reboot_required" : true
},

apps_needing_restart is the list of processes still mapping a file that's been replaced underneath them, and reboot_required flags when a restart of individual services won't cut it. The patch run acts on these according to its reboot policy, so the same job that applies the update also clears the stale library, or tells you precisely which nodes still need a bounce. That's the manual lsof check in the next section, done for the whole fleet as a fact.

If you went the module route instead, chain the dependent services onto the class so they refresh when it changes the library:

Class['openssl'] ~> Service['nginx']

Chaining on the class rather than a Package['...'] title means you don't have to know the package name the module picks per platform. The refresh fires only when something actually changes, so steady-state runs leave your services alone.

A note on the language-level copies inventory turned up. Where a gem or pyOpenSSL links the system library, patching libssl/libcrypto fixes the underlying crypto and these processes will pick up the patch on restart. The few that statically bundle their own copy get updated through their own toolchain (gem update, pip). The OS-packaged bindings ride along with the patch run either way.

Step 5: Verify the Process Has Reloaded the Library

The reboots fact above is your fleet-wide answer. When you want to confirm a single box by hand, or you're working somewhere the fact isn't available, lsof against the actual PID tells you what that process has mapped:

sudo lsof -p $(pgrep nginx | head -1) | grep libssl

If the lsof query still shows the old path after the run, the restart didn't fire. Check the agent log or the patch run's reboot status. The openssl CLI version won't help here, the version says nothing about what a long-running daemon has mapped.

Step 6: Confirm Convergence

Re-run the inventory query to verify closure. This query doubles as audit evidence:

puppet query 'package_inventory[certname, package_name, version, provider] {
  package_name ~ "(?i)openssl$|libssl$|libcrypto$"
}'

Anything still on an affected version, across any provider, is your remaining work. Puppet Enterprise users can pull the same data from the compliance dashboard for audit review.

The Point Isn't OpenSSL

OpenSSL is this month's fire drill. Next month it's something else, and the one after that hasn't been disclosed yet. None of the steps above were really about OpenSSL. They were about having a tool already in place that answers the questions every advisory asks, before the advisory lands.

Look back at what each step actually was:

The exposure query was inventory: what have I got, and where, as of the last check-in.
The patch task, scoped from that same query, was remediation. The reboots fact was reporting, telling you what's still exposed and what needs a bounce.
Enforcement was the bit that holds the line afterwards, so a reprovisioned box can't slip back in unnoticed.

That's the whole vulnerability-response loop, and the worst time to start building it is the morning a CVE lands with the clock already running.

That's the case for putting the capability in now, while nothing's on fire. The next disclosure becomes a query and a patch run instead of a fortnight of spreadsheets and change tickets. The same loop applies well beyond library upgrades, too. We recently showed how to deal with dirty frag and copy-fail with Puppet, which walks the same detect-mitigate-remediate pattern on a different class of problem.

Using Puppet provides a consistent way to address OpenSSL vulnerabilities across environments. It'll still be set up and ready when the next vulnerability lands.

🤖 AI Disclosure

This article has been reviewed by a human expert in the subject matter and all code samples have been reviewed by Puppet technical experts. Initial structural content has been generated by Claude AI tools to assist with editing for clarity, structure, grammar, and maintaining brand voice, and then passed through human review.

What You Need to Know About the New puppetlabs-stdlib 10 in June 2026

Jason St-Cyr — Thu, 11 Jun 2026 14:31:40 +0000

The TL;DR

We are releasing puppetlabs-stdlib 10.0.1 with a target date of June 30, 2026.
This is a major version bump because we are dropping support for Puppet 7 (which reached its end-of-life in February 2025) and requiring Ruby 3.1+.
If your modules pin stdlib to < 10.0.0, they will continue to work as-is on stdlib 9.x.
You do not need to take any immediate action, but we wanted to give the community advance notice so module owners have time to plan.

Why a Major Release?

The puppetlabs-stdlib module is one of the most widely depended-upon open source modules in the Puppet ecosystem. Because of that, we take major version bumps seriously and want to be transparent about what is changing and why.

The last release of stdlib (9.7.0) was published in December 2024. Since then, maintenance work has accumulated in the main branch, updates to Puppet Core tooling, CentOS 9 support, Rubocop alignment, CI and testing infrastructure updates, and various bug fixes and enhancements contributed by both Puppet engineers and community members.

Among those accumulated changes is the removal of Puppet 7 from the supported platforms in the module metadata. Since Puppet 7 reached end-of-life over a year ago, this is a natural and expected housekeeping step. However, because removing a previously supported Puppet version is a backwards-incompatible change under semver, it requires a major version bump. By making a major version release along with the removal of Puppet 7 support, this will make a clean delineation for any users still running Puppet 7.

Additionally, the Rubocop and tooling updates in the branch enforce Ruby 3.1+ syntax standards (such as the shorthand hash syntax). While these are primarily code-style changes, they mean the module codebase is no longer guaranteed to run on Ruby versions older than 3.1, which further supports the decision to move to a new major version.

What’s Included in stdlib 10

This release rolls up approximately 18 months of changes. The highlights include:

Puppet 7 support removed: The module metadata now requires Puppet 8.0.0 or later. Puppet 7 has been end-of-life since early 2025.
Ruby 3.1+ required: Rubocop and code style enforcement now targets Ruby 3.1 standards. Syntax that is incompatible with older Ruby versions has been adopted throughout the codebase.
CentOS 9 support: The module metadata now states support for CentOS 9.
Bug fixes and enhancements: Multiple community-contributed fixes and improvements that have been pending release.
CI and testing updates: Updated testing infrastructure using Puppet Core tooling, updated nightly test matrices, and improved CI workflows.

A full changelog will accompany the release on the Puppet Forge and on GitHub.

What This Means for Module Authors

If you maintain a Puppet module that depends on puppetlabs-stdlib, here is what you need to know.

If You Do Nothing

Your module will continue to work. Most modules pin their stdlib dependency with an upper bound like "puppetlabs/stdlib": ">= 4.0.0 < 10.0.0". The Puppet module resolver will keep you on the latest 9.x release. Nothing breaks, nothing changes.

If your module did not specify an upper bound, your module will be able to start using version 10 without any changes.

If You Want to Adopt stdlib 10

When you are ready, update the upper bound of your stdlib dependency in your metadata.json:

"puppetlabs/stdlib": ">= 4.0.0 < 11.0.0"

This will allow your module to resolve either stdlib 9.x or 10.x, giving your users flexibility. You should also confirm that your module no longer requires Puppet 7 support and that your testing and CI pipelines use Ruby 3.1 or later.

Timing Is Up to You

There is no urgency to adopt stdlib 10 on day one. The 9.x line will remain available on the Forge. We encourage module owners to update at their own pace, and we are providing this advance notice specifically so you can plan that work into your roadmap rather than being caught off-guard.

What Perforce Puppet Is Doing to Prepare

We recognize that stdlib touches a huge portion of the module ecosystem. There are approximately 34 puppetlabs modules that depend on stdlib. Between now and the release date, we will be updating all of those modules to expand their dependency bounds to accept stdlib 10.x. These updated modules will be released to the Forge ahead of or alongside the stdlib 10 release so that the transition is as smooth as possible.

Our goal is that by the time stdlib 10 lands on the Forge, the puppetlabs module ecosystem will already be ready for it.

Timeline

Date	Milestone
Now	This announcement. Community has advance notice.
June 18–30	Perforce will release updated dependency bounds across puppetlabs modules.
June 30, 2026	Target release date for puppetlabs-stdlib 10 on the Puppet Forge.

A Note on Communication

We want to acknowledge that an earlier attempt to release stdlib 10.0.0 was made without sufficient advance communication to the community. We heard the feedback, rolled that release back, and are now doing this the right way: giving you notice, giving you time, and coordinating the broader module ecosystem before the release lands.

Major stdlib releases have historically been disruptive because of how deeply the module is embedded across the ecosystem. We are committed to making this transition as smooth as possible, and your feedback during this notice period is welcome and appreciated.

How to Prepare

Review your dependency bounds: Check your metadata.json for your stdlib version constraint.
Check your Puppet version support: If your module still claims Puppet 7 support, consider whether that is still necessary given Puppet 7 is end-of-life.
Check your Ruby version: Ensure your testing and CI environments use Ruby 3.1 or later.
Test against the main branch: If you want to verify compatibility ahead of the release, you can test your module against the main branch of puppetlabs-stdlib on GitHub.

Questions and Feedback

We want to hear from you. If you have questions, concerns, or feedback about this upcoming release, please reach out through any of the following channels:

Community Slack: The Puppet community Slack workspace, particularly the #forge-modules channel where we have already had some discussion on this upcoming change.
Comments on this post: We will be monitoring and responding to comments here on dev.to.
Perforce Forums: Join the discussion on the Perforce Puppet forums, part of the official Perforce Portal.

Thank you for being part of the Puppet community! We appreciate your collaboration and your contributions, and we are looking forward to getting this release into your hands.

stdlib Forge Module

Puppetlabs Modules Roundup – May 2026

Jason St-Cyr — Wed, 03 Jun 2026 21:48:48 +0000

This time around we look back at May 2026 and the 11 Puppetlabs module releases on the Forge, with an emphasis on the changes most likely to matter in active environments.

Highlighted Updates

New Windows audit policy module released!

The new audit_policy module has been released by Perforce as a Ruby replacement for the generated DSC community auditpolicydsc module.

This module uses Puppet Resources API for managing Windows audit policy using auditpol.exe

ruby_task_helper Dependency Bound Update

Five Bolt-adjacent modules all bumped the ruby_task_helper upper bound to < 2.0.0 in a coordinated maintenance pass, helping with dependency resolution failures when using Bolt 5.x.

Affected modules: vault, terraform, http_request, gcloud_inventory, azure_inventory.

CentOS 9 Support

Multiple modules added explicit CentOS 9 compatibility, expanding the Linux platform coverage in line with the broader Puppet ecosystem push.

Affected modules: concat, inifile.

What Updates Happened to Puppetlabs Modules in May 2026?

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

apt 11.3.1

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

This release introduced an explicit hash value syntax while also adding a param to support purging keyrings and other community contributions.

Includes monthly releases: 11.3.1 (2026-05-19), 11.3.0 (2026-05-18).

Use explicit hash value syntax instead of shorthand #1285 (SugatD)
Add param for purging keyrings #1266 (bwitt)
Include components when suite does not end with slash #1259 (bwitt)
Bugfix - sources format and ensure => absent fails #1243 (traylenator)
fix: allow plus signs in ppa #1222 (moritz-makandra)
Fix and improve DEB822-style template #1212 (smortex)

audit_policy 1.0.0

🌟 New Module: 2026-05-29 (🌐 View on the Forge)

This new module allows you to manage Windows audit policy with auditpol.exe as a replacement for the generated DSC community module. Initial release contains:

audit_policy_subcategory: manage Windows audit policy subcategories by display name using auditpol.exe
audit_policy_guid: manage Windows audit policy subcategories by GUID using auditpol.exe
audit_policy_option: manage global Windows audit policy options (CrashOnAuditFail, FullPrivilegeAuditing, AuditBaseObjects, AuditBaseDirectories)
audit_policy_csv: manage Windows audit policy by importing settings from an auditpol /backup CSV file
Support for Windows Server 2016, 2019, 2022, and 2025
Pure Ruby implementation — no PowerShell dependency; replaces the dsc-auditpolicydsc community module
Puppet requirement pinned to >= 8.0.0 < 9.0.0

azure_inventory 0.5.1

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

This release bumped the ruby_task_helper upper bound to < 2.0.0.

Bump ruby_task_helper upper bound to < 2.0.0 (#16)

cd4peadm 5.15.1

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

A few highlights from this release:

Fixed an issue where SAML logins were failing.
Fixed an issue where CD would not use the configured HTTP timeouts when making calls to the Azure DevOps API, resulting in unexpected timeout failures.
Fixed an issue where GitLab merge request updates that do not involve code changes would trigger CD pipelines.
CVE-2026-42198. Updated to address this vulnerability.

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

concat 10.0.0

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

This release added support for CentOS 9 while also addressing runner images for Ubuntu 24.04.

Redact sensitive content #828 (smortex)
(CAT-2296) Update github runner image to ubuntu-24.04 #823 (shubhamshinde360)
(CAT-2152) Add support for CentOS 9 #818 (skyamgarp)
Allow user defined tag or list of tags #790 (Lightning-)
Use explicit hash value syntax instead of shorthand #835 (SugatD)

gcloud_inventory 0.3.1

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

This release bumped the ruby_task_helper upper bound to < 2.0.0.

Bump ruby_task_helper upper bound to < 2.0.0 (#14)

http_request 0.3.2

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

This release bumped the ruby_task_helper upper bound to < 2.0.0.

Bump ruby_task_helper upper bound to < 2.0.0 (#18)

inifile 6.4.0

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

The inifile module now supports multiple values per key while also adding support for CentOS 9.

Add support for multiple values per key #555 (bwitt)
(CAT-2152) Add support for CentOS 9 #549 (skyamgarp)

puppet_agent 4.28.0

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

Updates to new tooling (Bolt, PDK Templates) as well as support for MacOS 26 and some pre-work for the upcoming Puppet Core 9.

(PA-7824) Use newest Bolt #829 (mhashizume)
(PA-7897) Update to pdk-templates 3.6.1.1 #825 (joshcooper)
(PA-8250) Allow installation of puppetcore9-nightly packages #822 (joshcooper)
(PA-8238) Add support for MacOS 26 in install_shell.sh #821 (shubhamshinde360)
(PA-8250) Restore windows command to check puppet service #826 (joshcooper)
(PA-8041) Fix puppetcore8-nightly installs on rpm and mac #824 (joshcooper)
(PA-8247) Add guard against other ruby process when installing #823 (AriaXLi)

terraform 0.7.2

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

This release bumped the ruby_task_helper upper bound to < 2.0.0.

Bump ruby_task_helper upper bound to < 2.0.0 (#37)

vault 0.4.1

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

This release bumped the ruby_task_helper upper bound to < 2.0.0.

Bump ruby_task_helper upper bound to < 2.0.0 (#19)

Until Next Time!

That closes out the May 2026 update set. For deeper implementation detail, the linked module pages and release notes remain the best source of truth.

If you have feedback on the roundup format or want a deeper look at a specific module area, the Perforce Community Slack is still the best place to continue the conversation.

See you next month with a roundup for June releases!

Puppet Core 8.19 and PDK 3.7: Security Updates, Dependency Changes, and Windows Fixes

Jason St-Cyr — Thu, 21 May 2026 16:17:55 +0000

Puppet Core 8.19.0 focuses largely on security hardening, with some dependency cleanup and a small but important fix for Windows user management.

If you already run Puppet Core 8, this release is primarily about keeping your runtime secure and predictable, rather than introducing new workflows or configuration changes.

➡️ Full details: Puppet Core 8.19.0 release notes

PDK 3.7.0 was also released to improve performance on Windows, update dependencies, and provide other updates for security and known issues.

➡️ Full details: PDK 3.7.0 release notes

CSV gem dependency removed

Puppet Core no longer depends on the CSV Ruby gem.

Removes an external dependency from the Puppet runtime
Reduces overall dependency surface area
Simplifies installation and long-term maintenance

This change does not alter Puppet DSL behavior or require configuration changes.

Security updates

Puppet Core 8.19.0 updates several bundled runtime components to address recently disclosed security vulnerabilities. These updates apply automatically when you upgrade.

Ruby updated to 3.2.11 (CVE-2026-27820)
OpenSSL updated to 3.0.20 (CVE-2026-28387, CVE-2026-28388, CVE-2026-28389, CVE-2026-28390, CVE-2026-31789, CVE-2026-31790)
libxml2 updated to 2.15.3 (CVE-2026-6732)
curl updated to 8.20.0 (CVE-2026-6253, CVE-2026-6276, CVE-2026-6429, CVE-2026-7009, CVE-2026-7168)
net-imap updated to 0.4.24 (CVE-2026-42245, CVE-2026-42246, CVE-2026-42256, CVE-2026-42257, CVE-2026-42258)
erb updated to 6.0.4 (CVE-2026-41316)

ℹ️ Important note for net-imap users

If you use net-imap directly in custom Ruby code, the updated version enforces stricter argument validation. Check the release notes for some details on how to manage this gem if you cannot use the upgraded version of net-imap.

Windows user passwords now allow colons

When managing user resources on Windows, Puppet Core no longer rejects passwords containing colons (:).

Affects Windows platforms only
Behavior on other platforms is unchanged

This prevents unnecessary failures when managing Windows accounts with valid password formats.

Installation safeguards for Ruby versions

Puppet Core now prevents installation on unsupported Ruby versions.

Puppet Core 8 enforces a maximum supported Ruby version of 3.x
Prevents installation attempts using unsupported versions (such as Ruby 4)
Protects against installation failures like can't modify frozen Hash

This applies when installing Puppet Core via bundler or gem commands.

PDK 3.7.0 changes

This version of PDK was updated to help prevent security issues and reduce test failures, and made macOS 15 downloads available.

Rexml updated to version 3.4.4 to address CVE-2025-58767
macOS 15 downloads now available
Windows performance has been improved
YAML file validation issues should be resolved
Several puppet_forge gems and dependencies were updated

Should you upgrade?

Upgrading to Puppet Core 8.19.0 is recommended for Puppet Core 8.x users if:

You want current security fixes for bundled runtime dependencies
You manage Windows users with complex passwords
You want to avoid accidental installation on unsupported Ruby versions

Want to get started? Here are the install/upgrade guides:

For full details and CVE listings, see the release notes:

➡️ Puppet Core 8.19.0 release notes
➡️ PDK 3.7.0 release notes

Puppetlabs Modules Roundup – April 2026

Jason St-Cyr — Thu, 07 May 2026 16:31:43 +0000

In April 2026, the Puppetlabs module lineup saw 8 Puppetlabs module releases, with the most notable updates collected here for a quick review.

The overall pattern in these releases was event forwarding enhancements and security and compliance platform updates, which makes this month’s roundup a useful quick scan for teams planning upgrades or routine maintenance.

Highlighted Updates

Event Forwarding Enhancements

Coordinated updates to Splunk HEC and PE Event Forwarding modules add support for orchestrator_plan event type, improving visibility into Puppet orchestrator activities with enhanced filtering and integration capabilities.

Affected modules: splunk_hec, pe_event_forwarding.

Security and Compliance Platform Updates

Comply and Comply Admin modules received coordinated releases, advancing the Security Compliance Management platform capabilities.

Affected modules: comply, complyadm.

What Updates Happened to Puppetlabs Modules in April 2026?

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

cd4peadm 5.15.0

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

A few highlights from this release:

Added a Hiera configuration option, external_webhook_url, that allows you to set the webhook URL that Continuous Delivery sends to your VCS provider. This is useful if you are using a proxy between your VCS and CD.
Added an idle timeout to the CD console that logs users out after 30 minutes. Configure this using the Hiera option, web_session_idle_timeout_mins.
Added CSRF protection to the DeleteUserAccount and SetSuperUser endpoints by restricting them to POST requests and validating CSRF tokens issued at login and expired on logout.
20 CVEs addressed.

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

comply 3.7.1

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

A few highlights from this release:

Fixed a stale image which resulted in checksum and benchmark issues upon install.
CVE-2026-33815, CVE-2026-33816. Updated gorm.io to v5.9.2 to address these vulnerabilities.

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

complyadm 3.7.1

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

A few highlights from this release:

Fixed a stale image which resulted in checksum and benchmark issues upon install.
CVE-2026-33815, CVE-2026-33816. Updated gorm.io to v5.9.2 to address these vulnerabilities.

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

lvm 4.0.1

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

This release addresses two bug fixes. A race condition where lvcreate returns before udev finishes processing device-add events could cause a subsequent filesystem resource targeting the same logical volume to fail with "device or resource busy" — the fix calls udevadm settle after a successful lvcreate. The release also corrects an AIX-specific issue where boolean filesystem parameters such as isnapshot were passed to crfs as true/false instead of the required yes/no, causing the command to reject them outright.

(MODULES-11756) Wait for udev to settle after lvcreate #380 (imaqsood)
(MODULES-11788) Pass converted boolean parameter #379 (joshcooper)

pe_event_forwarding 2.3.0

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

This release adds orchestrator plan-job collection controls and fixes duplicate forwarding behavior in job collection.

Added plan job data collection from the orchestrator/v1/plan_jobs API, with progress tracked in a dedicated pe_event_forwarding_plan_index.yaml state file.
Added the pe_event_forwarding::skip_plans parameter to disable plan job collection when needed.
Fixed get_jobs behavior where the first page could return more records than newly available jobs, which could cause duplicate forwarded data.
Source attribution: (PIE-1683) Add support for collecting plan data #137 (coreymbe).

peadm 3.37.0

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

This release is a small change to add support for Puppet Enterprise 2025.10.0.

(PE-43654) Add support for PE 2025.10.0 #661 (davidmalloncares)

sce_linux 2.6.1

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

A few highlights from this release:

Error message: comparison of NilClass with failed. Some users saw this error message and experienced catalog compilation failures when attempting to manage mounted file system options with SCE for Linux. The issue was caused by /etc/fstab files that did not have at least one comment line or blank line. The internal parser was updated to avoid the issue and help prevent compilation errors.
sce_mount_info fact does not resolve to a value. This issue is related to the Linux findmnt command, which is used to list all mounted file systems. The command, which supports different options depending on operating system, was failing on specific systems, resulting in a failure of the sce_mount_info fact. Now, if the findmnt command fails, warnings will be logged, and the /etc/fstab file will be parsed directly for mount information.
Error messages related to rsyslog. Because the version of the rsyslog logging service used on Red Hat Enterprise Linux (RHEL) 9 differs from earlier versions, users of RHEL 9 sometimes see error messages like this: imjournal: open() failed for path: '/var/lib/rsyslog/imjournal.state.tmp': Operation not permitted These messages indicate a failure to load the rsyslog imjournal module. To accommodate the changes in rsyslog and avoid this error, the module loading syntax was updated in SCE for Linux.

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

splunk_hec 2.2.0

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

This release focuses on support for the orchestrator_plan event type from the puppetlabs-pe_event_forwarding module while also addressing orchestrator_plan to index mappings in util_splunk_hec template.

Added support for the orchestrator_plan event type from the puppetlabs-pe_event_forwarding module.
Added orchestrator_plan to index mappings in util_splunk_hec template.
New PE Event Forwarding filter orchestrator_plan_data_filter to allow filtering orchestrator plan event payloads.
Module dependency updated to ensure pe_event_forwarding v2.3.0+ is installed.
Removed support for Debian platform and EOL operating system versions.

Until Next Time!

That’s the full pass through the 8 Puppetlabs module releases from April 2026. The Forge links above are the quickest path to the underlying release details.

If there is a part of the Puppetlabs ecosystem that would benefit from more context in future roundups, that feedback is worth sending along.

Catch you in the next roundup for May 2026.

Puppet Continuous Delivery 5.15.0 is now available

Jason St-Cyr — Wed, 29 Apr 2026 16:20:25 +0000

Puppet Continuous Delivery (CD) version 5.15.0 is now available, with updates focused on stability, security, and day‑to‑day usability for teams running Puppet automation pipelines at scale.

If you’re already on CD 5.x, this is a straightforward upgrade that continues the work of refining the platform while keeping it aligned with current Puppet Enterprise releases and supported tooling.

The detailed release notes are linked below, but here’s a quick breakdown of what this release delivers and why you may want to upgrade.

What’s included in CD 5.15.0

CD 5.15.0 delivers targeted updates across webhook configuration, Pipelines as Code, Impact Analysis, VCS integrations, and platform security. The changes below focus on specific features and integrations rather than broad platform behavior.

Webhooks, sessions, and configuration

Added a new Hiera configuration option, external_webhook_url, which allows you to explicitly set the webhook URL that Continuous Delivery sends to your VCS provider. This is intended for deployments where CD is running behind a proxy.
Added an idle session timeout to the CD console. Users are logged out after 30 minutes of inactivity by default, configurable using the web_session_idle_timeout_mins Hiera option.

Pipelines as Code and Impact Analysis

Added the skip_empty_catalogs parameter to the Impact Analysis settings in the Pipelines as Code schema. When enabled, nodes with no catalog resources in PuppetDB are excluded from Impact Analysis results.
Fixed an issue where the browser would stop polling for Impact Analysis results when an IA run finished or when navigating away from the IA details view.

VCS integrations (Azure DevOps and GitLab)

Updated the Pipeline Summary view so the by field now displays the initiating user’s display name for Azure DevOps pipelines, instead of the user ID.
Changed how Continuous Delivery sends commit status updates to GitLab. When native GitLab pipelines are present, all CD commit status updates are now attached to the same branch pipeline, avoiding fragmented status reporting.

Data visibility and usability fixes

Fixed an issue where package_updates for pe_patch data did not appear in the fact picker. The query service was updated so this data now displays correctly.

Security and authorization hardening

Added CSRF protection to the DeleteUserAccount and SetSuperUser endpoints by restricting them to POST requests and validating CSRF tokens issued at login and expired on logout.
Fixed an issue where any authenticated user could enumerate user accounts and email addresses. Access to the GET /v1/users endpoint is now properly restricted to root and superusers.
Fixed an authorization bypass on the GraphQL /query endpoint where permission checks could be skipped when using workspace variables or omitting the id field. Authorization is now enforced consistently.

Platform and runtime updates

Added Amazon Linux 2023 as a supported platform for Docker‑based installs.
Updated the Postgres base image to postgres:17-trixie.

Security dependency updates

This release includes dependency updates to address reported vulnerabilities, including updates to:

lodash
diffjs
plexus-utils
glibc
undici
jackson
Jetty (updated to version 12)
golang.org/x/crypto
quartz
logrus
log4j2
bouncy-castle

Refer to the release notes for the full list of CVEs addressed in this release.

Why this release matters

For most users, CD sits in the middle of multiple systems: source control, CI tooling, Puppet Enterprise, and infrastructure targets. Small issues can quickly turn into pipeline friction.

CD 5.15.0 continues the effort to:

Reduce pipeline noise caused by edge‑case failures
Improve the quality of feedback when something goes wrong
Keep security posture current without forcing disruptive changes
Make upgrades between minor versions low‑risk

If you’re standardizing on CD 5.x, staying current helps ensure you’re getting fixes before they turn into operational problems.

Installation and upgrade notes

If you’re new to Puppet Continuous Delivery, start with the official install documentation:

Puppet CD installation docs

If you’re already running CD 5.x, upgrading to 5.15.0 should follow the standard upgrade path described in the documentation:

Puppet CD upgrade docs

As always, review the release notes before upgrading, especially if you rely on specific integrations or custom pipeline behavior.

Read the full details

For the complete list of fixes, security updates, and known issues, check the official release notes:

Continuous Delivery 5.15.0 release notes

If you have feedback or run into issues after upgrading, the Puppet community channels are always a good place to share what you’re seeing.

Happy automating!

Security Compliance Management 3.7.0 Is Now Available

Jason St-Cyr — Wed, 15 Apr 2026 14:56:44 +0000

Security Compliance Management (SCM) 3.7.0 helps teams assess systems against recognized security benchmarks. This release supports evolving baselines and improves audit readiness, operational reliability, and overall governance by giving administrators tighter control over platform performance, user access, and API security within the Puppet Enterprise platform.

What's new in this release

Expanded benchmark coverage for evolving environments

SCM 3.7.0 updates CIS-CAT Pro Assessor benchmark coverage to support newer operating systems and standards. This helps ensure compliance reporting remains current as teams adopt new platforms.

Highlights include:

New CIS benchmarks for numerous Linux distributions and macOS.
An updated benchmark for Microsoft Windows 11 Enterprise.

More predictable performance during compliance scans

Administrators can now control JVM memory allocation for the CIS Assessor, allowing performance tuning based on environment size and available resources. This results in more reliable scans and fewer disruptions during compliance assessments.

Greater control over user access and session behavior

New centralized session management options allow administrators to better align SCM authentication behavior with corporate security and identity policies. The outcome is reduced risk from long-lived sessions and improved governance.

Improved API governance and security posture

Additional GraphQL controls help limit exposure and enforce request limits in regulated or security-sensitive environments. The smaller API attack surface provides stronger API governance.

Security fixes and dependency updates

This release addresses multiple known vulnerabilities across core dependencies, helping reduce inherited risk and support ongoing vulnerability management.

For a complete list of addressed CVEs and detailed configuration guidance, see the release notes.

Why Upgrade to SCM 3.7.0

Organizations should consider upgrading to SCM 3.7.0 to reduce compliance gaps, stabilize large-scale assessments, and strengthen security controls as environments grow more complex.

With this release, teams can:

Maintain audit readiness as new operating systems and benchmarks are adopted.
Improve scan reliability and performance in large-scale environments managed through Puppet Enterprise.
Centralize and standardize user session and API behavior across the platform.
Reduce exposure to known vulnerabilities through updated dependencies and security fixes.

Next Steps

Review the release notes for technical details and configuration information.
Upgrade to SCM 3.7.0 to take advantage of expanded coverage and new governance controls.

Generate a Puppet Module Using GitHub Copilot and VS Code

Jason St-Cyr — Mon, 13 Apr 2026 13:23:29 +0000

This tutorial shows how to use GitHub Copilot with the Puppet Model Context Protocol (MCP) server to generate, validate, and refine a Puppet module—even if you’re new to Puppet development.

What You’ll Learn

How to configure GitHub Copilot with the Puppet MCP server
How AI agents can use the Puppet Development Kit (PDK) to generate Puppet modules
How AI agents can use the PDK to validate and iterate on generated Puppet code

The Challenge: Overcoming the Puppet Module Learning Curve

When you start automating infrastructure with Puppet, you might face an initial learning curve. You will begin to learn Puppet syntax, best practices around module structure and Puppet Domain-Specific Language (DSL), and even what tools are available to you.

To help DevOps practitioners get started, Puppet first released an MCP server to accelerate development when using the new Puppet EdgeOps module for working with network devices. Starting with Puppet Enterprise Advanced 2025.7, tools are available to provide even more guidance and information for working with agents on Puppet code in control repos, tasks, and modules. Traditional module development demanded deep domain expertise that teams often lack, but using modern AI-assisted development flows can help you bridge the knowledge gap.

Puppet's MCP server can be used with your favorite Integrated Development Environment (IDE) and code assist agent so that you can describe your requirements in natural language and work with your agent to get validated Puppet code and architecture. This tutorial demonstrates the use of Visual Studio (VS) Code and GitHub Copilot to generate a Puppet module with minimal Puppet expertise, helping you get started faster!

⚠️ Important: AI tools make mistakes, just like people. For this reason, your process should always involve review and testing as part of the end-to-end process. Use these tools to augment yourself and the team, but make those tools earn your trust.

Time to get started!

Tech Stack Overview: VS Code, GitHub Copilot, and Puppet MCP

For this tutorial, the Puppet development workflow will combine three key technologies:

Visual Studio Code: Serves as the IDE where all coding (and code generation) happens.
GitHub Copilot: Acts as the AI coding assistant that provides intelligent code suggestions and executes autonomous tasks.
Puppet MCP server: Exposes Puppet-specific intelligence through MCP, enabling GitHub Copilot to better generate Puppet solutions.

The MCP server provides several tools to provide Puppet language guides, information about Puppet environment entities, Puppet documentation, and networking info. This integration eliminates context switching between documentation, terminal windows, and code editors and provides the information required by AI agents to support smooth transitions from one step to the next.

Authentication to the Puppet MCP server happens via Puppet Enterprise (PE) API keys with secure token storage in VS Code. The MCP architecture follows a client-server model where VS Code instantiates client connections to the Puppet MCP server running in your Puppet Enterprise environment.

Prerequisites and Required Software Installation

This brief tutorial is based on the assumption that you have met several prerequisites. Plan time to go through this checklist before starting:

Obtain your authentication credentials to download Perforce Puppet applications. The credentials are either your Forge API key or your Puppet Enterprise license ID.
Install Puppet Enterprise Advanced 2025.7+.
Enable the Infra Assistant feature on your PE server. You do not have to configure the Infra Assistant OpenAI settings, but the Infra Assistant must be turned on in order for the MCP server to accept requests from your agent.
Generate a valid Puppet Enterprise API key from the console for a user with the infrastructure_assistant:use permission. (The API key is sometimes called a token.)
Install Visual Studio Code on your development machine and complete configuration tasks:
Configure the GitHub Copilot extension in Visual Studio Code.
Configure GitHub Copilot to use MCP servers in VS Code.
Ensure that your developer machine has network access to the PE console host.
Verify that your developer machine trusts the PE console CA certificate.

Tutorial Walkthrough: From Empty Repository to Generated Module

These steps walk through how you can take a completely empty repository to a validated Puppet module by using an AI-assisted flow in Visual Studio with a code assistant. Remember to meet the previously listed prerequisites! The following steps use GitHub Copilot, but if you happen to use a different stack (like Claude Code or Cursor), the process is mostly the same.

Tip: In this tutorial, “agent chat” refers to the GitHub Copilot Agent chat window in Visual Studio Code.

Using your favorite source control tool, create a blank repository to begin working.
Clone the repository and open it in Visual Studio Code.
To support the use of Puppet tools, install GitHub Copilot instructions in your solution. Sample instructions are available on GitHub. Tip: Some models cannot easily find instructions in subfolders and search only in the root directory. Some models look only for the copilot-instructions.md file. The example provides a README.md and a copilot-instructions.md file that help lead the model toward the custom Puppet instructions file.
Add the Puppet MCP server to your mcp.json file.
Start the Puppet MCP server, either by clicking Start in your mcp.json file or through the MCP Servers – Installed list in the Extensions view.
Open an agent chat window for GitHub Copilot.
Run a prompt to generate a new module. For example: “I want to create a new Puppet module to automate the provisioning of new AWS VMs. Please follow best practices for Puppet module creation.”

Note that this is a simple prompt example. To follow context engineering best practices, you would provide much more detail to get your desired output. For tutorial purposes, the prompt is intentionally lightweight. By using a simple prompt, you can recognize the extra context and benefits provided by Puppet tools to accelerate your progress.

Installing Puppet Development Kit (PDK)

At this point, your agent should be running and attempting to solve the problem. The agent will quickly detect the need for additional information from the Puppet MCP server. In addition, the agent will determine that the Puppet Development Kit (PDK) must be used to create modules. In my model testing, the GitHub Copilot agent undertook the following tasks, which required minimal input from the user:

Processed the provided Puppet instructions and determined that the Puppet MCP server should be connected to retrieve guidelines.
Attempted to connect to the Puppet MCP server for the get_puppet_guide tool and augmented the context with information from the Puppet MCP server.
Recognized that the PDK is required and attempted to check whether PDK was installed (by running pdk --version).
If PDK was not detected, attempted to fetch the PDK installation instructions.

Tip: The agent may use different URLs to search for the PDK installation instructions. Eventually, the agent will find the correct installation instructions for the operating system.
After the agent discovered the installation instructions, the agent determined that authentication credentials are required to download the software. At this point, the user would be prompted for Forge credentials or Puppet Enterprise credentials. At the prompt, you will specify the type of credentials. For example: “Here is my license ID: abcdefghizjklmnopzrstuvwxyz1”. This sample prompt informs the agent to use a Puppet Enterprise license ID, instead of a Forge API key, as the authentication method.
Submit the prompt and the agent will begin to download and install the PDK.

The agent typically installs the PDK as part of its setup routine. In practice, the agent might run incorrect commands or fail to use elevated privileges on the first attempt. When that happens, allow the agent to iterate until the installation succeeds.

💡 Tip: This is a huge boost for new users because the agent can search for instructions and quickly iterate through installation failures, while you focus on reviewing the results.

After the agent successfully completes the PDK download and installation on your behalf, the agent continues with module generation.

Generating the Module

With the PDK installed, it’s time to create the first steps of a module that will accomplish your goals. Only minimal context is provided in the tutorial example for provisioning new AWS VMs. The models will attempt to create the functionality you require based on their training data, the context from the Puppet MCP server, and the context you provide. The better your prompting, the more accurate the output will be. For this tutorial, however, assume that you are not trying to generate the module in one step and will follow up with further prompting to refine the module. During this tutorial step, the agent will generate the basics of the module.

At this stage, GitHub Copilot typically performs the following actions without requiring additional prompts:

After completing installation, validates the installation by running pdk --version.
If successful, creates a module with a PDK command like pdk new module aws_provisioning --skip-interview.
After the PDK module creation logic completes processing, creates profile classes for AWS VM provisioning. This command might be pdk new class aws_provisioning or similar.
Creates additional supporting classes. In my testing, the agent ran these additional commands:
1. pdk new class aws_provisioning::config
2. pdk new class aws_provisioning::instance
After the basic structure of the classes is in place, begins implementing Puppet code for the classes. The actions resemble typical code generation steps, creating and editing a variety of files and patching them with new implementation logic.
When the initial code generation is completed on top of the PDK skeleton implementations, updates documentation such as the metadata.json file and the README file to match the needs of the generated code.

When documentation updates are completed, a typical agent might stop without validating further. However, by setting the context for the agent with knowledge of PDK and its capabilities as well as the best practices from the Puppet MCP server, the agent knows that validation of modules is an important next step.

Validating the Module

PDK supports validation of a module to ensure that it meets specific standards. Even with the best practices and instructions that were provided to the agent, along with its training, agents can make mistakes. With validation, you can catch some of these mistakes up front. Augmenting with tools is a key strategy for agentic workflows. Using the agent as an automation process to leverage the tools you have is a great way to take advantage of more deterministic capabilities along with the non-deterministic nature of the agentic automation.

For validation, the agent should attempt to use the PDK: pdk validate
PDK should find issues, even if they are only indentation issues in YAML files. The agent should then attempt to correct the issues with code assist using the output of the PDK validation.
When the patch edits are complete, the agent should run PDK validation again (pdk validate).

If more issues are found, the agent should circle back and try to resolve them, looping until no more issues are found, but typically the first run of validation should find all issues.

You can now continue your own testing and building out the module with a solid base that follows Puppet best practices! This workflow compresses the traditional learning curve and gets you to the interesting bits of your development much faster.

Key Benefits of Agent-Assisted Module Creation

This AI-assisted approach offers several key advantages over manual development:

Agent-led requirements detection and installation help you get started so that your system achieves a correct state.
Autonomous error detection and correction reduce debugging time significantly.
The agent's ability to reference the Puppet MCP server and official Puppet documentation helps to ensure that generated code follows best practices and coding standards.
Integration with PDK tooling provides deterministic automation and continuous quality checks throughout the development process.
Structured instruction files create a consistent and repeatable development experience across different projects and team members.

By building your AI-assisted flow on top of solid DevOps tools and practices, you’ll be equipped to avoid the typical challenges faced by generic coding models.

“DevOps is not dying. It is becoming the economic and operational foundation for AI at scale.

The data shows the same pattern across every domain: AI succeeds when delivery systems are standardized, centralized, automated, and measurable. Where those foundations are weak, AI magnifies existing gaps in coordination, governance, auditability, cost, and outcomes.”

- State of DevOps Report 2026

Challenges and Solutions in AI-Assisted Puppet Development

You might encounter a few common challenges when using AI agents for Puppet module generation:

According to a recent evaluation by Vercel, coding agents ignore available skills in 56% of cases, choosing not to invoke skills even when relevant documentation exists. The solution involves using instruction files that force context loading rather than relying on agent decisions. In the evaluation, Vercel found that directly embedding a compressed 8 KB docs index into an AGENTS.md file helped coding agents achieve 100% pass rates compared to 79% with skills combined with explicit instructions. In my own tests with GitHub Copilot, references from the README.md file to other instruction files helped the agent, with less sophisticated models, to find the correct instructions and load them.
Agents sometimes refuse to use PDK or read proper installation instructions, requiring iterative prompt refinement. The solution involves adding explicit installation commands, troubleshooting steps, and URL references to your copilot-instructions.md file. Ensure that you follow best practices for instructions files to keep them lean. Getting GitHub Copilot to consistently read instruction files requires understanding that passive context (always-loaded files) outperforms active retrieval (on-demand skills). Instruction files should be concise (fewer than 1,000 lines), structured with headings and bullet points, and use imperative rules rather than long paragraphs.
AI agents can get stuck in validation and fixing loops. For linting and validation errors that agents struggle to fix, adding error-specific guidance to instruction files helps GitHub Copilot learn from mistakes. The goal is to eliminate decision points by providing persistent context rather than making agents decide when to look up information.

Table 1: Common challenges in AI-assisted Puppet module development and recommended solutions

Challenge	Impact	Solution
Agents ignore MCP tools (56% of cases)	Skills documentation not invoked when needed	Use .github/copilot-instructions.md for passive context loading (achieves 100% pass rate versus 79% with on-demand skills).
PDK installation issues	Agents fail to use PDK or read installation instructions	Add explicit installation commands and troubleshooting steps to copilot-instructions.md.
Inconsistent reading of instruction files	Agent decisions create unpredictable behavior	Provide persistent context (always-loaded files) rather than relying on agent retrieval decisions.
Incorrect Puppet code or missing namespaces or invalid spacing	Generated configurations fail validation	Include specific vendor configuration examples in instruction files and use PDK validation for testing modules.
Validation errors agents can't fix	Repeated mistakes across generations	Document error-specific guidance in instruction files so agents learn from past failures.
File structure guidelines	Keep instruction files concise (fewer than 1,000 lines) with clear structure	Use headings, bullet points, and imperative rules instead of long paragraphs.

Should You Use Agent Skills or Instructions?

Vercel's research on AI agent instruction approaches provides compelling evidence to show why instruction files are essential for effective AI-assisted development. Their evaluation tested Next.js 16 API generation using four configurations:

No documentation: 53% pass rate
Skills with default behavior: 53% pass rate, same as no documentation
Skills with explicit trigger instructions: 79% pass rate
A compressed 8 KB docs index in AGENTS.md: 100% pass rate

The static markdown file outperformed sophisticated retrieval systems because the file eliminated decision points where agents must choose whether to invoke tools. In 56% of eval cases, skills were never invoked despite being available, producing no improvement over the baseline.

Although these findings were focused on web development frameworks like Next.js, similar issues occur with agents across language frameworks and IDEs. For Puppet development, my testing found that combining instructions, PDK tooling, and the Puppet MCP server gave agents the best chance to have the correct context information.

AI-assisted development is still evolving but is expected to become an important part of many DevOps team processes. The Model Context Protocol is establishing itself as an enterprise-wide standard enabling vendor interoperability, with companies like Figma, Notion, Linear, Atlassian, and MongoDB building MCP servers that work seamlessly together.

For infrastructure-as-code specifically, the shift toward “vibe coding” is opening up the opportunity for developers to express intentions in natural language rather than memorizing command-line syntax or the specifics of the Puppet Desired State Language (DSL). Given a solid base of DevOps tools across the lifecycle, from development to testing to operations, coding assistants are well positioned to take advantage of these tools, thus unlocking opportunities for more practitioners to achieve greater efficiency across the entire workflow.

References

Check out the following sources, some of which were referenced in the document, and some of which provide a deeper dive if this topic is of interest to you!

Sample instructions for GitHub Copilot and Puppet MCP server (github.com/jst-cyr)
Installing Puppet Enterprise (PE) (help.puppet.com)
Infra Assistant: code assist (help.puppet.com)
Infra Assistant: Enable the Infra Assistant (help.puppet.com)
Infra Assistant - code assist: Available MCP tools (help.puppet.com)
Infra Assistant - code assist: Configuring your client to use the MCP server (help.puppet.com)
Infra Assistant - code assist: Add the Puppet MCP server (help.puppet.com)
SAML authentication: Generate a token in the console (help.puppet.com)
View your license details | Puppet Enterprise (help.puppet.com)
Get the Puppet CA certificate chain in Puppet Enterprise (portal.perforce.com)
Build Tasks for Network Devices Faster with Code Assistance and Puppet Edge (puppet.com)
The State of DevOps Report 2026 (perforce.com)
AGENTS.md outperforms skills in our agent evals (vercel.com)
GitHub Copilot: Use MCP servers in VS Code (code.visualstudio.com)
GitHub Copilot in VS Code (code.visualstudio.com)
Using custom instructions to unlock the power of Copilot code review (docs.github.com)
Bridging the Gap: A Deep Dive into the Model Context Protocol (MCP) (dev.to)

Puppet Core 8.18.0 is out: macOS 15 support and key security updates

Jason St-Cyr — Thu, 09 Apr 2026 12:06:38 +0000

You can now download Puppet Core 8.18.0! This update adds support for macOS 15 and includes several important security updates to help keep your infrastructure protected.

As always, Puppet Core releases focus on stability, platform support, and staying ahead of reported vulnerabilities.

👉 Official Puppet Core 8.18 release notes

What’s new in Puppet Core 8.18.0

Support for macOS 15: Puppet Core now supports macOS 15 on both x86_64 and ARM architectures. This enables continued management of macOS systems using the same automation controls and policies you already rely on.

Security focused dependency updates

Security remains a top priority in every Puppet Core release. This release includes updates to several bundled components to address recently disclosed security vulnerabilities. By delivering these updates as part of hardened Puppet Core builds, you reduce dependency risk without tracking, validating, or rebuilding components independently.

🔐 libxml2 updated

libxml2 has been updated to version 2.15.2
Addresses the following CVEs:
- CVE-2026-0989
- CVE-2026-0990
- CVE-2026-0992
- CVE-2026-1757

🔐 zlib gem updated

zlib gem updated to version 3.0.1
Addresses:
- CVE-2026-27820

🔐 curl updated

curl updated to version 8.19.0
Addresses:
- CVE-2026-1965
- CVE-2026-3783
- CVE-2026-3784
- CVE-2026-3805

If you rely on Puppet Core in security‑sensitive or regulated environments, this release is strongly recommended.

Getting Puppet Core 8.18.0

You can upgrade to Puppet Core 8.18.0 using your existing Puppet Core repositories and standard upgrade workflows. Upgrading to Puppet Core 8.18.0 helps you take advantage of the latest platform support, reduce exposure to dependency related security risk, and rely on vendor-tested packages instead of managing updates yourself.

As always:

Test upgrades in a staging environment first
Review the full release notes for platform‑specific details
Roll out broadly once validated

📄 Puppet Core Installation Docs:

Let us know how it goes

If you’re upgrading to 8.18.0, running Puppet Core on macOS 15, or have feedback on this release, let us know in the comments. Your input helps shape future updates.

Happy puppeting!

Puppetlabs Modules Roundup – March 2026

Jason St-Cyr — Mon, 06 Apr 2026 14:24:03 +0000

March 2026 brought 4 Puppetlabs module releases in the Puppetlabs Forge catalog. Read along to see what changed this month!

Across the month, the clearest themes were compatibility updates across Puppet Enterprise (PE), supported platforms, and operational hardening and troubleshooting improvements.

Highlighted Updates

Compatibility updates across PE and supported platforms

March releases leaned toward version-alignment work, with updates for newer Puppet Enterprise releases, Ubuntu 24.04 benchmark coverage, and dependency ranges that allow newer supporting modules.

Added support for PE 2023.8.9 and 2025.9.0.
Added CIS Benchmark support for Ubuntu 24.04 Server Levels 1 and 2.

Operational hardening and troubleshooting improvements

Several releases focused on making "Day Two" operations safer and easier to debug through better validation, more useful logging, and targeted runtime fixes.

Added installer untar checks and deduplicated hosts in the legacy compiler group.
Moved most SCE-specific logging into the Puppet agent run log for easier debugging.

What Updates Happened to Puppetlabs Modules in March 2026?

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

cd4pe 3.4.0

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

This release focuses on updated puppetlabs-docker and puppetlabs-hocon dependencies to allow usage of newer versions while also addressing updated module with PDK 3.6.1.

Updated puppetlabs-docker and puppetlabs-hocon dependencies to allow usage of newer versions
Updated module with PDK 3.6.1

peadm 3.36.0

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

This release focuses on adding support for PE 2023.8.9 and 2025.9.0 while also addressing deduplicate hosts in legacy compiler group.

Adding support for PE 2023.8.9 and 2025.9.0 #657 (Jade2153)
(PE-43572) deduplicate hosts in legacy compiler group #658 (davidmalloncares)
(PE-42686) Add checks to installer untar command #654 (davidmalloncares)

sce_linux 2.6.0

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

This release focuses on support for Ubuntu 24.04. You can use Security Compliance Enforcement (SCE) to enforce the Center for Internet Security (CIS) Benchmark for Ubuntu Linux 24.04, v1.0.0, Server Levels 1 and 2 while also addressing support for Puppet module dependencies.

Check the official release notes for sce_linux 2.6.0

sqlserver 5.1.1

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

Small change this month to ensure permission the variable is set.

(MODULES-11613) Set permission variable in permission sql EPP #500 (shubhamshinde360)

Until Next Time!

That wraps up the March 2026 roundup. If any of the modules overlap with your environment, the linked Forge pages and release notes are worth a closer look.

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 April 2026 releases land.