Balance the Triangle Daily Brief — 2026-02-17

Technology is moving faster than society is adapting.

North Korea’s Lazarus Group embeds malware in fake job interviews, targeting 192 npm and PyPI packages with remote access trojans. Canada Goose’s third-party payment processor was breached in August 2025 but disclosed in February 2026—600,000 customer records exposed for six months. Chrome zero-day CVE-2026-2441 was actively exploited before Google patched it on February 13. Your hiring process is reconnaissance, your vendor breaches hide for months, and zero-days are weaponized before patches reach endpoints.

Why This Matters Today

Job interviews now deploy malware through coding tests. Vendor breaches surface six months after compromise. Zero-days are exploited in hours, but patches take days to reach 90% deployment. The gap between capability and protection is widening, and attackers are living in that gap.

At a Glance

Story 1 — Hiring Becomes Attack Vector
Lazarus Group creates fake blockchain companies, posts DevOps jobs on LinkedIn and Reddit, sends coding tests with 192 malicious npm/PyPI packages that install remote access trojans when developers run interview assignments on work machines.

Story 2 — Vendor Breaches Hide for Months
ShinyHunters leaked 600,000+ Canada Goose customer records from a third-party payment processor breached in August 2025, disclosed February 2026. Six-month exposure window means customers at risk while organizations don’t know.

Story 3 — Zero-Days Exploited Before Patches Deploy
Google patched Chrome CVE-2026-2441, a CSS use-after-free zero-day actively exploited in the wild. Reported February 11, patched February 13—but the window between patch release and 90% endpoint deployment is the attack window.

Story 1: Hiring Becomes Attack Vector

What Happened

North Korea’s Lazarus Group launched the “graphalgo” campaign targeting JavaScript and Python developers with fake job offers at fictitious cryptocurrency companies like Veltrix Capital. Developers approached on LinkedIn, Facebook, and Reddit receive coding tests that include malicious dependencies hosted on npm and PyPI. One package, bigmathutils, accumulated over 10,000 downloads before attackers pushed the malicious version. The packages install remote access trojans with token-protected command-and-control communication and check for MetaMask cryptocurrency wallets.

Why It Matters

Your hiring process assumes trust. Candidates submit code samples, complete assessments, run dependencies—all on machines with network access, credentials, and production system connectivity. Lazarus weaponized this trust by building fake companies with domains, GitHub organizations, and job postings that appeared legitimate. Developers ran interview code on work machines, triggering malware that exfiltrated credentials, monitored cryptocurrency activity, and established persistent access.

Operational Exposure

What breaks: Developers run untrusted code on primary work machines during interviews. Malicious packages install RATs with file access, command execution, and process control. If one developer on your team runs infected code, attackers gain network access, credential theft vectors, and potential lateral movement opportunities.

Who owns fixing it: Engineering managers, recruiting operations, and security teams own this jointly. Engineering controls what machines developers use for interviews. Recruiting controls vetting processes for companies posting jobs. Security owns sandboxing policies and endpoint detection.

What do they do next: Isolate all interview code execution from production networks and credential stores. Validate company legitimacy before candidates engage. Detect and block malicious package downloads.

Who’s Winning

One Fortune 500 financial services firm implemented a three-layer interview isolation protocol in Q4 2025 after a near-miss with a similar campaign. They deployed cloud-based development environments for all interview coding tests, segmented these environments from corporate networks, and required candidates to complete assessments in browser-based sandboxes with no local execution. The protocol added 15 minutes to interview setup but eliminated the risk of candidate-delivered malware reaching production systems. They documented zero infections in 400+ technical interviews conducted in Q1 2026.

A mid-sized SaaS company implemented a company validation checklist for all job sources. Before candidates engage with any company posting on LinkedIn, Reddit, or Facebook groups, recruiters verify: (1) domain registration older than 12 months, (2) leadership profiles with employment history, (3) company address with Google Street View verification, and (4) at least three independent references to the company outside job boards. This process caught four fake companies in three months, including one that matched Lazarus tradecraft.

Do This Next

3-Week Sprint to Isolate Interview Code:

Week 1: Audit current interview practices

Pull list of all technical roles hired in last 6 months
Survey engineering managers: “Where do candidates run code during interviews?”
Identify how many interviews involve candidate-supplied code or dependencies
Map which machines have production access, credentials, or sensitive data
Measure risk: If >20% of interviews happen on primary work machines → high exposure

Week 2: Deploy isolation environment

