Sign in

Optional. What an account adds, and how the sign-in flow works.

Scanning works signed out. The CLI ships with community credentials, so the extension is useful the moment it is installed.

What signing in adds

• Private threat intelligence. Exploit maturity, in-the-wild sightings, indicators of compromise, detection rules, and the full vulnerability record rather than the community subset.
• Organisation policy. Your quality gate, package firewall, AI firewall and suppression rules, applied in the editor the same way they are applied in CI.
• Reachability analysis. Whether a vulnerable function is actually called from your code, which is usually the difference between an urgent fix and a scheduled one.
• Your own quota instead of a rate limit shared with every anonymous user.
• Publishing results, so what you see locally appears in your organisation’s view.

How to sign in

Run Vulnetix: Sign In. The extension shows a short code and opens your browser. Approve the code in the browser, and the editor picks up the credential.

This is a device authorisation flow, the same shape as gh auth login. The extension never asks for your password, and the secret half of the exchange never appears on screen: the code you see is only used to identify the request, so reading it over someone’s shoulder gains them nothing.

If the browser does not open, the notification includes the URL to visit.

Where the credential is kept

In your editor’s secret storage, which is the OS keychain on every desktop platform: Keychain on macOS, the Secret Service or KWallet on Linux, the Credential Manager on Windows.

Never put an API key in settings.json. There is deliberately no setting for it. Settings files get committed, shared in screenshots, and synced between machines.

Existing credentials

If you already use the Vulnetix CLI, the extension finds what you have rather than asking again. In order:

1. An account you signed into in the editor
2. VULNETIX_API_TOKEN
3. VULNETIX_API_KEY with VULNETIX_ORG_ID
4. .vulnetix/credentials.json in the project
5. ~/.vulnetix/credentials.json
6. The built-in community credentials

Set vulnetix.auth.preferEditorSession to false if you would rather an environment variable win over the editor session, which is usually what you want on a shared or CI-like machine.

More than one organisation

A Vulnetix credential belongs to exactly one organisation. If you work across two, you sign in twice and pick the account per workspace, so two windows can be signed into two different organisations at once.

Signing out

Vulnetix: Sign Out removes the credential from secret storage. It does not touch ~/.vulnetix/credentials.json, so the CLI keeps working in your terminal.