Daftar Periksa Keamanan SaaS Sebelum Peluncuran: 40 Pemeriksaan yang Kami Jalankan Pertama (2026)

Daftar Periksa Keamanan SaaS Sebelum Peluncuran: 40 Pemeriksaan yang Kami Jalankan Pertama (2026)

Daftar periksa keamanan SaaS sebelum peluncuran jauh lebih berharga daripada tumpukan lencana kepatuhan yang belum Anda miliki. Ini adalah kebenaran yang tidak nyaman: sebagian besar daftar periksa peluncuran hanya memberi tahu Anda apa yang harus diamankan dan tidak pernah menunjukkan caranya. Daftar ini menyertakan kodenya. Kami membangun di atas Next.js dan Supabase, kami telah menyaksikan satu filter tenant_id yang hilang memungkinkan akun uji coba membaca data pelanggan lain, dan laporan IBM Cost of a Data Breach 2024 menempatkan rata-rata global di $4,88 juta. Anda tidak memerlukan SOC 2 untuk go-live. Anda memerlukan baseline lapisan aplikasi di bawah ini, yang dikelompokkan, dapat dijalankan, dan dipetakan ke OWASP dan NIST.

Poin Penting

• Anda tidak memerlukan SOC 2 atau uji penetrasi untuk meluncurkan. Anda memerlukan baseline lapisan aplikasi di bawah ini.
• Bug peluncuran paling berbahaya adalah kebocoran data lintas-tenant akibat pemeriksaan tenant_id yang hilang.
• Jangan membuat sistem autentikasi sendiri. Gunakan Auth.js, Clerk, atau Supabase Auth.
• Audit awalan NEXT_PUBLIC_ sebelum Anda melakukan deploy. Itu adalah cara tercepat untuk membocorkan rahasia.

Baseline ini dipetakan ke OWASP ASVS 5.0 dan NIST Secure Software Development Framework (SSDF), dua referensi yang paling dipercaya Google untuk topik ini dan, yang perlu dicatat, dua hal yang tidak direpotkan oleh panduan peringkat teratas untuk dikutip.

Daftar Periksa Keamanan Pra-Peluncuran Anda (Versi Cepat)

Ini adalah persyaratan keamanan minimum sebelum Anda merilis produk, dikelompokkan menjadi enam kategori. Empat puluh item. Jalankan dari atas ke bawah, serahkan bagian kode kepada developer Anda, dan anggap apa pun yang ditandai P0 dalam tabel prioritas di bawah ini sebagai penghalang peluncuran.

Rahasia & Konfigurasi

1. .env ada di .gitignore sejak commit pertama dan tidak pernah di-commit.
2. Setiap awalan NEXT_PUBLIC_ dan VITE_ diaudit; tidak ada rahasia yang dikirim ke browser.
3. Rahasia server disimpan di manajer (variabel env platform, AWS Secrets Manager, Vault), bukan di repo.
4. Kunci apa pun yang pernah menyentuh riwayat git dirotasi sebelum peluncuran.
5. Tidak ada rahasia yang muncul di log, payload error, atau bundle klien.
6. Anda melakukan grep pada bundle yang dibangun untuk mencari kunci aktif (grep -r "sk_live" .next/).

Autentikasi & Akses

1. Autentikasi dibangun di atas pustaka (Auth.js, Clerk, atau Supabase Auth), bukan buatan sendiri.
2. MFA tersedia untuk akun.
3. Cookie sesi menetapkan Secure, HttpOnly, dan SameSite.
4. Tidak ada JWT atau token sesi yang disimpan di localStorage.
5. RBAC dan peran dengan hak akses minimal ditegakkan di sisi server, bukan hanya disembunyikan di UI.
6. Kata sandi di-hash dengan Argon2 atau bcrypt (hanya jika Anda mengelola autentikasi sendiri).
7. Alur reset kata sandi dan verifikasi email diuji terhadap penyalahgunaan.

Data & Tenancy

1. Setiap kueri membawa filter tenant_id.
2. Cakupan tenant ditegakkan di lapisan ORM atau repositori, bukan diingat per kueri.
3. Keamanan tingkat baris (Row-level security) diaktifkan dan mode kegagalannya dipahami.
4. Setiap endpoint ID objek menjalankan pemeriksaan kepemilikan (ini mematikan IDOR).
5. tenant_id disertakan dalam kunci cache dan jalur penyimpanan objek.
6. Data dienkripsi saat diam (at rest) dan dalam perjalanan (in transit).
7. Tanda tangan pembayaran dan webhook (Stripe, dll.) diverifikasi di sisi server.

