Σ
OASI
Hermes Console
oasi · core.ai · hermes console
Hermes/Legal/subprocessors
compliance · subprocessors

Subprocessor list

fornitori a cui passiamo dati (limitati), location, DPA

Definizione

"Subprocessor" = soggetto terzo a cui OASI passa dati del cliente (o metadati associati) per fornire il servizio Hermes. Conforme alla terminologia GDPR Art. 28 e standard SaaS.

OASI mantiene la lista aggiornata pubblicamente in questa pagina; ogni aggiunta di un nuovo subprocessor che tocca dati del cliente è comunicata via email ai clienti attivi con preavviso ≥30 giorni, fornendo facoltà di obiezione (vedi DPA §X).

Subprocessor attivi

1 · Anthropic, PBC (LLM provider)

  • Sede legale: San Francisco, CA, USA.
  • Cosa riceve: corpus di codice sorgente selezionato (top-N file dal repo cliente) durante CodeComprehender e RemediationPlanner. Vedi /legal/privacy-llm per il dettaglio completo.
  • Dove: API endpoint api.anthropic.com (US-region default). Per region EU usare l'opzione AWS Bedrock o GCP Vertex on-prem (vedi §6.A, §6.B).
  • Base contrattuale: Anthropic Commercial Terms of Service + Data Processing Addendum (DPA). Riferimenti:
  • Training opt-out: garantito di default sul tier API standard (i prompt non vengono usati per addestrare modelli futuri).
  • Retention dei log: 30 giorni standard; Zero-Data-Retention (ZDR) disponibile a tier enterprise (richiesto e in roadmap OASI).
  • Subprocessor di Anthropic: AWS, GCP (compute). Lista pubblica: https://trust.anthropic.com.

2 · Stripe Payments Europe Ltd. (billing, ATTIVO Sprint 20)

  • Sede legale: Dublin, Irlanda (DPC Ireland è autorità di riferimento).
  • Cosa riceve: SOLO i metadati di billing del cliente (email cliente, importo top-up in EUR, payment method, fatturato per il modello prepaid Pay-per-Discovery, OPPURE Customer/Subscription per il legacy plan FREE/PAID). Mai codice sorgente o output Hermes.
  • Quando: ogni volta che il cliente fa un top-up del saldo prepaid via Stripe Checkout (UI /billing) OPPURE se sottoscrive un piano a pagamento subscription-based. Cliente che non ricarica e non sottoscrive sub → Stripe NON viene mai chiamato (tenant ha solo trial Discovery gratuito; ulteriori run richiedono top-up).
  • Dove: data center EU (Stripe Payments Europe Ltd. è "EU-established" per soggetti EU; payment processing distribuito su CDN globale Stripe).
  • Base contrattuale: Stripe Services Agreement + Standard Contractual Clauses (SCC) + DPA Stripe. Riferimento:
  • Sub-processor Stripe: AWS, GCP, sub-processor list aggiornata da Stripe a https://stripe.com/legal/subprocessor-list.
  • Esclusione possibile: cliente che paga via bonifico SEPA direct
    • invoice (extra-Console, OASI gestione manuale del credit topup via DB query) → Stripe non viene coinvolto, ma perde l'auto-renewal/self-service del top-up. Cliente on-prem (licensing one-time + maintenance contract) → Stripe mai usato.

3 · Provider hosting infrastruttura (compute + storage)

  • Sede: il box srvai01 è ospitato presso il provider VPS attualmente utilizzato da OASI (data center EU). Identità del provider e copia delle sue certificazioni (ISO27001, SOC2) disponibili sotto NDA su security@oasi.systems.
  • Cosa riceve: l'intero stato di Hermes (database, file system, network traffic). Il provider ha accesso fisico/operativo al disco ma non ha credenziali applicative (nessun login operatore valido presso il provider per l'app Hermes).
  • Cifratura at-rest: volume cifrato lato provider; chiavi di cifratura applicative (REPO_DEPLOY_KEY_SECRET e simili) gestite da OASI, non condivise col provider.
  • Backup: snapshot giornaliero gestito dal provider (vedi DPA per RPO/RTO).
  • Base contrattuale: contratto di hosting + DPA Article-28 (con il provider).

