Add SecureChain for Open Source documentation section

[sboldyreva]

Adds a new top-level docs section for SecureChain: landing page, JavaScript/Lodash setup guide (a placeholder example), repository management page, ecosystem grid component, sidebar entry, and home card.

[aknol-tuxcare]

Reviewed in full. Overall the structure is right and the per-product Lodash page is in good shape. Two themes I'd push back on before this ships publicly:

1. Marketing overclaims that don't match what SecureChain actually delivers. "malware-free" appears in two prominent places (component H2 and the home-page card). We deliver verified, signed, rebuilt artifacts — we don't make a guarantee of malware absence, and that wording will create legal/support exposure. Tighten to "verified, signed" / "verified, signed, rebuilt" to match the per-product intro line on the Lodash page (which I think is the right phrasing).
2. Ecosystem list runs ahead of commitments. The home-page card and the component preview both list six ecosystems including Rust. Today only JavaScript ships, Python is on hold, Java is in pipeline, and there is no Rust commitment. Listing Rust in customer-facing copy creates an expectation we can't keep. Trim to JS at launch and a clear roadmap (Python/Java/Go/PHP) that we can actually defend.

A few smaller items in line comments — terminology fix on SBOM/VEX (VEX isn't an SBOM format), CVSS v3.1 vs v4.0, the SLA placeholder, npm _auth vs _authToken, the npm cache clean --force recommendation in the upgrade guide, and one Vue antipattern in the new component.

Also replying to Sofia's earlier question ("are coverage and support policy standard same as ELS?") — the README does copy ELS-for-Libraries verbatim for incident response, support duration, and technical support. That's fine if it's intentional, but I'd state it explicitly in the README rather than have customers diff two pages.

[aknol-tuxcare]

Mutating reactive state inside computed() is a Vue 3 antipattern (activeTab.value = 0 here triggers a reactivity warning in dev and can cause a re-render loop in edge cases). Move the reset into a watch(filteredData, ...) or watchEffect so the computed remains a pure getter.

[aknol-tuxcare]

Sofia asked in Slack whether SecureChain's coverage and support policy are the same as ELS. Looking at this README, the Incident Reporting, Support Duration, and Technical Support sections are copied verbatim from ELS for Libraries — which is the right call for consistency, but it's not stated. Add one sentence here, e.g.:

SecureChain follows the same coverage commitments, incident response, and technical support model as ELS for Libraries unless noted otherwise on a per-package page.

Otherwise customers (and reviewers like me) have to diff two pages to figure out what's the same and what's intentionally different.

[sboldyreva]

The current README includes the operational sections (Incident Reporting, Support Duration, Technical Support) but doesn't state that "these mirror ELS for Libraries." My hesitation with adding the suggested sentence only on the SecureChain page is consistency: ELS for Runtimes, ELS for Applications, ELS for Libraries and ELS for OS all reuse the same policy text (incident response, support duration, technical support) without explicitly stating it. Singling out SecureChain to say "this mirrors ELS for Libraries" implies the other pages have a different relationship to those policies, which isn't the case.

I'd rather keep SecureChain consistent with how the rest of the docs handle this. If we want the mirroring to be explicit, I'd prefer to do it everywhere — either by adding the disclaimer to each product README, or by promoting the shared sections to a single canonical page that the product pages link to.

[aknol-tuxcare]

I think we should delete the list. because we'll have ~10k packages.

[aknol-tuxcare]

Two issues with this .npmrc snippet:

1. _auth vs _authToken. _auth expects base64(user:password); _authToken expects a bearer token. Which one Sales hands the customer determines which field is correct here. If we're issuing Nexus user tokens (the Nexus default for npm), _authToken=NpmToken.<...> is the right field. Verify with the Nexus admin and update.
2. ${TOKEN} shell expansion in .npmrc is supported by npm but only at install time and only if TOKEN is exported in the environment. Lots of users miss this. Either:
   • Spell it out ("export TOKEN=... in your shell before running npm install, or store it in a CI secret"), or
   • Recommend npm config set //nexus.repo.tuxcare.com/repository/securechain-js/:_authToken <token> to avoid the env-var indirection entirely.

If Nexus needs it, also add always-auth=true.

[aknol-tuxcare]

npm cache clean --force is heavier than necessary and affects every project on this machine that shares the npm cache. For a fresh install from a different registry, rm -rf node_modules package-lock.json && npm install is sufficient — npm fetches from the configured registry regardless of cache. Suggest dropping --force (and the cache clean entirely on first install).

[aknol-tuxcare]

Same as the install page: npm cache clean --force shouldn't be needed for a normal upgrade. It clears the entire local npm cache (every project), which is rude side-effects for what's a one-package upgrade. Removing node_modules and package-lock.json then npm install is enough — the cache is keyed by URL+integrity hash so SecureChain artifacts won't collide with upstream. Recommend dropping the --force clean from the upgrade flow.