Trust Center

AlertaVuln is built by security engineers who assume you will verify our claims. This page lists what we do, how your data flows, and what we have not done yet. Every statement here corresponds to behaviour in our codebase or infrastructure configuration. Where something is planned rather than real, it is listed under Roadmap and nowhere else.

Security overview

You choose how much of your data reaches us at all. In local mode, nothing leaves your machine. In connected mode, we receive finding metadata - never your source code. Hosted analysis, when you opt into it, works on a temporary copy of your repository that is deleted the moment the scan completes.

The rest of this page is the detail behind those sentences: the exact data that crosses the wire, how we store and delete it, who our sub-processors are, how to report a vulnerability to us, and the controls that protect your data while we hold it.

Architecture and data flow

You choose how much reaches us. Local mode sends nothing. Connected mode sends finding metadata, never source. AV-hosted scanning reads your repository transiently and keeps only the derived results.

The diagram below shows the three paths. If it does not render as a diagram in your browser, the same flow is described in plain language immediately beneath it.

flowchart LR
  subgraph your_boundary[Your boundary]
    DEV["Developer machine (CLI + IDE)"]
    REPO[("Your repository")]
  end
  subgraph alertavuln[AlertaVuln on Azure]
    API["API"]
    DB[("PostgreSQL, private network only")]
    W["Scan workers: ephemeral tree, deleted after scan"]
  end
  DEV -- "local mode: nothing leaves" --> DEV
  DEV -- "connected mode: finding metadata only (rule, path, line, fingerprint, severity)" --> API
  REPO -- "AV-hosted scan: provider API read or archive at commit, processed then deleted" --> W
  W --> DB
  API --> DB
  API -- "alerts: your webhook destinations" --> EXT["Your Slack / Teams / chat"]

How to read the diagram, in words:

Local mode keeps everything on the developer machine. The CLI and the IDE extension run the scan locally and send nothing.
Connected mode sends finding metadata from your machine to our API - the rule identifier, rule description, file path, line numbers, a fingerprint and the severity signals - and nothing else.
AV-hosted scanning reads your repository transiently (through the git provider’s API, or by archiving the repository at the scanned commit), analyses it, and deletes the working copy. What persists is the derived results.
Alerts are delivered outbound to the chat and webhook destinations you configure.

What leaves your machine on a connected scan

On a connected code-scan push, the CLI uploads finding metadata only: an engine identifier, the rule id, the rule’s message, the severity level and security-severity score, the file path, the start and end line, a fingerprint, an optional help link and CWE id, plus the repository URL, git ref, commit sha, and the contents of the repository’s .alertavuln-ignore file. There is no source-content field in the upload.

To be precise rather than reassuring: rule messages are the scanner’s own description of the issue it found, so what we receive is finding metadata including the scanner’s description of the issue - not the surrounding source from your repository.

Secret findings are redacted before we see them

The secret-scanning stage runs in redacted mode, so a matched secret value is masked in the scanner’s own output before AlertaVuln ever processes or uploads the finding. We record that a secret of a given kind was found at a location - not the secret itself.

Local-only mode is real

av sast scan --no-upload and av reach sast --no-upload run entirely on your machine. The IDE extension’s local verification flows shell out to those same commands, and the pre-flight package check is a read-only lookup. Reachability analysis is designed so that source never leaves the machine: its evidence is a file path and a line number, never source content.

AV-hosted scanning touches source transiently

Connected dependency and tech-stack scanning reads your manifests through the git provider’s tree API - there is no working clone - and stores package coordinates. AV-hosted reachability archives the repository at the exact scanned commit into a worker’s temporary directory, analyses it, then deletes it; a start-up sweep removes any temporary tree that survived an unclean shutdown. What persists is verdicts plus the file-and-line evidence that justifies them, never the source.

Access and authentication

Interactive sign-in is via Google or Microsoft single sign-on, issuing a signed token. Organisation API keys carry scoped, admin-grantable permissions. Per-user personal access tokens for IDE integrations map to the same organisation claims and permission checks as an interactive user. Webhook destination URLs are redacted in our logs.

Tenant isolation is tested, not asserted

