Hello friends! 👋

Welcome back to Simplifying Cybersecurity, the weekly newsletter where I distill 25 years of cybersecurity experience into ideas, tools, and career hacks for every stage of the journey. This week we're covering the AI supply chain attack security teams are still untangling, a job-hunting strategy that actually works in a crowded market, and a question about your logging stack you should be asking before someone else forces you to. Let's go.

🔴 TeamPCP Supply Chain Campaign: Trivy → LiteLLM → Mercor (March–April 2026)

This one has everything: a poisoned vulnerability scanner, a stolen PyPI publishing credential, a 40-minute window on the most-downloaded AI library in Python, and a downstream breach that exposed the personal data of 40,000 contractors and potentially the internal AI training methodologies of OpenAI, Meta, and Anthropic.

It started with Trivy.

On March 19, 2026, threat actor group TeamPCP exploited a misconfigured GitHub Actions workflow in Aqua Security's Trivy project, a widely used open-source container and CI/CD vulnerability scanner. They stole CI/CD secrets and signing credentials, force-pushed malicious binaries to Trivy's release pipeline, and quietly hijacked 76 out of 77 version tags in the aquasecurity/trivy-action repository. Existing workflows across thousands of pipelines started executing attacker-controlled code while the release metadata looked clean. (Source: Arctic Wolf)

The Trivy compromise was not an end goal. It was a stepping stone.

TeamPCP used the credentials harvested from Trivy to pivot. By March 23, they had also hit Checkmarx KICS, a popular IaC security scanner, compromising its GitHub Actions and VS Code extensions. Then, on March 24 at 10:39 UTC, they published two malicious versions of LiteLLM directly to PyPI: versions 1.82.7 and 1.82.8. LiteLLM is a Python library with approximately 97 million monthly downloads, used by AI teams worldwide to connect applications to large language model APIs. It sits directly between applications and AI provider API keys, which means it routinely has access to credentials for services like OpenAI, Anthropic, and Google Gemini. (Source: Snyk, Datadog Security Labs)

PyPI quarantined the malicious packages roughly 40 minutes after publication. In that window, the infostealer payload embedded in proxy_server.py had already reached thousands of environments. (Source: LiteLLM Security Update)

Mercor was the first confirmed downstream victim. The company, a $10 billion AI recruiting startup that facilitates large-scale expert-led model training for OpenAI, Anthropic, and Meta, used LiteLLM in its infrastructure. The credential stealer gave TeamPCP access to Mercor's internal systems. (Source: TechCrunch)

The breach, confirmed March 31, exposed:

Meta indefinitely paused all work with Mercor. Five contractor class action lawsuits have been filed as of this writing. Extortion group Lapsus$ has also claimed involvement, though the connection to TeamPCP remains unconfirmed. (Source: Fortune, The Next Web)

Timeline of Key Events

Simplified Attack Flow

A word about the responders. Aqua Security disclosed the Trivy compromise publicly. LiteLLM's team posted a detailed security update the same day the malicious packages were quarantined and shared community-contributed detection scripts. That kind of rapid, transparent response deserves acknowledgment. The IR teams working these incidents were dealing with a cascading, multi-ecosystem attack in real time.

What this means for your role

TeamPCP Campaign - Ongoing Supply Chain Targeting The LiteLLM/Mercor attack was not a single incident. TeamPCP ran a coordinated, multi-ecosystem campaign across GitHub Actions, Docker Hub, npm, OpenVSX, and PyPI over roughly five weeks. Each compromise yielded credentials that unlocked the next target. Security teams should treat this as an active threat pattern, not a closed incident. Rotate credentials in any environment that ran affected versions of Trivy (v0.69.4), KICS GitHub Actions, LiteLLM (1.82.7 or 1.82.8), or Telnyx (4.87.1 or 4.87.2). (Source: Endor Labs, Help Net Security)

AI-Powered Phishing at Scale 2026 data shows 82.6% of analyzed phishing emails now show signs of AI-assisted generation. More concerning: 50% of security professionals cite hyper-personalized, AI-driven phishing as their top threat concern. The attack pattern combines behavioral data, writing style mimicry, and deepfake voice/video to bypass both technical controls and human judgment. Awareness training built around recognizing generic phishing templates is losing effectiveness. The next iteration of your phishing simulation program needs to account for this. (Source: Cynet)

Non-Human Identities as the Primary Cloud Breach Vector Tenable's 2026 forecast flags non-human identities (service accounts, API keys, tokens, machine credentials) as the top emerging cloud risk. The core problem has shifted from misconfiguration and missing patches. Billions of NHIs are operating with excessive permissions across cloud environments, and most organizations don't have full visibility into them. Strict permissions governance and automated remediation workflows are the starting point. (Source: Security Boulevard)

