DEV Community: puppet

Where to get your vendors' SOC 2 reports (AWS, Vercel, Supabase, GitHub, Stripe and 25 more)

oded moshe — Wed, 30 Sep 2026 18:37:25 +0000

Your SOC 2 auditor will ask how you reviewed your vendors. Here is where 30 common startup vendors publish their SOC 2 report, who can download it, and what to check once you have it.

If you are preparing for SOC 2, sooner or later your auditor asks how you reviewed the vendors that touch customer data. The usual evidence is each vendor's own SOC 2 report, plus a short record of what you checked in it.

Getting the reports is fiddlier than it should be. Some live in a console, some behind a trust-center request form, and some only on certain plans. A few examples, each checked on the vendor's own pages:

AWS: download from AWS Artifact in the console, at no charge; an NDA acceptance applies.
Google Cloud / Google Workspace: Compliance Reports Manager, after signing in.
Vercel: request access through the Vercel Trust Center.
Supabase: Team and Enterprise plan customers download it from the organization dashboard.
GitHub: Enterprise Cloud owners, from the Compliance tab in enterprise settings.
Cloudflare: Super Administrators, from Compliance Documents in the dashboard, after a confidentiality statement.
Stripe: provided on request.

The full table of 30 vendors (Azure, Microsoft 365, Okta, Auth0, Datadog, Sentry, PagerDuty, OpenAI, Anthropic, MongoDB Atlas, Snowflake, Notion, Linear, Slack, HubSpot, Zoom, 1Password, Heroku, Netlify and more) is here, with links to each trust page:

https://policyseed.vercel.app/guides/vendor-soc-2-reports

Downloading the PDF is not the review

Read these six parts and write down what you found:

Type and period. A Type II covers a period of operation; a Type I is a single date. If the period ended long ago, ask for the newer report or a bridge letter.
Scope. Make sure the system description covers the product you actually use. Big vendors publish several reports.
The auditor's opinion. Unqualified is the expected result. A qualified opinion means a material problem: read which criterion and why.
Exceptions in the test results. A clean opinion can still come with individual deviations. Decide whether any affect how you use the vendor.
Complementary user entity controls. What the vendor expects you to do: enable MFA, manage your own users, configure encryption. Those become your controls.
Subservice organizations. The vendor's own vendors (often a cloud provider), usually carved out. Note them as fourth parties.

Record the date, the report period, the reviewer, any exceptions and your decision. That record, not the PDF, is what the auditor samples.

Keep it proportionate

A small company can easily use dozens of SaaS tools, and not all of them need a SOC 2 review. Tier vendors by the data they touch: the ones that store or process customer data get a full review with the report; tools with no customer data get a short documented check. Auditors look for a consistent rule applied to the whole inventory.

If you need the policy that sets those tiers and the review cadence, there is a free, editable Vendor and Third-Party Risk Management Policy template (Word or Markdown, no signup) at https://policyseed.vercel.app/policies/vendor-and-third-party-risk-policy. It is part of an open-source (Apache-2.0) set of 22 SOC 2 policies; I built it.

Cybersecurity Compliance for Developers: What "Audit-Ready" Really Means

Diginatives LLC — Mon, 28 Sep 2026 12:27:38 +0000

If you're a developer, the word "compliance" probably makes your shoulders tense. It sounds like paperwork, meetings, and someone asking you to screenshot a settings page at 5 p.m. on a Friday.

Fair. But here's the thing: cybersecurity compliance touches your code, your pipelines, and your access controls far more than it touches a spreadsheet. So it's worth understanding, especially when a customer asks, "Do you have a SOC 2 report?" and your manager turns to look at you.

Let's break it down without the fluff.

What compliance actually is

Compliance means proving, with evidence, that you follow a defined set of security practices. Note the word proving. Doing the right thing isn't enough; you need to show it.

Common frameworks you'll hear about:

SOC 2: common for SaaS companies; checks controls around security, availability, confidentiality, and more
ISO 27001: an international standard for running an information security management system
PCI DSS: required when you handle card payments
HIPAA: for healthcare data in the US
GDPR: personal data protection for people in the EU

Which one you need usually depends on your customers and your industry, not on your preference.

So what does "audit-ready" mean?

