Inilalarawan ng Pangkalahatang-ideya ng Seguridad na ito ang mga teknikal at pang-organisasyong hakbang na kasalukuyang inilalapat ng Melaya, Inc. ("Melaya") upang protektahan ang pagiging kumpidensyal, integridad, at availability ng plataporma ng Melaya. Nilayon nitong bigyan ang mga prospektibo at kasalukuyang gumagamit, mga mamimili ng negosyo, at mga taga-audit ng tapat na larawan ng kung ano ang nasa produksyon ngayon, kung ano ang isinasagawa, at kung ano ang hindi pa isinasagawa. Kung ang isang kakayahan ay hangarin o isinasagawa, ito ay tahasang minarkahan ng gayon sa halip na nakatago sa likod ng malabong wika. Ang seguridad ay isang ibinabahaging responsibilidad: ang Melaya ay responsable para sa seguridad ng plataporma, at ang mga customer ay responsable para sa seguridad ng kanilang itinayo, na-upload, at isinagawa sa ibabaw nito.

1. Pag-encrypt sa Transit at sa Pahinga

Lahat ng datos na nasa transit sa pagitan ng mga kliyente ng gumagamit at ng mga Serbisyo ay protektado ng Transport Layer Security (TLS) bersyon 1.2 o mas mataas, na tinatapos sa Cloudflare sa gilid ng deployment. Ang profile ng TLS ng produksyon ay sumusunod sa gabay ng katamtamang compatibility ng Mozilla: TLS 1.2 at 1.3 lamang, mga ECDHE cipher suite lamang, HSTS na may dalawang taong max-age at ang direktiba na preload, at isang mahigpit na Patakaran sa Seguridad ng Nilalaman na may tahasang connect-src na listahan ng pahintulot. Ang buong profile, ang nakatuon na listahan ng cipher, at ang quarterly na ikot ng pagsusuri ay dokumentado sa runbook ng TLS Baseline sa panloob na vault ng seguridad at ipinapatupad ng helmet middleware sa server/src/index.ts. Ang mga panloob na tawag mula serbisyo hanggang serbisyo sa loob ng aming imprastraktura ay tumatakbo sa loopback o mga pribadong link ng network.

Ang datos sa pahinga sa pangunahing database ng Postgres at sa object storage ay naka-encrypt gamit ang simetrikong pag-encrypt na ibinibigay ng tagapagtago, na may mga susi na pinamamahalaan ng serbisyo ng pamamahala ng susi ng tagapagtago. Nagbibigay ito ng depensa laban sa pagnanakaw ng hilaw na disk ngunit hindi, sa sarili nito, nagtatanggol laban sa isang kompromiso ng application o tagapagtago.

Sa ibabaw ng pag-encrypt ng disk ng tagapagtago, ang mga sensitibong halaga ay karagdagang protektado ng isang antas ng pag-encrypt ng sobre sa antas ng application na isinagawa sa server/src/services/envelope.ts. Ang mga kredensyal ng API ng palitan (susi, lihim, passphrase) ay nakabalot gamit ang AES-256-GCM gamit ang isang 256-bit na master key na hawak lamang sa kapaligiran ng server bago ipadala sa tagapagbigay ng vault ng Infisical o isulat sa fallback table ng agents.credentials. Ang wire format ay nagdadala ng tahasang identifier ng susi (v1:<kid>:<base64(iv|ciphertext|tag)>) upang ang server ay maaaring tumanggap ng maraming valid na susi sa panahon ng rotation window at i-route ang mga pagbabasa sa eksaktong susi na nag-wrap ng bawat halaga. Ang mga bagong sulat ay palaging gumagamit ng aktibong susi, na siyang unang entry sa na-configure na listahan ng susi. Ang rotation ay isang tatlong-release na pamamaraan na hindi kailanman nagpapababa ng plataporma: idagdag ang bagong susi bilang pangalawang entry (ang mga sulat ay patuloy na napupunta sa lumang susi, ang bagong susi ay read-only), itaguyod ito sa una (ang mga sulat ay lumipat sa bagong susi, ang lumang susi ay nananatiling nababasa), i-re-wrap ang anumang mga makasaysayang row na nakatali sa pagreretiro ng kid, pagkatapos ay alisin ang lumang entry. Hindi nakakakita ng plaintext na mga kredensyal ang Infisical o ang host ng Postgres sa anumang punto: ang isang kompromiso ng alinman sa mga subprocessor na iyon sa pagkakataon ay nagbubunga lamang ng ciphertext, at ang attacker ay karagdagan pang nangangailangan ng na-configure na envelope key upang mabawi ang anumang susi ng palitan. Ang isang one-shot na script ng migrasyon sa server/src/scripts/migrate-envelope-wrap.ts ay humawak ng mga natitirang legacy plaintext row mula bago pa man umiral ang antas ng sobre; ang pagsasaksak ay nakumpleto laban sa database ng produksyon at ang round-trip verifier nito (envelope-verify.ts, 7/7 na mga senaryo) ay lumalabas nang zero sa bawat CI run at laban sa live na produksyon.