Compliance Certifications Under Scrutiny Post-Mercor The class action litigation tied to the Mercor breach names Delve AI, the GRC startup that issued LiteLLM's SOC 2 and ISO 27001 certifications, as a defendant. The company had claimed to compress certification timelines from months to days using AI-driven automation. This is an early signal that compliance certification vendors themselves are becoming a risk surface in the supply chain. Watch this litigation closely. It will likely reshape how procurement teams evaluate third-party compliance claims. (Source: StrikeGraph)

The security data lake vs. SIEM debate has been building for several years. The Mercor breach just added a new dimension to it.

Security teams are drowning in log volume. Containerized environments, multi-cloud deployments, and a growing stack of SaaS tools make terabytes of daily log data the norm, not the exception for mid-to-large organizations. Traditional SIEMs were built for a different era. Volume-based pricing creates hard choices about which log sources to keep and which to drop. At scale, those dropped log sources become blind spots, and blind spots become breach timelines.

Data lakes solve the volume problem. Storage in S3 or equivalent is cheap. Retention windows stretch as long as you need them. You stop making decisions about which logs to cut. But the tradeoff is real: data lakes require engineering. Every log source needs custom work to normalize into a usable schema. Query performance degrades as datasets grow without careful architecture. Teams that have tried the raw S3-plus-Athena approach often describe it as "great from a cost perspective, a disaster from a usability perspective." (Source: Cloud Security Podcast / Scanner.dev)

The Mercor breach adds a specific wrinkle. The attack pivoted through a poisoned package in an AI development pipeline, exfiltrating credentials stored in environment variables that LiteLLM could access. If your SIEM isn't ingesting pipeline logs, cloud secrets manager audit trails, and PyPI installation events in your CI/CD environment, you have a visibility gap that looks exactly like the one Mercor had. The question isn't just SIEM vs. data lake. It's: what are you not logging at all?

Why it matters to you

The job board is not the only door. Most people applying for their first security role treat it like it is.

What's actually happening on the other side of that job posting: a hiring manager is drowning. They're triaging hundreds of resumes, many of them polished by AI into nearly identical documents, trying to find one person who can actually do the work. When everything looks the same, signal disappears. Your application, no matter how good, is fighting a visibility problem, not a qualifications problem.

Maja, a career strategist and educator who wrote a widely read piece on job-hunting for students, frames it this way: a job is not a thing you find on a board. A job is a bundle of problems someone needs solved badly enough to pay another person to solve them. Once you see it that way, the question changes. Instead of "What's posted?" you start asking: Who is doing work I care about? Where are they stuck? What do I know how to do that would help them? (Source: Velvet Noise, Substack)

In security, this plays out in a few specific ways.

The front door (job boards, career pages, LinkedIn Easy Apply) is real and still worth using. But it's saturated. The signal-to-noise ratio for entry-level analyst roles is brutal in 2026. The side door is where you create a different kind of signal.

What side-door outreach looks like in security:

A student at a community college wrote a detailed breakdown of a recent CVE affecting a tool the hiring manager's company used. They posted it on LinkedIn and tagged the company. The CISO replied within two days. No job was posted.

A career changer submitted a detailed pull request fixing a documentation issue in an open-source SIEM project. A maintainer noticed. They talked. There was eventually a role.

A self-learner reached out cold to a local vCISO with a specific message: "I noticed your company is hiring for SOC analysts. I put together a quick home lab that simulates the detection scenario from the Change Healthcare breach. I'd value five minutes of your time." Not "Can I pick your brain?" Specific. With proof.

These have become the pattern.

The Hack: This week, identify one company you genuinely want to work at in security. Don't look for open roles. Look at what they're building, what threats are relevant to their industry, and where a junior analyst would add value. Then write one short, specific message (LinkedIn DM or email, 100-150 words) that demonstrates you understand their world and have something useful to offer. Include one proof artifact: a home lab screenshot, a CVE summary you wrote, a GitHub repo, anything concrete. You don't need permission to be visible. You need specificity.

🔒 Humble Bundle: Claude Code Mastery

If you're building your security knowledge base on a budget, Humble Bundle's cybersecurity book collections are worth bookmarking. Past bundles have included titles from Bruce Schneier, Kevin Mitnick, and practitioners across red team, blue team, forensics, and application security. Pay-what-you-want pricing with DRM-free downloads. A good bundle runs $18-25 for titles that would cost $300+ individually, and part of your purchase supports charity.

Check out this collection!

The LiteLLM compromise is a textbook case for why unpinned dependencies in CI/CD pipelines are a liability.

Most teams set their requirements.txt or pyproject.toml to allow floating versions. litellm>=1.80.0 is convenient. It means you get bug fixes and new features automatically. It also means you automatically got litellm 1.82.7 on March 24, 2026 if you ran a build in that 40-minute window.