Being audit-ready means that if an auditor walked in tomorrow, you could show them what you do and prove you've been doing it consistently.

In practice, that boils down to a few habits:

Written policies that people actually follow. A policy nobody reads is decoration.
Access control. Who can reach production? Is it reviewed regularly? Do departed employees lose access the same day?
Change management. Pull requests, reviews, and approvals leave a trail. Auditors love trails.
Logging and monitoring. You can detect and investigate suspicious activity.
Risk assessments. You've identified what could go wrong and decided what to do about it.
Vendor management. You know which third parties touch your data.

Notice something? A lot of this is already sitting in Git, your cloud console, and your ticket tracker. The trick is collecting it neatly.

The developer-side checklist

Here's what tends to land on an engineering team's plate:

Enforce multi-factor authentication everywhere
Require code review before merging to main
Keep secrets out of repositories (use a vault or environment-based secrets manager)
Patch dependencies and track known vulnerabilities
Encrypt data in transit and at rest
Back up critical data and test restoring it
Keep infrastructure defined as code so changes are traceable

None of this is exotic. Most teams do half of it already, just informally.

Evidence is the boring, important part

Auditors don't take your word for it. They want samples: a list of employees with production access, a few merged pull requests with approvals, an example of a resolved security incident.

If you gather this once a year in a panic, it hurts. If you collect it continuously, say a monthly export of access reviews and a saved report from your vulnerability scanner, audit season becomes a non-event.

Small tip: name and date your files clearly. "access-review-2026-09.pdf" beats "final_v3_new.pdf" every time.

Type I vs Type II, quickly

For SOC 2, a Type I report says your controls were designed properly at one moment in time. A Type II report says they actually worked over a period, often several months. Customers usually trust Type II more, but Type I is a reasonable first step for young companies.

When to bring in outside help

Not every team has a security specialist. That's normal. Many companies hire external experts to run gap assessments, write policies, and guide them through the audit. If you're weighing that route, reading about cybersecurity compliance firms can help you understand what these partners typically offer before you start comparing them.

Others prefer to add temporary security engineers to their own team through staff augmentation, which keeps day-to-day control in-house while filling the skills gap.

Mistakes I see teams make

Treating compliance as a one-time project instead of an ongoing habit
Buying tools before understanding the requirements
Writing policies that describe how they wish things worked
Leaving engineers out of the conversation until the last minute

That last one is the big one. Bring developers in early and the controls fit your workflow. Bring them in late and everyone's annoyed.

Wrapping up

Compliance won't make you unhackable, and it isn't magic. What it does is force you to build consistent, documented, reviewable security habits, and that's valuable whether or not a customer demands a certificate.

Start small: pick one framework, list your current controls, and find the gaps. You'll likely be closer than you think.

What's been the most annoying part of compliance on your team? Drop it in the comments.

Nigerian Fintech Architecture — Six Functions CBN Will Ask About in the Sandbox Application

zikarelhub — Mon, 28 Sep 2026 08:26:23 +0000

There is one architectural diagnostic that separates CBN Sandbox-ready Nigerian fintech from products that appear ready but have critical gaps.

Can you name — precisely, with regulatory status — who performs each of these six functions in your product?

The Six Functions

const architectureDiagnostic = {
  kyc:                'Named provider + regulatory status + KYC tier satisfied',
  sanctionsScreening: 'Automated + onboarding AND ongoing + users AND counterparties',
  fxConversion:       'Named licensed entity — "Paystack" is NOT an FX licence',
  custody:            'Legally segregated — company bank account is NOT segregated custody',
  settlement:         'T+1 or T+2 — NOT the same as authorization',
  payout:             'Named executor + SLA + failed payout handling + reconciliation'
};

The Most Common Gaps

const commonGaps = [
  {
    gap: '"We use Paystack" as the FX answer',
    reality: 'Paystack is a CBN-licensed PSP. Not an FX licence holder.',
    fix: 'Named AFEX-licensed BDC, CBN-licensed IMTO or licensed fintech with FX permissions'
  },
  {
    gap: 'User funds in company bank account',
    reality: 'This is fund commingling — not segregated custody',
    fix: 'Trust/escrow account at licensed bank — separate from operational account'
  },
  {
    gap: 'Wallet credited on Paystack success',
    reality: 'That is authorization. Settlement is T+1 or T+2.',
    fix: 'Credit wallet only on confirmed settlement — not on charge.success webhook'
  },
  {
    gap: 'Sanctions screening at onboarding only',
    reality: 'Users must be screened on an ongoing basis',
    fix: 'Nightly screening job against UN, OFAC, NFIU, PEP lists'
  }
];