Dependensi & Rantai Pasokan

1. npm audit atau pnpm audit bersih dari temuan tinggi dan kritis (atau secara eksplisit ditriase).
2. Dependabot atau Renovate diaktifkan.
3. Snyk atau Socket menjalankan SCA yang lebih dalam plus pemeriksaan malware dan lisensi.
4. Lockfile di-commit.
5. Tidak ada paket yang ditinggalkan atau tidak dirawat berada di jalur kritis.
6. Gambar container discan jika Anda menggunakan Docker.

Jaringan & Transport

1. HTTPS ditegakkan di mana-mana, dengan preload HSTS.
2. Content-Security-Policy ditetapkan (hanya laporan terlebih dahulu, lalu ditegakkan).
3. X-Content-Type-Options: nosniff dan X-Frame-Options/frame-ancestors ditetapkan.
4. Referrer-Policy dan Permissions-Policy ditetapkan.
5. CORS menggunakan daftar yang diizinkan, jangan pernah * dengan kredensial.
6. Pembatasan laju (Rate limiting) melindungi autentikasi dan endpoint yang mahal.
7. Setiap endpoint memvalidasi input dengan skema (Zod atau sejenisnya).

Pemantauan & Respons

1. Log audit terpusat mencatat siapa yang mengakses apa, dan kapan.
2. Penanganan error tidak pernah membocorkan stack trace kepada pengguna.
3. Peringatan berbunyi pada anomali autentikasi (lonjakan gagal login, perjalanan yang tidak mungkin).
4. Backup otomatis berjalan, dan Anda telah menguji pemulihan.
5. Kontak respons insiden dan runbook satu halaman tersedia.
6. Pemantauan uptime dan error (Sentry atau setara) sudah aktif.
7. Anda mengetahui pemicu untuk mendatangkan uji penetrasi.

Prioritas Perbaikan Pertama

Tidak setiap item menghalangi peluncuran. Tabel triase ini mengurutkan baseline berdasarkan kerusakan jika dilewati sehingga pendiri tahu apa yang tidak bisa ditawar. P0 = perbaiki sebelum peluncuran, P1 = perbaiki minggu pertama, P2 = perbaiki dalam kuartal ini.

Rahasia & Konfigurasi: Apakah Ada Kunci yang Bocor ke Bundle Klien Anda?

Kebersihan rahasia saat peluncuran berarti tidak ada kredensial yang pernah mencapai browser. Awalan NEXT_PUBLIC_ di Next.js (dan VITE_ di Vite) mengirimkan nilai ke setiap pengunjung, jadi satu awalan yang salah membocorkan kunci. Jauhkan .env dari git, letakkan rahasia server di manajer, dan grep output build Anda sebelum Anda melakukan deploy.

Inilah jebakan yang paling sering kami lihat: NEXT_PUBLIC_ tidak berarti "informasi publik." Itu berarti "Saya secara harfiah mengirimkan ini ke browser setiap pengunjung." Awali rahasia Stripe atau kunci peran layanan seperti itu dan itu akan hidup di bundle bagi siapa saja yang membuka DevTools.

# .env.local (the mistake)
NEXT_PUBLIC_STRIPE_SECRET=sk_live_51H...   # BAD: ships to every browser
STRIPE_SECRET_KEY=sk_live_51H...           # OK: server-only

# Public (safe to expose) vs server-only
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...       # anon key is meant to be public
SUPABASE_SERVICE_ROLE_KEY=eyJ...           # never NEXT_PUBLIC_ this

# Catch a leaked key before you deploy
grep -r "sk_live" .next/    # any hit means a secret is in your client bundle

Sisa dari baseline rahasia membosankan dan tidak bisa ditawar: .env di .gitignore sejak commit pertama, rahasia server di manajer daripada di repo, dan rotasi kunci apa pun yang pernah menyentuh riwayat git (menghapus commit tidak membatalkan kebocoran). Token deploy yang bocor adalah persis bagaimana pelanggaran seperti insiden Vercel dimulai, jadi perlakukan setiap token seolah-olah sudah ada di daftar pantauan seseorang.