2. Paghihiwalay ng Tenant at Daloy ng Proseso

Ipinapatupad ng plataporma ang lohikal na paghihiwalay sa pagitan ng mga nangungupahan sa antas ng aplikasyon. Bawat awtorisadong kahilingan ay nagdadala ng pagkakakilanlan ng gumagamit na nagmula sa isang napatunayan na JSON Web Token, at bawat katanungan sa database, pag-access sa tindahan ng bagay, at paghahanap sa index ng pagkuha ay nakalimitahan ng pagkakakilanlang iyon sa pamamagitan ng parameterized SQL at tRPC context plumbing. Ang mga index ng pagkuha na itinayo para sa Agentic Framework ay iniimbak bawat daloy ng proseso at ibinabalik lamang sa mga katanungang nagmumula sa daloy ng proseso na nagmamay-ari sa kanila. Ang estado ng makina, mga konfigurasyon ng estratehiya, at mga kasaysayan ng order ay katulad na hinati-hati ayon sa gumagamit. Ang Postgres row-level security ay ipinapatupad bilang isang defense-in-depth na antas sa likod ng application-layer scoping: ang FORCE ROW LEVEL SECURITY ay aktibo sa produksyon sa agents.mfa_challenge, agents.credentials, at agents.users, at ang aplikasyon ay kumokonekta sa ilalim ng isang mababang pribilehiyong papel (melaya_app, rolbypassrls=false) na hindi makakakita sa ibang mga nangungupahan kahit ang isang katanungan ay aksidenteng nakalimot ng WHERE user_id nito. Labimpitong cross-tenant na sitwasyon sa server/src/scripts/rls-verify.ts ay lumalabas ng zero laban sa live na database sa bawat CI run, kabilang ang SELECT, INSERT, UPDATE, DELETE, pagbabago ng pagmamay-ari, pag-bypass ng admin, walang kontekstong zero-row, at mga kaso ng GUC-leak regression.

3. Pamamahala ng Susi at Lihim

Ang mga lihim ng aplikasyon, mga susi ng pagpirma, mga kredensyal ng database, at mga susi ng API ng ikatlong panig na ginagamit ng Melaya mismo ay iniimbak sa mga variable ng kapaligiran na nilo-load sa pagsisimula ng proseso at sa aming tagapagbigay ng vault. Hindi kailanman inilalagay ang mga ito sa source control at ang mga halaga ng produksyon ay hindi ibinabahagi sa pagitan ng mga developer. Ang MEL_ENVELOPE_KEY ay hiwalay na hawak mula sa mga kredensyal ng database ng Postgres at hiwalay mula sa token ng Infisical, kaya ang pagsasamantala sa alinman sa tatlo ay hindi magbubunga ng plaintext na mga kredensyal ng palitan. Mahigpit na hinihikayat ang mga customer na limitahan ang bawat susi ng API ng palitan sa mga pahintulot na para sa trading lamang, na huwag paganahin ang mga withdrawal sa nagbigay na palitan, at mag-apply ng IP allowlisting kung sinusuportahan ito ng palitan.

Ang mga token ng sesyon ay pinirmahan sa ilalim ng isang multi-key rotation window. Tinatanggap ng server ang isang listahang pinaghiwalay ng kuwit ng mga susi ng pagpirma sa pamamagitan ng variable ng kapaligiran na JWT_SECRETS, bawat isa ay may kasamang maikling pagkakakilanlan ng susi. Ang mga bagong token ay pinirmahan sa ilalim ng unang (aktibo) na susi at nagdadala ng pagkakakilanlang iyon sa JWT header para sa O(1) na pagpapatunay. Ang mga token na inisyu sa ilalim ng anumang nagreretirong susi sa window ay patuloy na mapapatunayan hanggang sa lumipas ang kanilang pitong-araw na TTL, sa puntong iyon ay maaaring alisin ang nagreretirong susi. Ang mga nag-expire na token ay tinatanggihan kaagad kahit na ang isang hindi aktibong susi ay tatanggapin pa rin. Ang pamamaraan ng rotasyon ay dokumentado sa server/src/services/jwtKeys.ts; ang mga round trip ng pagpapatunay ay inuusbong sa server/src/scripts/jwt-keys-verify.ts.