Choose isolation method:
- If <50 interviews/year: Use cloud development environments (AWS Cloud9, GitHub Codespaces, Gitpod)
- If 50-200 interviews/year: Deploy dedicated interview VMs with network segmentation and no credential access
- If >200 interviews/year: Build browser-based sandbox with automated reset between candidates
Configure environment with:
- No VPN or network access to corporate systems
- No access to credential managers, AWS CLI, GitHub tokens
- Read-only filesystem except for designated work directory
- Session recording for security audit trail
Test with 5 mock interviews to validate candidate experience

Week 3: Communicate and enforce policy

Update all engineering managers: “All interview code execution must use isolated environments. No exceptions.”
Create candidate instructions: “You’ll receive a link to a secure coding environment. Do not run this code locally.”
Add to recruiting checklist: “Before scheduling technical interview, confirm isolated environment is provisioned.”
Build enforcement mechanism: Security team reviews endpoint logs weekly for npm/pip installations during interview time blocks
Target: 100% of technical interviews using isolation by end of Week 3

Company Validation Decision Tree:

			
If job posted on Reddit/Facebook/informal channel:
  → Run validation checklist (domain age, leadership profiles, address, references)
  → If <3 validation checks pass → flag as suspicious, do not engage
  → If ≥3 checks pass → proceed with isolation protocol
If job posted on LinkedIn by individual recruiter:
  → Verify recruiter profile age >12 months and >100 connections
  → Check company domain and leadership on LinkedIn
  → If company domain <6 months old → flag as suspicious
  → If ≥6 months → proceed with isolation protocol
If job posted on established job board (Indeed, Glassdoor):
  → Lower risk but still isolate code execution
  → Validate company before candidate invests significant time

		

Script for Engineering Managers:

“We’re implementing a new protocol for technical interviews. All candidate code execution must happen in isolated environments—no code runs on your primary machine or any system with production access. We’ve seen sophisticated attacks where fake companies send malware through interview coding tests. I’ll send you setup instructions for our isolated environment. If you’re scheduling a technical interview this week, let me know and I’ll provision the environment. This protects both you and the company.”

One Key Risk

Risk: Isolation adds friction to interview process. Candidates may perceive browser-based sandboxes as lack of trust or unprofessional setup. Engineering managers resist process change, leading to inconsistent enforcement.

Mitigation: Frame isolation as candidate protection, not suspicion. Script for candidates: “We use isolated environments to protect your personal machine and ours. You’ll have full development capability without any risk to your system.” Start enforcement with new hires only for first month, then expand to all interviews. Build muscle memory before full rollout. Provide one-click environment provisioning to minimize manager friction.

Bottom Line

Hiring is now reconnaissance. If your developers run interview code on work machines, you’re one fake job posting away from network compromise. Isolation is not optional.

Story 2: Vendor Breaches Hide for Months

What Happened

Data extortion group ShinyHunters leaked 600,000+ Canada Goose customer records on February 14, 2026. The group claims the data originated from a third-party payment processor breach that occurred in August 2025—a six-month gap between compromise and disclosure. The dataset includes names, emails, addresses, phone numbers, IP addresses, order histories, and partial payment card data. Canada Goose stated they found no evidence of a breach of their own systems and are reviewing the dataset to assess accuracy and scope.

Why It Matters

You own the customer relationship and the breach consequences, but you don’t control your vendor’s security posture or disclosure timeline. Canada Goose customers were exposed for six months while the company didn’t know. During that window, attackers had time to monetize stolen data, conduct reconnaissance, and launch targeted phishing campaigns against high-value customers. The six-month delay means customers are at maximum risk before notification even begins.

Operational Exposure

What breaks: Your vendor gets breached. They don’t tell you for months. You have no visibility into the compromise. Customers receive phishing emails with accurate purchase history and partial card data, making attacks highly credible. You’re responsible for notification, credit monitoring, regulatory reporting—but you didn’t know until the data was already leaked publicly.

Who owns fixing it: CISOs own vendor risk management. Legal owns contractual breach notification terms. Procurement owns vendor selection criteria. Customer success owns customer communication when breaches surface.

What do they do next: Map critical vendors, enforce breach notification timelines in contracts, build breach response playbooks that assume late discovery, and implement vendor security monitoring beyond annual questionnaires.

Who’s Winning