Every finding-mutation endpoint ships with cross-tenant denial tests - using a foreign project and real identifiers, asserting that no row is written - and a repository-wide sweep test enforces permission gates on key-reachable mutations. Isolation is part of the test suite, so a regression that weakened it would fail the build.

Platform and operations

The following are controls we configure and can point to in an audit:

The service runs on Azure Kubernetes Service.
The application database (Azure Database for PostgreSQL Flexible Server) is reachable only over the private network - it is injected into a private subnet with a private DNS zone, with no public network path - and requires TLS 1.3 for client connections.
Application secrets are held in Azure Key Vault and synced into the cluster by the External Secrets Operator; they are not committed to source.
Every container image is scanned for known vulnerabilities in CI with a blocking gate: a critical, fixable finding fails the build before the image can be promoted to a deployable tag. The few exceptions are recorded in an audited ignore file where each entry carries a written rationale and a date.
Secret-scanning runs first on every change and blocks all image builds if it trips.
A software bill of materials is generated for every image.
Staging and production are separate environments with separate databases.
Production deploys happen only through a manual, human-approved promotion that digest-copies the exact image already proven on staging - production runs the same bytes staging validated, never a fresh rebuild.
All deployment is GitOps-managed.
Cloudflare fronts public traffic for DNS, CDN, TLS and edge protection.

Scanner supply chain

Every scanning stage is version-pinned and fetched from a fixed release location, and its download is verified against a hard-coded SHA-256 checksum before first use. The server and the CLI run identical versions, so a scan produces the same result wherever it runs.

Data handling and retention

We store findings, package coordinates, verdicts, and the file paths and line numbers that justify them. We do not store your source code: hosted analysis works on a temporary copy that is deleted when the scan completes, and secret findings are redacted by the scanner before we ever see them.

Organisation data is deleted on request, including a hard purge - both exist as first-class administrative operations. A formal, written retention schedule is on our roadmap; until it ships, our retention is straightforward: your data is kept while your account is active, and deleted when you ask.

Sub-processors

These are the third-party services that process customer data on our behalf. We share only the data each one needs for the purpose shown. This table changes only with a dated entry in the page changelog; procurement teams can watch this page’s git history for sub-processor changes.

Sub-processor	Purpose	Data shared	Region
Microsoft Azure	Hosting: compute, database, messaging, secret storage and container registry.	All service data, stored and processed within our cloud tenancy.	Australia East
Cloudflare	DNS, CDN, TLS and edge network protection.	Request metadata and IP address.	Global edge network
Stripe	Payment and subscription billing.	Billing name, email and payment-method metadata. No scan data.	United States / global
Google Workspace	Single sign-on and outbound transactional email relay.	Account email, sign-on identifiers, and email content.	Global (Google-managed)
GitHub, Azure DevOps	Repository and dependency access for the sources you connect. (Only for repositories you choose to connect.)	Repository and manifest metadata, scoped by the access you grant.	Per your repository host
Slack, Microsoft Teams, Discord, Google Chat	Outbound alert delivery. (Optional - only the channels you enable.)	The alert content your organisation chooses to send.	Per the vendor you enable

We also read public vulnerability intelligence from upstream feeds (for example the NVD and OSV advisory databases). These are inbound data sources only - we read public advisory data and send them no customer data.

Reporting a vulnerability

We welcome reports of suspected security issues in AlertaVuln.

Security contact: [email protected] - monitored by our security group. Please include enough detail to reproduce the issue; we acknowledge reports and keep you informed through to resolution.

A machine-readable version of this contact and policy is published at /.well-known/security.txt.

Availability

AlertaVuln runs on Azure Kubernetes Service across separate staging and production environments, with GitOps-managed, human-approved production releases. We do not yet publish a public status page or a contractual service-level agreement; both are on the roadmap. An incident affecting customer data would be disclosed directly to the organisations affected.

Compliance roadmap

We are a young company and will not pretend otherwise. What is real today is the set of engineering controls described above, tested in CI on every change.

Planned, and listed here only as roadmap:

A formal, written data-retention schedule and a Data Processing Agreement template.
A third-party penetration test.
SOC 2 Type II. (No target date yet - we will name one here when a vendor is engaged.)