4. Pagpapatunay at Kontrol ng Pag-access

Ang pagpapatunay ng gumagamit ay nakabatay sa email at password na may bcrypt hashing sa work factor 12, kasama ang rate limiting sa mga endpoint ng pag-login, pagpaparehistro, at nakalimutang password (20 pagtatangka bawat IP bawat 15 minuto, ipinapatupad in-process ng express-rate-limit). Ang mga token ng sesyon ay inisyu bilang mga JSON Web Token na may pitong-araw na pagkabulok at nakatali sa gumagamit, papel, at mga claim ng antas. Ang role-based na kontrol ng pag-access ay nagtatangi sa user mula sa admin, at ang tier-based na kontrol ng pag-access ay nagta-gate ng mga tampok ayon sa apat na antas na katalogo. Bawat aksyon ng kahihinatnan ay sinusuri sa panig ng server; ang mga gate sa panig ng kliyente ay purong pahiwatig ng UX at hindi kailanman pinagkakatiwalaan para sa seguridad.

Ang two-factor na pagpapatunay ay makukuha ng lahat ng gumagamit sa pamamagitan ng karaniwang TOTP profile (RFC 6238, SHA-1, 6 digit, 30-segundong panahon, ±1 window drift) at katugma sa bawat pangunahing authenticator app. Ang mga TOTP shared secret ay nabuo sa panig ng server na may 160 bit ng entropy, nakabalot sa pamamagitan ng envelope encryption layer na inilalarawan sa seksyon 1, at nakaimbak sa hilera ng gumagamit. Ang mga recovery code ay nabuo nang isang beses sa enrollment, bcrypt-hashed sa work factor 12, at pagkatapos ay nakabalot nang pangalawang beses ng envelope layer kaya ang pagsasamantala sa database lamang ay hindi makakabuhay muli ng mga ito. Ang enrollment ay isang dalawang-hakbang na proseso na nangangailangan ng gumagamit na patunayan na na-configure nila ang kanilang authenticator sa pamamagitan ng pagpasok ng isang live na code bago mamarkahan ang pangalawang salik na aktibo. Ang daloy ng pag-login ay nagiging isang pagsusuri ng password, pagkatapos ay isang maikling (limang minuto) na token ng hamon, pagkatapos ay isang pagpapatunay ng code na atomically nakukonsumo ang hilera ng hamon; ang isang nakuha na token ng hamon ay hindi maaaring i-replay pagkatapos ng isang matagumpay na konsumo. Ang MFA ay kinakailangan para sa pagdaragdag ng mga kredensyal ng CEX API at para sa pagbuo ng mga susi ng API ng plataporma, ang dalawang pinakamataas na epektong aksyon na nakikipag-ugnayan sa pondo sa produkto. Bawat resulta ng hamon ng MFA (mfa.challenge_issued, mfa.challenge_ok, mfa.challenge_fail) ay isinulat sa append-only na audit log na inilalarawan sa §6 upang ang mga pattern ng hamon ay maaaring ma-audit at hindi mababago.

Ang pag-access ng empleyado ng Melaya sa mga sistema ng produksyon ay ibinibigay sa bawat-inhinyero na batayan at tinatanggal kapag hindi na kailangan. Ang mga stale na NOPASSWD sudoers entry at mga awtorisadong susi ng SSH ay nililinis sa bawat-sesyon na batayan. Ang isang pormal na quarterly-attestation na pamamaraan ng pagsusuri ng pag-access na may mga rekord ng pagsusuri na pinirmahan, at isang kumpletong paghihiwalay sa pagitan ng gumagamit ng deploy at ng gumagamit ng runtime ng serbisyo (upang ang isang nakompromisong proseso ng serbisyo ay hindi makakapag-pivot patungo sa landas ng deploy), ay parehong sinusubaybayan bilang mga planong kontrol sa roadmap ng seguridad.

5. Rate Limiting ng Network at Imprastraktura