KYC — Named Provider Required

// Not "some verification service" — a named provider with named status
const kycSetup = {
  bvnVerification: 'NIBSS (Nigerian Inter-Bank Settlement System)',
  idVerification: 'Smile Identity / Youverify / Prembly',
  livenessDetection: '95%+ confidence required — defeats static photo attacks',
  sanctionsAndPEP: 'Included in most Nigerian KYC providers',

  // VASP track additional
  blockchainAnalytics: 'Chainalysis / Elliptic / TRM Labs — ALL incoming deposits'
};

Settlement State Machine — Required

// Authorization ≠ Settlement — model this explicitly
const STATES = {
  INITIATED:  'created — no money moved',
  AUTHORIZED: 'bank approved — NOT settled, NOT available',
  SETTLED:    'in Paystack balance — T+1 or T+2',
  AVAILABLE:  'credited to user wallet — ready for use'
};

// Available balance: only settled credits minus pending debits
const availableBalance = await ledger.query(`
  SELECT SUM(CASE
    WHEN entry_type = 'CREDIT' AND settlement_status = 'SETTLED' THEN amount
    WHEN entry_type = 'DEBIT' AND settlement_status IN ('PENDING','SETTLED') THEN -amount
    ELSE 0
  END) AS available
  FROM ledger_entries WHERE account_id = $userId
`);

The Corridor Map

// Required CBN Sandbox document
// Every entity, their regulatory status, data flows, fund flows, failure scenarios

const corridorMap = {
  entities: [
    { name: 'Your Platform', status: 'CBN Sandbox Applicant' },
    { name: 'NIBSS', status: 'CBN-regulated infrastructure' },
    { name: 'Smile Identity', status: 'Licensed KYC provider' },
    { name: 'Paystack', status: 'CBN-licensed PSP' },
    { name: 'Partner Bank', status: 'CBN-licensed commercial bank' }
  ],
  fundFlow: [
    'User → Paystack (AUTHORIZED)',
    'Paystack escrow → Paystack balance (SETTLED T+1)',
    'Paystack → Trust account at Partner Bank (AVAILABLE)',
    'Trust account → User wallet ledger (CREDITED)',
    'User wallet → Recipient via NIP (PAID OUT)'
  ],
  failureScenarios: [
    'Paystack settlement delayed — do not credit user wallet',
    'KYC provider down — queue and retry, do not onboard',
    'Sanctions match on existing user — suspend account, escalate'
  ]
};

ZikarelHub LTD is Nigeria's #1 software and digital agency — Nigerian fintech built with the architectural clarity CBN examination requires.

Which of the six functions does your product have the least clarity on right now? 👇

Building a Living Case Database: Schema, Human-in-the-Loop AI, and the Math That Kills Most Niche Sites

Hossam Saif — Thu, 24 Sep 2026 22:31:31 +0000

Most "build a niche site" posts stop at the content strategy.

This one starts where those posts usually end: the operating model.

I spent time reverse-engineering what it actually takes to run a site that publishes living case files instead of one-and-done articles. The full blueprint (architecture, data model, nine-prompt production pipeline, privacy gates, economics, and monetization) is here:

→ How to Build a True-Crime Case-Tracking Website From Scratch

What follows is the part I think is most useful for builders: the data and process decisions that determine whether the site survives past the first six months.

1. The core unit is not an article — it's a row

Every case is a structured record before it becomes a page. The schema is deliberately over-normalized from day one:

defendants, victims, attorneys, judge are foreign keys (or arrays of FKs), not free-text fields.
charges is its own table with per-charge legal status.
hearings is an append-only log (newest first).
last_verified is a first-class field that drives the stale-case metric.

Why? Converting flat text into linked entities later is one of the most painful refactors you can do on a live site. Plan for the graph even if the MVP UI still renders everything as plain text.

