Skip to main content

Vulnerability Disclosure Policy

Version 2026.1, 11 September 2026

AlmaForge welcomes feedback from security researchers and the general public to help improve our security. If you believe you have discovered a vulnerability, privacy issue, exposed data, or other security issue in any of our assets, we want to hear from you. This policy outlines how to report vulnerabilities to us, what we expect, and what you can expect from us.

Systems in Scope​

This policy applies to any digital asset owned, operated, or maintained by AlmaForge.

We classify reports affecting the software and release artifacts we publish as product vulnerabilities:

  • The almad server and agents.
  • The alma client.
  • The Web UI.
  • Official packages, tarballs, and container images published at https://get.almaforge.com.

We also review reports affecting the marketing site and this documentation site, including their TLS configuration, response headers, and cookie flags. We do not classify those reports as product vulnerabilities.

Out of Scope​

  • Customer-operated infrastructure. We cannot authorize testing against hosts, networks, or data we do not own. Defects in AlmaForge remain in scope, including those found on a deployment you are authorized to test.
  • Vulnerabilities in third-party dependencies with no demonstrated path through AlmaForge.
  • Volumetric denial of service and resource-exhaustion tests.
  • Social-engineering tests or attempts involving our team, customers, or suppliers.
  • Automated scanner output with no demonstrated impact.

Vulnerabilities discovered or suspected in out-of-scope systems should be reported to the appropriate vendor or applicable authority.

Our Commitments​

When working with us, according to this policy, you can expect us to:

  • Respond to your report promptly, and work with you to understand and validate your report;
  • Strive to keep you informed about the progress of a vulnerability as it is processed;
  • Work to remediate discovered vulnerabilities in a timely manner, within our operational constraints; and
  • Extend Safe Harbor for your vulnerability research that is related to this policy.

We acknowledge every report within three business days. If we do not consider a report a vulnerability, we explain why. With your permission, we credit you by name in the release notes. We do not run a paid bug bounty program.

Our Expectations​

In participating in our vulnerability disclosure program in good faith, we ask that you:

  • Follow this policy and any other relevant agreements. For research under this policy, it prevails over conflicting restrictions in our Terms of Use;
  • Report any vulnerability you have discovered promptly;
  • Avoid violating the privacy of others, disrupting our systems, destroying data, and harming user experience;
  • Use only the Official Channels to discuss vulnerability information with us;
  • Provide us a reasonable amount of time (at least 90 days from the initial report) to resolve the issue before you disclose it publicly;
  • Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope;
  • If a vulnerability provides unintended access to data: limit the amount of data you access to the minimum required for effectively demonstrating a proof of concept, and cease testing and submit a report immediately if you encounter any user data during testing, such as personally identifiable information, protected health information, credit card data, or proprietary information;
  • Only interact with test accounts you own or with explicit permission from the account holder; and
  • Do not engage in extortion.

Official Channels​

Report a suspected vulnerability through the support portal. Choose Report a vulnerability, described as "Report a security vulnerability for investigation and responsible disclosure." You can also email security@almaforge.com. You do not need a license or a support agreement to report an issue.

The more detail you provide, the faster we can triage and fix the issue. Include the affected version, the environment, and the steps needed to reproduce it. Run almad version on the cluster and alma version on the client to identify the exact build. Include a short proof of concept, log excerpt, or packet capture when it helps demonstrate the issue.

Safe Harbor​

When conducting vulnerability research, according to this policy, we consider this research conducted under this policy to be:

  • Authorized concerning any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy;
  • Authorized concerning any relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls;
  • Exempt from restrictions in our Terms of Use that would interfere with conducting security research, and we waive those restrictions on a limited basis; and
  • Lawful, helpful to the overall security of the Internet, and conducted in good faith.

You are expected, as always, to comply with all applicable laws. If legal action is initiated by a third party against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further.

Note that the Safe Harbor applies only to legal claims under the control of the organization participating in this policy, and that the policy does not bind independent third parties. Research on an AlmaForge deployment owned by someone else requires that operator's permission, which this policy cannot grant on their behalf.

Securing Your Deployment​

This policy covers defects in AlmaForge. These guides explain its security model and the controls operators should configure:

  • The security whitepaper covers the architecture, the identity model, and the trust boundaries.
  • The hardening guide covers encryption at rest, mTLS, secret handling, filesystem modes, and Web UI defaults to review before go-live.
  • Revoking access and break-glass cover what to do during an incident of your own.