Ang rate limiting ay ipinapatupad sa antas ng aplikasyon ng express-rate-limit na may Redis-backed na shared store upang ang mga limitasyon ay pandaigdigan sa bawat instance ng server sa halip na per-proseso. Dalawang independyenteng naka-configure na timba ang naaangkop: isang mahigpit na timba sa mga endpoint ng pagpapatunay (20 pagtatangka bawat IP bawat 15-minutong window) at isang pangkalahatang timba ng API (200 kahilingan bawat IP bawat minuto). Ang limiter ay fail-closed: kung ang Redis store ay hindi maabot, ang mga endpoint ng auth ay tumatanggi sa halip na dumaan. Ang tRPC batch-aware wrapper ng limiter ay napatunayan ng server/src/scripts/rate-limit-verify.ts (7/7 na sitwasyon, kabilang ang pag-atake ng proc-laundering).

Ang trapiko sa edge ay nasa harapan ng Cloudflare na may WAF, pagtuklas ng bot, at geo-blocking sa mga landas na mataas ang panganib. Ang isang Terraform scaffold para sa Cloudflare zone ay nakatuon sa deploy/cloudflare/ kasama ang isang operational runbook na sumasaklaw sa drift detection, emergency override, at ang 24-oras na patakaran ng reconcile; ang pag-import at pagtatambal ng kasalukuyang manu-manong zone laban sa scaffold na iyon ay nasa progreso at ito ang pinaghahariang gawain bago mag-iskedyul ng unang panlabas na pagsubok sa penetrasyon.

6. Pagmamatyag, Pag-log, at Audit

Ang plataporma ay naglalabas ng mga structured na log mula sa Node.js tRPC server, ang Rust Engine, ang Python worker, at ang edge. Lahat ng log sa antas ng host at container (systemd journal, /var/log/, nginx access/error, Jenkins at Gitea container stdout, at bawat log file ng aplikasyon ng melaya) ay ipinapadala off-box sa real time sa isang Grafana Cloud Loki tenant sa parehong rehiyon bilang host ng produksyon sa pamamagitan ng isang Grafana Alloy collector, kaya ang audit trail ay nakaligtas sa pagsasamantala ng host o pagkawala ng disk.

Ang mga kaganapan na may kaugnayan sa seguridad (mga resulta ng pagpapatunay, mga resulta ng hamon ng MFA, mga pagdaragdag at pag-alis ng kredensyal ng CEX, pagbuo at pagbabawi ng susi ng API ng plataporma, mga pagbabago ng antas at mga rollback) ay karagdagang isinusulat sa isang append-only na talahanayan ng agents.audit_log na tinukoy sa server/sql/audit_log_schema.sql. Gumagamit ang schema ng REVOKE UPDATE, DELETE mula sa papel ng aplikasyon, isang cryptographic hash chain sa mga hilera (prev_hash / row_hash), HMAC-SHA256 sa IP ng aktor na may isang keyed na lihim (hindi plain SHA-256, na maaaring atakihin ng diksyunaryo), at isang side-table na agents.audit_log_tombstone para sa pagtanggal ng GDPR Article 17 na hindi kailanman binabago ang chain. Ang isang pang-araw-araw na verifier (verify-audit-chain.ts) ay lumalakad sa chain nang buo, nagpatunay ng monotonicity ng timestamp na may ±2 segundong NTP tolerance, at naglalabas ng anchor digest na angkop para sa panlabas na write-once na imbakan. Anim na sitwasyon ng pakikialam sa audit-log-verify.ts ay lumalabas ng zero laban sa live na produksyon.

7. Pamamahala ng Kahinaan

Bawat commit ay nagpapatakbo ng npm audit --production at isang Trivy filesystem scan bilang bahagi ng CI. Ang Trivy ay tinatawag nang dalawang beses sa bawat build: isang beses sa isang gated na mode na may ignore-unfixed: true upang ang mga makagagawang natuklasan ay mabigo sa pagsusuri, at isang beses na may ignore-unfixed: false at hindi gated upang ang kumpletong kalawakan ng kahinaan ay mai-upload sa tab ng Seguridad ng repositoryo para sa ebidensya ng SOC 2. Ang host ng produksyon ay nagpapatakbo ng unattended-upgrades na may naka-enable na channel ng seguridad. Ang mga third-party na imahe ng container para sa Jenkins, Gitea, Infisical, Postgres, at Redis ay review-gated bago ang mga pagbabago ng bersyon at sinusubaybayan sa runbook ng Patching Cadence sa panloob na vault ng seguridad.

Hindi pa sumasailalim ang Melaya sa isang third-party na panlabas na pagsubok sa penetrasyon. Ang saklaw ng pakikipag-ugnayan (kabilang ang mga asset na nasa saklaw at wala sa saklaw, mga patakaran ng pakikipag-ugnayan, shortlist ng vendor, at cadence ng remedyasyon pagkatapos ng pakikipag-ugnayan) ay nakatuon sa panloob na runbook ng Pentest Scope upang ang pagpili ng vendor ay makakilos sa sandaling matupad ang IaC reconcile ng Cloudflare mula sa §5. Walang claim na "taunang pentest" ang ginagawa kahit saan sa dokumentasyon ng Melaya.

