Vulkro Cloud data processing

Last updated: October 12, 2026

Vulkro Cloud is the hosted part of Vulkro. It has two apps in one workspace: Salesforce, which connects to your Salesforce orgs, and Core, which connects to your code repositories. It scans them on a schedule, when someone starts a scan and, for repositories where you turn it on, when you push code. It keeps the results for your team in a workspace of its own. This page says exactly what it reads, what it writes back, what it stores, who can see it, how long it is kept and how to remove it.

The command line tools and the VS Code extension work differently: they run on your own machine and do not use Vulkro Cloud unless you connect them to a workspace. See the Privacy Policy for the product as a whole.

1. Who is who​

You (the company that holds the workspace) are the controller of the data Vulkro Cloud processes for you: the data read from your Salesforce orgs and your code repositories, the issues and decisions your team records, and the names and email addresses of the people you add to the workspace. Vulkro is a product of Reveriext, and Reveriext acts as a processor of that data. It handles it only to provide Vulkro Cloud to you, on your instructions, which are your configuration of the workspace and these terms.

You are responsible for having a lawful basis to let Vulkro Cloud read your orgs and repositories, including the data they hold about your own users and developers, and for telling them where your own rules require it.

2. How it connects to your Salesforce orgs​

• You connect each org yourself, with a Salesforce External Client App that you create and control in that org. The connection uses the Salesforce OAuth web-server flow with PKCE.
• The OAuth scopes requested are api and refresh_token. The api scope is not limited to reading: what it allows is set by the permissions of the Salesforce user who authorises the connection. Vulkro Cloud is built to read only: it issues read requests and metadata retrieves, and it has no code path that creates, changes, deletes or deploys anything in your org.
• An org can also be connected with a Salesforce session token that you paste. That token is never refreshed and expires on Salesforce's schedule.
• Fixes are shown as instructions and patches. Vulkro Cloud never applies them to your org. Anything you download and run against your org runs under your control.
• You can revoke the connection at any time, either from Vulkro Cloud or in Salesforce Setup.

3. What it reads from your Salesforce org​

Settings and metadata. Permissions, profiles, permission sets and their assignments, object and field permissions, sharing settings, connected apps and External Client Apps, named and external credentials (their configuration, never their secret values), remote site, CORS and CSP settings, authentication providers, single sign-on settings, installed packages, Health Check, session and domain settings, sites and guest user access, sandboxes, licence usage and Apex test coverage.

Code. Apex classes and triggers, Visualforce, Lightning Web Components, Aura, Flows, static resources and similar metadata, retrieved through the Salesforce Metadata API. If you add a git repository as the code source for an org, Vulkro Cloud clones it for the scan instead, as described in section 5.

Users and activity. For each active user: name, username, email address, user type, profile, role, licence, whether they are active, when they last logged in and when they were created. Also MFA registration, permission assignments, login history (including source IP address, browser, platform, application and country), the Setup Audit Trail, the OAuth tokens users have granted to apps (which app and when it was used, never the token itself) and, where your org has Event Monitoring, its event log files.

Field names, not field values. To find where personal data lives, Vulkro Cloud reads the definitions of your objects and fields. It does not read the values stored in them.

4. What it does not read from your Salesforce org​

• Your business records: accounts, contacts, leads, opportunities, cases, and the records of your custom objects. Vulkro Cloud does not query them.
• Passwords, OAuth token values, or the secret values of named and external credentials.

5. Code repositories​

The Core app scans code repositories on GitHub, GitLab, Bitbucket, a self-hosted GitLab or Bitbucket server where your plan includes it, or any git host reachable over HTTPS.

How a repository connects​

• With an access token you paste. The token carries whatever permissions you gave it when you created it at your git host; Vulkro Cloud uses it only for the repository you added it to. A public repository can be added without a token. We recommend a token limited to that one repository, with read access, plus commit status and pull request write access only if you want the pull-request feedback described below.
• Through a provider application. Where your workspace connects through Vulkro's GitHub App, GitLab application or Bitbucket OAuth consumer, these are the permissions requested:

