jQWidgets Security & Compliance Licensing

Enterprise Security & Compliance

jQWidgets is commercial software built for teams who have to answer for what they ship. This page collects the security, supply-chain and accessibility documentation that enterprise procurement and security review ask for - each document published in full, generated from the product repository, and reproducible on request.

Nothing here is a summary of a document held privately. Every artifact linked below is the artifact itself.

At a glance

Software Bill of MaterialsCycloneDX 1.5, machine-readable, regenerated every release
Component verificationSHA-256 published for every distributed third-party file
Advisory monitoringEvery component checked against the OSV.dev vulnerability database weekly and on every change
Runtime dependenciesNone - the widget runtime contains no third-party code
Vulnerability acknowledgementA human response within 3 business days
Remediation targetsCritical 7 days · High 30 days · Medium 90 days
Severity scoringCVSS v3.1
Secure developmentPublished SDLC policy with automated gates in CI
AccessibilityWCAG 2.1 Level A and AA - all 50 criteria met across the component suite
Standards alignmentLifecycle mapped to the eight practices of IEC 62443-4-1
Product scope82 widgets for jQuery/JavaScript, Angular, React, Vue 3 and TypeScript

Supply chain transparency

Software Bill of Materials · machine-readable source: sbom.cyclonedx.json

Every third-party component distributed with jQWidgets is inventoried in CycloneDX 1.5, the format your supply-chain tooling already ingests. For each component the SBOM records the name, version, licence, supplier, upstream support status, which artifacts it ships in, and a SHA-256 of the distributed file - so a customer can verify what they received against the inventory rather than take it on trust.

The SBOM is generated, not maintained by hand. It is produced from the product repository by a script, with a --check mode that fails if the inventory has drifted from what is actually on disk. A hand-edited inventory goes stale at the first release, and a stale inventory is worse than none - it is a statement that turns out to be wrong. This one cannot drift.

The widget runtime contains no third-party code. Every component in the SBOM ships with the demo pages and trial download - sample applications a developer runs locally while evaluating the product - and none with the runtime a production deployment includes. The jqwidgets-scripts package declares no dependencies and bundles none, so a dependency scan of an application that uses it has no third-party tree under jQWidgets to report on.

Component support status is tracked explicitly rather than inferred from version numbers, because a component whose upstream project no longer issues fixes is a standing consideration whether or not a scanner currently flags it. Every component is checked against the OSV.dev vulnerability database weekly and on every change to the inventory. Findings in the demo bundle are recorded with a written reason, a remediation path and a review date; an advisory without one fails the check, and the check has been verified to fail when one is withdrawn.


Vulnerability management

Vulnerability Management Policy · Security Policy · Security Advisories

Reportingsupport@jqwidgets.com with a subject line beginning SECURITY:
AcknowledgementA human response within 3 business days, stating whether the report is confirmed, rejected or still under investigation
ScoringCVSS v3.1, adjusted for reachability through the public API
RemediationCritical 7 days · High 30 days · Medium 90 days, measured from confirmation
Regression preventionEvery confirmed vulnerability gets a committed test that fails without the fix
DisclosureA published advisory per fixed vulnerability, with the affected range as we determined it, the fix, a mitigation for anyone who cannot upgrade at once, and a timeline

Four commitments in that policy are worth drawing out, because they are the ones that affect a customer directly:

A report is never closed without a written reason. Reporters are told what happened to their report.

No conditions attached. We do not ask reporters to sign anything, and we do not ask anyone to stay quiet in exchange for acknowledgement.

Missing a target is a policy violation, not a footnote. Where a fix cannot meet its target, the reason and a revised date go to the reporter and to affected customers.

Security fixes are never held behind a support tier. A fix reaches every supported customer in the same release. Paying more does not get you a patch sooner.

Severity is scored with a product-specific adjustment we publish rather than apply quietly: reachability through the documented public API raises severity, because a defect an application can reach by passing options to a widget is not equivalent to one reachable only by calling an internal function.