The page template is just a view over that schema:

Case Name / Docket
├── Status + Last Updated
├── Summary (2–3 sentences, rewritten as the case evolves)
├── Timeline (dated, newest first)
├── The Money / Harm
├── Key Documents
├── Related Cases
└── Update Log

2. The production system is nine prompts + one human gate

This is not an autonomous AI newsroom. It's a research and drafting pipeline with mandatory human sign-off on every legal-status claim, every newly named person, and every publication decision.

High-level flow:

Signal Hunter – monitors new filings, hearings, sealed-to-unsealed changes
Qualification – hard PASS/FAIL gates (primary source exists? trackable docket? privacy risk?)
Source Hunter + Claim Ledger – builds a citation table with claim ID, source, page/para, legal status, confidence
Analysis – patterns only if the ledger supports them; alternative explanations required
Entity Map – what lives on the permanent case page vs. what becomes a standalone explainer
Case File Builder – every factual sentence must cite a claim ID
Accuracy + Privacy Gate – the single most important step
Update Check – for already-tracked cases
Distribution

The privacy/accuracy gate is non-negotiable. Any open flag (minor identification, sealed records, presumption of guilt, secondary-only sources treated as fact) blocks publication.

3. The real constraint is operating capacity, not content ideas

Homicide Watch D.C. peaked at ~500k pageviews/month and still closed. The cost of keeping every active case current was effectively one full-time reporter. When the founders moved and couldn't find a local partner willing to fund that role, the site shut down.

That is the actual problem this architecture tries to solve.

Define these metrics before you publish the first case file:

Metric	Target	Warning
Active cases per editor	15–25	>30
High-activity cadence	Daily	>48h
Dormant cadence	Weekly	>14 days
Stale-case rate	<5%	>10%
Correction rate	<2 / 100	>5

Site health formula:

stale-case rate < 5% AND correction rate < 2 → the site is delivering what it promised.

stale-case rate > 10% → it has operationally collapsed, even if traffic looks great.

Size the number of active cases to what one person can actually sustain, not to what would be editorially interesting.

4. Why this is interesting for builders

Most AI content systems optimize for volume. This one optimizes for trust under continuous update pressure. The claim ledger, the hard privacy gate, and the explicit automation boundary (what AI can draft vs. what a human must sign) are the parts that make the difference between a site that can keep running and one that quietly dies when the founder gets busy.

If you're building anything that needs to stay accurate over time (case tracking, regulatory monitoring, product changelogs, research databases), the same pattern applies:

Structured schema first
Provenance on every claim
Explicit human gates on the high-risk decisions
Metrics that tell you when the operation is failing, not just when traffic is up

Full write-up with the complete prompt set, site map, monetization layers, and real-world examples (Homicide Watch, DC Witness, CourtWatch, etc.) is here:

https://www.moneytraces.com/2026/09/how-to-build-true-crime-case-tracking.html

Curious what others have found when trying to keep structured "living" data products accurate at low headcount. The operating numbers are the part most architecture posts skip.

Puppet Core 9.1 and 8.22 adds Debian 12 ARM V7L support

Jason St-Cyr — Tue, 22 Sep 2026 12:58:58 +0000

The latest releases of Puppet Core 9 and Puppet Core 8 are now available! Both releases contain the same types of changes, with minor differences in versions of components that were updated. The new Debian 12 ARM V7L is the only new addition this release while the focus of the changes are on security updates and a pair of compatibility fixes that address issues some users may have encountered in production environments.

If you're currently running Puppet Core 8.x or 9.x, this is a straightforward update worth planning for.

What Changed in Puppet Core 9.1.0 and Puppet Core 8.22.0

New agent platform: Debian 12 ARM V7L added as a supported agent platform.
Security updates: Several bundled components received updates to address recently disclosed vulnerabilities: OpenSSL, curl, libxml2, RubyGems, Ruby's resolv gem.
Compatibility fix for hiera-eyaml and Bouncy Castle
JSON dependency constraints updated to >=2.0, <4 to prevent compatibility issues with latest JSON releases.

Together these updates address more than a dozen published CVEs. If you track vulnerabilities internally, review the release notes for the complete CVE listing associated with your Puppet version.