8. Ligtas na Pagbuo ng Software

Ang mga pagbabago sa plataporma ay dumadaan sa source control na may peer review bago ang merge. Ang strict mode ng TypeScript at static analysis ay tumatakbo sa bawat build ng kliyente at server. Ang gitleaks ay tumatakbo bilang isang pre-commit hook at sa CI, na may path-scoped na allow-list sa halip na isang pandaigdigan, kaya ang aksidenteng pagsisiwalat ng mga kredensyal ay nabibigo ang build bago ang merge. Lahat ng GitHub Actions ay naka-pin ayon sa commit SHA upang maiwasan ang mga pag-atake ng tag-rewriting sa supply-chain. Ang mga deployment ng produksyon ay dumadaan sa isang restricted na Jenkins SSH wrapper na may command= na paghihigpit ng authorized_keys upang kahit ang isang nakompromisong CI runner ay maaari lamang mag-invoke ng mga tahasang operasyon ng resync <service> at log <service> para sa apat na serbisyo ng Melaya: walang arbitrary shell, walang filesystem traversal, walang pribilehiyong pag-akyat higit sa mismong pag-restart ng serbisyo. Bawat invokasyon ng pipeline ng deploy ay naka-log off-box sa Grafana Cloud Loki tenant para sa audit.

9. Pagtugon sa Insidente

Nagpapanatili ang Melaya ng isang nakasulat na runbook ng Pagtugon sa Insidente na sumasaklaw sa deklarasyon ng kalubhaan (SEV-0 hanggang SEV-3), mga takdang papel (IC, teknikal na lider, komunikasyon, iskraib), isang checklist ng pagpigil na kinabibilangan ng mga hakbang ng rotasyon ng envelope-key, JWT-key, at audit-log IP-HMAC-key, ang GDPR Article 33 72-oras na matrisel ng abiso, at isang template ng post-mortem. Ang runbook ay nakatuon sa panloob na vault ng seguridad at tinatrato bilang isang live na dokumento: ang unang tabletop drill ay naka-iskedyul para sa Q3 2026, at ang runbook ay tahasang naka-flag bilang "hindi aktibo" sa sarili nitong §7 hanggang maisakatuparan ang drill na iyon. Ang mga inhinyero na naka-on-call ay tumutugon sa mga totoong insidente ngayon; ang gate ng drill ay tungkol sa pormal na tabletop na ehersisyo, hindi sa pagkakaroon ng landas ng tugon.

10. Backup at Pagbawi mula sa Sakuna

Ang mga target ng Recovery Time Objective (RTO) at Recovery Point Objective (RPO) bawat subsistema ay inilathala sa panloob na runbook ng RTO RPO: ang antas ng agents.* ay nagta-target ng 15-minutong RTO / 2-oras na RPO, ang pag-iimbak ng kredensyal ng CEX ay nagta-target ng 5-minutong RTO / 1-oras na RPO, ang Infisical at object storage ay nagta-target ng 1-oras na RTO / 4-oras na RPO, ang Redis ay walang backup at muling itinatayo sa muling koneksyon. Pinagsasama ng mga mekanika ng backup ang patuloy na WAL archiving, isang gabi-gabing lohikal na dump, isang buwanang base backup, at isang pang-araw-araw na write-once na pag-export ng anchor ng audit-log sa isang panlabas na lokasyon. Ang unang buong taunang drill ng pagpapanumbalik ay naka-iskedyul para sa Q3 2026 at ang nakasulat nitong pagpapatunay ng wall-clock ng pagpapanumbalik at pagsusuri ng integridad ay itatuon sa parehong runbook.

11. Pagpapatuloy ng Negosyo

Ang isang nakasulat na Plano ng Pagpapatuloy ng Negosyo ay nakatuon sa panloob na vault ng seguridad na sumasaklaw sa pagtugon sa pangunahing pagpalya ng rehiyon, pagpalya ng tagapagbigay ng Postgres, pagpalya ng Infisical vault (patuloy na naglilingkod ang server sa mga kasalukuyang sesyon sa pamamagitan ng mga cached na kredensyal, ang mga bagong pagsulat ng CEX ay tumatanggi na may error na nakikita ng gumagamit), pagpalya ng Stripe (ang mga kasalukuyang subscription ay hindi apektado), matrisel ng pagkakaroon ng tauhan, at isang talahanayan ng contingency bawat tagapagtustos. Ang plano ay sinusuri sa parehong quarterly na cadence bilang ang TLS baseline.

