Topic: supply-chain
-
Binding npm and PyPI publishing identity to approved release artifacts
OIDC trusted publishing removes stored publishing tokens, but its security still depends on the authorized workflow. Separate building from publishing, protect approvals, and verify the artifact's identity instead of treating provenance as a malware verdict.
-
Dependency confusion: when a public package shadows a private one
If a build resolves package names across a private index and a public one, an attacker who publishes the private name publicly with a higher version can get their code installed; pip's documentation calls --extra-index-url for private packages unsafe for exactly this reason. Defences are namespaces bound to one registry, a single proxying index, hash pinning and claiming names.
-
Subresource integrity for third-party scripts and stylesheets
An integrity attribute on a script or link element carries a base64 SHA-256, SHA-384 or SHA-512 hash of the expected file; the browser refuses to execute or apply a resource whose content does not match. It pins exactly what a CDN may deliver, requires CORS for cross-origin files, and therefore only works for resources with fixed content.
-
MCP tool definitions as an attack surface: poisoned descriptions, shadowing and silent changes
An MCP server's tool names, descriptions and annotations are text the model reads before any tool is called. A malicious or compromised server can use them to steer the agent, imitate another server's tools, or change behaviour after approval. Clients should pin, diff and review definitions like code.
-
Dependency hygiene and software supply-chain checks
Know what you depend on, pin and verify it, watch for known vulnerabilities, and build from trusted sources; SLSA levels, OpenSSF Scorecard and hash-checked installs give concrete steps.
-
Hallucinated and look-alike package names: checking a dependency before an agent installs it
Code-generating models sometimes name packages that do not exist; an attacker can register such a name, and typosquatters register near-misses of popular ones. Before installing, an agent should confirm the package exists, is the intended project and is not newly registered under a confusable name.
-
LiteLLM's October 2026 incident: confirmed token exposure and gateway-log precautions
LiteLLM's later postmortem replaced its initial log-theft theory with evidence of token exposure through an Agent Platform API. The incident still illustrates why agent credentials, response bodies and privileged automation must have separate access boundaries.
-
Software bills of materials with SPDX and CycloneDX
An SBOM is a machine-readable inventory of the components in a software artifact; SPDX and CycloneDX are the two widely used formats, and generating one per release supports vulnerability matching and licence review.
-
Dependency upgrade cadence: batching, grouping and what to merge at once
Update bots open one pull request per dependency unless configured otherwise; a sustainable cadence merges security fixes as they arrive, batches patch and minor updates into a scheduled group, and treats major versions as planned work. Dependabot and Renovate both document scheduling and grouping, and Renovate's guide names the cost of grouping: a failing group blocks all of its members.
-
Containing npm worm propagation across developer machines and publishing accounts
ChainDrop and the Tensorlake compromise show how installation-time credential theft can become unauthorized package publishing. Containment must cover dependency execution, publisher permissions, repository persistence, and contaminated build outputs.
-
Hardening GitHub Actions workflows: SHA-pinned actions, least-privilege tokens and untrusted inputs
Pin third-party actions to a full-length commit SHA, set the GITHUB_TOKEN to read-only by default and widen it per job, never interpolate untrusted event fields into run scripts, and treat pull_request_target and workflow_run as privileged triggers.
-
Package release cooldowns: exact settings, units, and enforcement boundaries
Release-age controls differ across npm, pnpm, uv, Renovate, and Dependabot. Configure the correct units, check timestamp handling and transitive resolution, and keep an explicit path for urgent security updates.
-
Building small, reproducible container images
Pin base images by digest, install from lockfiles with hash checking, copy only what the runtime needs, run as a non-root user, add a health check, and keep secrets out of layers and build arguments.
-
Software bills of materials (SBOM): the inventory of your own supply chain
A software bill of materials lists, in machine-readable form, which components in which versions are contained in a delivered artifact. SPDX (ISO/IEC 5962:2021) and CycloneDX (OWASP) are the common formats; an SBOM is generated per release from the built artifact, stored alongside it, and used to check against vulnerability reports and license obligations. Together with provenance attestations (SLSA), it makes the supply chain verifiable.
-
Automating end-of-life detection across SBOMs, container images and software inventories
Join runtime and image inventories to lifecycle data while preserving product identity, support provider and evidence freshness. This proposed workflow uses endoflife.date as a discovery feed, confirms deadlines with vendors, and alerts separately on expired support and missing evidence.
-
Signing commits and tags with an SSH key or GPG
Git signs commits and tags with OpenPGP, X.509 or, since gpg.format=ssh, a plain SSH key; the signer sets gpg.format and user.signingKey, verifiers need an allowed-signers file (SSH) or a trusted key ring (GPG), and forges are checked with git verify-commit or the host's signature badge.
-
Build provenance attestations: what SLSA provenance records and how it is verified
SLSA's Build track rates how trustworthy an artifact's provenance is, from 'provenance exists' (L1) to a hardened build platform (L3); the provenance is an in-toto attestation naming the artifact digests, the builder, the build type and its external parameters, and a consumer checks it against a root of trust and expected values before use.
-
Container image tags versus digests: mutable names and content addresses
A tag is a human-readable pointer that can be moved to a different manifest at any time; a digest is the hash of the manifest bytes and identifies exactly one image forever. Build and test by tag, deploy and pin by digest, and record the digest in every release note.
-
Building and maintaining a cryptographic inventory for post-quantum migration
Record where cryptography protects data, who owns each dependency, and what evidence supports the record. Use a CycloneDX CBOM to exchange technical assets without mistaking it for a complete migration plan.
-
Which checks on automated dependency-update pull requests have caught a malicious or broken release, and which only add noise?
Open question: automated update pull requests arrive daily and are often merged on green CI; the npm documentation describes provenance attestations that npm audit signatures can verify, but which checks (provenance, unpacked diff review, install-script inspection, waiting periods, lockfile diffs) have a record of catching a compromised or broken release?
Machine-readable: JSON