// ELUSIVE THOUGHTS — APPSEC / OWASP

Software Supply Chain Failures: The OWASP Category That Eats Everything

Posted by Jerry — May 2026

OWASP Top 10 2025 added Software Supply Chain Failures as a top-level category. The change reflects what every working application security professional has been seeing for two years: the supply chain is the dominant attack vector, and it is structurally distinct enough from "vulnerable components" to deserve its own category.

The numbers behind the elevation are not subtle.

Sonatype's State of the Software Supply Chain 2024 reported more than 700,000 malicious packages found across npm, PyPI, and Maven since 2019, with a 156 percent year-over-year jump. Indusface's State of Application Security 2026 reports 6.29 billion attacks targeting website vulnerabilities in 2025, up 56 percent year-over-year. The median time to weaponization of a disclosed vulnerability is now under five days. 54 percent of critical vulnerabilities face active exploitation within the first week of disclosure.

This is the category. This is what is happening.

// what makes supply chain different from "vulnerable components"

The previous OWASP category — A06:2021 Vulnerable and Outdated Components — focused on the use of components with known vulnerabilities. The fix was conceptually clear: keep components updated, scan for known CVEs, replace deprecated libraries.

Supply chain failures are a superset that includes scenarios where the component is not "vulnerable" in any classical sense, because it was deliberately weaponized:

SCENARIO 1 — MAINTAINER ACCOUNT COMPROMISE

An attacker steals or socially engineers credentials to a package maintainer's account. They push a malicious version under the legitimate maintainer's identity. The Axios npm compromise of March 2026, attributed to North Korean threat actor UNC1069, used patient social engineering of the lead maintainer to gain account access. The Bitwarden CLI npm compromise used a similar pattern.

SCENARIO 2 — BUILD PIPELINE INJECTION

The malicious code is injected during the build process, not in the source. The Trivy GitHub Action compromise modified release tags after the build had completed, redirecting downstream consumers to attacker-controlled artifacts. Source review would not catch this. The artifact in the registry differed from the source in the repository.

SCENARIO 3 — TYPOSQUATTING AND DEPENDENCY CONFUSION

Attackers register packages with names similar to legitimate ones (requets vs requests, colorama-py vs colorama) or names matching internal company packages on public registries. PyPI removed hundreds of malicious typosquats per month throughout 2024 according to Checkmarx and Phylum tracking. The pattern continues in 2026.

SCENARIO 4 — TRANSITIVE DEPENDENCY POISONING

The infected package is not a direct dependency. The PyTorch Lightning compromise propagated through pyannote-audio, infecting consumers who never directly installed Lightning. The further the malicious component is from the consumer's direct dependency declaration, the harder it is to detect with manual review.

SCENARIO 5 — TAG MUTATION

GitHub Actions and similar systems allow tags to be reassigned to point at different commits. An attacker who compromises the publishing pipeline can force-push tags to point at malicious code. Every workflow that references the action by tag silently runs the malicious code on next execution.

SCENARIO 6 — MODEL WEIGHT TAMPERING

The AI model supply chain is the newest layer. HuggingFace incidents through 2024 and 2025 demonstrated that model weights can be manipulated to embed backdoors that activate on specific inputs. The OWASP LLM Top 10 covers this under its supply chain category, which overlaps with the new core OWASP category.

SCENARIO 7 — TOOL DESCRIPTION INJECTION

For LLM agent ecosystems, malicious instructions can be embedded in tool descriptions that the agent processes during MCP server registration. The MCPTox benchmark found that more than 60 percent of popular agents are susceptible to this class of attack. The compromise is in the metadata, not the code, which makes traditional code review insufficient.

// the defensive playbook

The defensive techniques against this category are mostly known. Adoption is the gap. The list below is what produces real reduction in supply chain risk, ordered by effort to value ratio:

1. Lockfile and integrity hashes everywhere. package-lock.json, yarn.lock, poetry.lock, Pipfile.lock, Gemfile.lock, go.sum, Cargo.lock. No exceptions. Every CI job that installs dependencies must use the lockfile. Most ecosystems support integrity hashes — use them.
2. Pin GitHub Actions to commit SHA, not version tag. Tags are mutable. SHAs are not. The diff between uses: aquasecurity/trivy-action@master and uses: aquasecurity/trivy-action@a3e4f... is the difference between a vulnerable workflow and a hardened one.
3. Sigstore verification on package install where the ecosystem supports it. npm audit signatures. PyPI attestations. Cosign for container images. The verification is fast and the cost is low. The benefit is non-trivial.
4. Behavioral analysis at install time. Socket, Phylum, Snyk Reachability, JFrog Curation, Checkmarx Supply Chain. These tools execute or sandbox new packages and flag suspicious behaviors — unexpected network calls, filesystem access, postinstall scripts that match known malware patterns. Catches attacks that signature-based tools miss.
5. Internal proxy with quarantine period. Net-new dependencies — packages your organization has never used before — go through a quarantine period during which they are scanned, behaviorally analyzed, and reviewed before being available to developers. Most malicious packages are caught in the first 24 to 72 hours after publication. A quarantine period eats most of the risk window.
6. SBOM generation in CI for every release. The starting point for vulnerability triage and supply chain analysis. Required by EU CRA. Useful regardless.
7. Namespace ownership for internal packages. Register your internal package names as stubs on the public registry. Prevents dependency confusion attacks where an attacker publishes a public package matching your internal name.
8. Egress control on build runners. The build runner has unrestricted internet access by default. Constraining its outbound network destinations to known package registries and known internal services eliminates an entire class of exfiltration paths.
9. Disable install-time script execution where feasible. npm install --ignore-scripts. pip install with PEP 517 isolation. Some legitimate packages break, requiring an allowlist. The remaining attack surface is much smaller.
10. Provenance attestations on your published packages. npm publish --provenance generates SLSA-style provenance metadata that downstream consumers can verify. Free signal that protects your users.