12. Seguridad ng Vendor at Subprocesor

Gumagamit ang Melaya ng limitadong hanay ng mga subprocesor, bawat isa ay pinili para sa postura ng seguridad nito. Ang mga kasalukuyang subprocesor sa produksyon ay kinabibilangan ng Stripe para sa pagpoproseso ng bayad, Cloudflare para sa edge TLS at WAF, self-hosted na Infisical para sa pag-iimbak ng lihim (co-resident sa host ng produksyon, hindi isang ikatlong panig), ang aming tagapagbigay ng hosting ng Postgres, ang aming tagapagbigay ng hosting ng Redis, ang aming tagapagbigay ng object storage, mga tagapagbigay ng transaksyonal na email, at Grafana Labs para sa off-box na koleksyon ng log at metric sa Grafana Cloud (parehong rehiyon bilang host ng produksyon, SOC 2 Type II na napatunayan). Ang mga customer na nagko-configure ng mga third-party na tagapagbigay ng modelo ng wika ay epektibong nagdaragdag ng mga tagapagbigay na iyon bilang mga subprocesor para sa mga daloy ng proseso na isinasaayos nila sa kanila; ang mga tagapagbigay na iyon ay nasa sariling konfigurasyon ng customer at hindi saklaw ng mga kontrata ng vendor ng Melaya. Ang canonical na listahan ng subprocesor ay pinapanatili sa panloob na vault ng seguridad na may nakatuong 15-araw na pangako ng abiso sa pagbabago para sa mga enterprise na customer. Ang isang pampublikong bersyon ay inilalathala sa melaya.org/legal/subprocessors habang live ang frontend.

13. Postura ng Pagsunod

Itinatayo ng Melaya ang mga kontrol nito na isinasaalang-alang ang SOC 2 Trust Services Criteria at ISO/IEC 27001. Sa petsa ng dokumentong ito, WALA pang hawak na SOC 2 Type I, SOC 2 Type II, ISO/IEC 27001, o anumang katumbas na third-party na pagpapatunay ng seguridad ang Melaya. Ito ay mga mithiing milestone sa aming roadmap. Ang anumang potensyal na customer na nangangailangan ng pagpapatunay ngayon ay dapat umasa sa isang deliverable ng pagsusuri ng agwat sa halip na isang nakumpletong ulat. Maaaring humiling ang mga enterprise na customer ng aming kasalukuyang matrisel ng kontrol at listahan ng mga remedyasyon na nasa progreso sa pamamagitan ng pakikipag-ugnayan sa [email protected].

