Security

Reporting a vulnerability

Send your report to security@appjars.com.

Please do not report security vulnerabilities through public GitHub issues, discussions, or any other public channel until a fix has been released.

To help us assess the report quickly, include as much of the following as you can:

• The affected AppJar and its exact version.
• The Vaadin and Spring Boot versions in use.
• A description of the impact: what an attacker can do, and under what conditions.
• Steps to reproduce, or a proof of concept.
• Any suggested mitigation, if you have one.

Reports in English or Spanish are both fine.

Scope

In scope: the published AppJars artifacts (group ID com.appjars), in the versions listed under Supported versions below.

The following are out of scope for this process:

• Applications built with AppJars. Vulnerabilities in an application developed by a customer or a third party are the responsibility of whoever builds and operates that application. If you believe the root cause is in an AppJar itself, report it here and tell us so.
• Third-party dependencies. Report these to the upstream project. We track advisories affecting our dependencies and update them in our own releases.
• Web properties, including this site and the documentation site.
• The customer portal, which is operated by Flowing Code S.A. on a separate domain.
• License key validation and activation. Circumventing license enforcement is not a security vulnerability and is not handled through this process. It is a licensing matter; see the applicable license agreement.

Please do not test against systems you do not own, and do not attempt to access data belonging to other users. If you report a vulnerability in good faith, in a version of an AppJar running on infrastructure you own or control, and you follow the coordinated disclosure request below, we will not pursue legal action against you.

What we commit to

• We acknowledge every report within 5 business days.
• We tell you our assessment of the report, including if we conclude it is not a vulnerability, and why.
• We keep you informed while we work on a fix.
• We credit you in the published advisory, unless you ask us not to.

We do not publish a target time to fix. Remediation is prioritized by severity and by how the vulnerability can be reached in a real deployment.

Coordinated disclosure. We ask that you give us 90 days from the date we acknowledge your report, or until a fix is released, whichever comes first, before disclosing publicly.

We do not operate a bug bounty program and do not offer monetary rewards for vulnerability reports.

Severity

We classify vulnerabilities in four levels. This is independent of the severity labels used in our public issue tracker, which apply to functional defects.

• Critical — remotely exploitable without authentication, leading to data disclosure, data loss, or code execution.
• High — exploitable by an authenticated user to gain access or privileges beyond those granted to them.
• Medium — exploitable only under specific configurations, or with limited impact.
• Low — limited impact, or requiring conditions unlikely to occur in a production deployment.

Supported versions

Security fixes are issued for the latest released version of each AppJar. We do not maintain long-term support branches and do not backport security fixes to older versions. To stay covered, keep your AppJars dependencies current.

Security advisories

Published advisories for AppJars appear below.

No advisories have been published to date.