The GitLab api scope and the Bitbucket write permissions are broader than what Vulkro Cloud does with them. GitLab's api scope allows read and write access to everything the authorising user can reach through the API, and Bitbucket offers no narrower permission for build statuses. What they allow is set by the access of the person who authorises the connection. Vulkro Cloud is built to use them only for the actions in the table above, on the repositories you add. On GitHub, the Contents permission becomes read and write only if fix pull requests are offered; GitHub then asks the owner of each installation to accept the change, and nothing changes until they do. Each token Vulkro Cloud obtains from the GitHub App is narrowed to one repository, and the token used to read code is separate from the one used to post statuses and comments.

What is cloned, and for how long​

For each scan, Vulkro Cloud makes a shallow copy of the branch being scanned (and, for a pull request, enough history of the target branch to tell what changed) inside the scan job's own container. The copy exists only for the life of that scan job: it is deleted before the results are uploaded, and the container is destroyed when the scan ends. Your repository is never stored in your workspace.

What is read from the repository​

• the source code, configuration files, dependency manifests and lock files, to scan them
• the CODEOWNERS file, to suggest an owner for each issue; owners are matched to workspace members by email address
• for pull requests, the list of changed files and lines
• for a fix pull request, the dependency manifest and lock file on the branch being fixed

What is received from your git host​

If you add a webhook to a repository, your git host sends Vulkro Cloud push and pull-request events. Each delivery is checked against the repository's own webhook secret before anything is written, and deliveries are rate limited. Vulkro Cloud uses them to start the scans you configured and keeps the pull request's number, title, link, branches and latest commit.

What it writes back to your git host​

Only what you turn on for a repository, where your plan includes it:

• a commit status or check run with the scan's result and quality gate outcome
• one summary comment on each pull request, edited in place on later pushes
• line comments on new issues in a pull request, and check-run annotations on GitHub or a Code Insights report on Bitbucket. These carry the issue's rule, severity, title and location; they never carry source code or secret values
• fix pull requests, only when you ask, on repositories where a workspace admin has turned them on (off by default). When you ask, Vulkro Cloud opens a pull request that raises a vulnerable package to its fixed version: it creates one branch with one commit that changes the dependency manifest (and the lock file where it can do so exactly), then opens the pull request through your git host's API. Your team reviews and merges it; the next scan confirms it. Vulkro Cloud never changes any other branch, never merges, and never runs an install.

Vulkro Cloud never deletes branches, tags or repositories, and never changes repository settings.

Live vulnerability lookups (OSV)​

To catch advisories published after a scan, Vulkro Cloud looks up your repositories' dependencies in the public OSV vulnerability database (api.osv.dev, operated by Google), at each repository scan and in a daily check between scans. Each lookup sends the package ecosystem, name and version, including the names of private packages. It never sends code, file paths or repository names.

This is on by default. A workspace admin can turn it off in Workspace Settings > Data & Privacy ("Live Vulnerability Lookups"); dependencies are then matched only against the advisories bundled with the scanner, and nothing is sent to OSV. OSV is not our sub-processor: it is a public service that receives the lookup under its own terms.

6. What it stores​

Each scan produces a result set that Vulkro Cloud stores in your workspace:

• the findings, with the rule, severity, location (a file path, line or setting name) and the evidence behind each one
• from Salesforce orgs: the user and activity data listed in section 3, including users' email addresses and login IP addresses
• from repositories: the endpoints and their sign-in requirements, the data-flow and code structure the scanner derives, the database schema it finds in your code (table and column names, relationships and how sensitive each column looks), your dependency inventory with its advisories and licences, and where secrets were found
• code excerpts from your Apex, Visualforce and other retrieved files and from your repositories, and suggested patches. This is on by default; a workspace admin can turn off code excerpts in Workspace Settings > Data & Privacy, which removes them from new and stored results
• the issues your team works on, their status, assignee, owner, comments and approvals, and the custom rules and suppressions you create
• an activity log of what members and workspace API tokens did in the workspace

It also stores the connection details for each org, the name, address and access token of each repository, each repository's webhook secret, and the secrets of your notification destinations. These are encrypted by Vulkro Cloud with your workspace's own key (see section 8).

The retrieved metadata and any cloned repository exist only inside the scan job and are deleted when it ends. Only the result set is kept.