// the part that is not technical

The honest takeaway from every supply chain incident I have read post-mortems on: the open source supply chain is held together by individual humans who notice things. Andres Freund noticing 500ms of unexplained latency and discovering the XZ backdoor. The crypto developer who noticed an anomalous Lottie transaction. The Sansec engineer who spotted the polyfill.io rewrite. The Lightning maintainers who discovered their PyPI compromise via user reports.

Tools narrow the attack surface. Tools do not eliminate it. The durable defense is a team that has time to investigate anomalies. The unfashionable, unscalable, irreplaceable component of supply chain security is human attention and engineering judgment.

The investment that produces the highest return: give your senior engineers explicit budget for "weird things in the build." The next XZ-class incident will be caught by someone paying attention. Make sure that someone exists in your organization, and that their attention is not consumed by dashboards.

// the bottom line

Software Supply Chain Failures earned its OWASP Top 10 spot the hard way. The category is not going to shrink. The attack surface keeps expanding — new package ecosystems, new model registries, new agent tool catalogs.

The defensive playbook is mostly known. The work is adoption. The teams that close their supply chain gaps in 2026 will read about other people's incidents in 2027. The teams that do not will be in the news.

$ end_of_post.sh — what's your organization's biggest supply chain gap? honest answers welcome.

// ELUSIVE THOUGHTS — APPSEC / SUPPLY CHAIN

SBOM Is Necessary. SBOM Is Not Enough. Meet PBOM.

Posted by Jerry — May 2026

The Software Bill of Materials movement won the policy battle. EU CRA mandates them. US Executive Order 14028 mandates them. Every government procurement framework requires them. Every supply chain security vendor talks about them.

An SBOM is necessary. It is also, by itself, structurally insufficient against the supply chain attacks that the SBOM movement was supposed to prevent.

This post explains why, and what comes next: the Production Bill of Materials, or PBOM.

// what an sbom actually tells you

An SBOM is a manifest of components that were intended to be in a build. Generated typically at CI time, signed at release, stored as an artifact, distributed with the product.

The intended uses are clear. Vulnerability triage — when CVE-2026-X is announced for library Y, every SBOM that lists library Y is a potential exposure. Compliance — regulators can verify that products meet their declared component lists. Supply chain analysis — organizations can map their dependency graphs and identify concentration risk.

The SBOM is generated from the source. It reflects what the build process was supposed to produce. It is, fundamentally, a document about intent.

// why intent is not enough

Look at the supply chain attacks of 2025 and 2026 and notice a pattern.

The PyTorch Lightning compromise of April 2026 — the malicious version 2.6.2 was published directly to PyPI by an attacker with the maintainer's credentials. The Lightning team confirmed: "An attacker with access to our PyPI credentials cloned our open source code, injected a malicious payload, and pushed those tampered builds directly to PyPI as malicious versions, bypassing our source control entirely."

The Bitwarden CLI npm compromise of late April 2026 — same pattern. The malicious code went directly to npm. The GitHub repository was clean throughout.

The Trivy GitHub Action compromise — TeamPCP force-pushed tags to point at malicious code. The repository's main branch was unaffected. The release tags were the attack surface.

In all of these cases, an SBOM generated from source would be clean. The malicious artifact was introduced at the registry level, not the source level. The downstream consumer's SBOM, generated against the source they pulled, would also be clean. Because the SBOM is a document about intent, and the attacker bypassed the intent layer entirely.

The attacker is not in your source. The attacker is in your runtime.

// the pbom concept

A Production Bill of Materials is a manifest of what is actually running. Generated at runtime, by inspecting deployed processes, loaded libraries, container layers, and active configurations.

Where the SBOM answers "what was supposed to be in this build?", the PBOM answers "what is actually executing right now?"

The two should match. When they do not, something is wrong. Either the deployment was corrupted, the supply chain was compromised, or the build process was tampered with. The reconciliation between SBOM and PBOM is the actual security signal.

// how a pbom is constructed

Several techniques contribute to PBOM generation. The current state of the practice combines them.

TECHNIQUE 1 — CONTAINER LAYER ANALYSIS

For containerized workloads, the running container's image layers can be inspected to enumerate installed packages, files, and binaries. Tools like Syft, Trivy, and Grype can generate this from a running container or its image. The output is a list of components that were actually present at deploy time, which may differ from what was specified in the Dockerfile if the base image was updated, if a layer was rebuilt, or if a registry-level compromise occurred.

TECHNIQUE 2 — RUNTIME PROCESS INSTRUMENTATION

eBPF-based runtime inspection can enumerate the libraries actually loaded by running processes, the network connections they make, and the files they access. This catches dynamically loaded dependencies that may not appear in static analysis. Tools like Tetragon, Falco, and the runtime modes of several ASPM platforms produce this signal.