Notes for Puppet 8 vs Puppet 9 Users

The customer-facing changes are effectively the same in both releases. There are a couple of implementation differences:

Puppet Core 8.22.0 updates OpenSSL 3.0.x, whereas 9.1.0 updates to OpenSSL 3.5.x
Puppet Core 8.22.0 ships hiera-eyaml 4.3.0, whereas Puppet Core 9.1.0 ships hiera-eyaml 5.0.1

The fixes and outcomes delivered by these updates are equivalent across both release tracks.

Full Release Notes

Before upgrading, make sure to review the release notes for your release track:

This update is a small one operationally but an important one from a security and maintenance perspective. Make sure to drop any questions you have about the release either here or in the Puppet community slack.

A New Beginning This Festive Season: The Aishwaryam Vision for Modern Homeownership

Sathish Sundaram — Tue, 22 Sep 2026 07:34:06 +0000

The festive season often brings a renewed focus on new beginnings. For many people, that can mean starting a new chapter in their personal lives, reassessing financial goals, or finally exploring the possibility of owning a home.

Link: https://www.aishwaryam.com/blog/aishwaryam-vision-festive-season-homeownership/

But modern homeownership is changing. Buyers are increasingly looking beyond the traditional idea of purchasing a house. Location, connectivity, amenities, construction quality, community, convenience and long-term lifestyle requirements are becoming important parts of the decision-making process.

This shift creates an opportunity to rethink what a new home should represent.

The Changing Meaning of Homeownership

A home is no longer evaluated only by its size or number of rooms. Today's buyers often consider how the property fits into their daily routine.

How long is the commute? Are essential services accessible? Does the neighbourhood support the family's lifestyle? Are the amenities genuinely useful? What will the ownership experience look like several years from now?

These questions are influencing how people research residential properties.

The result is a more informed approach to homeownership, where buyers compare the overall living experience rather than focusing exclusively on the property itself.

Why the Festive Season Can Be a Time for New Beginnings

The festive season traditionally represents renewal and fresh starts. From a homebuyer's perspective, it can also be a natural point to review long-term plans.

However, a festive season property investment should still be approached with the same level of due diligence as a property purchase at any other time.

Festive offers or limited-period incentives should not replace fundamental checks such as:

Project approvals and documentation
Location and connectivity
Construction quality
Developer track record
Total purchase and ownership costs
Possession timelines
Amenities and maintenance considerations
Suitability for the buyer's long-term needs

The occasion may create the motivation to explore a home, but research should guide the final decision.

What Does Modern Homeownership Look Like?

Modern homeownership increasingly revolves around convenience and adaptability.

A well-planned residential environment can bring together homes, amenities, open spaces and community-oriented features designed around everyday living.

For families considering a new home this festive season, the decision can therefore begin with a broader question:

What kind of everyday life do we want our home to support?

The answer can help narrow down choices based on location, configuration, amenities and budget.

The Aishwaryam Vision

The Aishwaryam vision focuses on creating residential environments that go beyond the basic definition of a house.

The approach places emphasis on contemporary living, thoughtful planning, quality and the relationship between homes and their surrounding environment.

For a real-estate developer, this means looking at homeownership from the resident's perspective—not simply as a transaction, but as part of a person's longer-term lifestyle.

That perspective is particularly relevant as homebuyers become more research-oriented and compare projects across multiple dimensions before making a purchase.

Technology Is Also Changing the Homebuying Journey

The way people discover and evaluate properties has changed significantly.

Buyers can now research projects online, compare locations, examine project information, watch walkthroughs, read reviews and investigate developers before scheduling a site visit.

Search engines, social platforms and AI-powered discovery tools are also becoming part of the research journey.

This makes transparency and accessible information increasingly important for real-estate brands.

A modern homeownership vision therefore extends beyond the physical project. It also includes how clearly a developer communicates information throughout the buyer journey.

A More Informed Festive-Season Decision

Buying a home is a significant financial and lifestyle decision. Festive campaigns can encourage people to begin their search, but the decision itself should be based on factors that remain relevant after the celebrations are over.

For buyers considering a new home this festive season, the process can begin with a simple checklist:

Define your needs → Research locations → Compare projects → Verify documentation → Evaluate costs → Visit shortlisted properties → Make an informed decision

