JAVASCRIPT_ES / TYPESCRIPT_ES: document security-plugin usage + pre-bundle a few ESLint security plugins

[ofri-peretz]

What is the current behavior, if applicable?

The JAVASCRIPT_ES / TYPESCRIPT_ES descriptor documentation lists, among what ESLint detects:

• Security Issues: Detects potential security vulnerabilities (with security plugins)

but no security plugin is named anywhere in the descriptor, and none is bundled in the image. The plugins that are pre-installed are eslint-plugin-import-x, -jest, -n, -prettier, -promise, -vue.

So a user who follows that sentence and adds a security plugin to their flat config gets Cannot find module 'eslint-plugin-...', and has to reverse-engineer the PRE_COMMANDS recipe out of the error-guidance block in the descriptor. It works, but it's discovered by hitting the error rather than by reading the docs.

Related: the security flavor currently bundles 25 linters, none of which analyses JavaScript/TypeScript source (the JS-adjacent ones are the Kubernetes manifest linters). Repos on the security flavor get no JS SAST layer at all.

What is the desired behavior?

Two parts, and they're independent — the first is useful on its own:

1. Docs: a short "Security linting with ESLint" subsection in the JAVASCRIPT_ES / TYPESCRIPT_ES linter_text, naming a few plugins and showing a working PRE_COMMANDS snippet, so the existing "with security plugins" sentence has somewhere to land.

2. Bundling: pre-install a small number of MIT-licensed security plugins next to the existing eslint-plugin-n / -promise / -vue, with renovate-pinned version ARGs following the same pattern, so referencing them in an ESLint config works out of the box.

I have both prepared (descriptor edits for JS + TS, build.sh re-run so the generated Dockerfiles and docs stay in sync) and will open the PR if you're open to it.

Your impression of priority / how important this request is

• Critical: Can't use the tool without it.
• Business Critical: Immediate opportunity to win business with this feature
• Important: Will significantly enhance the overall utility of the demo
• Nice to have: self-explanatory

Business case or other information justifying priority

It closes a gap the descriptor's own documentation opens, and it's low-risk: no new linter is registered, and nothing changes for users who don't reference these plugins.

Other information

Disclosure: I maintain the plugins I'd propose bundling (eslint-plugin-secure-coding, eslint-plugin-node-security, eslint-plugin-browser-security — all MIT). I'm aware that makes part 2 a single-vendor ask, so to be explicit about the fallbacks:

• Happy to do docs-only and name whatever plugins you consider appropriate, mine or not — the docs gap is worth closing either way.
• Happy to cut the bundle to one plugin if image size is the concern.
• If the flavor-level gap is more interesting to you than either of these, I'd rather discuss that as a separate follow-up than smuggle it into this issue — it's a much bigger piece of work (a proper linter entry with fixtures and SARIF output) and I'd want to budget it honestly before committing.

Flat-config caveat worth stating up front: bundling into the image doesn't automatically make a bare import resolve from a user's eslint.config.mjs, so the docs section would cover the createRequire approach rather than implying it just works.