TECHNIQUE 3 — ARTIFACT ATTESTATION VERIFICATION

Sigstore and similar attestation frameworks let you verify at deployment time that the artifact you are pulling matches a trusted signing identity. The verification step itself produces a record of what was actually pulled, which becomes part of the PBOM. npm install with --provenance and Docker pull with cosign verification both contribute to this.

TECHNIQUE 4 — DEPLOYMENT MANIFEST CAPTURE

For Kubernetes and similar orchestrators, the deployed pod specs, image digests, and configmaps can be captured at deploy time. These are immutable references to what was actually scheduled, regardless of what the Helm chart or Terraform module said. Reconciling deployed manifests against their source-controlled definitions is part of the PBOM workflow.

// the reconciliation gap

SBOM and PBOM should agree. When they do not, you have a signal worth investigating.

Common patterns of divergence:

1. Image base layer was updated after the SBOM was generated. New CVEs may apply that the original SBOM did not capture.
2. A dependency was introduced via a transitive update that bypassed the lockfile. This is rarer with modern lockfiles but still occurs.
3. Configuration management injected an additional component at deploy time — sidecars, agents, monitoring tools that the SBOM did not include.
4. The package registry returned a different artifact than the SBOM was generated against. This is the supply chain compromise case. It is the most important signal in the list.
5. A runtime download — a model file, a binary blob, a configuration pulled from a remote source — added components after the build phase. This is increasingly common with AI workloads that download model weights at runtime.

The practical operational pattern: alert on PBOM-SBOM divergence at a configurable threshold, investigate the divergences, and update either the SBOM generation process or the deployment process to reduce future divergence.

// what to actually do

The full PBOM concept is not yet a single product category. Its components are spread across runtime security tools, container scanners, eBPF observability, and ASPM platforms. Adopting the concept in practice looks like this:

1. Continue generating SBOMs in CI. This is required for compliance and remains the baseline document.
2. Add Sigstore or equivalent attestation verification at deploy time. The deploy pipeline should refuse to deploy artifacts that do not verify.
3. Add container image scanning at registry pull time, not just at build time. Re-scan deployed images periodically to catch new CVEs in already-deployed components.
4. Capture deployment manifests with image digests at deploy time. Store them as immutable records.
5. If runtime instrumentation is feasible — eBPF, Tetragon, Falco — capture the actual loaded libraries and accessed files. Compare against expected.
6. Define what "divergence" means for your environment. Set thresholds. Build alerting.

// the larger principle

The supply chain security conversation has been dominated by source-based controls. Pin dependencies, lock versions, scan source, generate SBOMs. All of this matters. None of this catches an attacker who pushes malicious artifacts to the registry directly.

The PBOM concept extends the security model to include runtime. The defender does not assume that the artifact in production matches the manifest in source control. The defender verifies it, continuously, and alerts on divergence.

This is more work than just generating SBOMs. It is also the work that closes the gap between "we documented our intent" and "we know what is actually running."

SBOM is the table stakes. PBOM is where the actual defense lives. The 2026 supply chain attacks have made the distinction concrete. The defensive industry is starting to catch up. The teams that move first will pay less to attackers in the meantime.

$ end_of_post.sh — running runtime sbom comparison? what tooling worked?

// ELUSIVE THOUGHTS — APPSEC / COMPLIANCE

EU CRA: The Compliance Clock Nobody Is Watching

Posted by Jerry — May 2026

December 11, 2027. The EU Cyber Resilience Act becomes enforceable. Fines up to fifteen million euros or 2.5 percent of global annual turnover, whichever is higher. Mandatory Software Bills of Materials for every product. Twenty-four hour vulnerability disclosure to ENISA on awareness, not on confirmation. CE marking required to sell digital products in the EU.

If your organization sells software, firmware, IoT devices, or anything with digital elements into the European Union, this applies. Open source is partially scoped — commercial open source maintainers and corporate contributors fall under specific obligations. The shape of those obligations is still being clarified through implementing regulations.

Most engineering organizations I work with are doing nothing about this. The mood is identical to GDPR pre-2018 — a regulatory deadline that feels distant until it suddenly does not. The outcome will be similar.

// what the cra actually requires

The Cyber Resilience Act, formally Regulation (EU) 2024/2847, applies to "products with digital elements" sold into the EU market. The definition is broad: software, firmware, components, smart devices, and the cloud services that integrate with them. The regulation classifies products into three categories with progressively stronger obligations.

The four obligations that have the largest engineering impact:

OBLIGATION 1 — SBOM REQUIREMENT

Every product must ship with a Software Bill of Materials in a machine-readable format. CycloneDX and SPDX are the practical formats. The SBOM must list components, versions, suppliers, and known vulnerabilities. The SBOM must be maintained for the support period of the product, which means it cannot be a static artifact generated at release. It must be updated when components are updated.

OBLIGATION 2 — TWENTY-FOUR HOUR VULNERABILITY DISCLOSURE

When a manufacturer becomes aware of an actively exploited vulnerability in their product, they have twenty-four hours to file an early warning notification with ENISA. A more detailed vulnerability notification follows within seventy-two hours. A final report follows within fourteen days. This is not "after we have investigated and confirmed" — it is "when we become aware." The clock starts at internal awareness, not at confirmation.

OBLIGATION 3 — SECURE BY DEFAULT