A New Beginning, Thoughtfully Planned

The idea of a new beginning has always been closely connected with the festive season. In the context of homeownership, it can represent more than moving into a new address.

It can mean creating a space that supports family life, work, relationships, convenience and future aspirations.

As expectations around residential living continue to evolve, the future of homeownership will likely be shaped by a combination of thoughtful design, accessible information, technology and a deeper understanding of how people actually live.

For Aishwaryam, that is the larger idea behind its vision for modern homeownership: creating spaces where a new address can become the foundation for a new chapter.

CBN Regulatory Sandbox Cohort 2 — Technical Guide for Nigerian Fintech Builders

zikarelhub — Mon, 21 Sep 2026 11:10:27 +0000

The CBN has opened Regulatory Sandbox Cohort 2 to unlicensed Nigerian fintech startups for the first time. Here is the technical breakdown of what this means for Nigerian builders.

What the Sandbox Is and Is Not

const sandbox = {
  IS: 'Supervised testing with real users under CBN oversight',
  isNOT: 'A commercial licence or permission to scale',
  duration: '6-12 months',
  outcome: 'CBN readiness assessment for full licence application',
  cohort2Change: 'Unlicensed startups with working MVPs now eligible'
};

The Two Tracks

const tracks = {
  VASP: {
    for: ['Stablecoin settlement', 'Crypto on/off-ramps', 'Crypto wallets', 'Digital asset payments'],
    cbnChecks: ['AML/CFT for virtual assets', 'Blockchain analytics', 'Travel Rule', 'Cold storage custody'],
    additionalRegulator: 'SEC Nigeria — digital asset classification'
  },

  NON_VASP: {
    for: ['Open banking', 'Payment initiation', 'Fraud detection', 'Financial inclusion', 'RegTech'],
    cbnChecks: ['NDPA compliance', 'API security', 'Fraud controls', 'Complaints handling']
  },

  confirmWithCBN: ['Plain fiat remittance — not explicitly listed in either track']
};

Eligibility Check

function checkEligibility(startup) {
  const disqualifiers = [
    !startup.hasWorkingMVP && 'No MVP — concept stage not eligible',
    startup.hasOutstandingRegulatoryAction && 'Outstanding sanctions',
    !startup.hasInnovationBeyondExisting && 'No meaningful innovation'
  ].filter(Boolean);

  const missingCompliance = [
    'amlPolicy', 'sanctionsScreening', 'cdd',
    'consumerProtection', 'cybersecurity',
    'incidentResponse', 'dataProtection', 'namedComplianceOfficer'
  ].filter(item => !startup[item]);

  return {
    eligible: disqualifiers.length === 0,
    disqualifiers,
    complianceGaps: missingCompliance,
    readinessScore: Math.round(
      ((8 - missingCompliance.length) / 8) * 100
    )
  };
}

Don't Force a Track Fit

The most important advice for Nigerian fintech builders evaluating Cohort 2:

Do not add digital asset features just to qualify for the VASP track.

VASP adds: SEC Nigeria jurisdiction, blockchain analytics costs, Travel Rule infrastructure, custody architecture requirements and significant technical complexity. If your product is genuinely payments or open banking — the Non-VASP track is correct. The compliance overhead difference is substantial.

Tomorrow: The full readiness checklist — what CBN wants to see before you apply.

ZikarelHub LTD is Nigeria's #1 software and digital agency — CBN-ready fintech platforms built with compliance from the foundation.

Are you considering CBN Sandbox Cohort 2? Which track fits your product? 👇

A Guide to Developing HIPAA Compliant Chat for Telemedicine Apps

CometChat — Sun, 20 Sep 2026 06:16:37 +0000

Violating HIPAA is easier than it should be. One doctor-patient message through non-secure chat is enough to put you in violation and HIPAA's civil penalties run from $50,000 per violation up to $1.5 million a year for repeat offenses. That's enough to close a clinic.

HIPAA compliant chat for a telemedicine app is patient communication - text, voice, video, file sharing - that meets HIPAA's Security Rule: encrypted in transit and at rest, access-controlled, audit-logged, and covered by a Business Associate Agreement (BAA) with every vendor that touches protected health information (PHI). Miss one of those, and none of it is compliant. This guide covers what HIPAA requires, the features that matter for telemedicine, and how to build it without turning compliance into a second product you maintain forever.