Pin your dependencies. It's not glamorous. It's foundational.

Practical steps this week:

Step 1: Audit your unpinned Python dependencies.

Step 2: Pin to known-clean versions.

For LiteLLM specifically, last known-clean version before the compromise is litellm==1.82.6. Pin it explicitly.

Step 3: Add dependency integrity checking.

Use pip-audit or Snyk in your CI/CD pipeline to flag packages with known CVEs before they reach your build.

Step 4: Set up alerts for PyPI package anomalies.

Endor Labs, Snyk, and Socket all provide dependency monitoring that flags newly published versions of packages you rely on, including suspicious metadata changes. If a package you use publishes two new versions 13 minutes apart with no changelog, that's worth a look.

Step 5: Review your package installation logs.

If you were running any of the affected versions (LiteLLM 1.82.7/1.82.8, Telnyx 4.87.1/4.87.2, Trivy v0.69.4), treat your build environment as compromised. Rotate all credentials those environments had access to.

Why this matters: TeamPCP's playbook worked because security tooling itself, Trivy, KICS, is trusted implicitly in CI/CD pipelines. That trust is the attack surface. Verify before you trust, even for your security tools. (Source: GitGuardian)

Tool recommendation: pip-audit is FREE. Scans your Python environment against OSV and PyPI Advisory databases. Drop it into your pipeline today.

The Compliance Certification Problem

The Mercor litigation naming Delve AI as a defendant is worth your full attention.

Delve Technologies was a YC-backed GRC startup that issued SOC 2 and ISO 27001 certifications in days, not months, using AI automation. They had 1,700 customers across 50 countries. They had a $300 million valuation. A whistleblower alleged they were running what one source described as "fake compliance as a service." Their certifications covered LiteLLM, which is now a defendant in a class action tied to a 4TB breach affecting 40,000 people and the AI training pipelines of three of the most valuable companies on earth. (Source: StrikeGraph)

This will not be the last time this pattern surfaces.

The GRC automation space has exploded because compliance is painful and expensive. Startups promising faster, cheaper certifications found a real market need. But speed and cost are not quality signals. A SOC 2 report produced in 72 hours by an AI agent is not the same control environment as one produced through months of auditor scrutiny. Most procurement teams and vendor risk programs treat the certificate as the endpoint. It isn't.

The Play: Pull your top 10 third-party vendors. For any that hold a SOC 2 or ISO 27001, look at who issued the certification and when. If the timeline between audit start and certificate issuance was less than 30 days, schedule a deeper review. Ask for the bridge letter and the specific control evidence, not just the report. If a vendor can't produce it, that's your signal. Compliance certification is not vendor security assurance. Treat it as a starting hypothesis you verify, not a finish line.

One more thing: the Mercor breach exposed AI training data and methodologies for three frontier labs. If your organization is working with vendors who hold any access to proprietary AI development processes, AI model weights, or training pipelines, those vendors need to be treated as Tier 1 risk regardless of their size, valuation, or credential. The blast radius from an AI supply chain compromise is not bounded by the vendor's revenue.

Tool: pip-audit
Category: Software Composition Analysis / Dependency Scanning
Link: https://pypi.org/project/pip-audit/

pip-audit scans Python environments and requirements files against the Open Source Vulnerabilities (OSV) database and PyPI's advisory feed. It flags packages with known vulnerabilities, reports CVE details and fix versions, and integrates cleanly into CI/CD pipelines.

Who it's for: DevSecOps engineers, security analysts supporting development teams, students building home labs with Python tooling.

Use case:

If your team is using LiteLLM, Trivy, or any of the other affected packages in the TeamPCP campaign, run this before anything else.

Free vs. paid: Free and open-source.

Pull a threat actor profile from MITRE ATT&CK and map it to your environment.

This one takes five minutes and builds a skill you'll use for the rest of your career. Here's how to do it:

Why this works: Most security professionals have heard of MITRE ATT&CK but don't use it regularly. Making it a weekly habit trains you to think in adversary behavior rather than CVE numbers. After six months of this habit, you'll have built a working threat model for your environment. After a year, you'll be the person on your team who can answer "how would a nation-state actor get into our environment?" without needing to look it up.

What's one tool, course, or resource you wish someone had handed you when you were first getting into security? Reply and tell me. I'm building a community-sourced starter kit for the next cohort of aspiring analysts, and I want to hear what actually moved the needle for you.

Share your answer, find community, and follow the conversation at Simplifying Cybersecurity on LinkedIn.

Have a great week!

Jerod Brennen

🔗 Connect with me on LinkedIn
👥 Follow Simplifying Cybersecurity

Did someone forward this to you? Subscribe so you don't miss next week's issue. Have a question or topic you'd like covered? Hit reply. I read every message. 💬