Products must ship with secure default configurations. No default credentials. No unnecessary services enabled. Authentication required for management interfaces. Cryptographic protections enabled. The CRA defines this in Annex I as a set of essential cybersecurity requirements. Products that ship with admin/admin will not pass conformity assessment.

OBLIGATION 4 — SECURITY UPDATES THROUGHOUT THE SUPPORT PERIOD

Manufacturers must provide security updates for the duration of the declared support period, which must be at least five years for most categories. The update mechanism must itself be secure. End-of-life products must be communicated clearly to customers. The "ship it and forget it" model of consumer IoT does not survive CRA.

// the timeline

December 11, 2024 — entry into force. December 11, 2026 — vulnerability reporting requirements become applicable. December 11, 2027 — full applicability of all obligations. The intermediate dates are not theoretical. The vulnerability reporting clock is twenty months away from this writing.

There is no grandfather clause for products already in market. If a product is on the EU market on December 11, 2027, it must comply. The lead time for product changes — particularly in firmware and embedded software — means that work needs to start now if it has not already.

// what to do this quarter

The work breaks into four streams. Each can start independently. Each requires sustained execution.

STREAM 1 — SOFTWARE INVENTORY

Build a real, current inventory of what software your organization ships into the EU. Not a Notion document that is eighteen months stale. A maintained registry with product owners, versions, support timelines, and component lists. The inventory is the foundation of every other CRA work stream. If you cannot list your products, you cannot certify them.

STREAM 2 — SBOM GENERATION IN CI

Every release pipeline must generate an SBOM. Syft, cyclonedx-cli, Trivy SBOM, and Snyk SBOM all produce CRA-acceptable output in CycloneDX format. Sign the SBOM with cosign. Store it as a release artifact. Make it accessible to customers. The technical work is approximately a week per pipeline. The organizational work — getting every team to do this — is longer.

STREAM 3 — VULNERABILITY DISCLOSURE INFRASTRUCTURE

Establish a documented vulnerability disclosure process. Public security.txt file or equivalent. Monitored intake channel. Defined internal escalation. Defined external communication path. Practice the timeline. The first time you run a twenty-four hour disclosure clock should not be when an actively-exploited bug shows up in your product. Tabletop exercises with realistic scenarios produce significantly better outcomes than paper procedures alone.

STREAM 4 — DEFAULT CONFIGURATION REVIEW

Every product needs a security review of its default state. No default credentials. Unnecessary services disabled. Logs configured. Auth required for administrative functions. Encryption enabled where applicable. The review produces a list of changes. The changes go into the product roadmap. The roadmap completes before December 11, 2027.

// the open source question

The CRA has special provisions for open source software. Pure open source maintainers are largely exempt. Open source software made available "in the course of a commercial activity" is in scope. The line between these categories is blurry and is being clarified through implementing regulations and guidance from ENISA.

The practical impact for organizations: if you are a corporate contributor to open source projects that you also use commercially, you have obligations. If you embed open source components in your products, you remain responsible for those components from the perspective of CRA compliance — your supplier chain analysis must include them, and your SBOM must list them.

The "we are not responsible because it is open source" position is not consistent with CRA. Manufacturers integrate components and ship products. The product is what is regulated, regardless of the origin of its components.

// the bottom line

CRA is the largest regulatory shift to hit software product security since GDPR hit data privacy. The fines are large enough to matter to public companies. The scope is broad enough to affect every organization that sells into the EU. The technical requirements are achievable but require sustained engineering work.

The runway feels long. It is not. Twenty months to vulnerability reporting. Three years to full enforcement. The work is not glamorous. SBOM generation, secure defaults, and disclosure infrastructure are unsexy categories. They are also exactly what the regulation requires.

Organizations that start now will treat CRA as a manageable program. Organizations that start in 2027 will treat it as a crisis. The difference is operational maturity. The difference compounds.

$ end_of_post.sh — what's your CRA readiness state? honest answers in the comments.

// ELUSIVE THOUGHTS — APPSEC / TOOLING

ASPM Is Not Magic. It Is a Bandage. A Useful One.

Posted by Jerry — May 2026

Every AppSec vendor pitch deck in 2026 contains the acronym ASPM. Application Security Posture Management. The category is real. The marketing is louder than the substance.

This post is the practitioner's view of what ASPM actually does, what it does not do, and how to evaluate whether your organization is ready to spend on it. Written from the perspective of someone who runs assessments for clients and has watched several ASPM rollouts succeed and several fail.

// what aspm is, mechanically

An ASPM platform sits on top of your existing security scanners and aggregates their findings. SAST results, DAST results, SCA dependencies, secrets scanners, container image scanners, IaC scanners. The platform deduplicates, correlates, prioritizes, and routes findings to owners.

The market is crowded. Apiiro, Cycode, Backslash, OX Security, Snyk AppRisk, Endor Labs, Aikido, Dazz, Legit Security, ArmorCode, Phoenix Security. The differentiation between vendors is meaningful but smaller than the marketing suggests. The core capability — aggregation, correlation, prioritization — is shared across the category.

// what aspm actually does well

CAPABILITY 1 — DEDUPLICATION

Four scanners reporting the same SQL injection in the same line of code as four findings is a real problem in mature security programs. ASPM platforms collapse this to a single finding with multiple sources. The reduction in alert fatigue is significant and measurable. If your team is drowning in duplicate findings, this alone justifies ASPM.