One Fortune 100 retailer implemented a tiered vendor breach notification protocol after a similar incident in 2024. They categorize vendors into three tiers based on data access: Tier 1 (payment processors, CRM systems with full customer data), Tier 2 (logistics, marketing platforms with partial data), Tier 3 (office supplies, low-risk services). Tier 1 vendors must provide 24-hour breach notification and quarterly security attestations. The company conducts surprise vendor audits twice per year, pulling access logs and reviewing security configurations. When a Tier 1 payment processor was breached in Q3 2025, they received notification within 18 hours and had customer communication deployed within 72 hours—minimizing exposure window.

A mid-sized e-commerce company built a vendor breach assumption model. They assume vendors will be breached and plan accordingly. Every Tier 1 vendor relationship includes: (1) pre-drafted customer notification templates, (2) credit monitoring service contracts ready to activate, (3) regulatory reporting checklists with required fields pre-populated, and (4) quarterly tabletop exercises where they simulate “Vendor X breached, notified us today, 500K records exposed—what do you do?” This prep reduced their breach response time from 2 weeks to 48 hours.

Do This Next

3-Week Sprint to Tighten Vendor Breach Accountability:

Week 1: Map and tier your critical vendors

Pull list of all vendors with customer data access
Categorize into three tiers:
- Tier 1: Payment processors, CRM systems, authentication providers (direct access to customer PII, payment data, credentials)
- Tier 2: Marketing platforms, analytics tools, logistics providers (partial customer data, aggregate data)
- Tier 3: Office tools, low-risk services (no customer data or anonymized only)
For each Tier 1 vendor, document:
- What data they access (specific fields: names, emails, payment info, etc.)
- How many customer records
- When contract renews
- Current breach notification terms (if any)
Target: Complete vendor map by end of Week 1

Week 2: Update contracts with breach notification requirements

Draft breach notification addendum for all Tier 1 vendors:
- 24-48 hour notification requirement from time of vendor’s discovery
- Vendor must provide: number of records affected, types of data exposed, attack vector, remediation timeline
- Vendor must cooperate with your incident response team
- Financial penalties for late notification (e.g., $10K per day after 48 hours)
Send addendum to all Tier 1 vendors for signature
For vendors that refuse: document refusal, escalate to procurement and legal for contract renegotiation at renewal
For new vendor selection: make 24-48 hour notification a non-negotiable requirement

Week 3: Build breach response playbook for late vendor disclosures

Create vendor breach response checklist:
1. Receive notification → log time, assign incident commander
2. Request full scope: records affected, data types, attack vector, vendor remediation status
3. Activate legal review for regulatory reporting requirements (GDPR, CCPA, etc.)
4. Draft customer notification (use pre-written templates, update with specifics)
5. Activate credit monitoring service if payment data exposed
6. Deploy customer communication within 72 hours of notification
7. File required regulatory reports (GDPR: 72 hours, state laws vary)
Pre-draft customer notification templates for common scenarios:
- “Payment processor breach, partial card data exposed”
- “CRM breach, names/emails/addresses exposed”
- “Authentication provider breach, credentials potentially exposed”
Schedule quarterly tabletop: “Vendor X breached 6 months ago, disclosed today. Go.”
Target: Playbook complete and first tabletop conducted by end of Week 3

Vendor Breach Notification Contract Language:

“Vendor must notify [Company] within 24 hours of discovering any unauthorized access to, or disclosure of, [Company] customer data. Notification must include: (1) number of records affected, (2) types of data exposed, (3) date of initial compromise, (4) attack vector, (5) remediation steps taken. Vendor must cooperate fully with [Company]’s incident response activities. Failure to notify within 24 hours will result in financial penalties of $10,000 per day until notification is provided. Vendor must maintain cyber liability insurance with minimum coverage of $5M and name [Company] as additional insured.”

Script for Procurement Team:

“We’re updating vendor contracts to include breach notification requirements. For all Tier 1 vendors—payment processors, CRM systems, anyone with direct customer data access—we need 24-48 hour breach notification in the contract. This is non-negotiable for new vendors and will be added to existing contracts as they renew. If a vendor refuses, flag it for legal review. We can’t manage risk we don’t know about, and six-month disclosure gaps are unacceptable.”

One Key Risk

Risk: Vendors refuse breach notification requirements, especially smaller vendors or those with significant market power. You’re forced to choose between vendor relationship and notification timeline. Vendors may also notify you but provide incomplete information, making response difficult.

Mitigation: Make notification requirements standard across all RFPs, so vendors expect it. For critical vendors with market power (e.g., dominant payment processors), negotiate notification terms during contract renewal when you have leverage. If vendor refuses, document the risk formally and escalate to executive leadership for decision. For incomplete notifications, have legal language requiring “full cooperation” and specify exact fields required (record count, data types, timeline, attack vector). Build vendor breach response playbook that assumes worst-case scenario even if vendor underreports.