Secure development lifecycle

Software Development Lifecycle Policy

jQWidgets is 82 widgets delivered across four framework integrations, and the property that shapes everything else is that the integrations are generated rather than hand-written. One set of 82 JSON API definitions drives code generation for every Angular, React and Vue 3 wrapper and for the API documentation.

That makes automated validation the central control of the lifecycle, and it runs in CI on every push and pull request:

GateWhat it catches
Generation gateRegenerates all wrappers for all three frameworks and fails on a missing wrapper, a syntax error in generated output, a missing teardown hook (a component that would leak on unmount), or module-scope window access (which breaks server-side rendering). Currently 82 widgets × 3 frameworks, all passing.
Visual regression gateRebuilds the reference pages, verifies each renders before any image is compared, and fails on an unexplained visual difference - publishing the difference images for review.
Secret scanningScans every push, every pull request and weekly, at full repository history depth, so a credential is found wherever it was introduced.

Security is applied at defined points rather than left to judgement:

PhaseActivity
DesignThird-party components assessed for licence and support status before adoption
ImplementationUntrusted input handled as data - never merged into prototypes, never evaluated
ReviewChanges touching input parsing, deep merge, HTML rendering or serialisation get explicit security attention
TestConfirmed vulnerabilities get a committed regression test that fails without the fix
ReleaseSBOM regenerated; security fixes documented under a Security heading
Post-releaseReports handled under the Vulnerability Management Policy

The policy also names the product's security-relevant surfaces in the open, so that engineers know where the sharp edges are and reviewers do not have to discover them. Publishing that is a deliberate choice: an integrator who knows which widgets render bound data as HTML can escape it, and one who does not cannot.

Change classification protects your code, not just ours. Changes to a widget's emitted DOM structure or ARIA semantics are classified as major even when no scripting API changes, because customer stylesheets and test suites select on that markup. A supplier that treats markup as an internal detail breaks your test suite on a patch release.


Quality engineering

Every claim on this page is backed by a suite a reviewer can ask us to re-run.

SuiteCoverage
Behavioural and accessibility280 assertions in Chromium across the widget suite
Security regressionPrototype pollution regression, including a counterfactual that fails without the fix
Functional regressionWidget behaviour, independent of accessibility
Visual regression435 reference images across the widget and theme matrix
Generation validation82 widgets × 3 frameworks, parse and teardown verified
Screen readerAutomated NVDA pass, plus a listening session with a screen-reader user
Accessibility criteriaContrast, keyboard reach, focus order, reflow, text spacing, error states, colour independence

Visual regression matters more here than in most products. jQWidgets ships 82 widgets against 41 themes, so a single edit to a shared stylesheet reaches roughly 3,400 widget and theme combinations. The suite is verified in both directions, because a visual suite that has never failed proves nothing: a 3px padding change to a shared button rule is detected, adding an ARIA attribute correctly produces no difference, and consecutive full runs produce zero differences.

The reference pages are generated from a declarative specification rather than captured from the shipped demos, and every fixture is gated to confirm it renders before its image is trusted - a widget that fails to render produces an empty image, and empty images compare equal to one another indefinitely.


Accessibility

Accessibility Conformance Report · VPAT® 2.5 format, WCAG 2.1 Level A and AA

All 50 Level A and AA criteria are met: 37 Supports, 13 Not Applicable to a component library. Nothing is partial and nothing is unevaluated. The six criteria WCAG 2.2 adds at A and AA are assessed in the same report, with measurement rather than assertion. Every rating names the command that reproduces it, and every widget is exercised through a purpose-built fixture - 83 of them - rather than through a demo page, so nothing is skipped for want of a demo.

The claim, stated with the scope that belongs to it:

The jQWidgets components conform to WCAG 2.1 Level A and AA on the base, light and dark themes. Data-visualisation widgets take their colours from the application that configures them and are covered separately; the tailwind and fluent themes reproduce external design systems and are provided rather than claimed.

