Software Supply Chain Security

Because the artifact is made by the build, not by the repository. Anything that runs during the build - a build script, a plugin, a build-time dependency, the compiler image, a packaging step - can add code that appears in no source file.

It runs whatever that URL returns at that moment, with the caller's full privileges and no version, review or integrity check. Anyone who can write to the hosting location therefore runs code on every laptop and every CI job.

Five different doors. SUNBURST came through a compromised build system, xz-utils through a contributor who earned maintainer trust, event-stream through inherited maintainership, Codecov through a tampered delivery script, and ua-parser-js through a stolen publisher account.

Many package managers let a package declare install hooks, scripts the manager runs automatically as part of installing it. Installing is therefore code execution, not a file copy, and it happens before your tests or scanners ever run.

AI assistants invent plausible package names that were never published. Attackers collect those hallucinated names, register them on the public index, and wait for someone to install one. The name looks right precisely because a model generated it.

NVD enriches a CVE record with a severity score and product applicability. GHSA describes the flaw per package ecosystem with a package name and affected version range. OSV is a schema and aggregator normalising many feeds into ecosystem-native ranges.

A lockfile line names the exact package version, the source it is fetched from and the bytes accepted as that release. Editing it swaps different executable code into the build, with no source-file diff to review.

Scope says where a package is needed, so it decides whether the package is in the artifact you deploy. A test-only library is absent from production and a production attacker cannot reach it.

Check how many people really maintain it, whether releases and patch fixes still ship, whether it publishes a way to report a flaw privately, what the license is, how large the transitive tree is, and how much of it you actually need.

EPSS estimates the probability a vulnerability will be exploited in the wild within 30 days. A score of 0.08 means roughly an 8 percent chance. It forecasts likelihood, not how damaging the flaw is.

A stored, queryable estate answers 'where do we run this component, and at what version' in seconds. Regenerating means rebuilding every service at its deployed commit, which is slow and describes today's source rather than what is actually running.

Little, as a live inventory. An SBOM describes one build at one moment, so after a year of vendor releases it need not match the version you run. It survives as a baseline and as proof the vendor can produce one.

VEX defines four statuses for a product-and-vulnerability pair: not_affected, affected, fixed, and under_investigation. They state whether a known vulnerability is actually exploitable in that product, not whether the flawed component is present.

A purl is a coordinate computed from where a package actually came from: ecosystem, namespace, name, version. A CPE is a string from a curated dictionary that a human assigns, so it is often missing, duplicated or ambiguous.

Syft unpacks the image's layers, runs per-ecosystem catalogers over the resulting filesystem to list installed packages, then serialises that list as SPDX or CycloneDX. It reports what is present, not whether anything is vulnerable.

It binds a published tarball's digest to the source repository, commit and CI workflow that built it, signed by that build's identity. It says nothing about whether the code is reviewed, safe, or free of vulnerabilities.

A Fulcio certificate binds a one-time public key, generated locally at signing time, to the OIDC identity and issuer in the token you presented. It stays valid for roughly ten minutes, so no signing key is ever stored.

It proves the file is byte-for-byte what the holder of that private key signed. It does not prove the key belongs to the project, that the build was clean, or that the code is safe.

Keyless signing still uses a private key, but it is generated for that one signing operation and destroyed immediately afterwards. Nothing long-lived is left behind to store, guard, rotate, or lose.

Nothing about behaviour. A signature binds a signer identity to one exact set of bytes: it says who vouched for them, not that the chart's contents, defaults or dependencies are safe to install.

A valid signature proves only that the bytes are unchanged since signing and that a named identity vouched for them. It says nothing about which components are inside the binary or which source revision and build produced it.

A reused machine keeps state from earlier builds - caches, installed tools, leftover credentials, running processes - so an earlier job could have altered this build or what was recorded about it. A single-use environment removes that whole class of doubt.

No. The SLSA build track attests to how an artifact was produced and by which builder, not to what is inside it or whether those components are flawed. Vulnerable dependencies are a separate question.

