Skip to main content
Draft: under legal review, not yet in force
This page is published for review. Its terms are not in force and are not offered until the review is complete and the draft marker is removed. Questions: legal@vulkro.com.

Security overview

Last updated: October 19, 2026

This page is for a security or procurement review of Vulkro. It summarises how Vulkro is built and links to the document behind each part. The procurement documents are listed at the end.

Two ways to run Vulkro​

  • On your machines. The vulkro and vulkro-sf scanners, the local console and the VS Code extension run on your own machines and work fully offline. Your code and your findings stay there. The network calls a scan makes are listed in the privacy policy; none carries your code or your findings. Vulnerability data arrives as a signed bundle, and air-gapped machines run on a signed licence file.
  • In Vulkro Cloud. The hosted workspace for your team's Salesforce orgs and code repositories. The rest of this page is mostly about it.

Isolation​

  • Each customer gets an isolated tenant: its own database, its own results storage, its own application and scan environment, and its own encryption key. None of them is shared with another customer.
  • Each scan runs in a container of its own, destroyed when the scan ends. A cloned repository exists only inside that container, for the life of the scan.
  • Scan egress is strict. 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.

What Vulkro Cloud reads and writes​

  • Salesforce orgs are read, never changed. You connect each org through a Salesforce External Client App you create and control, with the OAuth web-server flow and PKCE. There is no code path that creates, changes, deletes or deploys anything in your org, and business records (accounts, contacts, cases and the like) are never queried.
  • Repositories. Vulkro Cloud reads code and writes back to your git host only what you turn on for a repository: commit statuses, check runs and pull-request comments, and, when a member asks, a pull request that raises a vulnerable package to its fixed version. It never merges, never pushes to an existing branch and never changes repository settings.
  • Narrow git tokens. Tokens from the Vulkro GitHub App are issued per repository, and the token that reads code is separate from the one that writes statuses and comments.
  • No AI model receives your workspace data. Findings, triage and scoring are rule-based.

The full list is on Vulkro Cloud data processing.

Encryption​

  • Salesforce tokens, git tokens, webhook secrets and notification secrets are encrypted with AES-256-GCM under the workspace's own key.
  • The hosting platform encrypts 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. Incoming push and pull-request events are checked against each repository's own webhook secret; unsigned deliveries are refused.

Access control​

  • Roles. Built-in roles (Owner, Admin, Security analyst, Developer admin, Developer, Auditor, Viewer) and roles of your own decide who can connect orgs and repositories, scan, export and change settings. Members can be limited to particular orgs and repositories.
  • Two people for risky decisions. Marking an issue a false positive or an accepted risk needs a second person's approval.
  • Sign-in controls. A workspace can require MFA, limit sign-in to its email domains, set an IP allowlist and set session timeouts. Single sign-on (SAML or OIDC) is available from the Business plan and is set up with you by our team.
  • Workspace API tokens are shown once, stored only as a hash, carry limited scopes (never administration), can be limited to particular orgs and repositories, can expire and can be revoked at any time.
  • An activity log records connections, scans, exports, member and role changes, triage decisions, rule changes, data settings and support access, with who did it and when.

Our access to your workspace​

  • Our support team can enter a workspace only while one of your members has granted access, for a period you choose between one hour and seven days. You can end it at any time, and every visit is recorded in your activity log.
  • Our staff tools show workspace status, plan, usage counts and members' names and email addresses, not your findings. Engineers who operate the platform can reach a workspace's database to apply updates and to carry out a deletion you request, and only for that.

Personal data​

  • New workspaces mask email addresses, usernames, phone numbers and IP addresses in results, reports, exports and the API.
  • You choose how long scan results are kept, can turn off stored code excerpts and live vulnerability lookups, and can export or delete an org, a repository or the whole workspace.
  • The companies that process data for us are on Sub-processors. Where data is stored is described on Vulkro Cloud data processing.

Backups and deletion​

  • The workspace database can be restored to an earlier point in time with the hosting platform's built-in recovery, within the platform's recovery window. Stored result files are not versioned, and there is no copy outside the platform.
  • Deleting a workspace has a 14-day grace period, then removes its application, scan environment, database, results storage, encryption key and sign-in organisation. The final copy taken before deletion is deleted 30 days later, and its encrypted secrets can no longer be read once the key is destroyed.

Release integrity​

  • The vulkro and vulkro-sf installers, for macOS, Linux and Windows, check the SHA-256 checksum of the archive they download and refuse to install when the checksum is missing or does not match.
  • The shell installers also verify the release's signed checksum list (ed25519, against the release key the scanner itself trusts) when the release carries a signature and the machine has OpenSSL 3.
  • Vulkro is closed source. Licence files and vulnerability bundles are signed with our keys, and the scanners check those signatures.

Reporting a vulnerability​

Write to security@vulkro.com. We acknowledge a report within 2 business days and give a first severity assessment within 5. The security policy has the full process, our safe harbour for good-faith research and what is out of scope.

Documents​

For a security questionnaire, write to contact@vulkro.com.