What is HIPAA, and how does it apply to chat?

HIPAA - the Health Insurance Portability and Accountability Act, enacted in 1996 is the US federal law that keeps private health information secure. It sets the rules for how healthcare organizations store, manage, and grant access to patient data.

Chat is squarely in scope. Sensitive information created inside a care relationship - images, file attachments, even IP addresses - moves easily through private messages and group threads. Less-secure chat apps ship with weak encryption, thin authentication, and few controls. That's exactly the gap HIPAA exists to close.

Are you subject to HIPAA?

Two roles matter. Covered entities provide treatment, payment, or healthcare operations - hospitals, doctors, pharmacies, insurers. Business associates are the services that transmit, store, or receive PHI on a covered entity's behalf - which, since a 2013 expansion, includes cloud vendors and chat software providers serving healthcare.

If you're building a telemedicine app that handles PHI, you're a business associate. So is your chat provider. Both are on the hook.

What counts as PHI in a telemedicine app?

PHI is any information that identifies a patient and relates to their health, care, or payment for care. In a chat context that's broad:

Medical records, from an MRI scan to blood test results
Billing records and payment methods
Conversations between patient and doctor, or between clinicians
Any message, note, image, voicemail, or video created inside the care relationship plus metadata that ties a person to a treatment

Assume more PHI than you'd expect, and protect accordingly.

What HIPAA actually requires from your chat

The Security Rule splits into administrative, physical, and technical safeguards. For messaging, these are the ones you implement in code and contracts:

Requirement	What HIPAA expects	What it looks like in practice
Encryption	PHI protected in transit and at rest	AES-256 at rest, TLS 1.2 in transit
Access controls	Only authorized users reach PHI	Role-based permissions, MFA, SSO
Audit controls	A record of who accessed what, when	Logs of message and data access
Integrity	PHI can't be improperly altered or destroyed	Message integrity, retention controls
Transmission security	PHI is safe as it moves across networks	Encrypted channels for chat, calls, files
BAA	Contract making the vendor liable for PHI	A signed BAA with every processor

Two things people get wrong here.

The BAA is the one that gets skipped. A covered entity or business associate must have a signed, executed BAA with every service provider that touches PHI. If a vendor handles PHI and won't sign one, you cannot use them for a compliant workflow - no matter how good their encryption is. The Department of Health and Human Services publishes a sample BAA if you need a starting point.