Autentikasi & Akses: Haruskah Anda Membangun Autentikasi atau Menggunakan Pustaka?

Haruskah Anda membangun autentikasi atau menggunakan pustaka? Hampir selalu gunakan pustaka. Auth.js, Clerk, dan Supabase Auth telah menyerap tahun-tahun kasus tepi yang sebaliknya akan Anda temukan kembali di produksi: fiksasi sesi, pencabutan token, penyalahgunaan alur reset. Membuat sendiri hanya dapat dibela jika Anda memiliki engineer keamanan dan alasan bahwa tidak ada penyedia yang cocok, yang jarang terjadi.

Membuat autentikasi sendiri adalah cara termahal untuk menghemat $25 sebulan. Berikut adalah perbandingan opsi yang jujur.

Dua jebakan menenggelamkan tim yang memilih pustaka tetapi melewatkan konfigurasi. Pertama, pencabutan JWT benar-benar sulit, jadi token yang dicuri tetap valid sampai kedaluwarsa; jaga masa hidup token tetap pendek dan utamakan sesi sisi server untuk apa pun yang sensitif. Kedua, token di localStorage dapat dicuri oleh payload XSS apa pun, jadi simpan sesi di cookie httpOnly dengan Secure dan SameSite. Terapkan RBAC di server, bukan dengan menyembunyikan tombol di UI.

Jika SaaS Anda memiliki fitur AI atau LLM, perlakukan input model sebagai batas autentikasi yang tidak tepercaya juga. Lihat panduan kami tentang mencegah injeksi prompt, karena asisten yang dijebol dengan akses alat adalah masalah kontrol akses yang mengenakan jendela obrolan.

Data & Tenancy: Bagaimana Anda Mencegah Satu Tenant Membaca Data Tenant Lain?

Isolasi tenant berarti setiap kueri, kunci cache, dan jalur penyimpanan dicakup ke tenant saat ini. Filter tenant_id yang hilang memungkinkan satu pelanggan membaca data pelanggan lain, bug peluncuran paling berbahaya yang ada. Keamanan tingkat baris membantu, tetapi itu adalah sabuk pengaman, bukan medan gaya, jadi tambahkan pemeriksaan kepemilikan pada setiap endpoint ID objek juga.

Ini adalah bagian yang tidak dibahas oleh kompetitor sebagai kode, dan inilah alasan kebocoran lintas-tenant menyusup ke produksi. Perbaikannya dimulai dengan tidak pernah mempercayai ID sendirian. Cakup setiap pembacaan ke tenant pemanggil, dan tegakkan itu di lapisan data sehingga tidak ada yang perlu mengingatnya per kueri.

// BAD: no tenant scope. Any valid id returns any tenant's row.
const order = await db.order.findFirst({ where: { id } });

// GOOD: scoped to the caller's tenant on every read.
const order = await db.order.findFirst({
  where: { id, tenantId: session.tenantId },
});

Kegagalan terkait adalah IDOR (insecure direct object reference), yang oleh OWASP API Security Top 10 dikategorikan di bawah API1: Broken Object Level Authorization. Akun uji coba menambah ID di URL dan membaca rekaman yang seharusnya tidak pernah dilihat. Web Security Academy milik PortSwigger memiliki walkthrough lengkap tentang bagaimana penyerang menemukan ini. Perbaikannya adalah satu pemeriksaan kepemilikan.

// GET /api/invoices/1234, a test account increments the id
// and reads another tenant's invoice. Classic BOLA.
const invoice = await db.invoice.findUnique({ where: { id } });

// Fix: verify ownership before you return anything.
if (invoice.tenantId !== session.tenantId) {
  return res.status(403).json({ error: "Forbidden" });
}

Berikut adalah kerangka kerja yang membuat Anda tetap jujur: setiap IDOR adalah kegagalan isolasi tenant, tetapi tidak setiap kegagalan isolasi tenant adalah IDOR. Keamanan tingkat baris Postgres menangkap banyak dari mereka di database, tetapi ia memiliki mode kegagalan diam-diam yang patut diketahui sebelum Anda bergantung padanya.

-- Postgres RLS: a seatbelt, not a force field.
alter table orders enable row level security;

