Patch NetScaler, then read the Labcorp terms
Free weekly email
This went to subscribers on September 29. Get the next one.
One email every Tuesday: what changed in security and compliance that week, and what it means if you sell to enterprise buyers.
Free. Unsubscribe in one click, and replies reach Jacob directly. Read the latest issue or browse the archive.
Two things happened this week that are worth your attention for different reasons. There is an actively exploited gateway bug that needs a maintenance window, and there is a settlement in the United States whose remediation terms will show up in your customers' vendor contracts within a year. The rest is context for how security reviews are shifting.
Eight NetScaler flaws, two already being exploited
Source: CISA
Citrix disclosed eight vulnerabilities in NetScaler ADC and NetScaler Gateway, and CISA added two of them to the Known Exploited Vulnerabilities catalogue. Both are critical zero-days that can each enable remote code execution on their own, and CISA says partner intelligence confirms active exploitation. Canada's Cyber Centre published its own alert on the same products the same day.
If you terminate remote access or load balancing on NetScaler, stop reading the rest of this email and go check your version. Beyond the immediate patching, a KEV listing has a second life in your sales cycle, because enterprise questionnaires increasingly ask how fast you remediate KEV-listed issues and ask you to prove it with ticket history. I would rather you have a dated change record for this one than a policy document that says you patch critical issues promptly.
Labcorp's settlement is a preview of your next vendor contract
Source: The Record
Labcorp agreed to pay $2.3 million and overhaul its security practices to settle a multistate investigation led by a coalition of state attorneys general. The required changes include an incident response plan that covers vendor security failures, limits on how much data Labcorp shares with vendors, and a risk management team that tracks whether vendors are meeting security commitments.
The penalty is small enough that nobody will remember it, and the remediation terms are the part that matters to you. Terms like these get copied into enterprise vendor programmes, which means your American buyers will start asking for evidence that they can monitor your compliance on an ongoing basis rather than once at signing. Data minimisation is the piece most Canadian SaaS companies fail on, because the product collects fields nobody has justified in years and the customer's counsel now wants that list.
A stolen OAuth token from a former employee's laptop
Source: Dark Reading
CrowdSec confirmed that attackers took the contents of 170 private repositories from its GitHub organisation. The token used was an OAuth token stolen from a former employee's computer through the TanStack npm supply chain compromise earlier this year.
Offboarding at most companies this size disables the account and stops there, leaving OAuth grants, personal access tokens and CI credentials alive behind it. Pull the list of third-party OAuth apps authorised against your GitHub organisation this week and see how many you recognise. I also treat any source code exposure as a secrets exposure until somebody has actually grepped the history, because hardcoded keys in old commits are what turn an embarrassing incident into a customer-notifiable one.
Your AI agents are logging in as humans and SOC 2 cannot tell
Source: BleepingComputer
A vendor-authored piece argues that AI agents often operate through human credentials, so actions taken by an agent look identical to actions taken by the person whose credentials it borrowed. The argument is that existing SOC 2 controls have no way to distinguish the two, leaving a gap in access review and logging evidence.
It is marketing content and the framing is overheated, but the underlying problem is one I run into on real engagements. If your agent authenticates as a staff member, your quarterly access review is describing a person who is not the one taking the actions, and your audit trail will not survive a serious customer question. Give agents their own identities with their own scopes now, while it is a half-day of work, rather than during fieldwork when the auditor has already sampled your logs.
Ottawa is looking at how a breach was disclosed, not only how it happened
Source: The Record
Canada's federal privacy regulator opened an investigation into IDScan following a data breach. The probe covers the company's security practices and, separately, whether the notifications sent to affected individuals met the requirements of the federal private-sector privacy law.
Notification adequacy being named as its own line of inquiry is the detail to take away. Almost every incident response plan I review has a solid technical section and two vague sentences about telling people, with no template, no owner and no defined clock. American buyers doing diligence on a Canadian vendor tend to ask what your obligations are under Canadian law, and a plan that answers that question specifically is one of the cheapest credibility wins available to you.
Short week ahead for anyone running Citrix gear, so I will keep the next issue light. If something breaks before Friday I will send it as it happens rather than holding it.
Jacob
Free weekly email
Get the next issue on Tuesday
One email a week from Jacob Masse: the security and compliance stories that changed something that week, and what each one means if you sell software to enterprise buyers. Five stories, a take on each, five minutes to read.
Free. Unsubscribe in one click, and replies reach Jacob directly.