There is no official HIPAA certification. No government body stamps a product 'HIPAA approved.' Compliance is a shared responsibility between you and your vendors, established through safeguards and BAAs - not a certificate. Anyone selling you a 'HIPAA certificate' is selling you a PDF. (SOC 2 and HITRUST are real certifications, and they overlap heavily with HIPAA's safeguards, being SOC 2 compliant puts you most of the way there.)

One myth worth retiring: HIPAA does not require PHI to stay on US servers. There's no data-residency rule in the law. Safeguards and a BAA are what matter though some providers still prefer US-based data centers for their own policy reasons.

Must-have vs. nice-to-have chat features for telemedicine

Requirements get you compliant. Features get you adopted. Here's the split for a telemedicine chat client.

Non-negotiable, across text and video:

Enterprise-grade encryption. All data, in transit or at rest, encrypted at AES-256 or higher.
Strong authentication. MFA plus unique credentials before anyone reaches PHI.
Automatic logoff. Doctors set devices down mid-shift. Auto-logoff keeps an unattended screen from becoming a breach.

Nice-to-have, and worth it for adoption:

Notifications and reminders. Pre- and post-care reminders cut no-shows and improve follow-through.
Rich media. Audio, video, and images together make a virtual visit feel closer to an in-person one.
Secure file sharing. Lab results and diagnostic scans move between doctor and patient without leaving the compliant channel.

For text chat, add saved history, presence, typing indicators, and multi-device sync. For video, add screen sharing, group calls (when you need a specialist), and secure recording. All of it inside the same compliant infrastructure because HIPAA covers every channel, not just the text box.

How to build HIPAA compliant chat into a telemedicine app

Building it in-house is a real option and it's a serious engineering lift plus a compliance posture you now own forever. The faster path uses infrastructure already built for it.

Run a risk assessment first. Find the security and privacy gaps before you write code. A HIPAA compliance checklist speeds this up.
Sign the BAA. Before a single message carries PHI, get the BAA in place. CometChat signs BAAs covering chat, voice, video, and notifications, so you're not chasing a separate agreement per channel.
Turn on the technical safeguards. Encryption in transit and at rest; role-based access for patients, clinicians, and care teams; MFA; and SSO. CometChat ships these rather than leaving you to assemble them.
Integrate the SDK or UI Kit. Drop in pre-built UI Kits for React, React Native, Flutter, iOS, or Android, or go lower-level with the SDKs. We've also published step-by-step tutorials for iOS and Android telehealth apps.
Confirm audit logging covers PHI access, across every channel. You need a record of who accessed what for both security and any future audit and it has to include voice, video, and files, not just text.

If you're mapping the bigger picture, our guide to telemedicine app development covers the full build, and the telehealth trends piece has the industry numbers.

Is CometChat HIPAA compliant?

Yes. CometChat is HIPAA-compliant and signs BAAs to protect PHI, and is independently certified for SOC 2 and HITRUST. It uses AES-256 and TLS 1.2 encryption, role-based access with MFA and SSO, and secure audit logs - across chat, voice, video, and notifications. Infrastructure runs on a 35+ location edge network with a 99.999% uptime SLA.

That last part matters more than it sounds. Compliance that falls over under load isn't compliance - it's a demo. Patient communication has to hold when the clinic is busy, not just when you're showing it to a stakeholder. CometChat gives you text, voice, and video ready to integrate into a telemedicine app, with the must-have and nice-to-have features already there. See the healthcare solution for the full picture.

Frequently asked questions

Is there an official HIPAA certification? No. Unlike SOC 2 or ISO 27001, HIPAA has no certifying body. Compliance is a shared responsibility between covered entities and their vendors, established through safeguards and BAAs - not a certificate.
Do I need a BAA for a telemedicine chat feature? Yes, if the chat vendor stores, processes, or transmits PHI. Without a signed BAA, using that vendor for patient communication is itself a HIPAA violation, regardless of how strong the encryption is.
Does HIPAA require end-to-end encryption specifically? Not by that name. The Security Rule requires PHI to be encrypted in transit and at rest using recognized standards - AES-256 at rest and TLS 1.2 in transit are the common bar. The rule cares about the protection, not the label.
Does HIPAA apply to video visits and voice calls, not just text? Yes. Any channel carrying PHI is in scope - voice, video, file sharing, notifications, all of it. Keeping every channel inside one compliant platform is simpler than securing each separately.
Does PHI have to stay on US servers? No. HIPAA has no data-residency requirement. Proper safeguards and a signed BAA are what keep PHI protected, wherever it's stored.
Can I build HIPAA compliant chat myself? You can, and it's a large, ongoing commitment - you own the encryption, access controls, audit logging, and compliance posture forever. Most telemedicine teams use compliant infrastructure so their engineers can build the care experience instead of maintaining a messaging stack.

Get started

Chat looks simple right up until PHI touches it. If you're building a telemedicine app and want the compliance groundwork handled before it becomes a second product to maintain, that's what CometChat is built for. Sign up and start building, or talk to our team first.

SCE for Linux: now with Debian 12 and Puppet 9 support

Jason St-Cyr — Tue, 15 Sep 2026 11:44:00 +0000

Debian 12 support and Puppet 9 compatibility are now available in version 2.9.0 of Security Compliance Enforcement (SCE) for Linux!

For teams already using SCE, this release adds CIS Benchmark enforcement for Debian Linux 12 (Bookworm) and ensures SCE can run on Puppet 9, making it easier to keep compliance automation aligned across more Linux deployments and Puppet deployments.

Other notable updates include:

Fixes for Ubuntu authentication hardening where profiles were enabled but not always applied correctly
Updates to strong cryptography enforcement on Rocky Linux 8
Resolution for file integrity monitoring initialization issues on Ubuntu

Check out the full release notes for these and other details!
➡️ SCE for Linux v2.9.0 Release Notes

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.