4 · Let's Encrypt (Internet Security Research Group — ISRG)

  • Sede legale: Salt Lake City, UT, USA.
  • Cosa riceve: domain validation challenge HTTP per emissione del certificato TLS di hermes.oasi.systems. Nessun dato cliente.
  • Base contrattuale: Let's Encrypt Subscriber Agreement.
  • Classificato qui per completezza/trasparenza ma è subprocessor marginale (riguarda solo l'emissione certificato, non il dato processato).

5 · VCS provider del cliente (subprocessor condizionale — Sprint 3)

OASI non sceglie il VCS provider — è il cliente che registra un repo in Hermes (/repos) e, solo se attiva poi Apply→PR sul piano PAID, il VCS provider corrispondente diventa subprocessor della Discovery di quel cliente.

I provider supportati (Sprint 3) sono:

5.A · GitHub, Inc.

  • Sede legale: San Francisco, CA, USA.
  • Quando: il cliente registra un repo github.com/*.github.com e attiva Apply→PR.
  • Chiamate: api.github.com via @octokit/rest. Clone HTTPS oauth2:<PAT>@github.com/.... Apertura PR + label.
  • Token cliente: fine-grained PAT (scope Contents+Pull requests RW sul singolo repo).
  • Base contrattuale: il rapporto è GitHub Terms ↔ cliente.

5.B · GitLab Inc.

  • Sede legale: San Francisco, CA, USA (SaaS gitlab.com). Per GitLab self-host (es. gitlab.foo.it della PA italiana) il provider È il cliente stesso — nessun trasferimento extra-perimetro.
  • Quando: il cliente registra un repo gitlab.com o un hostname gitlab.* (self-host).
  • Chiamate: REST v4 POST /projects/:id/merge_requests. Clone HTTPS oauth2:<PAT>@<host>/....
  • Token cliente: Personal Access Token (scope api + write_repository).
  • Base contrattuale: GitLab Terms / propria policy on-prem.

5.C · Atlassian (Bitbucket Cloud)

  • Sede legale: Sydney, Australia (Atlassian Pty Ltd).
  • Quando: il cliente registra un repo bitbucket.org e attiva Apply→PR.
  • Chiamate: REST v2 POST /repositories/{ws}/{slug}/pullrequests. Clone HTTPS x-token-auth:<app-pwd>@bitbucket.org/....
  • Token cliente: username:app_password (scope Repositories+PR write).
  • Limitazione: Bitbucket non supporta labels su PR → addLabels no-op.

5.D · Microsoft (Azure DevOps Services)

  • Sede legale: Redmond, WA, USA.
  • Quando: il cliente registra un repo dev.azure.com (o legacy *.visualstudio.com) e attiva Apply→PR.
  • Chiamate: REST 7.1 POST /{org}/{project}/_apis/git/repositories/{repo}/pullrequests. Clone HTTPS hermes:<PAT>@dev.azure.com/....
  • Token cliente: PAT (scope Code RW + Pull Request RW).
  • Particolarità: Azure ha 3 livelli (org→project→repo); HermesRepo.owner deve contenere {org}/{project}.

In ogni caso:

  • Cosa "esce": solo gli artefatti che il cliente vuole esplicitamente vengano scritti sul suo repo (nuovo branch + commit con i file telemetria + il doc Hermes). Nessun altro dato.
  • OASI non ha contratto separato con questi provider: il cliente è contraente diretto del VCS provider scelto; Hermes è un client API che agisce per conto del cliente.
  • Alternative sovrane: il flusso .patch (vedi /legal/dfd flusso 4) non coinvolge nessun VCS provider esterno — Hermes genera il diff unificato e lo restituisce all'operatore via TLS; questo path resta disponibile anche per il cliente che non vuole coinvolgere nessuno dei 4 provider.

6 · LLM provider alternativi (subprocessor condizionali — Sprint 4)

In modalità SaaS default Anthropic è subprocessor di OASI (§1). In modalità on-prem (vedi /legal/dfd "Topologia on-prem" + /legal/dpa §7.ter) il cliente può scegliere un LLM provider diverso — in tal caso quel provider diventa subprocessor del cliente, non di OASI (il cliente è contraente diretto).

Analogamente alla §6.A del cliente per Anthropic (Sprint 2), configurare uno dei provider sotto esclude OASI dal flow GDPR Art. 28 verso quel provider.

6.A · AWS, Inc. (Bedrock — Claude in EU-region) — DISPONIBILE rb49

  • Sede legale Anthropic-on-Bedrock: il modello Claude è fornito via AWS Bedrock; AWS Inc. ha sede Seattle, WA. Le region EU disponibili sono eu-central-1 (Frankfurt) e eu-west-3 (Paris).
  • Quando: cliente sceglie HERMES_LLM_PROVIDER=bedrock (env Console). Chiamate verso bedrock-runtime.<region>.amazonaws.com.
  • Auth: AWS standard chain (AWS_ACCESS_KEY_ID+AWS_SECRET_ACCESS_KEY o IAM role). Hermes non gestisce le credenziali AWS — sono del cliente.
  • Base contrattuale: contratto AWS ↔ cliente + AWS DPA EU.
  • OASI position: non è subprocessor in questo path (il cliente parla direttamente con AWS via le proprie credenziali).

6.B · Google LLC (Vertex AI — Claude in EU-region) — DISPONIBILE rb49

  • Sede legale: Google LLC, Mountain View, CA. Region EU: europe-west1 (St. Ghislain), europe-west4 (Eemshaven).
  • Quando: cliente sceglie HERMES_LLM_PROVIDER=vertex (env Console)
    • HERMES_LLM_GCP_PROJECT. Chiamate verso <region>-aiplatform.googleapis.com.
  • Auth: GCP Service Account JSON via GOOGLE_APPLICATION_CREDENTIALS (montato come Docker secret).
  • Base contrattuale: contratto GCP ↔ cliente + GCP DPA EU.
  • OASI position: non è subprocessor in questo path.

6.C · Ollama (LLM locale air-gapped) — DISPONIBILE rb49

  • Sede legale: nessuna — Ollama è un daemon open-source che il cliente esegue sulla propria infrastruttura (box locale o GPU node su rete privata interna).
  • Quando: cliente sceglie HERMES_LLM_PROVIDER=ollama + HERMES_LLM_OLLAMA_ENDPOINT=http://... (interno).
  • Cosa esce dal perimetro cliente: NIENTE — il modello gira in casa, zero outbound. Massima sovranità.
  • Quality trade-off: i modelli open (Qwen 2.5-Coder, Llama 3.x) al 2025-mid sono inferiori a Claude opus-4-7 sulla code-comprehension italiana. Vedi /legal/privacy-llm §6.E.
  • Base contrattuale: nessuna verso terzi.
  • OASI position: non è subprocessor; nessun trasferimento.

7 · osv.dev (Open Source Vulnerabilities, Google operated)

  • Cosa riceve: nomi+versioni delle dipendenze del cliente (es. "MongoDB.Driver@2.2.3") via il tool osv-scanner.
  • Cosa NON riceve: codice sorgente, identificativo del cliente, metadata personali.
  • Base contrattuale: osv.dev è servizio pubblico open data; non è un subprocessor in senso classico GDPR (i nomi+versioni non sono dati personali). Classificato qui per piena trasparenza del DFD.

Subprocessor pianificati (NON ancora attivi)

SubprocessorFunzioneStatoQuando
Sentry / similarerror tracking lato OASIvalutazioneQ4 2025 (con DPA dedicato)

Quando attiveremo uno di questi, sarà aggiunto qui con preavviso ≥30 giorni; il cliente può obiettare entro tale termine (cfr. DPA).

Audit dei subprocessor

OASI esegue review annuale della lista subprocessor:

  • riconferma della validità del DPA;
  • conferma delle certificazioni / posture di sicurezza;
  • valutazione di alternative;
  • aggiornamento di questa pagina.

L'esito è riportato (forma sintetica) nel Security Whitepaper sezione 7-9 alla revisione corrispondente.

Cosa fare in caso di mancata accettazione di un subprocessor

Se il cliente non può accettare uno o più subprocessor della lista (es. policy regolamentare che vieta il trasferimento USA), le opzioni sono:

  1. Modalità "no LLM" (skip per Discovery) — DISPONIBILE rb50: checkbox "Discovery senza LLM" sul form /discovery (CodeComprehender + RemediationPlanner saltati per quella singola Discovery, audit-logged). Per disattivazione permanente, lasciare ANTHROPIC_API_KEY unset sul box → CodeComprehender ritorna sempre llm_unavailable.
  2. Modalità on-prem — DISPONIBILE rb49 (deploy/onprem/): Hermes deployato dentro la DMZ del cliente, LLM swap a Bedrock/Vertex EU (§6.A/6.B) o Ollama (§6.C, zero outbound). OASI esce dal flow GDPR Art. 28 verso il LLM. Vedi /legal/dpa §7.ter.
  3. Esclusione di Stripe: se il cliente paga tramite bonifico, Stripe non viene coinvolto. Cliente on-prem: licensing one-time, Stripe mai usato.
  4. Esclusione di qualunque VCS esterno: usare solo .patch download (vedi DFD flusso 4), mai Apply→PR. Disponibile ora; nessun adapter VCS coinvolto.
  5. GitLab self-host (sovrano): registrare un repo gitlab.<dominio-cliente> invece che gitlab.com → Hermes parla con il GitLab self-host del cliente, nessun trasferimento extra-perimetro verso GitLab Inc.

Per richieste su un subprocessor specifico, certificazioni correlate, copia degli SCC firmati, scrivere a privacy@oasi.systems.