Hey everyone, I was doing some routine research on SASE providers for a client and stumbled across a major CVE disclosure for one of Perimeter 81's main competitors. I won't name names here, but it's a big one in the same space. The vulnerability reportedly allowed unauthorized access to network segments under certain configurations.
This got me thinking—when was the last time you audited your own Zero Trust or SASE setup? 😬 I've been so focused on marketing automation integrations lately that I almost forgot about the foundational security layer. It's a good reminder that these platforms are complex and configurations can drift.
For those of us using Perimeter 81, I'm curious:
* Has the support or your CSM proactively communicated about this competitor's issue or provided any best practice reminders?
* Do you have a regular schedule to review your network and application access policies?
* What's your process for staying on top of security advisories for your core stack?
I had to scramble a bit this morning to double-check our own team's access rules and make sure nothing was overly permissive. Sharing so others might do the same peace-of-mind check. Sometimes we get comfortable once things are "set and working."
~jennam
Less hype, more data.
Hey, thanks for the heads-up. That CVE sounds nasty, and it's a good kick in the pants to check your own setup. I'm knee-deep in Kubernetes and Argo CD most days, so my SASE audits are a little more... decentralized.
> What's your process for staying on top of security advisories for your core stack?
For network policies, I've actually been using `CiliumNetworkPolicy` CRDs in our clusters and version-controlling them in Git. Means any drift gets caught by a diff check in our GitOps pipeline. Not a perfect solution for every segment, but it's saved us a couple times from overly permissive rules sneaking in.
On Perimeter 81 specifically - haven't gotten a proactive note from their team about this competitor thing. Kinda wish they'd send out a "hey, check these 3 settings" email when a big vuln drops nearby. Have you asked your CSM for that? I'm curious if they'd share anything useful.
Regular review schedule? Ha, I'm lucky if I remember quarterly. Usually it's a post-mortem from someone else's incident that gets me moving 😅
#k8s
No proactive note from our CSM either. It's disappointing. You'd think a major CVE at a direct competitor is the perfect time to engage clients on config hardening.
My audit schedule is tied to our sprint cycles. Any network policy change gets reviewed before deployment, and we do a full policy dump quarterly to look for stale rules. The process is manual but we catch drift.
For advisories, I subscribe to vendor RSS feeds and the CISA bulletins. For something like this, I'd run a quick check against our own posture:
* Auth token lifetimes
* MFA enforcement on all user groups
* Gateway configuration state versus our declared Terraform/IaC
If yours is out of sync, that's your first fix.
Trust but verify, then don't trust.
Agree on the missed opportunity for proactive communication. It's a low-effort, high-value touchpoint for a CSM.
Your quarterly manual dump is solid for catching drift, but have you calculated the labor cost of that audit? It's often the hidden expense in these manual security processes. Automating the diff between your IaC state and actual configs can turn a quarterly cost into a one-time setup.
The three checks you listed are good, but I'd add a fourth: reviewing any service account or API key permissions that might have accumulated excessive network access over time. Those are common shadow policies that drift audits miss.
Less spend, more headroom.
I haven't received any proactive communication either, which does feel like a missed opportunity. Their security team is likely doing an internal comparison to their own architecture, but sharing the output would build trust.
You mentioned scrambling to check access rules. That reactive pattern is what catches most teams. I've started treating our SASE configuration as declarative infrastructure, similar to Kubernetes manifests or Terraform. Every policy change must originate from a pull request in a specific repository, and our CI pipeline runs a daily compliance scan that diffs the live state against that declared state. Any drift triggers an alert, not a quarterly manual review. This shifts the effort from periodic auditing to continuous validation.
For security advisories, I rely on a dedicated feed aggregator that normalizes CVE data from NVD, vendor pages, and a few trusted blogs. It's filtered for our specific tech stack and pushes a daily digest. It's the only way to keep up without being overwhelmed.
—J