Masking. The workspace setting "Mask Personal Data" hides email addresses, usernames, phone numbers and IP addresses in results shown in the app, in reports, evidence packs, downloads and through the API. Names stay visible. It is on by default for new workspaces; a workspace created before this default keeps the setting it had, and an admin can change it in Workspace Settings > Data & Privacy. Masking applies when data is shown; the stored result set keeps the values as Salesforce or the scanner reported them.

7. Where it is stored​

Vulkro Cloud runs on Cloudflare. Each customer gets one isolated tenant: its own database, its own storage for scan results, its own application and scan environment, and its own encryption key. Each scan runs in a container of its own, which is destroyed when the scan ends.

The location of a workspace's database and stored results is chosen by Cloudflare when the workspace is created, normally close to where it was set up. It is not pinned to a jurisdiction such as the EU or the US, you cannot choose a data region, and scans run on Cloudflare's network. Your workspace settings show the current position. If you need data kept in a particular jurisdiction, contact us before you connect an org or a repository.

Sign-in is provided by Clerk, which holds members' names, email addresses and sign-in sessions in the United States.

8. How it is protected​

• Isolated tenant. A workspace's database, results storage, application and encryption key are not shared with any other customer.
• Strict scan egress. A scan container has no open internet access. It can reach only the hosts its job needs: the Salesforce org or the git host it scans, the workspace that receives the results, our licence service, and api.osv.dev only when live vulnerability lookups are on.
• Encryption. Salesforce tokens, the External Client App secret, git tokens, webhook secrets and notification secrets are encrypted by Vulkro Cloud with AES-256-GCM, using a key held only for your workspace. Cloudflare encrypts the databases and stored files at rest and in transit as part of its platform.
• Access inside your team. Roles (Owner, Admin, Security analyst, Developer admin, Developer, Auditor, Viewer and your own) decide who can connect orgs and repositories, scan, export and change settings. 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.
• Workspace API tokens. Tokens for the workspace API are shown once and stored only as a hash. Each has scopes (never administration), an optional expiry and an optional limit to particular orgs or repositories, can be revoked at any time. Creating and revoking a token, and what is done with it, are recorded in the activity log under the token's name.
• Workspace security. You can require MFA, limit sign-in to your email domains, set an IP allowlist and set session timeouts.
• Activity log. Connections, scans, exports, role and member changes, triage decisions, rule changes, data settings and support access are recorded with who did it and when.
• Backups. The workspace database can be restored to an earlier point in time with the hosting platform's built-in database recovery, within the platform's recovery window. That is the only backup: stored result files are not versioned, and there is no separate copy outside the platform. Deleting a workspace deletes its database together with that recovery history.

9. Who at Vulkro can see it​

• Support access is yours to grant. Our support team can enter your workspace only while a member of your workspace has granted access, for a period you choose between one hour and seven days. You can end it at any time, and each visit is recorded in your activity log.
• Account recovery. If your team is locked out, support can reset your workspace's MFA, IP allowlist and session settings. The reset is recorded in your activity log with the name of the person who did it.
• Operations. Our staff tools show workspace status, plan, usage counts and the names and email addresses of members, 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. We limit this to operating the service.

10. Notifications you configure​

If you add a notification destination, Vulkro Cloud sends messages to it over HTTPS: Slack, Microsoft Teams, Jira, PagerDuty, Google Chat, Discord, email through your own mail server, or a webhook (signed with HMAC-SHA256 so you can verify it came from your workspace).

A message carries the workspace, org and repository names, scan status, counts and score, and up to 20 issues with their key, rule, severity, title, location and a link back to the workspace. An issue title can include the name of a Salesforce user (for example on a suspicious-activity issue), and an approval request carries the requester's name and reason. Messages never carry record data, code excerpts or secrets.

Once a message reaches a tool you chose, that tool's own terms and privacy policy govern it. Those services are yours, not our sub-processors.

11. AI​

Vulkro Cloud does not send your data to any AI model. Its findings, triage and scoring are rule-based. If you connect vulkro-sf or an AI assistant to your workspace, what that assistant does with the data it reads is governed by the assistant you chose.