create policy tenant_isolation on orders
  using (tenant_id = current_setting('app.tenant_id')::uuid);
-- Silent-failure trap: forget to SET app.tenant_id on a pooled
-- connection and the policy reads the PREVIOUS request's tenant.

Kontaminasi pool koneksi, kebocoran konteks async, dan racun cache bersama semua mengalahkan RLS secara diam-diam, itulah sebabnya OWASP Multi-Tenant Security Cheat Sheet memberitahu Anda untuk mengawali kunci cache dan jalur penyimpanan dengan tenant juga. Bab kontrol akses dari OWASP ASVS 5.0 dan dokumen RLS Supabase adalah dua referensi yang layak dibaca sepenuhnya di sini.

Dependensi & Rantai Pasokan: Apa yang Bersembunyi di node_modules Anda?

Aplikasi Anda hanya seaman dependensi transitif terlemahnya. Jalankan npm audit atau pnpm audit di CI dan gagalkan build pada temuan tinggi atau kritis sebelum Anda pernah meluncurkan. Tambahkan Dependabot atau Renovate untuk pembaruan otomatis, dan Snyk atau Socket untuk pemeriksaan malware dan lisensi yang lebih dalam.

Jebakannya adalah menjalankan audit sekali secara manual, melihat hasil hijau, dan tidak pernah menjalankannya lagi. Hubungkan ke CI sehingga CVE baru dalam paket yang belum Anda sentuh tetap memblokir merge.

# .github/workflows/ci.yml: block the merge on high/critical
- name: Audit dependencies
  run: npm audit --audit-level=high    # non-zero exit fails the job

Dokumen npm audit mencakup tingkat keparahan dan flag --production jika Anda ingin mengabaikan temuan khusus dev. Pemindaian otomatis adalah standar dasar, meskipun; untuk analisis statis yang lebih dalam yang menangkap code smell dan jalur injeksi yang dilewatkan oleh pemindai dependensi, lihat ulasan SonarQube kami. Commit lockfile Anda, hapus paket yang belum merilis update selama bertahun-tahun, dan scan gambar container Anda jika Anda mendeploy Docker.

Jaringan & Transport: Header Keamanan Apa yang Sebenarnya Dibutuhkan SaaS?

Header keamanan apa yang dibutuhkan SaaS? HTTPS plus HSTS dan set header pendek menutup celah yang paling mudah dieksploitasi. Tambahkan Content-Security-Policy, daftar yang diizinkan CORS alih-alih wildcard, dan batasan laju pada autentikasi dan endpoint yang mahal. Validasi setiap input dengan skema seperti Zod sehingga payload buruk tidak pernah mencapai logika Anda.

Anda tidak memerlukan setiap header yang pernah diciptakan. Anda memerlukan daftar pendek ini, dan referensi header keamanan MDN menjelaskan masing-masing secara mendalam.

Tetapkan header sekali, di edge, dan tambahkan pembatas laju sehingga skrip tidak dapat melakukan brute-force rute login Anda sepanjang malam.

