Pangkalahatang-tanaw ng Seguridad

Inilalarawan ng Pangkalahatang-ideya ng Seguridad na ito ang mga teknikal at pang-organisasyong hakbang na kasalukuyang inilalapat ng Melaya Labs LLC ("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

Ang lahat ng datos na dumadaan sa pagitan ng mga kliyenteng gumagamit at ng mga Serbisyo ay protektado ng Transport Layer Security (TLS) bersyon 1.2 o mas mataas, na tinatanggap sa Cloudflare sa gilid ng deployment. Ang production TLS profile ay sumusunod sa gabay ng Mozilla Intermediate na pagkakatugma: TLS 1.2 at 1.3 lamang, ECDHE cipher suites lamang, forward-secret AEAD ciphers lamang, HSTS na may dalawang taon na max-age at ang preload na direktiba, at isang mahigpit na Content Security Policy na may tahasang connect-src na listahan ng mga pinahintulutan. Ang Content Security Policy ay inilalapat sa parehong mga ibabaw: itinatakda ng API server ang default-src 'none' sa pamamagitan ng security-header middleware nito, at ang pampublikong web application ay nagpapadala ng patakaran na nagbibigay-pahintulot sa aming sariling mga backend kasama ang mga tagabayad at tagapag-sign in, humahadlang sa plugin content at base-tag o form-action hijacking, at nililimitahan ang pagsasagawa ng script, upang ang isang iniksyong script ay hindi makakapag-exfiltrate ng datos sa isang mapanganib na pinagmulan. Ang buong TLS profile, ang nakatuon na listahan ng cipher, at ang quarterly na takdang pagsusuri ay nakadokumento sa runbook na TLS Baseline sa internal na security vault. Ang mga internal na tawag ng serbisyo-sa-serbisyo sa loob ng aming imprastraktura ay tumatakbo sa loopback o pribadong mga link ng network.

Ang pag-encrypt ng datos na nakapahinga ay isinasagawa ngayon sa application layer sa pamamagitan ng field-level na envelope encryption. Ang full-volume na disk encryption sa storage layer ay hindi pa pinagana: ang mga production block device ay kasalukuyang hindi naka-encrypt sa antas ng disk. Ang volume-level na encryption gamit ang LUKS ay pinili bilang landas ng remedyasyon at ito ay isang nakatuong aytem sa security roadmap. Hanggang sa maisagawa ito, ang Melaya ay HINDI nagpapahayag ng disk-layer o provider-managed na volume encryption bilang isang aktibong kontrol.

Ang mga sensitibong halaga ay pinoprotektahan ng isang application-level na envelope encryption layer na isinagawa sa aming serbisyo ng envelope encryption. Ang mga kredensyal ng API ng palitan (susi, lihim, passphrase), ang mga kredensyal ng koneksyon bawat gumagamit at mga OAuth token, at ang mga lihim ng MFA at mga recovery code ay binabalot ng AES-256-GCM gamit ang isang 256-bit na master key na hawak lamang sa proseso ng server bago ipadala sa Infisical vault provider o isulat sa fallback na talahanayan na agents.credentials. Ang wire format ay nagdadala ng tahasang key identifier (v1:<kid>:<base64(iv|ciphertext|tag)>) upang matanggap ng server ang maraming wastong susi sa panahon ng rotation window at maipadala ang mga pagbabasa sa eksaktong susi na nagbalot ng bawat halaga. Ang mga bagong pagsusulat ay palaging gumagamit ng aktibong susi, na siyang unang aytem sa naka-configure na listahan ng mga susi. Ang rotation ay isang tatlong-release na pamamaraan na hindi nagpapatigil ng platform: idagdag ang bagong susi bilang pangalawang aytem (ang mga pagsusulat ay patuloy na napupunta sa lumang susi, ang bagong susi ay read-only lamang), i-promote ito sa una (ang mga pagsusulat ay lilipat sa bagong susi, ang lumang susi ay nananatiling mababasa), balatusin muli ang lahat ng makasaysayang hilera na nakatali sa retired na key identifier, pagkatapos ay alisin ang lumang aytem. Hindi nakikita ng Infisical o ng Postgres host ang mga kredensyal sa plaintext kahit kailan: ang pagkakompromiso ng alinman sa mga subprocessor nang hiwalay ay nagbubunga lamang ng ciphertext, at ang umaatake ay karagdagang nangangailangan ng isang naka-configure na envelope key upang mabawi ang anumang susi ng palitan. Isang one-shot na migration script ang nag-asikaso ng mga natitirang legacy plaintext na hilera mula bago pa lumabas ang envelope layer. Ang paglilinis ay nakumpleto laban sa production database at ang round-trip verifier nito (envelope-verify.ts, 7/7 na sitwasyon) ay lumalabas ng zero sa bawat CI run at laban sa live na produksyon.

2. Paghihiwalay ng Tenant at Daloy ng Proseso

Ipinapatupad ng platform ang lohikal na paghihiwalay sa pagitan ng mga tenant sa layer ng aplikasyon. Ang bawat authenticated na kahilingan ay nagdadala ng identifier ng gumagamit na nagmula sa isang validated na JSON Web Token, at ang bawat query sa database, pag-access sa object store, at paghahanap sa retrieval index ay inilimit ng identifier na iyon sa pamamagitan ng parameterized SQL at tRPC context plumbing. Ang mga retrieval index na itinayo para sa Agentic Framework ay iniimbak bawat pipeline at ibinabalik lamang sa mga query na nagmumula sa pipeline na nagmamay-ari sa mga ito. Ang estado ng engine, mga konfigurasyon ng estratehiya, at mga kasaysayan ng order ay katulad na pinaghatid-hatid ayon sa gumagamit. Ang row-level security ng Postgres ay ipinapatupad bilang isang defense-in-depth na layer sa likod ng application-layer scoping: ang FORCE ROW LEVEL SECURITY ay aktibo sa produksyon sa 44 talahanayan sa mga schema ng agents.* at cex.* sa ilalim ng 117 patakaran ng row-level-security, at ang aplikasyon ay kumokonekta sa ilalim ng isang nakatuong low-privilege na papel na nagpapatakbo ng NOBYPASSRLS at samakatuwid ay hindi makakakita sa mga tenant kahit na ang isang query ay aksidenteng nakalimot ng sarili nitong WHERE user_id na sugnay. Ang per-request na konteksto ng row-level-security ay nagtatakda ng identifier ng tenant at papel bilang mga parameter ng sesyon bago mag-execute ang anumang query, at ang connection pool ay nag-iisyu ng DISCARD ALL sa paglabas upang ang konteksto ay hindi makapagdala sa pagitan ng mga tenant. Labimpitong cross-tenant na senaryo sa aming verifier na rls-verify.ts ay lumalabas na zero laban sa live database sa bawat CI run, kabilang ang SELECT, INSERT, UPDATE, DELETE, ownership-reassignment, admin bypass, no-context zero-row, at mga kaso ng context-leak regression.

3. Pamamahala ng Susi at Lihim

Ang mga lihim ng application, mga susi sa paglagda, mga kredensyal ng database, at mga susi ng API ng third-party na ginagamit ng Melaya ay inimbak sa isang operator-controlled na file ng mga lihim na iniload sa pagsisimula ng proseso at sa aming vault provider. Hindi kailanman isinasakontrol ng pinagmulan at ang mga halaga ng produksyon ay hindi ibinabahagi sa pagitan ng mga developer. Ang envelope encryption key ay isang nakatuong encryption key na hawak lamang sa secrets store ng tagapagpatakbo, hiwalay mula sa mga kredensyal ng Postgres database at hiwalay mula sa Infisical vault token, kaya ang pagkakompromiso ng alinman sa tatlo ay hindi nagbubunga ng mga plaintext na kredensyal ng palitan. Lubos na hinihikayat ang mga customer na takdaan ng saklaw ang bawat susi ng API ng palitan sa mga pahintulot na pang-kalakalan lamang, upang huwag paganahin ang mga withdrawal sa nagbibigay na palitan, at upang mag-apply ng IP allowlisting kung saan sinusuportahan ito ng palitan.

Ang mga session token ay pinirmahan sa ilalim ng isang multi-key rotation window. Tinatanggap ng server ang isang naayos na hanay ng mga susi sa paglagda, ang bawat isa ay may maikli na key identifier. Ang mga bagong token ay pinirmahan sa ilalim ng unang (aktibong) susi at nagdadala ng identifier na iyon sa JWT header para sa O(1) na pag-verify. Ang mga token na inisyu sa ilalim ng anumang retired na susi sa window ay patuloy na mave-verify hanggang sa matapos ang kanilang pitong araw na TTL, kung saan maaari nang alisin ang retired na susi. Ang mga expired na token ay tinatanggihan agad kahit na ang isang hindi aktibong susi ay matatanggap ang mga ito. Ang mga round trip ng pag-verify ay ipinahayag sa aming verifier na jwt-keys-verify.ts.

4. Pagpapatunay at Kontrol ng Pag-access

Ang authentication ng gumagamit ay batay sa email at password na may bcrypt hashing sa work factor 12, kasama ang rate limiting sa mga login, register, at forgot password endpoint (20 pagtatangka bawat IP bawat 15 minuto, na ipinapatupad ng isang Redis-backed na distributed limiter). Ang mga session token ay inisyu bilang mga JSON Web Token na may pitong araw na expiry at nakatali sa mga claim ng gumagamit, papel, at antas. Ang role-based access control ay nagtatangi ng user mula sa admin, at ang tier-based access control ay nagtatakda ng mga tampok ayon sa apat na antas na katalogo. Ang bawat aksyon na may kahihinatnan ay sinusuri sa bahagi ng server. Ang mga gate sa bahagi ng kliyente ay purong pahiwatig ng UX at hindi kailanman inaasahan para sa seguridad.

Ang two-factor authentication ay makukuha ng lahat ng gumagamit sa pamamagitan ng karaniwang profile ng TOTP (RFC 6238, SHA-1, 6 digit, 30-segundong panahon, toleransya ng ±1 window drift) at katugma sa bawat pangunahing authenticator app. Ang mga TOTP shared secret ay nalilikha sa bahagi ng server na may 160 bits ng entropy, binabalot sa pamamagitan ng envelope encryption layer na inilarawan sa bahagi 1, at inimbak sa isang nakabalot na kolum sa hilera ng gumagamit. Ang mga recovery code ay nalilikha nang minsan sa enrollment, bcrypt-hash na may work factor 12, at pagkatapos ay binabalot ng ikalawang beses ng envelope layer upang ang pagkakompromiso ng database nang mag-isa ay hindi makapagpapanumbalik ng mga ito. Ang enrollment ay isang dalawang hakbang na proseso na nangangailangan sa gumagamit na patunayan na na-configure na nila ang kanilang authenticator sa pamamagitan ng pagpasok ng live na code bago ang pangalawang salik ay markahang aktibo. Ang daloy ng login ay nagiging isang pagsusuri ng password, pagkatapos ay isang maikling (limang minutong) challenge token, pagkatapos ay isang code verification na atomically kumukonsumo ng challenge row. Ang isang captured na challenge token ay hindi maaaring i-replay pagkatapos ng matagumpay na pagkonsumo. Ang MFA ay kinakailangan para sa pagdaragdag ng mga kredensyal ng API ng CEX at para sa paglikha ng mga susi ng API ng platform, ang dalawang aksyong may pinakamataas na epekto sa pakikipag-ugnayan sa pondong naroroon sa produkto. Ang bawat kinalabasan ng MFA challenge (mfa.challenge_issued, mfa.challenge_ok, mfa.challenge_fail) ay isinusulat sa append-only na audit log na inilarawan sa bahagi 6 upang ang mga pattern ng challenge ay maaring i-audit at hindi matatablan ng pagbabago.

Ang pag-access ng empleyado ng Melaya sa mga production system ay ibinibigay sa bawat inhinyero sa ilalim ng isang nakatuong dalawang-taong daloy ng pag-apruba at aalisin kapag hindi na kailangan. Ang provisioning ng access ay nangangailangan ng pag-apruba mula sa ibang tao kaysa sa humihiling, at ang offboarding ay nagde-deactivate ng account, nagro-rotate ng mga JWT signing key upang ma-invalidate ang mga natitirang session, nagbabawi ng mga susi ng API, at nag-aalis ng mga SSH key. Ang mga lipas na pribilehiyong sudoers entry at SSH authorized key ay nililinis sa bawat session, at isang quarterly na agwat ng pagsusuri ng access ay naidokumento. Ang isang buong pagkakaiba sa pagitan ng deploy user at ng service runtime user (upang ang isang nakompromisong proseso ng serbisyo ay hindi makapag-pivot sa landas ng deployment) ay sinusubaybayan bilang isang nakaplanong kontrol sa security roadmap.

5. Rate Limiting ng Network at Imprastraktura

Ang rate limiting ay ipinapatupad sa application layer ng isang Redis-backed na shared store upang ang mga limitasyon ay pandaigdigang pag-aari ng bawat instance ng server sa halip na bawat proseso. Dalawang independyenteng naka-configure na balde ang inilalapat: isang mahigpit na balde sa mga authentication endpoint (20 pagtatangka bawat IP bawat 15 minutong window) at isang pangkalahatang API balde (200 kahilingan bawat IP bawat minuto). Ang limiter ay fail-closed: kung hindi maabot ang Redis store, tinatanggihan ng mga auth endpoint kaysa pumayag na dumaan. Ang tRPC batch-aware wrapper ng limiter ay na-verify ng aming verifier na rate-limit-verify.ts (7/7 na sitwasyon, kabilang ang batch-laundering na pag-atake).

Ang edge traffic ay inuuna ng Cloudflare na may WAF, pagtuklas ng bot, at geo-blocking sa mga landas na may mataas na panganib. Ang isang Terraform scaffold para sa Cloudflare zone ay nakatuon kasabay ng isang operational runbook na sumasaklaw sa drift detection, emergency override, at ang 24-oras na tuntunin ng pagkakasundo. Ang import at pagkakasundo ng kasalukuyang-mano-manong zone laban sa nasabing scaffold ay kasalukuyang isinasagawa at ito ang gating task bago maiskedyul ang unang external penetration test.

6. Pagmamatyag, Pag-log, at Audit

Ang platform ay naglalabas ng mga nakastrukturang log mula sa Node.js tRPC server, ang Rust Engine, ang Python worker, at ang edge. Ang lahat ng log sa antas ng host at container (ang systemd journal, mga log ng sistema ng host, mga log ng access at error ng nginx, CI at source-forge container stdout, at bawat log ng aplikasyon ng Melaya) ay ipinapadala off-box nang real time sa isang Grafana Cloud Loki tenant sa parehong rehiyon ng production host sa pamamagitan ng isang Grafana Alloy collector, kaya ang audit trail ay nakaligtas sa kompromiso ng host o pagkawala ng disk. Ang mga papalabas na koneksyon sa network ay naitala ng isang network-layer egress logging rule at ipinadala sa parehong off-box na sink; ang trapikong egress na ito ay naka-log at sinusunod ngayon, habang ang enforced deny-based egress allowlisting ay nananatiling isang nakabinbing aytem sa roadmap.

Ang mga kaganapan na may kaugnayan sa seguridad (mga kinalabasan ng authentication, mga resulta ng MFA challenge, mga pagdaragdag at pag-aalis ng CEX credential, pag-isyu at pagbawi ng mga susi ng API ng platform, mga pagbabago at rollback ng antas) ay karagdagang isinusulat sa isang append-only na talahanayan ng agents.audit_log. Ang schema ay nagbabawi ng UPDATE at DELETE mula sa papel ng application, nagpapanatili ng cryptographic hash chain sa mga hilera (prev_hash / row_hash), nag-iimbak ng IP ng aktor bilang HMAC-SHA256 digest lamang sa ilalim ng isang keyed secret (hindi plain SHA-256, na susceptible sa dictionary attack), at nagbibigay ng side-table na agents.audit_log_tombstone para sa GDPR Article 17 erasure na hindi kailanman nagbabago ng chain. Ang isang araw-araw na verifier (verify-audit-chain.ts) ay naglalakad sa chain mula dulo hanggang dulo, nagpapatunay ng timestamp monotonicity na may ±2 segundong toleransya ng NTP, at naglalabas ng anchor digest na angkop para sa external na write-once storage. Anim na sitwasyon ng pagsisira ng datos sa audit-log-verify.ts ay lumalabas ng zero laban sa live na produksyon.

7. Pamamahala ng Kahinaan

Ang 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: minsan sa gated mode na may ignore-unfixed: true upang ang mga aksyonableng natuklasan ay magpalya ng tseke, at minsan na may ignore-unfixed: false at hindi gating upang ang kumpletong vulnerability surface ay ma-upload sa Security tab ng repository bilang patunay ng pagsunod. Ang production host ay nagpapatakbo ng unattended-upgrades na may security channel na pinagana at isang awtomatikong window ng pag-restart. Ang mga third-party na larawan ng container para sa mga serbisyo ng CI, source-forge, secrets-vault, Postgres, at Redis ay kinokontrol ng review bago ang mga pagbabago ng bersyon, sinusubaybayan sa Patching Cadence runbook sa panloob na security vault, at binibigyan ng alert ng isang araw-araw na image-digest drift detector sa loob ng 24 oras ng anumang tahimik na pag-rotate ng larawan.

Ang Melaya ay hindi pa sumasailalim sa isang third-party na external penetration test. Ang saklaw ng pakikipag-ugnayan (kabilang ang mga in-scope at out-of-scope na asset, mga tuntunin ng pakikipag-ugnayan, maikling listahan ng vendor na nangangailangan ng CREST accreditation, at ang post-engagement remediation cadence) ay nakatuon sa panloob na runbook na Pentest Scope upang ang pagpili ng vendor ay makakasulong sa sandaling maibaba ang Cloudflare IaC reconcile mula sa bahagi 5. Walang pahayag na "taunang pentest" ang ginagawa kahit saan sa dokumentasyon ng Melaya.

8. Ligtas na Pagbuo ng Software

Ang mga pagbabago sa platform ay dumadaan sa source control na may peer review bago ang pagsasama. 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 listahan ng pinahihintulutan sa halip na isang pandaigdigan, upang ang aksidenteng pagsisiwalat ng mga kredensyal ay magpalya ng build bago ang pagsasama. Lahat ng aksyon ng CI ay pinned sa pamamagitan ng commit SHA upang maiwasan ang mga pag-atake ng supply-chain tag rewriting. Ang mga deployment sa produksyon ay dumadaan sa isang restricted na Jenkins SSH wrapper na may command= na paghihigpit sa authorized_keys upang kahit ang isang nakompromisong CI runner ay makakapagtawag lamang ng mga tahasang operasyon na resync <service> at log <service> para sa mga allowlisted na serbisyo ng Melaya: walang arbitrary na shell, walang filesystem traversal, walang privilege escalation na higit pa sa service restart mismo. Ang bawat invocation ng deploy pipeline ay naka-log nang off-box sa Grafana Cloud Loki tenant para sa audit, kasabay ng isang nakatuong provenance record na nag-uugnay ng tumatakbong binary sa source commit nito.

9. Pagtugon sa Insidente

Ang Melaya ay nagpapanatili ng isang nakasulat na Incident Response runbook na sumasaklaw sa deklarasyon ng kalubhaan (apat na antas ng kalubhaan), mga takdang papel (Incident Commander, teknikal na lider, komunikasyon, kalihim), isang checklist ng containment na kinabibilangan ng mga tahasang hakbang ng rotation ng envelope key, JWT key, at audit-log IP-HMAC key, ang 72-oras na notification matrix ng GDPR Article 33, at isang template ng post-mortem. Ang runbook ay nakatuon sa panloob na security vault at tinatrato bilang isang live na dokumento. Ang unang tabletop drill ay nakatakda para sa 2026-07-15, at ang runbook ay tahasang minarkahan bilang "hindi aktibo" sa sarili nitong mga pamamaraan hanggang sa maisagawa ang nasabing drill. Ang mga inhinyero na naka-oncall ay sumasagot sa mga tunay na insidente ngayon. Ang drill gate ay tungkol sa pormal na tabletop exercise, hindi sa pagkakaroon ng landas ng pagtugon.

10. Backup at Pagbawi mula sa Sakuna

Ang mga target na Recovery Time Objective (RTO) at Recovery Point Objective (RPO) bawat subsystem ay inilalathala sa panloob na runbook na RTO RPO: ang antas ng agents.* ay nagtatarget ng 15-minutong RTO at 2-oras na RPO, ang imbakan ng kredensyal ng CEX ay nagtatarget ng 5-minutong RTO at 1-oras na RPO, ang Infisical at object storage ay nagtatarget ng 4-oras na RTO at 1-oras na RPO, at ang Redis ay walang backup at muling itinatayo sa muling koneksyon. Ang mga mekanismo ng backup ay pinagsasama ang tuluy-tuloy na WAL archiving na may 14-araw na point-in-time-recovery window, isang gabi-gabing lohikal na dump na pinanatili sa ibang rehiyon, isang buwanang base backup, at isang araw-araw na write-once audit-log anchor export sa isang panlabas na lokasyon. Lahat ng backup artifact ay naka-compress, may checksum, at naka-encrypt gamit ang restic. Ang pag-verify ng pagpapanumbalik ay tumatakbo sa dalawang agwat: isang awtomatikong lingguhang trabaho ay nagsasagawa ng restic integrity check at isang spot-restore sa isang scratch directory, at ang unang buong restore drill sa isang throwaway environment ay nakatakda para sa 2026-07-15, pagkatapos nito ang nakasulat na pagpapatunay ng restore wall-clock at integrity check ay itatago sa parehong runbook. Ang Melaya ay nagpapatakbo mula sa isang pangunahing hosting rehiyon ngayon. Ito ay tahasang inihahayag, at ang mga compensating control (cross-region na gabi-gabing dump, tuluy-tuloy na WAL archiving, isang cross-region na health probe, at Cloudflare DNS failover) ay nagtatakda ng pinakamalaing worst-case full-region-loss RTO na humigit-kumulang 24 oras bilang isang naidokumento at tinatanggap na panganib.

11. Pagpapatuloy ng Negosyo

Ang isang nakasulat na Business Continuity Plan ay nakatuon sa panloob na security vault na sumasaklaw sa pagtugon sa pagkawala ng pangunahing rehiyon, kabiguan ng Postgres provider, pagkawala ng Infisical vault (ang server ay patuloy na nagsisilbi sa mga kasalukuyang session sa pamamagitan ng mga cached na kredensyal, ang mga bagong pagsusulat ng CEX ay tumatangging sumama na may error na nakikita ng gumagamit), pagkawala ng Stripe (ang mga kasalukuyang subscription ay hindi naaapektuhan), matrix ng availability ng tauhan, at isang contingency table bawat supplier. Ang plano ay sinusuri sa parehong quarterly na agwat ng TLS baseline, na may taunang buong walk-through bilang bahagi ng tabletop exercise.

12. Seguridad ng Vendor at Subprocesor

Gumagamit ang Melaya ng mga subprocessor at infrastructure tagapagbigay para sa mga tungkuling inilalarawan sa pampublikong listahan ng mga Subprocessor. Dapat suriin ang kontraktuwal na papel, lokasyon, at pananggalang sa paglilipat ng bawat tagapagbigay batay sa aktuwal na deployment at kasunduan; ang modelo, connector, merchant, o tagapagbigay ng kasangkapan na pinili ng kliyente ay maaaring kumilos ayon sa mga tagubilin ng kliyente at sarili nitong mga tuntunin sa halip na sa mga kontrata ng tagapagtustos ng Melaya. Tumatanggap ang mga kliyenteng enterprise ng naaangkop na abiso at karapatang tumutol sa subprocessor sa ilalim ng kanilang kasunduan o data processing addendum. Ang pangunahing hosted environment ng Melaya ay kasalukuyang pinatatakbo sa Singapore, na hindi sakop ng isang EU adequacy decision, kaya nangangailangan ang mga naaangkop na paglilipat ng legal na mekanismo sa paglilipat at mga karagdagang pananggalang kung kailangan. Isinasagawa ng lokal na runner ang Python, mga lokal na file, retrieval operation, at mga piniling kredensiyal sa hardware na kontrolado ng kliyente, ngunit maaari pa ring dumaan o makarating sa Melaya at mga ikatlong partido ang run configuration, nilalaman ng signed dispatch, paghahatid ng piniling kredensiyal, collaboration event, telemetry, cloud-kahilingan sa modelo, o connector call ayon sa napiling mode. Ang pampublikong pahina ng mga Subprocessor, kasunduan ng kliyente, at aktuwal na daloy ng datos - hindi ang salitang “local” lamang - ang tumutukoy sa mga pagsisiwalat tungkol sa tatanggap at residency.

13. Postura ng Pagsunod

Ang Melaya ay nagtatayo ng mga kontrol nito na isinaalang-alang ang SOC 2 Trust Services Criteria at ISO/IEC 27001. Sa petsa ng dokumentong ito, ang Melaya ay WALA pang hawak na SOC 2 Type I, SOC 2 Type II, ISO/IEC 27001, o anumang katumbas na third-party na security attestation, at walang pagsusuri o pagtatasa ng katawan ng sertipikasyon na naganap. Ang mga ito ay mga aspirasyonal na milestone sa aming roadmap. Ang anumang potensyal na customer na nangangailangan ng attestation ngayon ay dapat umasa ng isang gap analysis deliverable sa halip na isang kumpletong ulat. Ang mga customer ng enterprise ay maaaring humiling ng aming kasalukuyang control matrix at listahan ng mga remedyasyon na kasalukuyang isinasagawa 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 Labs LLC 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. Ang Melaya ay nangako na kilalanin ang mga wastong ulat sa loob ng limang (5) araw ng trabaho mula sa pagtanggap, magbigay ng paunang pagtatasa ng kalubhaan sa loob ng sampung (10) araw ng trabaho mula sa pagkilala, at remedyahin ang mga natuklasan ayon sa hagdan ng kalubhaan: Kritikal sa loob ng 48 oras, Mataas sa loob ng 7 araw ng kalendaryo, Katamtaman sa loob ng 30 araw ng kalendaryo, Mababa sa loob ng 90 araw ng kalendaryo. Kung ang Melaya ay mapalampas ng isang pangako ng SLA, ang mananaliksik ay maaaring magbigay ng pitong (7) araw na nakasulat na abiso ng intensyon na mag-publish at ang proteksyon ng safe-harbor ay nananatiling may bisa sa buong panahon ng publikasyon basta't ang mananaliksik ay sumunod sa mga tuntunin ng pakikipag-ugnayan sa buong proseso.

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.

Modelo ng seguridad ng Device Control

Idinisenyo ang Device Control bilang channel na awtorisado ng gumagamit at deny-by-default. Hindi kayang i-enable ng Android aplikasyon ang Accessibility o screen capture nang kusa; dapat ibigay ng gumagamit ang mga pahintulot na iyon sa operating system. Maaaring mangailangan ang Android ng restricted-settings pag-apruba para sa sideloaded build.

Nagpapatunay ang mga nakapares na telepono gamit ang nababawi na device token na ang SHA-256 hash ang iniimbak sa server. Kasalukuyang nakaimbak ang raw Android token sa pribadong SharedPreferences ng aplikasyon sa halip na hardware-backed encrypted storage; iniimbak naman ng iOS aplikasyon ang token nito sa Keychain. Hiwalay ang phone token sa browser session at runner token, limitado sa phone endpoint, nag-e-expire o maaaring bawiin, at dapat protektahan ng seguridad ng device ng gumagamit.

Sinusuri sa server at Android device ang pagbasa ng accessibility screen tree at ang mga pag-tap, pag-type, pag-swipe, at katulad na operasyong limitado sa foreground, batay sa listahan ng mga aplikasyon na pinahintulutan ng gumagamit. Iba ang hangganan ng global navigation action, at ang full-display MediaProjection frame ay hindi teknikal na kina-crop o nililimitahan sa pinahintulutang aplikasyong nasa foreground; kaya maaaring lumitaw sa isang frame ang hindi pinahintulutan o sensitibong aplikasyon na nakikita habang nagmi-mirror.

Ang mga live screen frame ay downscaled na full-display image na ipinapasa bilang latest-frame data para sa napatunayang session ng may-ari at sa screenshot kasangkapan. Panandaliang pinananatili ang mga ito sa memorya ng server process para sa pagiging napapanahon at paghahatid, ngunit maaaring manatili o makarating sa piniling modelong cloud o connector ang ilang screenshot, resulta ng kasangkapan, kahilingan sa modelo, telemetry, o log. Dapat ihinto ng mga gumagamit ang pagmi-mirror bago magbukas ng walang-kaugnayang sensitibong nilalaman.

Ang phone pila ng mga utos at patakaran sa pinahihintulutang aplikasyon ay kasalukuyang nakasaklaw ayon sa account ng gumagamit, hindi sa piniling device. Kung maraming telepono ang nakapares, maaaring kunin ng unang karapat-dapat na teleponong nagpo-poll ang nakapilang utos; pagkatapos nitong kunin, iuugnay ang resulta sa job at phone token na iyon. Nagrerehistro rin ang native mobile run ng isang aktibong run upang makahiling ang overlay emergency stop control ng parehong gumagamit na wakasan ang nakarehistrong run; hindi nito maaaring wakasan ang pipeline ng kahit sinong ibang gumagamit.

Mga kontrol sa Mobile Agent at pagpapatakbo sa device

Pinaghihiwalay ng seguridad ng Mobile Agent ang pagpapasya, authorization, routing, at pisikal na pagpapatakbo. Maaaring magmungkahi ng utos ang isang modelo o agent; pinatutunayan ng mga serbisyo ng Melaya ang authenticated gumagamit, katayuan ng nakapares na telepono, patakaran sa operasyon, at sobre ng utos; maaaring kunin ng unang karapat-dapat na teleponong nagpo-poll ang gumagamit-scoped queued job; at pagkatapos ay isinasagawa ng nakarehistrong device na kontrolado ng gumagamit ang utos sa ilalim ng mga pahintulot ng operating system.

Hiwalay ang device credential sa browser session, cloud-serbisyo identity, kredensiyal ng tagapagbigay, at lokal-runner token. Iniimbak ng server ang SHA-256 hash ng nababawi na phone token. Kasalukuyang iniimbak ng Android ang raw token sa pribadong SharedPreferences, habang iniimbak naman ito ng iOS sa Keychain. Hindi nagbibigay-awtoridad ang phone token para sa pangkalahatang pangangasiwa ng account, phone endpoint ng ibang gumagamit, o walang-kaugnayang runner.

Deny-by-default ang mga utos at nakasaklaw sa authenticated gumagamit, nakuhang job, patakaran sa aplikasyon, uri ng operasyon, parameter, at tagal ng queue. Sa kasalukuyan, gumagamit-scoped ang queue at allowlist at hindi deterministikong nakaturo sa piniling device kapag maraming telepono ang nakapares; pagkatapos kunin ng isang telepono ang job, ibinibigkis ng ownership check ang resulta nito. Pinatutunayan ng sensitibong endpoint ang caller, sinusuri ang laki at pagmamay-ari, at tinatanggihan ang expired na job, ngunit dapat ipares ng mga kliyente ang mga pinagkakatiwalaang device lamang.

Dapat mangailangan ang high-impact o hindi malinaw na operasyon ng bagong kumpirmasyon ng tao, malinaw na impormasyon tungkol sa target at bunga, at available na pause o emergency stop path. Nagbibigay ng defense in depth ang persistent indicator, overlay, foreground-serbisyo notification, paunang pagtingin, timeout, rate limit, audit trail, at terminal-state cleanup ngunit hindi ginagarantiyahang tama o maibabalik ang isang operasyon.

Gumagamit ang utos at telemetry channel ng encrypted transport at authenticated identity. Kung naipatupad, ginagamit ang signed o integrity-protected dispatch, nonce, identifier ng utos, expiry, device binding, at replay detection upang bawasan ang pakikialam at cross-gumagamit pagpapatakbo. Hindi pinipigilan ng transport encryption ang awtorisadong endpoint na makita ang plaintext na kailangan upang isagawa ang kahilingan.

Pinananatili ng lokal runner ang Python pagpapatakbo, lokal na file, at lokal-modelo inference sa loob ng kapaligiran ng gumagamit, nang napapailalim sa kontrol ng operating system ng gumagamit. Inilalantad din ng hybrid run ang inference o kasangkapan payload sa piniling cloud tagapagbigay. Isinasagawa ang cloud run sa infrastructure na pinamamahalaan ng Melaya at maaari nitong iproseso ang runtime data at piniling secret. Binabawasan ngunit hindi inaalis ng sandboxing at isolation ang panganib sa aplikasyon, dependency, modelo, prompt injection, o infrastructure.

Gumagamit ng encryption o secret-management control ang mga nakaimbak na kredensiyal at inihahatid lamang kapag pinili para sa isang run. Kinakailangang tumanggap ang pagpapatakbo process at external tagapagbigay ng magagamit na authentication material. Dapat ipatupad ng mga gumagamit ang least privilege, paghiwalayin ang production at testing credential, agad na mag-rotate at magbawi, limitahan ang saklaw ng tagapagbigay, at huwag kailanman maglagay ng secret sa prompt, screenshot, log, o hindi pinagkakatiwalaang output ng kasangkapan.

Maaaring tumanggap ang telemetry at collaboration serbisyo ng anumang mensahe, trace, kasangkapan event, resulta, gastos, katayuan, kahilingan sa pag-apruba, screenshot, o diagnostic payload na inilalabas ng runtime. Dapat angkop na i-configure ng mga kliyente ang detalye at retention ng event, iwasan ang hindi kailangang sensitibong datos, at magpatupad ng workspace at project access control. Inilalarawan ng “lokal” ang lokasyon ng pagpapatakbo, hindi isang garantiya na walang ipinapadalang telemetry.

Ang Android Accessibility at MediaProjection ay sensitibong kakayahang ibinibigay ng gumagamit. Bago mag-access, dapat magbigay ang mobile na aplikasyon ng kinakailangang kapansin-pansing pagsisiwalat at kumuha ng positibong pahintulot, gumamit ng pinakamakitid na available na API, manatiling nakikita kung kinakailangan, mag-degrade kapag tinanggihan ang pahintulot, at huwag kailanman gumamit ng pahintulot upang lampasan ang seguridad ng platform o itago ang aktibidad. Hindi dapat pahintulutan ng build na ipinamamahagi sa Google Play ang Accessibility na autonomously na simulan, planuhin, at isagawa ang mga operasyong salungat sa patakaran ng Google Play.

Nililimitahan ng sandbox, entitlement, at public API ng Apple ang iOS aplikasyong App Store at hindi ito nag-aalok ng walang-pigil na kontrol sa aplikasyon ng ikatlong partido. Ang Mac runner, Developer Mode, XCTest, WebDriverAgent, paired-device, at developer-signed testing path ay may naiibang threat at trust modelo at nangangailangan ng kontrol sa Mac, signing identity, device pairing, test target, at network channel.

Walang kontrol na nakapag-aalis ng lahat ng panganib. Maaaring manipulahin ang modelo sa pamamagitan ng prompt o nilalaman ng screen; maaaring baguhin ng aplikasyon ang layout; maaaring maging labis ang pahintulot; maaaring makompromiso ang dependency; maaaring mawala ang device; at maaaring abusuhin ng awtorisadong gumagamit ang kakayahan. Sinisiyasat namin ang kapani-paniwalang ulat, maaari naming bawiin o ihiwalay ang apektadong kredensiyal o device, at hinihikayat ang agarang paggamit ng emergency stop, pagbawi, pag-rotate, at mga pamamaraan sa pag-uulat ng insidente.

16. Mga Pagbabago sa Overview na Ito

Ang Melaya ay maaaring mag-update ng Security Overview na ito paminsan-minsan upang ipakita ang mga pagbabago sa platform, sa aming mga kontrol, o sa aming mga subprocessor. Ang petsang "Huling na-update" sa itaas ng dokumentong ito ay nagpapakita ng pinakabagong rebisyon. Kapag nakumpleto ang mga operasyonal na nakabinbing aytem (tulad ng unang restore drill, ang unang IR tabletop drill, ang unang external pentest, ang volume-level na disk encryption, o ang pagsusuri ng panlabas na tagapayo sa DPA template), ang kaukulang seksyon ay muling sinusulat upang ipakita ang bagong kalagayan at ang pagbabago ay inihahayag sa product changelog.

17. Pakikipag-ugnayan

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