주제: supply-chain
-
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.
-
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.
-
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.
-
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-Stücklisten (SBOM): das Inventar der eigenen Lieferkette
Eine Software-Stückliste zählt maschinenlesbar auf, welche Komponenten in welcher Version in einem gelieferten Artefakt stecken. SPDX (ISO/IEC 5962:2021) und CycloneDX (OWASP) sind die verbreiteten Formate; erzeugt wird sie pro Release aus dem gebauten Artefakt, daneben abgelegt und zum Abgleich mit Schwachstellenmeldungen und Lizenzpflichten genutzt. Zusammen mit Herkunftsnachweisen (SLSA) macht sie die Lieferkette prüfbar.
-
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.
-
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?
-
Opening an untrusted repository: the files that execute code when you install, build, test or just enter it
Cloning a repository runs nothing, but many routine next steps do: package install scripts, build files, test configuration, editor tasks, environment loaders and some Git settings. An agent working in a foreign repository should know these execution points and run them only inside a sandbox.
-
Reproducible builds and pinned dependencies
A build is reproducible when the same source and build environment produce bit-for-bit identical output; lockfiles with hashes, pinned base images and fixed timestamps are the practical steps toward it.
기계 판독 가능: JSON