Isang labinlimang-seksyong template ng Data Processing Addendum ang nagawa na at nakatuon sa panloob na vault ng seguridad. Isinasama nito ang European Commission Standard Contractual Clauses (Module 2 para sa controller-to-processor at Module 3 para sa processor-to-processor), ang UK International Data Transfer Addendum, at ang katumbas na Swiss FADP. Ang pangako ng abiso sa paglabag ng 72 oras ng GDPR Article 33, ang pamamaraan ng pagbabalik o pagtanggal, at mga karapatan sa audit (limitado sa taunang at NDA'd na SOC 2 Type II kapag natupad iyon) ay lahat ay nakatali sa template. Ang pagsusuri ng panlabas na abogado ay nakabinbin bago ang DPA ay inaalok bilang isang clickwrap sa mga bayad na antas at bilang isang bilateral na lagdaan na bersyon sa citadel na antas.

14. Mga Responsibilidad ng Customer

Ang seguridad sa Melaya ay ibinahagi. Ang mga customer ay responsable sa pagpili ng matibay at natatanging mga password, pagprotekta ng kanilang mga kredensyal ng account, pagliit ng mga susi ng API ng palitan sa pinakamaliit na kinakailangang mga pahintulot, pagsusuri at pagpapatunay ng gawi ng mga daloy ng proseso na itinayo nila, pagkontrol sa nilalaman na ina-upload nila sa mga index ng pagkuha, pagsusuri ng mga tuntunin at mga kagawian ng paghawak ng datos ng anumang mga third-party na tagapagbigay ng modelo ng wika na pinipiling i-route nila, at agarang pag-uulat ng anumang pinaghihinalaang pagsasamantala. Mahigpit naming inirerekomenda ang pag-enable ng two-factor na pagpapatunay sa mga setting ng account sa unang pagkakataon na mag-sign in kayo; ito ay kinakailangan bago ang anumang kredensyal ng CEX ay maidagdag o anumang susi ng API ng plataporma ay mabuo, at ito ang pinaka-mataas na epektong kontrol ng seguridad na maaaring ilapat ng customer sa sarili nilang account.

15. Responsableng Pagsisiwalat at Safe-Harbor

Safe-harbor. Ang Melaya, Inc. ay hindi maghahabol ng legal na aksyon laban sa, o susuportahan ang anumang third-party na legal na aksyon laban sa, mga mananaliksik ng seguridad na kumikilos nang may mabuting intensyon at sumusunod sa patakarang ito. Ang pangakong ito ay naaangkop sa mga claim na maaaring ibangon ng Melaya sa ilalim ng U.S. Computer Fraud and Abuse Act (CFAA), ang U.K. Computer Misuse Act, ang katumbas na probisyon ng mga batas ng computer-misuse ng Miyembro ng EU, at anumang civil-law na claim para sa paglabag sa kontrata, tortious interference, o trespass to chattels. Ang "mabuting intensyon" ay nangangahulugang ang mananaliksik ay gumawa ng tunay na pagsisikap na sumunod sa saklaw at mga patakaran ng pakikipag-ugnayan sa ibaba, hindi nag-access, nagbago, nawasak, o nag-exfiltrate ng datos na kabilang sa ibang mga gumagamit, hindi sinadyang nasira ang Mga Serbisyo para sa ibang mga gumagamit, at naisiwalat ang natuklasan nang pribado sa [email protected] bago ang anumang pampublikong pagsisiwalat. Ang sugnay na ito ay may bisa sa Melaya at hindi nangangailangan ng pag-apruba bawat ulat. Hindi saklaw ang mga gawi na independyenteng ilegal sa ilalim ng hurisdiksyon ng mananaliksik, tulad ng aktwal na panloloko sa pananalapi laban sa ibang mga gumagamit, o pangingikil.

Saklaw. Ang pagsubok ay awtorisado laban sa melaya.org at lahat ng subdomain sa *.melaya.org zone, ang surface ng aplikasyon sa app.melaya.org, ang mga endpoint ng Builder API, at ang mga legal na pahina na inilathala ng Melaya. Ang pagsubok ay HINDI awtorisado laban sa: (i) live na paglalagay ng order, pagkansela, o pagbabago sa anumang third-party na palitan na naabot sa pamamagitan ng Melaya; (ii) mga third-party na tagapagbigay ng modelo ng wika (OpenAI, Anthropic, Google, Cohere, mga lokal na runtime) na naabot sa pamamagitan ng isang daloy ng proseso na naka-configure ng gumagamit; (iii) Cloudflare, tagapagbigay ng hosting, o imprastraktura ng tagapagbigay ng vault mismo; (iv) anumang anyo ng pag-atake ng denial-of-service (L3/L4 flood, L7 flood, credential stuffing sa dami); (v) social engineering ng mga empleyado, kontraktor, o customer ng Melaya; (vi) pisikal na panghihimasok.

Mga patakaran ng pakikipag-ugnayan. Ang mga mananaliksik ay dapat huminto sa pagsubok sa sandaling napatunayan na ang isang natuklasan (ang isang solong hindi mapaminsalang pagbasa ay sapat na patunay ng cross-tenant na pag-access), hindi dapat baguhin o i-exfiltrate ang datos ng ibang mga gumagamit, hindi dapat mag-install ng persistence, at dapat panatilihing mababa ang awtomatikong pagsubok sa 1 kahilingan bawat segundo nang patuloy. Ang trapiko ng pagsubok ay dapat magdala ng isang natatanging header na User-Agent: Melaya-research/<handle> upang matukoy ng Melaya ito mula sa totoong trapiko at hindi ma-page ang on-call para dito.

Triage SLA. Nangako ang Melaya na kikilalanin ang mga wastong ulat sa loob ng limang (5) araw ng negosyo mula sa pagtanggap, magbibigay ng paunang pagtatasa ng kalubhaan sa loob ng sampung (10) araw ng negosyo mula sa pagkilala, at magrerememdiya ng mga natuklasan ayon sa hagdan ng kalubhaan: Kritikal sa loob ng 48 oras, Mataas sa loob ng 7 kalendaryo na araw, Katamtaman sa loob ng 30 kalendaryo na araw, Mababa sa isang pagkakataong batayan. Kung hindi matutupad ng Melaya ang isang pangako ng SLA, maaaring magbigay ang mananaliksik ng pitong (7) araw na nakasulat na abiso ng intensyon na maglathala at ang proteksyon ng safe-harbor ay nananatiling may bisa sa buong paglalathala basta't sumunod ang mananaliksik sa mga patakaran ng pakikipag-ugnayan sa buong panahon.

Pakikipag-ugnayan. Ang mga ulat ay dapat ipadala sa [email protected]. Ang isang PGP key para sa mga naka-encrypt na ulat ay ilalathala sa /.well-known/security.txt. Ang mga ulat ay hindi dapat ipadala sa pamamagitan ng social media, mga isyu ng GitHub sa mga pampublikong repositoryo ng Melaya, o anumang surface ng chat ng suporta: ang mga channel na iyon ay hindi sinusubaybayan para sa nilalaman na sensitibo sa seguridad at lumilikha ng panganib ng aksidenteng pampublikong pagsisiwalat bago ang remedyasyon.

Ang Seksyong 15 na ito ay self-contained at ang mga pangako nito ay may bisa. Ang safe-harbor sa unang talata, ang saklaw at mga patakaran ng pakikipag-ugnayan sa ikalawa at ikatlong talata, ang triage SLA sa ikaapat na talata, AT ang pakikipag-ugnayan ng Terms-of-Service at mga patakaran ng pagbabago na prospective-only sa kaagad na sumusunod na talata ay magkasamang bumubuo sa buong hanay ng mga pangako na may bisa sa Melaya kaugnay ng mga mananaliksik ng seguridad. Bawat talata sa Seksyong 15 na ito, hindi lamang ang unang apat, ay bahagi ng nakataling hanay ng pangako. Nagpapanatili ang Melaya ng isang panloob na operational runbook para sa triage routing at escalation, ngunit ang runbook na iyon ay hindi nagdaragdag sa, nagbabawas mula sa, o nagbabago ng alinman sa mga pangako sa Seksyong 15 na ito, at ang isang mananaliksik ay hindi kailangang basahin ang anumang ibang dokumento upang umasa sa safe-harbor sa itaas. Ang anumang pagbabago sa Seksyong 15 na ito ay naaangkop nang prospective lamang: ang isang natuklasan na iniulat nang may mabuting intensyon sa ilalim ng bersyon ng Seksyong 15 na ito na may bisa sa oras ng ulat ay nananatiling protektado ng safe-harbor ng bersyong iyon anuman ang anumang kasunod na pagbabago.

Pakikipag-ugnayan sa Mga Tuntunin ng Serbisyo (may bisa). Ang Seksyong 15 na ito ay bumubuo ng tahasang awtorisasyon ng Melaya para sa aktibidad ng pananaliksik sa seguridad na kung hindi man ay maaaring mapaghigpitan ng mga pagbabawal ng Mga Tuntunin ng Serbisyo laban sa pag-circumvent, pagpapatay, o pakikialam sa seguridad, rate-limiting, o mga tampok ng kontrol ng pag-access ng Melaya. Ang isang mananaliksik na kumikilos sa loob ng saklaw at mga patakaran ng pakikipag-ugnayan sa itaas ay samakatuwid ay hindi lumalabag sa Mga Tuntunin para sa gawi na iyon, at iwinawaksi ng Melaya ang anumang claim na maaaring ibangon nito sa ilalim ng Mga Tuntunin kaugnay ng partikular na gawi na iyon. Ang talatang ito mismo ay bahagi ng nakataling hanay ng pangako sa itaas at hindi lamang interpretasyon na teksto.

16. Mga Pagbabago sa Overview na Ito

Maaaring i-update ng Melaya ang Security Overview na ito paminsan-minsan upang ipakita ang mga pagbabago sa plataporma, sa aming mga kontrol, o sa aming mga subprocesor. Ang petsang "Huling na-update" sa itaas ng dokumentong ito ay nagpapakita ng pinakabagong rebisyon. Kapag nakumpleto ang mga item na operasyonal na nakabinbin (tulad ng unang drill ng pagpapanumbalik, unang IR tabletop drill, unang panlabas na pentest, o pagsusuri ng panlabas na abogado ng DPA template), ang kaukulang seksyon ay muling isinusulat upang ipakita ang bagong estado at ang pagbabago ay inihayag sa changelog ng produkto.

17. Pakikipag-ugnayan

Para sa mga katanungan sa seguridad, mga ulat ng kahinaan, o upang humiling ng dokumentasyon ng pagsunod, makipag-ugnayan sa: