Reporting vulnerabilities

How to report a security issue to WASViking. Coordinated disclosure, safe harbor, response timelines.

WASViking^® welcomes coordinated disclosure of security issues. This page is the policy and the procedure. If you believe you have found a vulnerability in the platform, follow the steps below.

Where to send a report

Email [email protected] with:

• A clear description of the issue.
• Steps to reproduce.
• The affected URL, endpoint, or component.
• Your assessment of impact (what an attacker could do).
• Optional: your name and contact for acknowledgement.

PGP key fingerprint for sensitive submissions: posted on the Trust Center under portal.wasviking.com/trust-center/security.

What to expect after submission

We will keep you informed throughout. We do not gag valid reporters.

Safe harbor

If you operate in good faith under the rules below, WASViking will not pursue legal action.

You may:

• Test against *.wasviking.com endpoints you can reach without abusing authentication.
• Test against your own organization's WASViking tenant (you own what you scan inside your tenant).
• Test the public REST API with credentials WASViking has issued to you.
• Test the Sentinel agent code published in our release artifacts.

You may NOT:

• Test against another customer's tenant. Tenant boundary respect is a hard requirement.
• Exfiltrate, retain, or share customer data.
• Run denial-of-service tests.
• Perform social engineering against WASViking employees, contractors, or sub-processors.
• Modify, alter, destroy, or use customer or production data.

What is in scope

• wasviking.com (marketing site).
• docs.wasviking.com (this site).
• portal.wasviking.com (customer portal).
• api.wasviking.com (public REST API).
• partners.wasviking.com (Partner Console).
• posture.wasviking.com (Posture Shares).
• The Sentinel agent code in the published release artifacts.
• Our SAML 2.0 SP integration.

What is out of scope

• Issues in third-party software we use that already have public advisories (report those to the upstream).
• Issues that require physical access to a victim's device.
• Issues that require an attacker to already have a privileged WASViking account.
• Social engineering against customers or our team.
• DOS / DDOS / volumetric tests.
• Findings that depend on outdated browser versions.
• Self-XSS without a meaningful exploitation chain.
• Disclosure of public information.
• Missing security headers without an exploit chain.
• TLS configuration without a meaningful exploit chain (we already run modern TLS).

What we will publish

For resolved high or critical issues, WASViking notifies affected customers directly with:

• A short description.
• The affected components.
• The remediation timeline.
• Acknowledgement of the reporter (with permission).

Minor findings are fixed and noted in the release notes without a dedicated advisory.

Bounties

WASViking does not run a public bug bounty program at this time. We acknowledge reporters publicly (with permission) and may offer discretionary recognition.

Why this policy looks the way it does

We treat coordinated disclosure as a partnership. The fastest path to a safe internet is researchers and vendors working together with clear expectations. This page is our side of that bargain.