Reaching that meant fixing real defects rather than describing existing behaviour favourably. Sixteen Level A keyboard failures were found by measurement and corrected - in the worst cases a widget announced an interactive role while responding only to a mouse, so assistive technology described an adjustable control the user then had no way to adjust. Every graphic widget now carries a text alternative. Text contrast and component boundaries both meet their thresholds on the claimed themes: 66 boundary and focus-indicator measurements with none below 3:1, and zero text contrast violations.

A listening session with a screen-reader user found five defects no automated test could see - among them a grid that could not be keyboard-navigated at all, and row numbering that announced row 7 for a row holding record 43. All five are fixed and re-confirmed by ear. A wrong attribute is worse than a missing one: silence is a gap, but misinformation is a false statement the user acts on.

Themes

Accessibility claims are scoped to a defined supported set: base, light and dark. base is the stylesheet every consumer gets before choosing a theme, so it has to hold up on its own.

fluent passes both contrast criteria and needed no compromise to do it. tailwind meets text contrast and reproduces its source palette faithfully; an application that also needs its component boundaries to clear 3:1 overrides a single variable:

:root { --jqx-border: #6B7280; }   /* Tailwind gray-500 - 4.83:1 on white */

Per-theme measurements across all 41 shipped themes are available on request.

Charts

Line, spline, stepline and scatter series carry a distinct marker shape per series by default, and the legend key draws that shape rather than a coloured square, so those chart types do not depend on colour at all. For column, bar, stacked area, pie and donut, turning on per-point labels prints each value on its column; of the 27 shipped palettes, scheme09 keeps every pair of series distinguishable under deuteranopia, protanopia and tritanopia. All 27 were measured rather than assumed.


Standards alignment

The jQWidgets product lifecycle is documented against the eight practices of IEC 62443-4-1, Secure product development lifecycle requirements:

PracticeWhere it is documented
SM - Security managementSDLC policy; named security roles and responsibilities
SR - Specification of security requirementsSDLC policy; documented security-relevant surfaces
SD - Secure by designSDLC policy; change classification and design review
SI - Secure implementationSDLC policy; secure input handling, review triggers
SVV - Security verification and validation testingSecurity, functional, visual and generation suites
DM - Management of security-related issuesVulnerability Management Policy, intake through disclosure
SUM - Security update managementVulnerability Management Policy; published remediation targets
SG - Security guidelinesDeployment guidance for integrating applications

A per-practice response mapping every control to its evidence is available to customers running a formal supplier assessment. Contact us and we will send it.


Deployment model

Worth stating plainly, because it changes which controls apply to whom:

jQWidgets executes entirely in the end user's browser, inside your application, on your infrastructure. It opens no network connections of its own, holds no credentials, has no server component, and processes no data through any jQWidgets-operated system. There is no jQWidgets service in your data path.

For most enterprise reviews this resolves a large part of the questionnaire in one line: there is no supplier-hosted runtime to assess, no data residency question, and no supplier access to customer data.


Licensing

jQWidgets is commercial software distributed under the jQWidgets license. A licence is required for development and production use, and an evaluation build is available for assessment.

Perpetual licences include the version they were purchased against, and security fixes are provided for the current major version. Source code licences are available for customers whose review process requires them.


Requesting documentation

Enterprise customers routinely need more than a published page: a completed security questionnaire, a specific test re-run, a component-level answer, contractual security terms, or the per-practice IEC 62443-4-1 response mapping.

Contact support@jqwidgets.com. Security reports should use a SECURITY: subject prefix so they are routed for triage rather than into the general support queue.

Document
Software Bill of MaterialsEvery distributed third-party component, with hashes
Vulnerability Management PolicyIntake, scoring, remediation targets, disclosure
Security AdvisoriesEvery fixed vulnerability, with affected range, fix and mitigation
Security PolicyHow to report a vulnerability and what to expect
Software Development Lifecycle PolicyHow the product is designed, built, tested and released
Accessibility Conformance ReportVPAT 2.5, WCAG 2.1 Level A and AA