CAPABILITY 2 — REACHABILITY ANALYSIS

A vulnerable function in an imported library is only exploitable if your code actually calls it. ASPM platforms with reachability analysis can downgrade findings in unreachable code paths, frequently reducing the open finding count by 60-80 percent. This is the most concrete value-add of the category. The reachability analysis quality varies meaningfully between vendors.

CAPABILITY 3 — OWNERSHIP MAPPING

Findings get routed to the team that owns the code, via Git blame, CODEOWNERS, and integration with the engineering org chart. The "who fixes this?" question is answered automatically. This is more valuable than it sounds in any organization with more than three engineering teams.

CAPABILITY 4 — RISK SCORING THAT INCLUDES BUSINESS CONTEXT

Generic CVSS scores treat every vulnerability the same regardless of where it lives. ASPM platforms can incorporate context: is this service internet-facing, does it handle PII, is it in production, is the vulnerable code path actually invoked? The result is a risk score that reflects the organization's actual exposure, not just the theoretical severity.

CAPABILITY 5 — TREND REPORTING TO LEADERSHIP

If you have ever tried to produce a quarterly board report on AppSec posture by manually pulling from five scanners and reconciling the numbers, you understand why this matters. ASPM platforms produce reports that can be defended in a board meeting. The strategic value of having a single number to talk about — even an imperfect one — is real.

// what aspm does not do

The honest list, which vendors will not put on their slides:

1. It does not find vulnerabilities your existing scanners did not already find. Aggregation is not detection. The underlying scanner quality is what determines what gets identified. ASPM organizes the output, it does not produce new output.
2. It does not replace threat modeling. Threat modeling is a forward-looking design exercise. ASPM is a backward-looking finding aggregator. Different work, different time, different output.
3. It does not fix anything automatically. Auto-remediation features exist but are limited to specific cases — package upgrades, simple config changes. The hard fixes still require engineers writing code.
4. It does not solve organizational dysfunction. If your AppSec team and your engineering teams have a poor working relationship, an ASPM platform makes the problems more visible without resolving them.
5. It does not eliminate the need for security expertise on the team. Someone has to interpret the findings, calibrate the prioritization, configure the integrations, and respond to the alerts.

// the readiness test

Before signing a six-figure ASPM contract, run this test on your existing security program:

Pull a week of findings from every scanner you currently run. Put them in a spreadsheet. Manually deduplicate them. Manually assign owners. Manually prioritize.

If the result is unmanageable chaos, ASPM will help significantly. The platform will do this work continuously and at scale.

If the result is tractable — annoying but doable in a day — your problem is not tooling. Your problem is more likely to be one of the following: scanner configuration that is producing too many false positives, lack of clear ownership, lack of remediation SLA enforcement, or a backlog that has not been triaged in months. ASPM will not solve these. They are organizational problems disguised as tooling problems.

// the implementation pattern that works

Successful ASPM rollouts share a few characteristics from the engagements I have seen:

The implementation is owned by a senior AppSec engineer with explicit allocation, not a side project. The engineer becomes the operator of the platform — tuning the rules, calibrating the scoring, training the engineering teams on how to interpret the output.

The rollout is phased. Start with one set of scanners and one engineering team. Demonstrate value. Expand. Trying to integrate every scanner and every team in a quarter is how ASPM rollouts become shelfware.

The integration with engineering workflow is taken seriously. The findings need to land in the engineer's existing tools — Jira, Linear, GitHub Issues — with clear context, clear severity, and clear remediation guidance. Findings that require engineers to log into yet another portal are findings that do not get fixed.

The metrics are tracked from baseline. Mean time to remediation. Open finding count by severity. Trend over time. These metrics are what justifies the platform spend at renewal time.

// the bottom line

ASPM is a real category that solves a real problem. It is also being marketed as a transformative platform, which it is not. It is a useful aggregation and prioritization layer that reduces operational toil and produces better metrics.

If your AppSec program is mature enough that the volume of findings is the bottleneck, ASPM helps. If your AppSec program is still building scanner coverage, building threat modeling practice, or building remediation discipline, ASPM is premature optimization. Spend the budget on the underlying work first.

Tools do not fix process gaps. They expose them faster. Whether that exposure becomes useful depends on whether the organization is ready to act on it.

$ end_of_post.sh — running ASPM at your shop? what's working, what isn't?

// ELUSIVE THOUGHTS — APPSEC / SOCIAL ENGINEERING

The CFO Was Never On the Call: Deepfake-Driven BEC in 2026

Posted by Jerry — May 2026

A finance director joins a Zoom call. The CFO is on the screen, voice and face perfectly familiar, requesting an urgent wire transfer. The transfer goes through. The CFO never logged in.

In 2024, this exact playbook cost engineering firm Arup roughly twenty-five million dollars in Hong Kong. In 2026, the cost of running this attack has fallen below five US dollars and requires under thirty seconds of public training audio. The infrastructure to do this at industrial scale is now sitting in consumer SaaS products.

// the threat model has shifted

Traditional BEC playbooks assume a text-based attack: spoofed email, lookalike domain, social-engineered urgency. Defensive guidance was built around DMARC, DKIM, SPF, and "verify the sender's email domain." All of that still matters. None of it covers the current attack vector.