Other items customers sometimes ask about - ISO 27001, a public bug-bounty programme, a public status page, a contractual SLA, and formal GDPR or UK representation - are potential future work and are not in progress today. We update this section with dates only when they are real.

AI at AlertaVuln

Today, AlertaVuln does not send your data to any AI model. There is no model, operated by us or by a third party, in the path of your data. Our AI-assisted features work by handing structured context to your own assistant - through an IDE handoff or a copied prompt - so anything a model sees is under your organisation’s own AI policy and tooling. We call this BYOAI: bring your own AI.

Upon launch of AlertaVuln AI (Coming Soon)

This subsection describes a feature that is not yet available. It is kept here from day one, flagged as upcoming, so that the opt-in consent flow can point at stable anchors when the feature ships.

AlertaVuln AI will be optional and off by default. It will activate only when an organisation administrator explicitly enables it. When enabled:

Requests go to an Azure AI Foundry resource provisioned within our own Azure subscription in Australia East. Authentication is managed-identity only - key authentication is disabled on the account, so no API key exists to leak.
Microsoft does not use these inputs to train its models, and we opt out of human review for abuse monitoring where we are eligible to.
We send the minimum context the feature needs - finding metadata, reachability verdicts and, for code-aware features, the relevant code snippet - and we show you what will be sent before you enable it.
Disabling it stops all model calls immediately.

Model conversations are retained, deliberately

An earlier draft of this page said we would not store model inputs or outputs. That is not what we built, and we would rather correct it here than let a convenient claim stand. Every hosted AI conversation is written to a separate, locked-down evidence store, and every call produces a usage record alongside it:

Record	Contents	Why
Usage	Organisation, project, the user who asked, feature, model, token counts, duration, and the outcome - including calls that were refused or denied	Answering “what did this organisation’s AI do, and how often was it turned down” without touching any content
Conversation	What was asked and what was answered	Being able to reproduce, later and under scrutiny, exactly what an assistant was told and what it said

The conversation store is write-once, so a record cannot be quietly rewritten after the fact. It is unreachable from the public internet, has no account key (only revocable managed-identity access), and its paths carry the organisation and the finding - never a user identity or an email address. In production it is held under a retention policy that prevents modification or deletion inside the window, including by an administrator.

We keep these because an assistant that suggests changes to security-relevant code and leaves no reproducible record is not something we are willing to operate. If your organisation’s policy cannot accommodate that retention, BYOAI above remains available and involves no model operated by us.

The exact request contents for each feature will be documented here before that feature ships. See AlertaVuln AI for the full description.

Test coverage leverage (Coming Soon for the hosted analysis)

Test coverage leverage ranks which function a single new test would exercise the most of your application through. The ranking is a deterministic set-cover over the call graph: no model is involved at any point, and your tests are never executed by us.

The hosted version of this analysis - where AlertaVuln computes the ranking server-side from a connected repository, rather than the CLI computing it on your machine - is not yet generally available. Where it is enabled, it uses the same transient-clone path as AV-hosted scanning described above, under the same retention terms. AI-drafted tests, when they arrive, will run under the AlertaVuln AI terms in the preceding section and will be separately opt-in.

Page changelog

Every material edit to this page gets a dated line. Git history is the full record; this list is the human-readable summary.

2026-07-26 - Initial Trust Center published: data-flow, data handling and retention, sub-processors, vulnerability disclosure, availability, compliance roadmap, and AI posture.
2026-07-26 - Added a Region column to the sub-processors table, rendered the data-flow diagram in the browser, and added the operating-entity footer.
2026-07-30 - Corrected the AlertaVuln AI retention claim. The previous wording said model inputs and outputs would not be stored; the implementation retains every hosted conversation in a write-once evidence store, plus a content-free usage record per call. Both are now described, with the reason. Also resolved the hosting region to Australia East, noted that the pre-release model tier is a global rather than data-zone deployment, and added a Coming Soon note for hosted test-coverage analysis.

Operated by Black Ops Solutions IT Pty Ltd (ABN 55 234 810 713).