Vectasec FAQ

Short answers to common questions about Vectasec. Each one links to the page that covers it in full.

Access and data#

Does Vectasec write to my systems?#

No. Connectors read configuration and status, and they don't change configuration or data on the systems they scan. On AWS they make List*, Get* and Describe* calls, plus sts:AssumeRole when you give the connection a role to assume. On Kubernetes they make LIST and GET calls. On brokers and gateways they read admin and monitoring APIs. The MCP connector reads discovery and tools/list and never issues tools/call, and its extra protocol probes run only if you set active_probes.

Two checks test whether a product's default account still works: a GET /api/whoami as RabbitMQ's guest user, and, in the coord connector's Nacos mode, a login as the default nacos user unless you set a username and password. Neither changes configuration or data. Discovery sends only pre-authentication bytes, never credentials. See the security model.

Does Vectasec read message payloads?#

No. Vectasec reads configuration. It doesn't consume messages, sample rows or read the values held in caches and key-value stores. Data classification works from resource names, namespaces and label values, so a topic called payments is recorded as named like PCI data, not as containing it.

A name match is never a vulnerability on its own. A resource named like PCI, PHI or secrets data gets a low-severity inventory finding. On Kafka, a classified topic on a broker with a plaintext listener or no authorizer gets a high or critical exposure finding. See data classification.

Where do my credentials live?#

For a cloud-mode connection, the default, each field the connector declares secret is stored in Supabase Vault, one secret per connection. Secrets are merged into memory only at scan or test time, and deleting a connection deletes its secret in the same transaction. Scan-queue payloads carry the public config only.

With a collector, credentials stay in your network. targets.json can refer to them as ${ENV_VAR} placeholders, which the collector fills from its environment at startup, so the file itself doesn't need to hold secrets. See the security model.

What leaves my network when I use a collector?#

• Findings: rule id, severity, title, remediation, detail and fingerprint, each with the observation behind it. An observation quotes the config value the rule read, such as security.inter.broker.protocol=PLAINTEXT.
• Resources and edges: each resource's kind, name, ext_id, namespace and labels, and the edges between resources. Labels can include internal hostnames and ports.
• Target config, redacted: each target's config with credentials masked, so the console can show what a connection points at, such as host, port and TLS flags.
• Status: scan stats, the collector version, a redacted error message for a failed scan, and target names and types on each heartbeat.

Redaction runs over every results payload as the last step before it is sent. It masks every credential the collector holds that is 8 or more characters long, wherever it appears, plus every value under a credential-shaped key, URL userinfo and PEM private keys. Credentials, raw configuration and message contents never leave. Run vectasec-collector preview to print the redacted payload for each target without contacting the control plane. See Run a collector in your network.

AI and evidence#

Is AI required?#

No. If you set none of ANTHROPIC_API_KEY, OPENAI_API_KEY or GEMINI_API_KEY, triage writes a deterministic rule-based summary, and nothing is sent to a model. With a key, the engine sends a finding and its observations to the configured provider. Every claim in the reply must cite one of those stored observations, and Postgres refuses to commit AI output that cites none. Priority is clamped to a severity floor: critical is P0, high is P1, medium is P2, and low and info are P3. A model can raise urgency but never lower it. See grounded AI triage.

Why do I see not-assessable findings?#

The check could not read its evidence, for example after an AWS AccessDenied or a Kubernetes 403. Vectasec files a not-assessable finding rather than reporting a pass. Grant the connection read access to that resource and rescan. On compliance views, these findings map to unknown. See Findings, evidence and compliance.

Why does compliance never show pass after a clean scan?#

A finding can prove that a control fails. Its absence cannot prove that the control passes, because Vectasec sees only the systems it scanned. Evaluation therefore produces only fail, unknown or not_applicable. A control reaches pass only when a user with the analyst role or higher attests to it with a scope, in the console or with POST /compliance/{framework}/{control_id}/attest. An expired attestation stops counting, and a live failing finding always overrides an attestation. See compliance mapping.

How do I verify the evidence has not been altered?#

Run vectasec doctor --verify-ledger. It recomputes the per-finding hash chain over stored observations and prints chain intact, or lists up to 20 breaks, each with its finding, observation and reason, plus a count of any others. doctor exits non-zero when it finds a break, so you can run it on a schedule. Database triggers also reject any update that would change an observation's evidence, and any update to the audit log. See the evidence ledger.

Coverage#

Which systems are supported?#

There are 39 connectors and 448 detectors. The connectors cover message brokers and streaming platforms, API gateways and API descriptions, Kubernetes and service meshes, cloud messaging and API services on AWS, Azure and Google Cloud, iPaaS and workflow tools, coordination services, Vault, Keycloak, search engines, managed file transfer servers, vector stores, MCP servers and infrastructure-as-code files. A discovery connector also identifies middleware on the hosts and ranges you declare, including systems you haven't connected yet. The connector reference lists each connector's fields and rules.

Can Vectasec scan SASL-authenticated Kafka?#

Not through the Kafka protocol yet. The kafka connector builds its admin client from the bootstrap servers alone and passes no SASL or TLS settings, so it can't scan a cluster through a listener that requires SASL or TLS. Some platforms have control-plane connectors that don't depend on the Kafka listener: aws reads MSK cluster properties, confluent reads Confluent Cloud through its REST API, and redpanda reads the Redpanda Admin API. See the connector reference.

Which cloud providers can Vectasec scan?#

AWS, Azure and Google Cloud, through their management APIs, with no agent to install. AWS is the documented path: one cross-account read-only role, assumed with sts:AssumeRole and an optional external ID, covers SQS, SNS, EventBridge, MSK and API Gateway across the regions you list. The Azure connector reads Service Bus, Event Hubs, API Management and Logic Apps with an Entra app registration's client secret. The GCP connector reads Pub/Sub, Apigee and the project IAM policy with a service-account key or an access token. Azure and GCP have been tested only against recorded API responses, so treat them as preview. See Scan AWS with a read-only role.

Is there a runtime sensor?#

No. Vectasec has no in-cluster sensor. Runtime evidence is read agentlessly from each system's own APIs: RabbitMQ connections, Redis CLIENT LIST and ACL LOG, NATS connection monitoring, PgBouncer SHOW CLIENTS and Kafka consumer groups. See runtime evidence.

Deployment and access#

Can I self-host Vectasec?#

You run the engine API, workers and console yourself, beside a Supabase project that provides Postgres, Auth, Vault, pgmq and pg_cron. Deployment covers that setup. The self-hosted preview bundle (Docker Compose and a Helm chart), which also runs the Supabase services, is a preview: its configuration validates, but it has never been booted, and it needs the changes listed on the Deployment page before you try it.

To keep target credentials inside your network, run a collector. Collector enrollment tokens can't be issued from the console or the API yet, so an operator with database access creates them.

Is SSO supported?#

Not yet. You sign in with email and password, or with Google when that provider is enabled in Supabase Auth. There is no SAML or OIDC single sign-on and no SCIM provisioning. Whoever creates an organization becomes its admin and can add members, and each member has a role in that organization. See the security model.

Is the code open?#

The source is shared on request, including the engine, console, collector, detectors and database migrations. It does not carry a license file yet, so ask us before you reuse the code. Book a demo to get access.

How do I get a demo?#

Book a demo to talk it through with the ZHASK team. For a product overview, see the Vectasec product page. To try it yourself, start with the quick start, which scans deliberately misconfigured Kafka, RabbitMQ and Redis containers on your machine.