A provenance statement proves nothing until something checks it. The control is a consumer verifying the statement against expectations fixed in advance and refusing the artifact when the check fails. Unverified attestations are metadata, not protection.

Verification compares the statement against expectations written down in advance: the builder identity that produced the artifact, the source repository and revision it was built from, the build entry point, and the subject digest matching the artifact you actually hold.

Default-deny outbound stops build-time code reaching unapproved hosts: no exfiltrating secrets or source, no pulling a second-stage payload. It does not make a malicious dependency safe - the code still runs and can still corrupt the artifact.

Anything a person typed is attacker-controlled: branch and tag names, commit messages, git author names, issue and comment bodies, pull request descriptions. Commit hashes, the repository name and the event type are produced by the platform, not by the submitter.

The trigger event, and whose context it runs in. Runs in the fork's context get no repository secrets and a read-only token; a second family of events runs in the base repository's context with full secrets and a write token.

A hermetic build declares and pins every input before it starts and fetches nothing while it runs. It can still emit different bytes on each run, because embedded timestamps, absolute paths and file ordering vary independently of the inputs.

A repository-wide grant is the ceiling for every job in it, so a docs-preview job inherits whatever the deploy job needs. Per-job scoping means code running in a low-value job cannot touch the release path.

They turn one code-execution bug into a working foothold: the attacker can explore the filesystem, read mounted credentials, fetch more tooling and pivot. An image holding only a static binary forces them to bring everything themselves.

The approval is not attached to what runs. Anyone able to push to that repository can re-aim the tag at different bytes, so the next pull fetches an image nobody reviewed, with no change to the deployment.

Almost nothing on its own. A signature is only a claim until something refuses an artifact whose signature is missing or wrong. The value appears at the enforcement point: a pipeline gate, admission, or pull-time policy.

Pickle files carry executable instructions: unpickling can call arbitrary Python code while it rebuilds objects. A safetensors file holds only raw tensor bytes plus a JSON header, so loading it parses data and never runs code from the file.

Audit mode records which images would have been rejected without rejecting anything. That record is the blast radius: it exposes unsigned images, registries nobody documented and workloads with no owner, before a blocking rule takes production down.

EO 14028 binds federal agencies, not vendors directly. It reaches sellers as a procurement condition: an agency may buy software only from a producer who attests to following NIST secure-development practices, and the agency may also require an SBOM.

The CRA covers products with digital elements: hardware or software placed on the EU market, including firmware and components. The manufacturer, whoever sells it under their own name, carries the duties; importers and distributors carry lighter ones.

SSDF has four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). They cover org readiness, protecting code and releases, building software securely, and handling flaws found after release.

Sort every clause into four buckets: already satisfied, partly satisfied, a real gap, or refused. For each satisfied clause name the evidence artifact, cost each gap in engineer-months, and get vague scope agreed in writing before signature.

Becoming aware that a vulnerability in your product is being actively exploited, or that a severe incident affects its security. Within 24 hours you send an early warning to the coordinating national CSIRT and ENISA - not a public advisory.

A passkey signs a challenge bound to the registry's real domain, so a lookalike login page cannot relay it. A TOTP code is just six digits, which an attacker proxying your login replays within seconds.

Trusted publishing lets a registry accept a release from one specific CI workflow by verifying a short-lived OIDC identity token, instead of a long-lived API token stored as a CI secret. No reusable credential exists to steal.

Deprecating leaves the version fully installable and only attaches a message the registry shows at install time. Unpublishing removes the version so it can no longer be downloaded. One is a signal, the other is a withdrawal.

Name the package identity in its ecosystem, the version where the vulnerable code was introduced, and the first fixed version on every release line you maintain. Ranges must be structured data, not prose like 'all earlier versions'.

Coordinated disclosure means the finder reports privately and gives the maintainer an agreed window to ship a fix before details go public. That window is the embargo. Full disclosure publishes the details straight away, with no window.