svelte-security¶

The web-UI sibling of go-security / rust-security: one job per scanner, each opt-out-able, tool images/versions pinned per input. Three layers of coverage, all free / OSS:

retire scans the built bundle, not node_modules — a raw node_modules scan flags vulnerable libraries vendored inside dev tooling (e.g. svelte-check bundling an old lodash) that never reach users, which would fail essentially every real project. The job builds the bundle first, then scans output_dir. Declared deps stay covered by npm-audit + osv-scanner (lockfile-based).

The malicious-package execution vector is neutralised by the npm_config_ignore_scripts job variable, set by every svelte-* component that installs — so a hostile postinstall in a transitive dependency cannot execute during build, test or lint either.

That wording used to describe an --ignore-scripts flag on the two installs in this component. It read as a pipeline-wide guarantee and was not: six of the eight installs across the track never opted in, and the unprotected ones run earlier and far more often. Protection applied per-invocation requires every new job to remember; a job variable is inherited by any install added later. See spec 0069.

A consumer whose dependency genuinely needs its install hook — a native module that compiles on install — sets ignore_install_scripts: "false" on the affected component. A project's own prebuild/postbuild hooks are unaffected: the components re-enable scripts explicitly for the commands that run first-party build scripts.

Pair with Renovate minimumReleaseAge in the consumer for the novel-malicious-release window.

retire's database¶

retire ships no vulnerability data. It fetches jsrepository-v5.json from raw.githubusercontent.com — anonymously, on every run — and fails the job outright when GitHub rate-limits it:

Error downloading: ...jsrepository-v5.json: HTTP 429 Too Many Requests

That limit is per source IP, and CI shares one. It fails closed on an unrelated axis: a GitHub limit blocks any merge request touching the svelte track, whatever the change was about.

The database is now resolved in three tiers, each logged:

Tier 3 is a deliberate fallback: a component that hard-failed without a token would break consumers who have not set one, to fix a problem they may not have.

Two things worth knowing if you touch this:

• --jsrepo, not --cachedir. Both exist. --cachedir relocates retire's own cache but leaves it deciding whether to re-fetch; --jsrepo takes the database as given and makes no call.
• The fetcher is detected, not assumed. npm_image defaults to node-tools, which has curl and no wget; a consumer overriding it with a node:*-alpine gets wget and no curl. The job uses whichever is present. Hardcoding one shipped red once — worth remembering that this job only runs on merge requests touching this component, so a runtime assumption fails rarely and inconveniently.
• A local database still detects. Verified against a known-vulnerable fixture: exit 13, jquery 1.4.2 has known vulnerabilities … CVE-2011-4969 … CVE-2019-11358. The check is intact, not merely quiet — which is the failure mode to watch for in any change here.

See spec 0071.

Always-on — unlike the other svelte-* components, this carries no change-detection changes input; every MR re-checks deps against the latest advisory DB and re-scans for secrets. See Explanation: security, always-on. paths is required (no default).

Jobs¶

Inputs¶

Usage¶

include:
  - component: gitlab.com/phpboyscout/cicd/[email protected]
    inputs:
      paths: "pkg/studio/web"

See also¶

• svelte-build, svelte-lint, svelte-test
• Explanation: security, always-on
• Spec: 0031-svelte-frontend-track