The current attack vector is real-time voice and video synthesis, deployed on live conferencing platforms. Open-source models like FaceFusion and commercial offerings like ElevenLabs Pro have collapsed the technical barrier. The latency required for a convincing real-time conversation has dropped below two hundred milliseconds. The training audio requirement has dropped to under a minute.

Sora 2 and Veo 3 enable pre-recorded video that survives casual scrutiny. The combination — pre-recorded video for the appearance plus real-time voice cloning for the dialogue — is what attackers are using now.

// what mfa cannot save you from

The first thing to understand: this attack does not bypass authentication. It bypasses the human in the loop. Your finance director has authenticated correctly. They are on the right Zoom call. They are talking to what looks like the right person. The compromise is not at the auth layer — it is at the trust-the-call layer.

Identity verification at the start of the call does not help, because the attacker is on the same call as a legitimate participant. Speaker verification on the conferencing platform does not help — the platform sees a verified meeting host inviting a guest. The guest just happens to look and sound like the CEO.

// what actually works

The defensive controls below are not novel. They are operational discipline that most organizations have not implemented because, until recently, they felt like overkill. They no longer do.

CONTROL 1 — OUT-OF-BAND CALLBACK VERIFICATION

Any wire transfer above an organizationally defined threshold requires verification via a callback to a pre-shared phone number. Not the number on the email. Not the number from the call. The number stored in the procurement system from when the relationship was established. The number that was set up before any social engineering took place.

CONTROL 2 — CHALLENGE PHRASES FOR HIGH-VALUE APPROVALS

Yes, like spy films. Pre-agreed code phrases between executives and finance teams, rotated quarterly, used as a final challenge for any approval over a defined value. The reason this technique appears in fiction is that it works in reality. A deepfake of someone's voice cannot reproduce a code phrase the original person never spoke.

CONTROL 3 — LIVENESS CHALLENGES

Real-time deepfake models still degrade noticeably under unscripted physical motion. Ask the person to turn their head sharply, hold up a specific number of fingers, or move the camera. Pre-recorded video fails immediately. Real-time synthesis fails on novel gestures. This is a stopgap — the technology will improve — but in the current threat landscape it is effective.

CONTROL 4 — APPROVAL THRESHOLDS AND DUAL CONTROL

No single human should be able to approve a transfer above a meaningful threshold based on a video call alone. Dual control — two distinct authenticated approvals through the financial system, not through the conferencing platform — moves the trust boundary back to systems with stronger guarantees than the human eye and ear.

CONTROL 5 — TRAIN THE SPECIFIC FAILURE MODE

Generic phishing training does not cover this. Finance staff, executive assistants, and treasury operators need specific tabletop exercises against deepfake scenarios. They need to feel the social pressure of being asked by a "C-level" to bypass procedure, and they need explicit organizational backing to refuse. "Trust your instincts" is not a control — clear procedural authority is.

// detection technology

Several vendors are building real-time deepfake detection for conferencing platforms — Reality Defender, Pindrop, Sensity AI. The technology exists. It is not yet good enough to be the only line of defense. Detection accuracy degrades against the latest generation of synthesis models, and the false positive rate creates real friction for legitimate calls.

The honest assessment in 2026: deploy the detection technology where you can, but do not depend on it. The procedural controls above carry the load.

// the larger pattern

This category of attack is the leading edge of a broader shift. The attack surface is no longer the email, the network, or the application. It is the trusted communication channel that humans use to coordinate work. The voice you recognize. The face on the screen. The conversational dynamics that signal legitimacy.

Application security as a discipline has historically been about code, infrastructure, and data flows. The discipline now extends to the human protocols that surround those systems. The threat model that does not include synthetic media is incomplete.

If your incident response runbook does not include "what we do when an employee reports an executive impersonation," it is missing a chapter that 2026 has made mandatory.

$ end_of_post.sh — comments open. Tell me what your org is doing about this.

// ELUSIVE THOUGHTS — APPSEC / SUPPLY CHAIN

The CI/CD Pipeline Is the Crown Jewel: Why Every 2026 Supply Chain Attack Targets the Same Thing

Posted by Jerry — May 2026

If you list the named supply chain attacks of the last twelve months and look at what each one was trying to steal, the answer is identical across the list.

Trivy. KICS. LiteLLM. Telnyx. Axios. Bitwarden CLI. SAP CAP. PyTorch Lightning. Intercom Client. PGServe. Different ecosystems, different threat actor groups in some cases, identical objective in every case: extract the secrets and tokens that live inside CI/CD pipelines and developer environments.

GitHub Actions secrets. AWS access keys. GCP service account JSON. Azure managed identity tokens. npm publish tokens. PyPI API tokens. Docker Hub credentials. SSH keys for deploy targets. Kubernetes service account tokens. Cloud database credentials. The same shopping list, every time.

// the math the attackers worked out first

Phishing one developer to compromise their personal machine yields one set of credentials. Phishing a hundred developers yields a hundred sets, with proportional cost and detection risk.

Compromising one widely-used build tool, GitHub Action, or npm package yields the credentials of every CI/CD pipeline that uses it. The blast radius scales with the popularity of the package, not the effort of the attack.

TeamPCP, the threat actor group behind the Trivy, KICS, LiteLLM, and Telnyx campaigns, internalized this math. So did the Shai-Hulud worm operators behind the Bitwarden CLI compromise. The attacks of 2026 are not opportunistic. They are systematic, with each compromise feeding the next via stolen npm publish tokens that allow lateral movement across packages.

