Security and CVEs
Factor House continuously scans our products for known vulnerabilities (CVEs). CVE management is an absolute priority for us and our goal is zero CVEs, though closing a finding is often dependent on an upstream fix being available.
This page explains what we scan, how we classify severity, how we remediate, and how to report an issue.
Scope
This policy covers the most recent released version of Kpow and Flex, and our current development branch.
Earlier releases are re-scanned and the results are published. Remediation is delivered in the latest release. See Remediation for what that means in practice.
Images built on end-of-life runtimes are also outside this policy. See End-of-life and legacy images.
What we scan, and how often
We scan the most recent release of each product daily against the latest NVD data.
We scan our main code branch against the NVD daily and on every code merge.
Dependencies are scanned with OWASP Dependency-Check against the NVD. We publish the report for every release, for example the Kpow 96.3 dependency report. Each finding carries our assessment, such as not affected or no upstream fix available.
The web front end is scanned with npm audit on every push. Container images referenced by our published Helm charts are scanned at the image layer, with results reviewed daily.
Security testing in development
Static analysis. Every push runs language-appropriate static analysis against the codebase, with dependency conflict checks, blocking merge on failure. Tooling is selected per language and runtime, and static assurance is deliberately paired with the dependency and image scanning described above.
Dynamic analysis (DAST). OWASP ZAP runs daily against a dedicated internal Kpow instance: a passive baseline scan of the web interface and an active scan of the API driven by the product's OpenAPI specification. Both scans run authenticated under a read-only role. Reports are retained, and findings enter the same severity and remediation process as every other vulnerability.
Supporting controls. Every change requires review and approval by an independent engineer, enforced by protected branch rules. All commits are signed. Development, test, and production build environments are segregated, and customers receive compiled artifacts only.
Severity
We classify each vulnerability by its CVSS base score (v3.1 or v4.0):
| Severity | CVSS score |
|---|---|
| Critical | 9.0 – 10.0 |
| High | 7.0 – 8.9 |
| Medium | 4.0 – 6.9 |
| Low | 0.1 – 3.9 |
Where scores differ between sources we use the higher.
For Critical and High findings, our engineering team also assesses actual exploitability in the context of the product's architecture, which can differ from the automated CVSS score — many library CVEs sit in code paths our products do not reach. The assessed severity drives prioritisation, and the assessment is recorded either way. Findings that are genuinely exploitable are prioritised ahead of all other work.
Remediation
We treat severity as the primary input to how quickly we act, and we prioritise Critical and High findings over Medium and Low. Where a finding requires a change we do not control, remediation is dependent on an upstream patch being published, and we track the issue until one is available.
Remediate means we publish a fixed image. Depending on the finding and where we are in the release cycle, that is either a point release of the most recent version or the next scheduled release.
Mitigate means we provide a documented workaround or configuration change, or a formal statement that the product is not affected.
How to get a fix
Upgrade to the latest release. That is the remediation path for every finding covered by this policy.
We design our releases so that upgrading is a low-risk operation. New versions are backwards compatible, and we strive to ensure that upgrading requires no migration steps or additional work on your side.
On occasion, we may choose to cut a point release of the most recent release version. A release email is sent to notify all customers on every release.
When a fix is not the answer, or available
Not every CVE reported against an image is exploitable in that image. We assess each finding and may resolve it in one of these ways:
Not affected. The component is present, but the vulnerable code path is not reachable or not used.
No upstream fix. Where no patch exists yet, we record the issue, apply any available mitigation, and track it until a fix is released. At this point we will release a new version, or a point release of the most recent release.
False positive or disputed. Documented with a reason, and re-checked on every scan.
Every exception is recorded with a justification.
Reporting a vulnerability
If you believe you have found a security issue in a Factor House product, email support@factorhouse.io.
We aim to acknowledge reports within 2 business days. Please do not disclose the issue publicly until we have had a chance to investigate and respond.
End-of-life and legacy images
For some customers we provide images built on end-of-life runtimes, including older Java versions less than Java 17. These runtimes and their base images are no longer maintained upstream and cannot be patched.
CVEs affecting end-of-life images are not tracked, triaged, or remediated under this policy. They are provided as-is for compatibility only.
We strongly recommend moving to a supported runtime.