Skip to main content

Security policy

Vulkro is a security tool, and we hold our own software to the standard we help our users meet. If you have found a vulnerability in the Vulkro binaries, the VS Code extension, Vulkro Cloud, the customer portal at app.vulkro.com, the license-issuing infrastructure, the website, or our CDN, we want to hear from you, and we will work the issue with you in good faith.

Security contact​

Please send vulnerability reports to security@vulkro.com, not to the public support, billing, or sales inboxes.

What to include​

A good report helps us reproduce and fix the issue quickly:

  • A clear description of the vulnerability and its impact.
  • The exact version (vulkro --version) and platform.
  • Step-by-step reproduction, ideally with a minimal proof of concept.
  • Any logs, output, or crash traces, with secrets redacted.

If you need to send sensitive details, say so in your first email and we will arrange an encrypted channel.

Coordinated disclosure​

We follow a coordinated-disclosure model:

  1. Report privately. Email security@vulkro.com first. Please do not open a public issue, post the details on social media, or disclose publicly before a fix is available.
  2. We acknowledge. We confirm receipt and begin triage (see the response commitment below).
  3. We investigate and fix. We assess severity, develop a fix, and prepare a release. We will keep you updated on progress.
  4. We coordinate the announcement. We agree on a disclosure timeline with you. Our default target is to ship a fix within 90 days of a valid report, sooner for high-severity issues. Once a fix has shipped, the advisory is recorded in the changelog.
  5. We credit you. With your permission, we credit the reporter in the advisory.

Response commitment​

Stage Our commitment
Acknowledge receipt Within 2 business days
Initial severity assessment Within 5 business days
Status update cadence At least every 10 business days until resolved
Target fix window Within 90 days; expedited for high-severity issues

Safe harbour​

We will not pursue or support legal action against researchers who:

  • Make a good-faith effort to follow this coordinated-disclosure policy.
  • Avoid privacy violations, data destruction, and service degradation.
  • Only interact with accounts, machines, Vulkro Cloud workspaces and Salesforce orgs they own or have explicit permission to test, and never try to reach another customer's data.

This is research-friendly by design. If you are acting in good faith and you are unsure whether an action is in scope, ask first at security@vulkro.com.

Out of scope​

To keep signal high, the following are generally not treated as security vulnerabilities on their own:

  • Reports from automated scanners with no demonstrated impact.
  • Social-engineering, physical, or denial-of-service testing against our infrastructure.

When in doubt, report it and let us decide. We would rather receive a borderline report than miss a real issue.

How we protect your data in Vulkro Cloud​

Vulkro Cloud is the hosted part of Vulkro, for your Salesforce orgs and your code repositories. These are the measures it is built with today. The full data-processing terms are on Vulkro Cloud data processing.

  • Read-only access to your Salesforce orgs. You connect each org through a Salesforce External Client App you create and control, using the OAuth web-server flow with PKCE. On your orgs Vulkro Cloud only reads: it has no code path that creates, changes, deletes or deploys anything in your org, and fixes are shown as instructions for you to apply. You can revoke the connection at any time, and disconnecting an OAuth connection revokes its token at Salesforce.
  • No business records. Vulkro Cloud reads settings, metadata, code and user activity. It does not query your accounts, contacts, cases or other business records.
  • What it writes to your git host, and only when you turn it on. On repositories Vulkro Cloud reads code and, if you allow it for a repository, posts commit statuses and check runs, comments on pull requests and, on Bitbucket, Code Insights reports. A workspace admin can also allow fix pull requests for a repository (off by default): when a member asks, Vulkro Cloud opens a pull request that raises a vulnerable package to its fixed version, and your team reviews and merges it. It never merges, never pushes to an existing branch and never changes repository settings.
  • Narrow git tokens. Tokens from Vulkro's GitHub App are issued per repository, and the token that reads code is kept separate from the one that posts statuses and comments. The app's private key stays on our control plane and never reaches a workspace.
  • Signed, rate-limited webhooks. Push and pull-request events from your git host are checked against the repository's own webhook secret before anything is written. Unsigned deliveries are refused and throttled, and scans started by webhooks are capped per workspace.
  • An isolated tenant per customer. Each workspace has its own database, its own results storage, its own application and scan environment, and its own encryption key. Each scan runs in its own container, which is destroyed when the scan ends, and a cloned repository exists only inside that container for the life of the scan.
  • Strict scan egress. A scan container has no open internet access: it can reach only the hosts its job needs, such as the org or git host it scans and the workspace that receives the results.
  • Encryption. Salesforce tokens, git tokens, webhook secrets and notification secrets are encrypted with AES-256-GCM under the workspace's own key. Cloudflare encrypts the stored databases and files at rest, and connections to the service use TLS. Notifications are sent over HTTPS only, and outgoing webhooks are signed with HMAC-SHA256.
  • Personal data masked by default. New workspaces mask email addresses, usernames, phone numbers and IP addresses in results, reports, exports and the API.
  • Access controls. Built-in and custom roles decide who can connect orgs and repositories, scan, export and change settings, and members can be limited to particular orgs and repositories. Marking an issue a false positive or an accepted risk needs a second person's approval. Workspaces can require MFA, limit sign-in to their email domains, set an IP allowlist and set session timeouts. Single sign-on is available on higher plans and is set up with you by our team.
  • Workspace API tokens. Tokens for the workspace API are shown once and stored only as a hash, carry limited scopes (never administration), can be limited to particular orgs and repositories and given an expiry, can be revoked at any time, and are recorded in the activity log.
  • Support access only when you grant it. Our support team can enter a workspace only while a member has granted access, for one hour to seven days, and every visit is recorded.
  • An activity log. Connections, scans, exports, member and role changes, triage decisions, rule changes, data settings and support access are recorded with who did it and when.
  • Your data, your controls. You choose how long scan results are kept, can turn off stored code excerpts and live vulnerability lookups, can change personal-data masking, can export everything, and can delete an org, a repository or the whole workspace.

See also: Privacy policy, Vulkro Cloud data processing, security.txt.