The PyTorch Lightning compromise of late April 2026 demonstrated the secondary effect: the malicious version was live for forty-two minutes before quarantine. The infection vector was not even direct download — it spread through a transitive dependency in pyannote-audio, infecting downstream consumers who never directly installed Lightning.

// the structural weakness

CI/CD pipelines were designed for trust. Build them, watch them work, deploy what they output. The historical threat model assumed the build environment was clean and the inputs were trusted. That assumption no longer holds.

The specific structural failures that supply chain attacks exploit, in approximate order of impact:

FAILURE 1 — TAG MUTATION

GitHub Actions and npm both allow tags to be reassigned to different commits or versions. uses: aquasecurity/trivy-action@master and uses: aquasecurity/trivy-action@v1 both resolve dynamically. When TeamPCP compromised the Trivy action repository, they force-pushed tags to point at malicious code. Every workflow that referenced the action by tag silently received the malicious version on the next run. The fix is to pin to commit SHA. Adoption remains low.

FAILURE 2 — STATIC LONG-LIVED CREDENTIALS

A static AWS access key with broad permissions stored in GitHub Actions secrets is the most common pattern in 2026. It is also the most exploitable. AWS, GCP, and Azure all support OIDC federation that issues short-lived tokens scoped to specific workflows. Adoption requires changing the IAM model, which is real work, which is why most organizations have not done it.

FAILURE 3 — UNCONSTRAINED EGRESS FROM BUILD RUNNERS

Build runners typically have unrestricted internet access during dependency installation. The malicious postinstall script can exfiltrate to any HTTPS endpoint. The CanisterSprawl campaign used Internet Computer Protocol canister endpoints specifically because they look like generic HTTPS traffic and survive most network filtering. Egress allow-listing on build runners is operationally hard but eliminates an entire category of exfiltration.

FAILURE 4 — INSTALL-TIME CODE EXECUTION

npm postinstall scripts and Python setup.py scripts execute arbitrary code as part of dependency resolution. The original ecosystem decision to allow this was a developer convenience that became a permanent attack surface. npm install --ignore-scripts and pip's PEP 517 build isolation reduce this surface but break enough legitimate workflows that they are not universally adopted.

FAILURE 5 — SCANNER AS ATTACK VECTOR

Security scanners like Trivy and Checkmarx KICS are run early in the pipeline with broad access to source code and credentials. When the scanner itself is compromised, it has access to everything the pipeline has access to. The Trivy compromise specifically exploited this: a tool intended to find vulnerabilities was used to deliver malware. Treat scanners as untrusted dependencies. Pin them. Sandbox them. Audit their network access.

// hardening checklist for this week

The full hardening of a CI/CD environment is a multi-quarter project. The list below is what is achievable in a focused week of work and produces the largest reduction in attack surface per hour invested.

1. Audit every uses: reference in every workflow. Replace tag references with commit SHAs. Tools like StepSecurity and Renovate can automate the SHA-pinning and the subsequent maintenance.
2. Enable npm audit signatures and PyPI attestations on every install command in CI. Sigstore-backed verification is no longer optional.
3. Replace one long-lived cloud credential with OIDC federation as a proof of concept. The first one is the hardest. The rest follow the pattern. Start with the deployment role for the highest-traffic service.
4. Add npm publish --provenance to publishing workflows. Free signal that downstream consumers can verify.
5. Implement an egress allow-list on the build runner network for production-deployment workflows at minimum. Define the legitimate egress destinations. Block everything else. Audit the alerts. Adjust.
6. Document the rotation procedure for every secret in your CI environment. Practice it. Test the runbook. The first time you rotate a deeply-embedded production credential under incident pressure should not be the actual incident.
7. Inventory the security scanners running in your pipelines. Pin their versions. Read the security advisories of the scanner vendors. Subscribe to their disclosure feeds.
8. Add a workflow that scans for unintended secret usage — accidental references to secrets in unprotected branches, secrets in PR builds, secrets in fork builds. The default GitHub configuration leaks secrets to fork builds in some scenarios.

// the principle

The CI/CD pipeline now contains more privilege than the people who use it. Production deployment credentials. Cloud admin tokens. Package publish authority. Database access. The pipeline is a service identity with broader access than most service accounts in your organization.

The defensive posture must match the privilege level. Most organizations are running their CI/CD environment with the security maturity of a printer. The supply chain attacks of 2025 and 2026 have made the cost of that mismatch concrete.

The good news: the controls that close this gap are well-documented and ecosystem-supported. SHA pinning, OIDC federation, Sigstore verification, egress control, and scanner sandboxing are not exotic. They are operational discipline. The work is the work.

$ end_of_post.sh — what's the worst credential you found in your CI? no judgment, just curiosity.

// ELUSIVE THOUGHTS — APPSEC / DEVELOPER TOOLING

Your IDE Is the Endpoint Now: Coding Agents as the New Privileged Surface

Posted by Jerry — May 2026

Your security program probably has a category for endpoints. Workstations. Servers. Mobile devices. EDR coverage, MDM enrollment, baseline hardening, the usual.

There is a category that is missing from most programs in 2026, and it is the most privileged category in the modern engineering organization: the AI coding agent running inside the developer's IDE. Cursor. GitHub Copilot. Claude Code. Windsurf. Aider. Cline. Continue. The list keeps growing and the threat model is consistent across all of them.