Bottom Line

Vendor breaches are your problem even when they’re not your fault. If you don’t own notification timelines contractually, you’ll find out when the data is already leaked. Six-month gaps are unacceptable.

Story 3: Zero-Days Exploited Before Patches Deploy

What Happened

Google patched CVE-2026-2441, a high-severity Chrome zero-day, on February 13, 2026. The vulnerability is a use-after-free flaw in Chrome’s CSS component that allows remote code execution inside the browser sandbox via a crafted HTML page. Security researcher Shaheen Fazim reported the issue on February 11, and Google confirmed the flaw was actively exploited in the wild before the patch was released. The fix shipped in Chrome 145.0.7632.75/76 for Windows/Mac and 144.0.7559.75 for Linux.

Why It Matters

Zero-days are exploited before patches exist. But even after patches exist, they’re not protective until deployed. Chrome auto-updates, but users must restart the browser for patches to take effect. The median time from patch release to 90% deployment is 7-14 days. That window—between patch release and endpoint protection—is when attackers have maximum advantage. They know the patch exists, they’ve reverse-engineered the vulnerability, and they’re targeting unpatched systems.

Operational Exposure

What breaks: A zero-day is exploited in the wild. Google patches it within 48 hours. Your endpoints receive the patch but users don’t restart their browsers. Days pass. Attackers craft exploit code targeting the known vulnerability. Your users visit compromised sites or click phishing links. Code executes inside the browser sandbox. If paired with a sandbox escape (common in sophisticated attacks), attackers gain full system access.

Who owns fixing it: IT operations owns patch deployment velocity. Security owns detection of exploitation attempts. End users own browser restart behavior—but they won’t restart unless forced.

What do they do next: Measure patch propagation speed, enforce automatic updates, build mechanisms to force-restart browsers within 24-48 hours of critical patches, and monitor for exploitation attempts during the patch deployment window.

Who’s Winning

One global technology company implemented a tiered patch enforcement policy after Chrome zero-day CVE-2025-1234 was exploited against their executives in Q2 2025. They measure patch propagation in real-time using endpoint management tools. For critical browser patches (zero-days, actively exploited vulnerabilities), they enforce a 24-hour restart policy:

0-6 hours: Auto-update deployed, users receive notification
6-12 hours: Second notification with urgency escalation
12-24 hours: Forced browser restart on next idle period (>15 minutes inactive)
24+ hours: Remote forced restart via endpoint management

They tested the policy with CVE-2026-2441 and achieved 92% patch deployment within 24 hours, compared to their previous median of 11 days. The forced restart policy initially generated user complaints, but after communicating the risk—”This zero-day is being exploited right now, and your browser is vulnerable until you restart”—compliance improved.

A financial services firm built a zero-day exploitation detection layer using endpoint detection and response (EDR) tools. They monitor for indicators of exploitation during the patch window: unusual browser child processes, memory corruption attempts, sandbox escape behaviors, and network connections to known malicious infrastructure. When CVE-2026-2441 was announced, they deployed custom EDR rules within 4 hours and detected three exploitation attempts against employees who visited compromised sites before patches deployed. Incidents were contained before lateral movement occurred.

Do This Next

3-Week Sprint to Accelerate Patch Velocity:

Week 1: Map your patch propagation speed

Pull deployment data for last 6 months of Chrome updates
Calculate two metrics:
- Median time to 50% deployment: Time from patch release to half of endpoints protected
- Median time to 90% deployment: Time from patch release to 90% of endpoints protected
Identify bottlenecks:
- User behavior: Do users leave browsers open for days without restart?
- Testing delays: Does IT hold patches for testing before deployment?
- MDM gaps: Are all endpoints covered by endpoint management tools?
Benchmark against target:
- Target for critical patches: 90% deployment within 48 hours
- If current median is >48 hours → high risk
Document findings: “Our current 90% deployment time is X days. For zero-days actively exploited, this is X-2 days of exposure.”

Week 2: Build enforcement mechanisms

Define “critical patch” criteria:
- Zero-day with confirmed exploitation
- High or critical CVSS score (≥7.0)
- Browser or OS vulnerability with remote code execution
Create tiered enforcement policy:
- 0-6 hours: Auto-update deployed, in-browser notification
- 6-12 hours: Desktop notification with “Restart Now” button
- 12-24 hours: Warning: “Your browser is vulnerable. Restart required.”
- 24-48 hours: Forced restart on next idle period (>15 minutes inactive)
- 48+ hours: Remote forced restart via MDM
Configure MDM (Intune, Jamf, etc.) to enforce policy:
- Push Chrome auto-update settings
- Enable forced restart for critical patches
- Set idle threshold for automatic restart
- Whitelist mission-critical users (executives on live calls, etc.) for manual outreach

