Add SecureChain for Open Source documentation section#536
Conversation
Adds a new top-level docs section for SecureChain: landing page, JavaScript/Lodash setup guide, repository management page, ecosystem grid component, sidebar entry, and home card. JavaScript ships first; other ecosystems are scaffolded but commented out. https://claude.ai/code/session_01EV89C7mnQRZJAa2D9SDbFH
aknol-tuxcare
left a comment
aknol-tuxcare
left a comment
There was a problem hiding this comment.
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:
- 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).
- 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.
| @@ -0,0 +1,339 @@ | |||
| <template> | |||
| <div class="heading text-center"> | |||
| <h2>Get your open-source packages – verified, malware-free, and secured for as long as they're in your stack.</h2> | |||
There was a problem hiding this comment.
Drop "malware-free." We deliver verified, signed, rebuilt artifacts — that's a defensible, specific claim. "Malware-free" is a stronger guarantee than the product actually makes and creates needless legal/support exposure if a downstream dependency is later found to contain malicious code.
Suggest:
<h2>Get your open-source packages — verified, signed, and supported for as long as they're in your stack.</h2>(Same wording as the per-product page intro on lodash/README.md.)
| ecosystem: "Rust", | ||
| ecosystemIcon: "/images/rust.webp", // TODO: add rust.webp before uncommenting | ||
| projects: [], | ||
| }, |
There was a problem hiding this comment.
Remove the Rust block. There is no roadmap commitment for Rust SecureChain — leaving it in the source (even commented) signals intent to ship and tends to leak into screenshots, sales decks, and customer expectations. Trim the planned ecosystems to Python / Java / Go / PHP, which are the four we've been saying out loud.
| projects: | ||
| filteredProjects.length > 0 || matchEcosystem | ||
| ? filteredProjects.length > 0 | ||
| ? filteredProjects |
There was a problem hiding this comment.
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.
| }, | ||
| { | ||
| title: "SecureChain for Open Source", | ||
| description: "delivers verified, malware-free open-source packages from a single trusted source - stopping threats at install, continuously patching vulnerabilities, and extending protection beyond end of life across Python, Java, JavaScript, Go, Rust, and PHP.", |
There was a problem hiding this comment.
Two issues in this description:
- "malware-free" — same as the H2 in the component, drop it. We do not make a no-malware guarantee; the verifiable claim is "verified, signed, rebuilt from trusted sources."
- "Python, Java, JavaScript, Go, Rust, and PHP" — only JavaScript ships at launch; Python is on hold; Java is in the AI pipeline; Rust isn't on the roadmap at all. Don't advertise six ecosystems on the home card.
Suggest:
description: "delivers verified, signed, continuously patched open-source packages from a trusted, TuxCare-managed registry — drop-in replacements that extend protection beyond upstream end of life. Available for JavaScript at launch, with Python, Java, Go, and PHP on the roadmap.",|
|
||
| <SecureChainTechnology /> | ||
|
|
||
| <ContactSales text="Need a version not listed? Contact sales@tuxcare.com for more information." /> |
There was a problem hiding this comment.
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.
| Note: SBOM support for certain components is in progress and will be available soon. To confirm current availability or expected timeframes, please contact [sales@tuxcare.com](mailto:sales@tuxcare.com). | ||
| ::: | ||
|
|
||
| * **Enhanced Metadata in Standard Formats:** Each SBOM is provided in universally recognized formats such as SPDX and VEX. These include enhanced metadata like artifact analysis, package health, and vulnerability impact data, ensuring that you have the most detailed and actionable information at your fingertips. |
There was a problem hiding this comment.
Terminology error: VEX is not an SBOM format.
- SBOM formats are SPDX and CycloneDX.
- VEX is a separate document type that references an SBOM/components and adds exploitability status. CycloneDX has a VEX profile; OpenVEX is another.
Our pipeline emits CycloneDX VEX (per security.tuxcare.com/vex/cyclonedx/...). Suggested rewrite:
Enhanced metadata in standard formats. SBOMs are provided in SPDX and CycloneDX. CycloneDX VEX documents accompany them with exploitability status (
affected,not_affected,fixed,under_investigation) so scanners can suppress non-applicable findings.
This matches what WhatsNext actually links to and avoids the category error that auditors / SBOM-savvy customers will flag immediately.
|
|
||
| ## Supported Versions | ||
|
|
||
| * **Lodash** 4.17.20 |
There was a problem hiding this comment.
Confirm Lodash 4.17.20 is intentional — upstream latest is 4.17.21 (Feb 2021, fixes CVE-2021-23337 prototype-pollution-via-template). Shipping a SecureChain rebuild of the older release is an odd starting point given that the value prop is "continuously patched." If 4.17.21 is what's actually in Nexus, fix the version here and in the package.json snippet on line 49.
|
|
||
| ```text | ||
| registry=https://nexus.repo.tuxcare.com/repository/securechain-js/ | ||
| //nexus.repo.tuxcare.com/repository/securechain-js/:_auth=${TOKEN} |
There was a problem hiding this comment.
Two issues with this .npmrc snippet:
_authvs_authToken._authexpects base64(user:password);_authTokenexpects 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.${TOKEN}shell expansion in.npmrcis supported by npm but only at install time and only ifTOKENis exported in the environment. Lots of users miss this. Either:- Spell it out ("export
TOKEN=...in your shell before runningnpm 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.
- Spell it out ("export
If Nexus needs it, also add always-auth=true.
| Remove the lockfile and cached modules so npm fetches Lodash from the SecureChain registry: | ||
|
|
||
| ```text | ||
| rm -rf node_modules package-lock.json && npm cache clean --force |
There was a problem hiding this comment.
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).
| Remove the lockfile and cached modules so npm picks up the latest TuxCare-built version from the SecureChain registry: | ||
|
|
||
| ```text | ||
| rm -rf node_modules package-lock.json && npm cache clean --force |
There was a problem hiding this comment.
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.
3 participants
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.