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
CodeComprehendereRemediationPlanner. Vedi/legal/privacy-llmper 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_SECRETe 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.come attiva Apply→PR. - Chiamate:
api.github.comvia@octokit/rest. Clone HTTPSoauth2:<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.itdella PA italiana) il provider È il cliente stesso — nessun trasferimento extra-perimetro. - Quando: il cliente registra un repo
gitlab.como un hostnamegitlab.*(self-host). - Chiamate: REST v4
POST /projects/:id/merge_requests. Clone HTTPSoauth2:<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.orge attiva Apply→PR. - Chiamate: REST v2
POST /repositories/{ws}/{slug}/pullrequests. Clone HTTPSx-token-auth:<app-pwd>@bitbucket.org/.... - Token cliente:
username:app_password(scope Repositories+PR write). - Limitazione: Bitbucket non supporta labels su PR →
addLabelsno-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 HTTPShermes:<PAT>@dev.azure.com/.... - Token cliente: PAT (scope Code RW + Pull Request RW).
- Particolarità: Azure ha 3 livelli (org→project→repo);
HermesRepo.ownerdeve 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/dfdflusso 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) eeu-west-3(Paris). - Quando: cliente sceglie
HERMES_LLM_PROVIDER=bedrock(env Console). Chiamate versobedrock-runtime.<region>.amazonaws.com. - Auth: AWS standard chain (
AWS_ACCESS_KEY_ID+AWS_SECRET_ACCESS_KEYo 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)
| Subprocessor | Funzione | Stato | Quando |
|---|---|---|---|
| Sentry / similar | error tracking lato OASI | valutazione | Q4 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:
- 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, lasciareANTHROPIC_API_KEYunset sul box → CodeComprehender ritorna semprellm_unavailable. - 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. - Esclusione di Stripe: se il cliente paga tramite bonifico, Stripe non viene coinvolto. Cliente on-prem: licensing one-time, Stripe mai usato.
- Esclusione di qualunque VCS esterno: usare solo
.patchdownload (vedi DFD flusso 4), mai Apply→PR. Disponibile ora; nessun adapter VCS coinvolto. - GitLab self-host (sovrano): registrare un repo
gitlab.<dominio-cliente>invece chegitlab.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.