GitHub menambahkan Proof of Presence, kebijakan yang meminta autentikasi ulang atau tantangan multifaktor sebelum anggota enterprise melakukan aksi berisiko tinggi di GitHub Enterprise Cloud. Fitur ini diumumkan pada 24 September 2026 dan masih berstatus public preview.
Untuk sementara, cakupannya terbatas. GitHub menyebut Proof of Presence hanya tersedia untuk enterprise dengan Enterprise Managed Users di github.com dan GHEC-DR yang menggunakan Microsoft Entra ID sebagai identity provider melalui SAML atau OIDC. Jadi, ini bukan pengaturan keamanan baru yang otomatis berlaku untuk semua akun GitHub.
Meski cakupannya sempit, idenya penting untuk organisasi yang mengelola kode produksi, kredensial, dan otomasi dalam satu tempat. GitHub ingin membedakan antara sesi yang masih valid dan tindakan yang benar-benar dilakukan oleh orang yang berwenang pada saat itu.
## Sesi yang sah belum tentu berarti tindakan yang sah
Banyak sistem menganggap permintaan aman ketika datang dari sesi login atau token yang valid. Masalahnya, sesi dapat dicuri dan token berumur panjang dapat bocor. Jika penyerang memperoleh salah satunya, mereka bisa mencoba membuat token baru, mengubah webhook, mengganti pengaturan keamanan organisasi, atau mengakses recovery code tanpa harus melewati pemeriksaan tambahan.
GitHub mengaitkan perubahan ini dengan munculnya session cookie yang dicuri dan token autentikasi berumur panjang dalam sejumlah serangan supply chain. Proof of Presence mencoba menambah satu pertanyaan di titik yang paling sensitif: apakah ada manusia berwenang yang baru saja mengonfirmasi tindakan ini melalui identity provider perusahaan?
Ketika kebijakan aktif, GitHub mengarahkan anggota enterprise kembali ke identity provider sebelum aksi diteruskan. Pemeriksaan itu dapat berupa login ulang, MFA, pemeriksaan kepatuhan perangkat, atau kombinasi yang ditentukan oleh kebijakan di Microsoft Entra ID. GitHub hanya melanjutkan aksi jika pengguna kembali dengan bukti bahwa kebijakan tersebut sudah dipenuhi.
## Aksi apa yang dilindungi?
Contoh yang disebut GitHub mencakup pembuatan token, perubahan webhook, perubahan pengaturan keamanan organisasi, dan pengambilan recovery code. Daftar tersebut mengikuti pola yang sudah dikenal di sudo mode GitHub: operasi yang dapat memperluas akses, mengubah jalur otomasi, atau memengaruhi pemulihan akun mendapat perlakuan lebih ketat.
GitHub juga menyebut bahwa dukungan untuk pemeriksaan sebelum pull request merge akan datang kemudian. Artinya, Proof of Presence pada tahap awal belum dimaksudkan untuk memaksa autentikasi ulang pada setiap aktivitas pengembangan sehari-hari. Fokusnya adalah aksi administratif yang dampaknya lebih besar daripada sekadar membuat commit atau membuka pull request.
Setelah tantangan berhasil diselesaikan, status verifikasi berlaku selama dua jam dalam sesi browser tersebut. Pengguna dapat melakukan beberapa aksi berisiko tinggi tanpa mengulang tantangan setiap kali. Model ini menjaga pemeriksaan tetap berguna tanpa membuat administrator harus melewati MFA untuk setiap perubahan kecil.
## Bedanya dengan sudo mode
GitHub sudah memiliki sudo mode untuk meminta autentikasi ulang pada operasi sensitif. Dokumentasi GitHub mencantumkan contoh seperti membuat atau mencabut personal access token, mengubah webhook, mengatur keanggotaan organisasi, mengubah ruleset, serta melihat recovery code. Sudo mode dapat dipenuhi melalui beberapa metode, termasuk password, passkey, security key, GitHub Mobile, atau kode 2FA, tergantung konfigurasi akun.
Proof of Presence memperluas gagasan tersebut ke tingkat enterprise dan identity provider. Dalam preview ini, administrator enterprise dapat memilih apakah pengguna cukup melakukan re-authentication atau harus menyelesaikan MFA. Pemeriksaan tidak berhenti di GitHub; pengguna harus memenuhi kebijakan yang ditetapkan di Entra ID lalu kembali ke GitHub.
Perbedaan ini membuat Proof of Presence lebih cocok untuk organisasi yang sudah mengelola akses melalui SSO. Enterprise dapat menyatukan aturan perangkat, lokasi, tingkat risiko, dan MFA di identity provider, lalu menerapkannya ketika anggota hendak melakukan operasi yang sensitif di GitHub.
## Mengapa ini relevan untuk supply chain?
Webhooks, token, recovery code, dan pengaturan keamanan adalah bagian dari rantai kepercayaan software. Perubahan pada satu titik dapat mengubah proses build, deployment, notifikasi, atau akses repository. Jika penyerang berhasil menyisipkan endpoint webhook, menciptakan token, atau melonggarkan kontrol organisasi, dampaknya dapat menyebar jauh melampaui satu akun.
Autentikasi ulang tidak menghapus risiko tersebut. Ia juga tidak menggantikan least privilege, rotasi secret, audit log, branch protection, atau pemeriksaan terhadap workflow. Namun, pemeriksaan kehadiran menambah hambatan ketika penyerang hanya memiliki cookie atau token yang sudah dicuri. Dalam skenario itu, kredensial yang valid tidak lagi cukup untuk menyelesaikan aksi yang paling berbahaya.
Ada sisi lain yang perlu diperhatikan: agen otomatis. GitHub secara eksplisit menyebut bahwa Proof of Presence dapat menghalangi compromised credentials atau agent yang melangkah lebih jauh tanpa sepengetahuan pengguna. Ini bukan berarti semua otomasi akan berhenti. Tetapi workflow yang membuat token, mengubah webhook, atau melakukan operasi administratif perlu dirancang dengan jalur persetujuan dan identitas yang jelas.
## Batas preview dan pekerjaan administrator
Public preview berarti detail kebijakan masih dapat berubah. Administrator enterprise yang ingin menggunakannya perlu memastikan SSO dengan Entra ID sudah berjalan, menentukan level assurance yang dibutuhkan, dan menguji alur pemulihan jika pengguna tidak bisa menyelesaikan tantangan. Kebijakan MFA yang terlalu longgar tidak memberi perlindungan yang diharapkan, sedangkan kebijakan yang terlalu ketat dapat menghambat respons insiden.
Tim juga perlu memetakan aksi mana yang benar-benar membutuhkan kehadiran manusia. Tidak semua operasi harus diberi friksi yang sama. Token produksi, webhook deployment, aturan keamanan, dan recovery code layak ditempatkan di lapisan terkuat. Sebaliknya, aktivitas rutin developer sebaiknya tetap mengalir tanpa pemeriksaan tambahan yang tidak perlu.
GitHub belum menjadikan Proof of Presence sebagai default untuk semua enterprise. Untuk organisasi yang memenuhi syarat preview, fitur ini menawarkan pendekatan yang masuk akal: jangan hanya percaya bahwa sesi masih hidup; minta bukti baru ketika konsekuensi aksinya besar. Di tengah meningkatnya serangan terhadap rantai pasok software, lapisan kecil semacam itu bisa menjadi pembeda antara token yang bocor dan perubahan yang benar-benar berhasil dilakukan.
Sumber utama: - GitHub Changelog, Require proof of presence for high-impact actions (24 September 2026): https://github.blog/changelog/2026-09-24-require-proof-of-presence-for-high-impact-actions/
Sumber tambahan: - GitHub Docs, Configuring Proof of Presence: https://docs.github.com/en/enterprise-cloud@latest/admin/configuring-settings/hardening-security-for-your-enterprise/configuring-proof-of-presence - GitHub Docs, Sudo mode: https://docs.github.com/en/enterprise-cloud@latest/authentication/keeping-your-account-and-data-secure/sudo-mode