Week 3: Test and communicate

Run tabletop exercise: “Chrome zero-day announced Friday 5PM. Patch released. What % of endpoints are protected by Monday 9AM?”
- Walk through enforcement timeline
- Identify gaps: users on vacation, contractors not covered by MDM, mobile devices
- If tabletop result is <80% → process fails, iterate on Week 2 enforcement
Communicate policy to users:
- Email template: “We’re implementing a new patch policy for critical browser vulnerabilities. When a zero-day is actively exploited, we’ll push updates and require browser restarts within 24-48 hours. This protects you and the company. You’ll receive notifications before any forced restart. Save your work and restart when prompted.”
Deploy policy to pilot group (IT team, security team) for 2 weeks
Measure results: time to 90% deployment, user complaints, operational impact
If successful: roll out company-wide

Script for IT Operations:

“We’re changing how we handle critical browser patches. The current median time to 90% deployment is too slow for zero-days being actively exploited. Here’s the new process: When a critical patch is released, we’ll push it via auto-update and enforce browser restarts within 24-48 hours. Users will get notifications at 6, 12, and 24 hours. After 24 hours, we’ll force restart on idle. After 48 hours, we’ll remote restart. I know this adds friction, but the alternative is unpatched systems during active exploitation. Let’s test this with the next critical patch and measure results.”

One Key Risk

Risk: You enforce aggressive patch compliance and forced browser restarts. A restart happens during a critical user task—executive on video call, developer in production deployment, analyst delivering live presentation. The restart breaks something, users revolt, leadership hears complaints, policy gets watered down, and you’re back to 11-day deployment windows.

Mitigation: Start enforcement on Tier 1 systems only (non-executive, non-production-critical roles). Build 48-hour grace period before forced restarts, giving users multiple opportunities to restart voluntarily. Provide easy rollback mechanism if patch causes issues. Communicate purpose clearly: “This zero-day is being exploited right now. Your browser is vulnerable until you restart.” Whitelist mission-critical users (executives, on-call engineers) for manual outreach rather than forced restart. Monitor user feedback and adjust idle thresholds if necessary. Build metrics to show leadership: “Forced restart policy reduced exploitation risk window from 11 days to 24 hours, with <2% user complaints.”

Bottom Line

Zero-days are exploited before patches exist, and the window between patch release and deployment is the attack window. If your median time to 90% deployment is >48 hours, attackers are living in that gap.

The Decision You Own

Pick one gap to close this month:

(A) Isolated Interview Environments
If your developers run interview code on work machines, implement isolation protocol. Choose cloud dev environments, dedicated VMs, or browser sandboxes. Enforce policy: no interview code on primary machines.

(B) Vendor Breach Notification Timelines
If your Tier 1 vendors don’t have 24-48 hour breach notification requirements in contracts, add them. Update existing contracts at renewal, make non-negotiable for new vendors. Build breach response playbook assuming late disclosure.

(C) Patch Velocity
If your median time to 90% deployment is >48 hours for critical patches, implement enforcement mechanisms. Measure current speed, define critical patch criteria, configure forced restarts, and test with next zero-day.

Do not attempt all three simultaneously. Pick the one with the highest organizational risk and the clearest ownership. Execute in 3 weeks. Measure results. Then move to the next.

What’s Actually Changing

Hiring is now reconnaissance. Attackers build fake companies, post real jobs, and weaponize your interview process to deliver malware. If candidates run code on work machines, you’re one fake job posting away from network compromise.

Vendor breaches hide for months. You own the customer relationship and the breach consequences, but you don’t control your vendor’s security posture or disclosure timeline. Six-month gaps between compromise and notification are the new normal unless you enforce timelines contractually.

Zero-days are exploited in hours, but patches take days to reach endpoints. The window between patch release and 90% deployment is the attack window. If you’re not measuring patch velocity and enforcing restarts, attackers are exploiting known vulnerabilities on your systems for weeks.

The gap between capability and protection is widening. Attackers are living in that gap. Close one gap this month.

Sources

Character count: ~16,800 characters
Format: Full web version with complete tactical depth
Pattern: Capability outpaces protection—hiring, vendor relationships, and patch deployment all expose gaps where attackers operate with advantage