Motivasi
- Mengapa “Sec” harus disematkan ke semua X-Ops:
- DevOps → DevSecOps
- DataOps → secure data lifecycle
- MLOps → secure & trustworthy ML (serangan, privasi, governance)
- Shift Security Left — mengintegrasikan security sejak awal dan secara berkelanjutan, bukan sebagai gerbang di akhir.
Security dalam DevOps
Threats & Vulnerabilities di Pipeline DevOps
- CI/CD compromise: kode berbahaya di repository, supply-chain attack (misal dependency yang di-poison), build agent/runner yang tidak aman.
- Container & orchestration risks: container image tidak aman, privilege berlebihan, tanpa isolasi.
- Configuration/IaC risks: cloud resource yang salah konfigurasi, secret yang di-hardcode di IaC.
- Operational risks: access control yang buruk di sekitar deployment tools, stack monitoring/observability yang terlalu permisif (misal Prometheus, Grafana), tidak ada audit trail siapa men-deploy apa dan kapan.
- Configuration Management Risks: configuration drift (perubahan manual yang tidak terlacak), secret yang tidak terenkripsi di file konfigurasi, tidak ada pemisahan kredensial dev/staging/production.
Security by Design dalam Praktik DevOps
Dipetakan ke siklus DevOps infinity loop:
- Plan: threat modeling.
- Build: SAST, dependency scanning.
- Test: DAST, security testing.
- Deploy: container scanning, secrets management.
- Operate: runtime security, monitoring.
- Monitor (Observe, Feedback, Discover): security alert, incident response.
Prinsip pendukung:
- Continuous Security — security bukan gerbang satu kali (one-time gate), melainkan proses berkelanjutan; memantau dan merespons ancaman secara real-time.
- Shared Responsibility — security adalah tanggung jawab semua orang, bukan hanya tim security; developer, operations, dan tim security berkolaborasi.
Shift-Left Security Practices
Mengintegrasikan security sejak awal dalam CI/CD:
- At Commit Stage:
- SAST (Static Application Security Testing) — scan source code untuk vulnerability.
- Dependency Scanning — cek known vulnerability di library pihak ketiga (contoh: OWASP Dependency-Check, Snyk).
- Secret Scanning — mendeteksi secret yang di-hardcode (password, API key) dalam kode (contoh: git-secrets, TruffleHog).
- Code Review with Security Checklist — peer review yang fokus pada best practice security.
- At Build Stage:
- Container Image Scanning — scan Docker image untuk vulnerability (contoh: Trivy, Clair, Anchore).
- Signed Commits & Artifacts — memastikan kode dan artifact ditandatangani (signed) dan terverifikasi.
- At Test Stage:
- DAST (Dynamic Application Security Testing) — menguji aplikasi yang sedang berjalan untuk vulnerability.
- Infrastructure Security Testing — memvalidasi konfigurasi IaC (contoh: Checkov, tfsec).
CI/CD Pipeline Hardening
- Least Privilege for CI/CD: runner CI/CD punya permission minimal; gunakan service account dengan scoped access (bukan admin); kredensial dev/staging/production dipisahkan.
- Secrets Management: jangan pernah menyimpan secret di Git atau Dockerfile; gunakan tools khusus (HashiCorp Vault, AWS Secrets Manager, Kubernetes Secrets dengan enkripsi at rest); suntikkan (inject) secret saat runtime, bukan saat build time.
- Artifact Integrity: tandatangani container image dan binary; gunakan artifact registry dengan access control; verifikasi signature sebelum deployment.
- Security as Code: otomasi security testing dan compliance check; kebijakan security disimpan dalam version control bersama kode aplikasi.
- Audit Trails: log semua aktivitas CI/CD (siapa memicu, apa yang berubah); audit log bersifat immutable untuk keperluan compliance.
Container Security Best Practices
- Base Image Security: gunakan base image minimal (Alpine, distroless); perbarui base image secara rutin; scan image sebelum deployment.
- Runtime Security: jalankan container sebagai non-root user; gunakan read-only file system jika memungkinkan; batasi capability container (drop Linux capability yang tidak perlu).
- Network Security: terapkan network policy (Kubernetes NetworkPolicy); segmentasikan jaringan container (isolasi workload sensitif); gunakan service mesh untuk komunikasi terenkripsi (Istio, Linkerd).
- Runtime Monitoring: deteksi perilaku anomali (Falco, Sysdig); memantau syscall dan file access; alert pada aktivitas mencurigakan.
Securing Infrastructure as Code
- Policy as Code: mendefinisikan kebijakan security dalam kode (contoh: Open Policy Agent); memvalidasi IaC sebelum deployment (Checkov, tfsec, Terraform Sentinel).
- Common IaC Vulnerabilities: IAM role yang terlalu permisif, storage tidak terenkripsi (S3, EBS), akses publik ke resource, secret yang di-hardcode.
- Drift Detection: memantau perubahan manual (configuration drift); merekonsiliasi drift secara otomatis atau memberi alert.
- Best Practices: version control seluruh IaC, peer review perubahan IaC, automated testing IaC (unit test, integration test), gunakan module dan template untuk konsistensi.
DevSecOps Bertemu SRE
Pertanyaan pemicu: “Canary deployment + feature flags dipakai untuk merilis auth flow baru; security check dan telemetry apa yang harus ada sebelum ke 100% traffic?”
- Insiden security sebagai reliability event: downtime akibat security tetap dihitung terhadap error budget (lihat 6_Site_Reliability_Engineering).
- SLO untuk security: contoh — “99.9% operasi privileged diaudit dan dapat dilacak”.
- Change management: secure release engineering (hermetic build, audit trail, model configuration management — lihat 7_SRE_Practices).
- Blameless postmortem untuk insiden security, tidak hanya untuk outage.
Monitoring & Observability untuk Security
- Memperluas observability stack (log, metrik, trace) tidak hanya untuk performa, tapi juga security.
- Metrik security yang dipantau: failed authentication rate, API abuse (pelanggaran rate limiting), lonjakan error yang tidak biasa (potensi serangan), percobaan privilege escalation, traffic jaringan yang anomali.
- Integrasi dengan praktik SRE: mendefinisikan Security SLI/SLO (contoh: “99.9% operasi privileged diaudit dan dapat dilacak”, “failed auth rate < 0.1% dari total request”); insiden security dihitung terhadap error budget; menggunakan canary deployment untuk mendeteksi masalah security lebih awal.
Secure Release Engineering
- Hermetic Builds: build yang reproducible dan terisolasi — source + tools yang sama menghasilkan binary yang sama; mencegah tampering dan menjamin auditability.
- Signed Artifacts: semua binary dan container image ditandatangani; signature diverifikasi sebelum deployment.
- Audit Trails: melacak setiap perubahan dari commit hingga production; tahu persis apa yang berjalan di mana.
- Configuration Management: memisahkan config dari kode; config di-version-control; config sensitif dienkripsi.
- Progressive Rollouts: canary deployment (1-5% traffic awal); memantau isu security selama rollout; automated rollback saat ada security alert.
Canary Deployment untuk Security
- Deploy versi baru ke 1-5% server/user; memantau metrik security (autentikasi gagal, error otorisasi, pola penggunaan API yang tidak biasa, lonjakan error rate); membandingkan canary dengan baseline; jika terdeteksi masalah security → automated rollback.
- Trigger rollback otomatis: failed auth rate melewati threshold, terdeteksi percobaan privilege escalation, pola traffic anomali, SLO burn rate melewati limit.
- Feature Flags untuk Security: men-deploy kode tanpa mengaktifkan fitur; menguji kontrol security di produksi dengan exposure terbatas; rollback instan tanpa perlu redeploy.
Security Governance dalam DevOps
- Access Control (RBAC): role-based access control untuk semua sistem; prinsip least privilege; role terpisah untuk dev/ops/security.
- Compliance Automation: otomasi pengecekan compliance (CIS benchmark, PCI-DSS); continuous compliance monitoring; log dan report yang audit-ready.
- Incident Response: rencana incident response yang terdokumentasi; blameless postmortem; continuous improvement.
- Security Training: pelatihan security rutin untuk semua anggota tim; security champion di setiap tim.
Security dalam DataOps
Threats & Vulnerabilities dalam Data Lifecycle
Merujuk pada 8_DataOps_Data_and_Lifecycle (Plan → Design & Enable → Create/Obtain → Store/Maintain → Use → Enhance → kembali ke Plan, dengan cabang Dispose):
- Create/Obtain: sumber data yang tidak divalidasi/tidak dipercaya, schema drift yang menyembunyikan serangan injeksi, tidak ada autentikasi/otorisasi untuk sumber data.
- Store/Maintain: data lake/warehouse yang tidak terenkripsi, akses luas ke PII (Personally Identifiable Information) mentah, tidak ada klasifikasi atau tagging data.
- Use/Enhance: job ETL/ELT yang tidak aman, data exfiltration lewat log atau notebook, tidak ada audit trail untuk transformasi data.
- Use: dashboard yang mengekspos data lebih dari yang dibutuhkan, tidak ada row-level/column-level security, tidak ada data masking di environment non-produksi.
- Dispose: ketidakmampuan menegakkan kebijakan retensi data.
- Governance and Compliance: tidak ada data lineage (tidak bisa menjawab “siapa yang menyentuh data apa?”), kurangnya metadata management.
Threats di Sepanjang Arsitektur Data Modern
Alur: Data Source (databases, API, files) → Ingestion (batch/streaming) → Storage (zona raw, curated, refined) → Processing (pipeline ETL/ELT) → Analytics/ML (Feature Store, Model Repo, ML Env) → Consumption (BI Server, Reporting Server).
Security Consideration di Data Environment
- Network segmentation: mengisolasi zona data.
- Encryption: at rest dan in transit.
- Access control: kontrol ketat untuk setiap layer.
- Audit logging: melacak semua akses data.
| Layer | Kontrol Utama |
|---|---|
| Data Source | Authentication |
| Ingestion | Validation, Encryption |
| Storage | Encryption, Access Control |
| Processing | Audit logging, Isolation |
| Consumption | Masking, Access Control |
Access Control
- Prinsip least privilege dan segregation of duty.
- Role terpisah: Data engineers (membangun pipeline), Data analysts (membaca curated data), Data scientists (mengakses feature store), Operations (memonitor, tanpa akses data), dst.
Data Classification
- Klasifikasikan dataset: Public / Internal / Sensitive / Regulated.
- Terapkan data masking/tokenization di environment non-produksi.
- Gunakan synthetic data untuk testing jika memungkinkan.
Encryption
- At rest: enkripsi semua data store (database, data lake, warehouse).
- In transit: gunakan TLS untuk semua transfer data.
- Key management: gunakan layanan key management khusus (KMS).
Security dalam DataOps CI/CD
- DataOps CI/CD: version control untuk kode pipeline (Git); automated testing (unit test, integration test, data quality test); CI/CD untuk pipeline data (build, test, deploy).
- Pipeline Code Security: SAST untuk kode pipeline (Python, SQL, dll); dependency scanning untuk library pemrosesan data; secret scanning (tidak ada kredensial hardcode).
- Data Quality as Security: schema validation (mencegah serangan injeksi); data quality test (mendeteksi anomali, outlier); range check (contoh: umur harus 0-120).
- Pre-Deployment Checks: security test (tidak ada kebocoran PII di log); compliance check (kebijakan retensi data ditegakkan); validasi access control.
Metadata, Lineage, dan Auditing untuk Security
- Data Lineage: melacak data dari sumber hingga konsumsi; menjawab “pipeline mana yang mengonsumsi PII?”, “model ML mana yang dilatih dengan data regulated?”; impact analysis — “jika sumber data ini dibobol, apa yang terdampak?“.
- Metadata Management: menangkap metadata (owner, klasifikasi, sensitivitas, kebijakan retensi); menegakkan kebijakan berdasarkan metadata; audit trail — siapa mengakses data apa, kapan.
DataOps untuk Compliance
Bagaimana DataOps membantu memenuhi kebutuhan compliance yang terus berkembang:
- Reproducibility: dataset dan pipeline yang versioned; bisa membuktikan data apa dipakai kapan; bisa menjalankan ulang atau menghapus (purge) derived data.
- Right to Be Forgotten: pipeline otomatis dapat mempropagasi penghapusan; lineage menunjukkan semua derived data yang perlu dihapus.
- Purpose Limitation: metadata melacak tujuan penggunaan data yang dimaksud; kebijakan menegakkan batasan penggunaan.
- Audit Trails: log immutable dari semua akses dan transformasi data; laporan yang siap untuk compliance.
Secure MLOps
Threats & Vulnerabilities dalam MLOps
Merujuk pada siklus MLOps di 15_MLOps_ML_Lifecycle:
- Data Collection: data yang di-poison/mislabeled, access control lemah pada dataset berlabel, tidak ada validasi sumber data.
- Data Preparation: data leakage (data test masuk ke training set), tidak ada audit trail untuk transformasi data.
- Feature Engineering: re-implementasi logika feature yang berulang (menyebabkan inkonsistensi dan vulnerability), tidak ada access control pada feature store.
- Modeling: script dan environment yang tidak terkontrol, dependency yang tidak dilacak (supply chain risk), tidak ada reproducibility (tidak bisa mengaudit apa yang dilatih).
- Model Evaluation: tidak ada validasi security/fairness, model di-deploy tanpa approval.
- Deployment & Serving: prediction API yang terekspos tanpa autentikasi, tidak ada rate limiting (memungkinkan serangan ekstraksi), tidak ada logging (tidak bisa mendeteksi abuse).
- Monitoring & Feedback: feedback loop yang di-poison (interaksi user adversarial), tidak ada deteksi drift (model terdegradasi secara diam-diam).
Advanced Risks dalam ML Modeling
- Adversarial Attacks:
- Evasion Attacks — memanipulasi input untuk menipu model saat inference time (contoh: menambahkan noise ke gambar agar salah klasifikasi).
- Poisoning Attacks — mengkorupsi data training untuk menurunkan performa model (contoh: menyuntikkan data mislabeled ke training set).
- Model Extraction/Stealing — melakukan query ke model API untuk melakukan reverse-engineer model tersebut (contoh: query berulang untuk membangun salinan model).
- Data Privacy:
- Training pada data sensitif (PII, catatan kesehatan).
- Membership Inference — menentukan apakah record tertentu ada dalam data training.
- Model Inversion — merekonstruksi data training dari output model.
- Data & Model Drift: data drift yang memengaruhi keputusan safety-critical; concept drift yang membuat model tidak andal.
Adversarial Attacks Deep Dive
| Jenis Serangan | Waktu | Cara Kerja | Contoh | Pertahanan |
|---|---|---|---|---|
| Evasion Attacks | Inference time | Attacker memanipulasi input untuk menipu model | Mobil self-driving salah membaca rambu stop | Input validation, adversarial training, ensemble models |
| Poisoning Attacks | Training time | Attacker menyuntikkan data berbahaya ke training set | Spam filter dilatih untuk meloloskan spam tertentu | Data validation, anomaly detection, robust training |
| Model Extraction Attacks | Inference time (berulang) | Attacker melakukan query ke model untuk mencuri IP | Query API berulang untuk membangun surrogate model | Rate limiting, query monitoring, differential privacy |
Konsekuensi: di bidang security (bypass autentikasi, fraud), healthcare (misdiagnosis), transportasi (kecelakaan).
Secure Data & Feature Management
- Access Control: access control untuk feature store; permission terpisah untuk read/write; audit log untuk semua akses feature.
- Data Validation: input validation untuk semua feature; schema enforcement; range check dan anomaly detection.
- Encryption: enkripsi feature at rest dan in transit; komunikasi aman antara feature store dan layanan ML.
- Versioning: feature di-versioning bersama model; melacak feature mana yang dipakai di versi model mana.
Secure Model Development
- Experiment Tracking & Reproducibility: melacak versi kode (Git commit), versi data, hyperparameter, metrik.
- Reproducibility for Forensics: mencatat semua training run (data, kode, config); bisa menjawab “model mana yang di produksi dan bagaimana cara melatihnya?”; bisa melatih ulang model terbaik tahun lalu secara persis (untuk keperluan audit).
- Access Control: membatasi siapa yang bisa mengakses eksperimen/dataset tertentu; memisahkan eksperimen dev/staging/production.
- Dependency Management: pin semua dependency (library, framework); scan dependency untuk vulnerability; gunakan hermetic training environment (container).
- Data Provenance: melacak data apa yang dipakai untuk training; memastikan compliance (misal consent untuk penggunaan data).
Model Registry and Governance
- Model Registry: tempat sentral menyimpan versi model beserta metadata; stages: Staging, Production, Archived.
- Model Metadata: referensi data training, git hash, metrik (performa, fairness), owner, status approval.
- Access Control: hanya user yang authorized bisa mendaftarkan model; hanya model yang approved bisa dipromosikan ke production; audit log untuk semua operasi model.
- Model Signing: model ditandatangani sebelum deployment; signature diverifikasi sebelum serving; mencegah tampering.
- Rollback Capability: menyimpan versi model sebelumnya; rollback cepat jika terdeteksi masalah security.
Secure Model Deployment
Opsi deployment: batch inference (prediksi periodik) atau online/real-time inference (REST/gRPC API) — lihat 15_MLOps_ML_Lifecycle untuk detail pola deployment.
Pertahanan:
- API Security: Authentication (verifikasi identitas API client), Authorization (menegakkan permission — siapa boleh memanggil model mana), Rate Limiting (mencegah abuse dan serangan ekstraksi), Input Validation (menolak input yang malformed/mencurigakan).
- Network Security: gunakan API gateway untuk security terpusat; TLS untuk semua komunikasi API; isolasi jaringan untuk infrastruktur model serving.
- Logging and Monitoring: log semua request API (siapa, apa, kapan); memantau pola anomali (potensi serangan); alert pada aktivitas mencurigakan.
Protecting ML APIs from Attacks
Ancaman: model extraction, evasion attack, denial of service.
Pertahanan:
- Rate Limiting: batasi request per user/IP; throttle pola mencurigakan.
- Input Validation: schema validation, range check, anomaly detection.
- Output Obfuscation: hanya mengembalikan class label, bukan probabilitas (mempersulit ekstraksi model); menambahkan noise pada output (differential privacy).
- Monitoring: melacak pola query (mendeteksi percobaan ekstraksi); alert pada distribusi input yang tidak biasa; log semua request untuk analisis forensik.
CI/CD/CT untuk ML Security
- CI for ML: unit test untuk logika feature, pengecekan skema data, security test (input validation, tidak ada kebocoran PII).
- CD for ML: otomasi deployment layanan model; security gates (verifikasi signature, pengecekan approval).
- CT (Continuous Training): retraining otomatis saat ada data baru/penurunan performa; pertimbangan security: memvalidasi data training baru (mencegah poisoning).
- Contoh workflow: Git push → CI tests (termasuk security) → Training → Register → Security tests → Canary deploy → Monitor → Full rollout.
- Integrasi Security: SAST untuk kode ML (Python, notebook); dependency scanning untuk library ML (TensorFlow, PyTorch); model scanning untuk vulnerability yang diketahui; automated security testing sebelum deployment.
Monitoring and Observability untuk ML Security
Memperluas monitoring tradisional (accuracy, latency, drift) ke arah security monitoring (adversarial input, percobaan ekstraksi, data poisoning):
- Input Anomalies: distribusi input yang tidak biasa (potensi evasion attack), nilai out-of-range, request malformed.
- Output Anomalies: perubahan mendadak pada distribusi prediksi, confidence score yang tidak biasa.
- API Abuse: query rate tinggi dari satu user (percobaan ekstraksi), query serupa yang berulang (probing).
- Model Drift: penurunan performa (potensi poisoning), concept drift (perubahan distribusi data).
- Data Drift: training-serving skew, perubahan distribusi feature.
SRE dan MLOps Security
Konsep SRE yang diterapkan pada ML:
- SLO untuk ML Security: contoh — “99.9% inference request diautentikasi”, “MTTD (Mean Time to Detect) adversarial input < 1 menit”, “model drift terdeteksi dalam 24 jam”.
- Error Budgets: insiden security dihitung terhadap error budget; menyeimbangkan inovasi (model baru) dengan security.
- Canary Deployments: men-deploy model baru ke 1-5% traffic; memantau metrik security (bukan hanya accuracy); automated rollback saat ada security alert.
- Blameless Postmortems: belajar dari insiden security; terus memperbaiki pertahanan.
Release Strategies untuk Secure ML
- Blue-Green Deployment: dua environment identik (blue = current, green = new); alihkan traffic setelah validasi; rollback cepat jika ada masalah.
- Canary Deployment: kirim persentase kecil ke model baru (1-5%); pantau metrik security; ekspansi bertahap jika sehat.
- A/B Testing: dua model berjalan paralel; evaluasi KPI bisnis dan metrik security; pilih model yang lebih aman.
- Success Criteria: metrik bisnis (accuracy, revenue), metrik security (tidak ada peningkatan anomali, tidak ada API abuse), batasan risiko (fairness, compliance).
Responsible AI and Governance
- Explainability as Security: model blackbox lebih sulit diaudit; explainability membantu mendeteksi perilaku berbahaya; teknik: SHAP, LIME, attention visualization.
- Logging and Lineage: data mana yang membuat model mana? di-deploy kapan? dipakai oleh service mana? bisa menjawab pertanyaan compliance.
- Regulatory Compliance: model high-risk (finance, healthcare, critical infrastructure) membutuhkan dokumentasi eksplisit, human-in-the-loop, rencana rollback yang jelas, audit trail.
- Fairness and Bias: model yang bias bisa menjadi risiko security/legal; memantau bias (demographic parity, equal opportunity); memitigasi bias dalam data training dan model.
Feedback Loops and Poisoning
- Risiko Feedback Loop: model memengaruhi data yang nantinya dipakai untuk melatihnya kembali; user adversarial bisa meracuni (poison) feedback.
- Contoh: sistem rekomendasi menyarankan item → user berinteraksi (klik, pembelian) → interaksi dipakai untuk retrain model → attacker memanipulasi interaksi untuk membiaskan model.
- Strategi Pertahanan:
- Validate Feedback Data: anomaly detection pada feedback; menyaring interaksi mencurigakan; human review untuk edge case.
- Separate Training and Feedback: tidak langsung retrain pada semua feedback; mengkurasi data training dengan hati-hati.
- Monitor for Drift: mendeteksi perubahan mendadak pada distribusi feedback; alert pada pola yang tidak biasa.
Final Remarks (Rangkuman Prinsip Keamanan X-Ops)
- Shift Security Left: integrasikan security sejak awal dan berkelanjutan; otomasi security testing.
- Defense in Depth: berlapis-lapis security (jaringan, aplikasi, data, model); tidak ada single point of failure.
- Least Privilege: akses minimal yang diperlukan untuk semua sistem dan user; strict access control di mana-mana.
- Observability for Security: memantau metrik security bersamaan dengan performa; menggunakan praktik SRE (SLO, error budget) untuk security.
- Governance and Compliance: version control untuk segalanya (kode, data, model, config); audit trail untuk compliance; reproducibility untuk keperluan forensik.
Flashcard
flashcards Sebutkan bagaimana aspek “Sec” tertanam di masing-masing X-Ops (DevOps, DataOps, MLOps). :: DevOps → DevSecOps; DataOps → secure data lifecycle; MLOps → secure & trustworthy ML (mencakup pertahanan terhadap serangan, privasi, dan governance). Apa itu “Shift Security Left” dan mengapa penting? :: Prinsip mengintegrasikan security sejak tahap paling awal dan secara berkelanjutan dalam siklus pengembangan (bukan hanya sebagai gerbang pemeriksaan di akhir), sehingga vulnerability bisa ditemukan dan diperbaiki lebih dini dengan biaya lebih rendah. Sebutkan 3 jenis adversarial attack pada model ML beserta waktu terjadinya. :: Evasion Attacks (saat inference time, memanipulasi input agar model salah prediksi), Poisoning Attacks (saat training time, menyuntikkan data berbahaya ke training set), Model Extraction/Stealing Attacks (query berulang ke API untuk mencuri/mereplikasi model). Bagaimana insiden security dikaitkan dengan konsep error budget dari SRE? :: Downtime yang disebabkan oleh insiden security (misal DDoS atau respons terhadap breach) tetap dihitung dan mengurangi error budget yang sama dengan downtime akibat masalah reliability biasa, sehingga tim harus menyeimbangkan kecepatan inovasi dengan investasi keamanan. Sebutkan 4 kontrol keamanan utama di sepanjang layer arsitektur data (Data Source hingga Consumption). :: Data Source → Authentication; Ingestion → Validation & Encryption; Storage → Encryption & Access Control; Processing → Audit logging & Isolation; Consumption → Masking & Access Control. Apa itu Membership Inference dan Model Inversion sebagai risiko privasi data pada ML? :: Membership Inference adalah teknik menentukan apakah record data tertentu pernah dipakai dalam training set model; Model Inversion adalah teknik merekonstruksi data training asli dari output/prediksi model, keduanya mengancam privasi data sensitif yang dipakai untuk melatih model. Jelaskan risiko Feedback Loop Poisoning pada sistem ML dan berikan contohnya. :: Risiko di mana model memengaruhi data yang nantinya dipakai untuk melatihnya kembali, sehingga user adversarial bisa memanipulasi interaksi (misal klik/pembelian pada sistem rekomendasi) untuk membiaskan model secara bertahap melalui siklus retraining otomatis. Sebutkan strategi pertahanan terhadap Model Extraction Attack pada ML API. :: Rate limiting (membatasi request per user/IP), output obfuscation (hanya mengembalikan class label bukan probabilitas, atau menambah noise via differential privacy), dan monitoring pola query untuk mendeteksi percobaan ekstraksi. Sebutkan 5 prinsip dalam Final Remarks security X-Ops. :: Shift Security Left, Defense in Depth, Least Privilege, Observability for Security, Governance and Compliance.