// next.config.js: security headers on every response
const securityHeaders = [
  { key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains; preload" },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "X-Frame-Options", value: "DENY" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
];
// Rate-limit auth routes (Upstash example)
const { success } = await ratelimit.limit(ip);
if (!success) return new Response("Too many requests", { status: 429 });

Mulai CSP Anda dalam mode report-only agar Anda tidak merusak aplikasi Anda sendiri, pantau laporan pelanggaran selama beberapa hari, lalu ubah ke enforce. Batasi CORS ke daftar yang diizinkan bernama, dan jangan pernah memasangkan * dengan kredensial.

Pemantauan & Respons: Bagaimana Anda Akan Tahu Jika Anda Telah Dilanggar?

Anda tidak dapat merespons apa yang tidak dapat Anda lihat. Sebelum peluncuran, hubungkan log audit terpusat, peringatan pada anomali autentikasi seperti lonjakan gagal login, backup otomatis dengan pemulihan yang diuji, dan runbook insiden satu halaman. Backup yang tidak diuji adalah harapan, bukan backup, dan waktu untuk menulis runbook adalah sekarang, bukan di tengah insiden.

Data IBM menempatkan waktu rata-rata untuk mengidentifikasi dan containment pelanggaran pada 258 hari, dan Anda tidak dapat mengurangi angka itu jika log Anda tidak mencatat siapa yang menyentuh apa. Pusatkan mereka, beri peringatan pada anomali yang penting (lonjakan gagal login, login perjalanan yang tidak mungkin, volume ekspor tiba-tiba), dan pastikan handler error Anda mengembalikan pesan bersih alih-alih stack trace yang memetakan internal Anda.

Deteksi pelanggaran modern mengandalkan pemantauan anomali daripada aturan statis; ada lebih banyak tentang bagaimana itu sebenarnya bekerja dalam artikel kami tentang bagaimana AI mencegah pelanggaran data. Untuk dukungan kerangka kerja, NIST SSDF (SP 800-218) menguraikan praktik respons-dan-pemantauan dalam bahasa yang jelas. Uji pemulihan sebelum peluncuran, bukan setelah database Anda menghilang.

Apa yang Sebenarnya Kami Temukan Saat Meninjau Peluncuran Kami Sendiri

Ketika tim kami menjalankan pass keamanan pra-peluncuran pada build, milik kami atau klien, dua kelalaian muncul lebih dari apa pun else. Pertama: rahasia masuk ke browser pada awalan NEXT_PUBLIC_, biasanya kunci API pihak ketiga yang diawalkan seseorang agar panggilan sisi klien berfungsi. Kedua: setidaknya satu endpoint kehilangan cakupan tenant_id atau pemeriksaan kepemilikan.

Kelalaian cakupan tenant adalah yang menakutkan karena aplikasinya terlihat baik-baik saja. Setiap halaman dimuat. Bug hanya muncul ketika seseorang mengubah ID di URL. Pada satu tinjauan, GET /api/orders/:id mengembalikan pesanan apa pun ke pengguna yang login; akun uji coba membaca pesanan tenant lain dengan menambah angkanya. Perbaikannya adalah dua baris: bandingkan order.tenantId dengan session.tenantId sebelum mengembalikan.

Kami tidak akan mengutip tingkat tangkapan palsu di sini. Apa yang jujur dan dapat diulang adalah ini: kebocoran NEXT_PUBLIC_ dan cakupan tenant yang hilang adalah dua hal yang kami temukan di hampir setiap tinjauan pertama, dan keduanya murah untuk diperbaiki begitu Anda tahu harus mencarinya. Itulah tepatnya mengapa daftar periksa mengutamakan mereka sebagai P0.

Jika Anda lebih suka tim menjalankan pass ini untuk Anda sebelum hari peluncuran, itulah pekerjaan yang kami lakukan. Dapatkan tinjauan keamanan pra-peluncuran →

Tentang Penulis

Mert Batur Gurbuz adalah Co-Founder Techsy.io, di mana timnya mengirimkan agen AI, sistem otomasi, dan pipeline voice/SDR untuk klien B2B. Ia belajar di University of Birmingham dan menulis tentang tumpukan alat LLM yang benar-benar digunakan tim Techsy dalam produksi. Terhubung di LinkedIn.

Pertanyaan yang Sering Diajukan

Apa yang harus ada dalam daftar periksa keamanan SaaS sebelum peluncuran?

Enam kategori: rahasia dan konfigurasi (jauhkan kunci dari bundle klien), autentikasi dan akses (gunakan pustaka, tambahkan MFA), data dan tenancy (cakupan tenant_id plus pemeriksaan kepemilikan), dependensi (npm audit di CI), jaringan dan transport (HTTPS, HSTS, CSP, batasan laju), dan pemantauan serta respons (log audit, backup yang diuji, runbook).

Apakah SaaS saya cukup aman untuk diluncurkan?

Anda siap ketika baseline P0 selesai: rahasia keluar dari bundle klien, isolasi tenant pada setiap kueri, autentikasi pada pustaka, HTTPS dengan header keamanan, dan pemindaian dependensi yang bersih. Kesempurnaan bukanlah tolok ukur. Aplikasi yang dirilis, dipantau, dengan baseline yang tercakup lebih baik daripada yang "sempurna" yang tidak pernah diluncurkan.

Apakah saya memerlukan uji penetrasi sebelum meluncurkan SaaS?

Tidak untuk meluncurkan secara legal. Utamakan jika Anda menangani pembayaran atau PII, menargetkan pembeli enterprise, atau auditor/investor meminta. Pada tahap MVP, habiskan upaya itu untuk baseline lapisan aplikasi dan OWASP Top 10 terlebih dahulu. Uji penetrasi menemukan lebih banyak ketika celah IDOR dan header yang jelas sudah ditutup.

Apakah saya memerlukan SOC 2 untuk meluncurkan SaaS?

Tidak. Tidak ada pelanggan yang mengharapkan SOC 2 dari startup yang meluncurkan minggu lalu. Itu adalah pembuka penjualan enterprise, bukan gerbang peluncuran, dan membutuhkan waktu berbulan-bulan. Luncurkan dengan baseline lapisan aplikasi, lalu mulai proses SOC 2 ketika kesepakatan enterprise nyata membutuhkannya, bukan sebelumnya.

Haruskah saya membangun autentikasi sendiri atau menggunakan pustaka seperti Auth.js, Clerk, atau Supabase Auth?

Hampir selalu gunakan pustaka. Auth.js, Clerk, dan Supabase Auth telah menangani kasus tepi sesi, token, dan alur reset yang menyebabkan sebagian besar bug autentikasi buatan sendiri. Membuat sendiri hanya dapat dibela jika Anda memiliki engineer keamanan dan persyaratan keras yang tidak dipenuhi penyedia, yang benar-benar jarang.

Bagaimana cara menjaga rahasia agar tidak masuk ke bundle klien saya?

Audit setiap awalan NEXT_PUBLIC_ dan VITE_, karena apa pun dengan awalan itu dikirim ke browser. Jauhkan .env dari git sejak commit pertama, simpan rahasia server di manajer, dan grep bundle yang dibangun Anda (grep -r "sk_live" .next/) sebelum Anda melakukan deploy untuk menangkap kunci yang bocor.

Bagaimana cara mengisolasi data tenant di SaaS multi-tenant?

Letakkan filter tenant_id pada setiap kueri dan tegakkan di lapisan ORM atau repositori sehingga otomatis. Aktifkan keamanan tingkat baris dan pelajari mode kegagalannya (kontaminasi pool, kebocoran async). Tambahkan pemeriksaan kepemilikan ke setiap endpoint ID objek untuk menutup IDOR, dan cakup kunci cache serta jalur penyimpanan berdasarkan tenant.

Header keamanan apa yang dibutuhkan SaaS sebelum peluncuran?

Minimal: Strict-Transport-Security (HSTS), Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options atau frame-ancestors, Referrer-Policy, dan Permissions-Policy. Mulai CSP Anda dalam mode report-only, tinjau pelanggaran, lalu tegakkan. Dokumen header keamanan MDN mencantumkan nilai yang direkomendasikan untuk masing-masing, dan tabel header di atas merangkum apa yang dihentikan oleh masing-masing.

Apakah pemindaian otomatis seperti npm audit atau Snyk cukup?

Perlu tetapi tidak cukup. Alat seperti npm audit, Snyk, dan Socket menangkap CVE yang dikenal dan paket berbahaya, tetapi mereka tidak dapat menemukan cacat logika bisnis dan kontrol akses seperti IDOR atau cakupan tenant yang hilang. Itu membutuhkan manusia, akun uji coba, dan pemeriksaan kepemilikan eksplisit. Jalankan keduanya: pemindai dan pass manual.

Intinya: Daftar Periksa Keamanan SaaS yang Benar-Benar Dapat Anda Luncurkan

Anda tidak perlu sempurna untuk meluncurkan. Anda memerlukan baseline. Tutup item P0 terlebih dahulu: rahasia keluar dari bundle, isolasi tenant pada setiap kueri, pemeriksaan kepemilikan pada setiap endpoint objek, autentikasi pada pustaka, dan HTTPS dengan header. Jika Anda memperbaiki satu hal sebelum peluncuran hari Jumat, jadikan itu isolasi tenant, karena itulah bug yang membocorkan data pelanggan tanpa peringatan.

Semua di sini dapat dijalankan hari ini, dan tidak ada yang memerlukan anggaran kepatuhan. Kerjakan 40 pemeriksaan, serahkan bagian kode kepada developer Anda, dan luncurkan. Ingin sepasang mata kedua sebelum Anda go-live? Dapatkan konsultasi gratis dan kami akan menelusuri daftar dengan Anda.