12. Retention​

• Scan results. Each workspace chooses how long scan results are kept: 180 days unless you choose otherwise, between 7 days and the most your plan allows. When a result passes that window its stored result files are deleted.
• Issues and the activity log are kept for the life of the workspace, so that the history of each issue and each decision stays intact. Deleting an org or a repository deletes its issues (section 13); the activity log is kept.
• Sign-in locations. For each Salesforce user, Vulkro Cloud keeps a record of each IP address they signed in from, with the first and last time it was seen and a count, so it can tell a new sign-in location from a known one. A record is deleted once the address has not been seen for longer than the workspace's scan-result retention window; if the address comes back after that, it counts as new again. Detailed suspicious-activity events follow the same window.
• A plan change never deletes anything in a workspace. If a trial ends, a plan is cancelled or a renewal payment fails, the workspace becomes read-only: scans and new connections stop, and everything stays readable and exportable. A workspace is created only once checkout for its plan completes, so every workspace starts on a plan.
• Cloud scans on Pro. The Cloud scans that come with an individual Pro subscription (the Vulkro Cloud app for one person, in the customer portal) are not a workspace. Those scans and their results are deleted automatically 14 days after they ran. Issues marked as a false positive or an accepted risk are kept so the next scan does not reopen them. If Pro ends, the account becomes read-only, and its data and Salesforce grants are deleted after 30 days.

13. Disconnecting and deleting​

• Disconnect an org. Vulkro Cloud revokes its Salesforce token and deletes the stored copy. The org's past results and issues stay readable until your retention window removes the results. For a session-token connection, the token is deleted but not revoked; it expires on Salesforce's schedule.
• Disconnect a repository. Scanning stops, and the stored access token and webhook secret are deleted. A token you pasted is not revoked at your git host: revoke it there. The repository's past results and issues stay readable until your retention window removes the results.
• Delete an org or a repository. Deletes everything the workspace holds for it: its scans and stored results, its issues with their comments, approvals and ticket links, its schedules, change history, suspicious-activity events and sign-in locations, its access reviews, and its evidence packs with their stored files. For a repository, its branches, pull requests, dependency records and fix pull request records go too. The activity log is kept, as the record of the deletion, and so is a minimal record of a deleted repository (its name and address, with its token and webhook secret removed). Statuses, comments and pull requests already posted to your git host stay there; remove them at your git host if you want them gone.
• Delete the workspace. An owner can request deletion in the workspace settings. There is a 14-day grace period, during which any owner can cancel. After it we delete the workspace's application, scan environment, database, results storage, encryption key and sign-in organisation. Before deleting, we take a final copy of the workspace's data; because the encryption key is destroyed, the encrypted secrets in that copy can no longer be read. That final copy is deleted 30 days after it is taken. We keep a minimal record that the workspace existed (the company name and the admin contact).
• Remove a member. Their access to the workspace and their command line tokens are removed. Workspace API tokens belong to the workspace, not to the member who created them: they keep working until they are revoked or expire.

14. Export​

You can export every scan's results as HTML, Markdown, SARIF, JSON, a CycloneDX SBOM, CSV and OCSF (an export for your SIEM to ingest; Vulkro Cloud does not push events to a SIEM), and an owner can export the whole workspace (every record, with secrets removed) as one file. A workspace export you start is available to download for 7 days and is then deleted. Export stays available while a workspace is read-only.

15. Sub-processors and other recipients​

Other recipient. While live vulnerability lookups are on, the public OSV vulnerability database (api.osv.dev, operated by Google) receives the package ecosystem, name and version of your repositories' dependencies, as described in section 5. It never receives code.

Salesforce, your git host and the notification tools you add are services you choose and contract with directly; they are not our sub-processors. We will update this list before adding a sub-processor that handles your workspace data.

16. A signed agreement​

If your procurement process needs a countersigned data-processing agreement, a security questionnaire, or a record of processing, write to contact@vulkro.com.

17. Changes​

If what Vulkro Cloud reads, writes back or stores changes, this page changes with it before the change takes effect.

Contact​

Questions about this page or about your workspace data: support@vulkro.com. Data-processing agreements: contact@vulkro.com.