// what is actually running on the developer's machine

A coding agent in 2026 is not an autocomplete extension. It is a process with the following capabilities:

• Full read access to the developer's filesystem within the project directory, frequently extending beyond it
• Write access to project files, often with auto-save enabled
• Shell command execution, frequently with the developer's shell environment, meaning their AWS profile, GCP credentials, kubectl context, GitHub tokens, and SSH keys
• Network access to LLM providers and arbitrary URLs encountered in tool use
• MCP server connections that grant additional capabilities, including database access, browser automation, and external API integration
• Configuration files that may execute on project open

From a permission standpoint, this is more privileged than most production service accounts.

// the trust boundary moved

The traditional trust model for a developer machine assumes that the developer is the agent of action. Code is reviewed before execution. Configurations are inspected before applied. Repositories are explored before built.

Coding agents invert this. The agent reads the repository's instructions, configurations, and prompt files. It executes based on what it reads. The developer is the approver, but only if the tool surfaces the approval. Every coding agent that exists has some path that bypasses or pre-emptively answers the approval prompt.

CVE-2025-59536, disclosed by Check Point Research in February 2026, demonstrated this against Claude Code. Two vulnerabilities, both in the configuration layer:

VULN 1 — HOOKS INJECTION VIA .claude/settings.json

A repository could contain a settings file that registered shell commands as Hooks for lifecycle events. Opening the repository in Claude Code triggered execution before the trust dialog rendered. No user click required. Effectively, repository-controlled remote code execution on every developer who opened the project.

VULN 2 — MCP CONSENT BYPASS VIA .mcp.json

Repository-controlled settings could auto-approve all MCP servers on launch, bypassing user confirmation. Combined with a malicious MCP server in the repository, this gave the attacker a tool execution channel with full developer credentials.

The structural lesson is more important than the specific CVE. Any coding agent that respects in-repository configuration files has this attack surface. Cursor's .cursor/. Aider's project config. Continue's .continue/. The patterns are similar. The vulnerabilities are not all disclosed yet.

// the prompt injection vector

Configuration injection is the obvious attack. Prompt injection is the subtler one and arguably the larger problem.

When a coding agent processes a repository, it reads the README. It reads source files. It reads issue descriptions, commit messages, dependency manifests, and documentation. Every text input is potentially adversarial. The "Agent Commander" research published in March 2026 demonstrated that markdown files committed to GitHub repositories can contain prompt injection payloads that hijack coding agent behavior — specifically, instructing the agent to make outbound network requests, modify unrelated files, or execute commands while appearing to perform the user's original task.

This is not theoretical. It has been observed in production environments. The Cloud Security Alliance documented multiple incidents in their April 2026 daily briefings.

// what the security program needs to add

The corrective controls below are organized by maturity level. Most organizations are at level zero on this category. Moving up two levels is a significant lift but produces meaningful risk reduction.

LEVEL 1 — INVENTORY

Know what coding agents are installed across your developer fleet. Browser extension audit on managed Chrome and Edge. IDE plugin audit via VS Code, JetBrains, and editor-specific management consoles. Survey developers directly. Most organizations are surprised at how many distinct coding agents are in active use.

LEVEL 2 — APPROVAL AND VERSION CONTROL

Establish an approved-tools list. Pin versions. Auto-update is now part of your supply chain — when Claude Code, Cursor, or Copilot pushes an update, that update has access to your developer machines. The compromise of any single coding agent vendor is a fleet-wide developer machine compromise. Treat the version pinning seriously.

LEVEL 3 — REPOSITORY HYGIENE

When opening unfamiliar repositories, use a sandboxed profile or a clean container. The Hooks-injection attack only works if the developer opens the repo in their privileged primary environment. A scratch container with no real credentials makes the attack much less effective. Several teams I work with have adopted devcontainer-based defaults specifically for this reason.

LEVEL 4 — CREDENTIAL HYGIENE FOR CODING AGENTS

Coding agents should not have access to long-lived production credentials. Period. Developer machines should authenticate to cloud providers via short-lived tokens issued through SSO, with explicit time-bounded sessions for production access. The standard developer setup of a static AWS key in ~/.aws/credentials with admin policies is incompatible with running a coding agent in 2026.

LEVEL 5 — MCP SERVER GOVERNANCE

Maintain an approved-MCP-server list. Treat MCP server URLs the same way you treat API integrations: registered, audited, time-bounded. The April 2026 research showing 36.7 percent of MCP servers vulnerable to SSRF means that even legitimate MCP integrations are potential attack vectors.

// the cultural change

The harder part of this work is convincing engineering leadership that developer machines are now in scope for the security program in a way they previously were not. The traditional argument — developers are trusted, their machines are behind VPN, EDR is sufficient — is structurally inadequate when the developer's IDE is reading and acting on instructions from external sources.

The framing that lands with engineering leaders: the coding agent is a junior contractor with administrative access to production. You would not give that role to an unvetted human. The agent has the same effective access. Treat it accordingly.

The endpoint that ships your code is the endpoint attackers want. They have already figured this out. The defensive side of the industry is roughly twelve months behind, which is enough time to close the gap if the work starts now.

$ end_of_post.sh — what does your dev fleet inventory look like? hit reply.