Dependabot gak bisa baca github secrets

[feryardiant]

Dari beberapa PR dependabot malem ini (khususnya setelah aku bikin config nya di #40), semua CI di PR tersebut bermasalah. Setelah tak pelajari lagi ternyata issue nya karna dependabot gak bisa akses github secrets. Hal tersebut di konfirmasi dengan :

• Dependabot triggered Actions cant access secrets or use a writable token dependabot/dependabot-core#3253
• https://github.com/orgs/community/discussions/30588

Hipotesa

• Berdasarkan post ini disebutkan bawa workflow trigger nya perlu diganti dari pull_request jadi pull_request_target
• Opsi lain yang mungkin diterapkan adalah dengan menggunakan field token di dependabot.yml, tapi untuk saat ini saya masih belum yakin apakah token ini juga berlaku untuk composer package yang ada di github repo. Sementara di dokumentasinya hanya menyebutkan private composer registry.

[feryardiant]

Bangun tidur langsung baca-baca lagi link yang aku cantumin diatas dan kesimpulan yang aku dapet sementara ini adalah konyol, gimana gak, dalam hal ini keliatan sama sekali gak ada celah sama sekali kecuali dari sisi kita yang "intentionally" bikin workflows "vunerable".

Dan aku sama sekali gak dapet poin nya ketika mereka bilang

Security is important for us, therefore we applauded the change made in dependabot/dependabot-core#3253 (comment) where bots lost access to secrets by default to prevent eg. npm based attacks.

We have a lot (and I mean a lot) of secrets that we do not give access to bots (dependabot, renovate) and our workflow for all PRs opened by those, was (up until recently) to review PR and re-run their build by someone from the team.

Ok, dan disini mereka bilang

If your workflow needs to have a write token or access to secrets, you can use the pull_request_target event;

Tapi disini mereka juga bilang

There exists a potentially dangerous misuse of the pull_request_target workflow trigger that may lead to malicious PR authors (i.e. attackers) being able to obtain repository write permissions or stealing repository secrets.

Dari situ mereka menyarankan untuk mix workflow dimana perlu ada job tersendiri untuk memastikan bahwa workflow tersebut "aman" yaitu workflow dengan trigger pull_request untuk cek PR dan output berupa label, misal "safe" setelah pr tersebut diberi label github akan trigger workflow pull_request_target. Ini buat aku terkesan kayak "Ok, PR ini kayaknya aman, silakan pintunya dibuka semua".

Nah waktu aku coba cek repo settings, ternyata dependabot bisa set secrets tersendiri. Yang intinya adalah kita bisa kasih dependabot akses ke secret tertentu agar workflow kita bisa jalan.

Ok, berarti kita bisa "ngasih kunci tertentu" biar dependabot "bisa masuk".

Buat aku 2 opsi tersebut konyol semua, gimana gak? Kita harus kompromi dengan "extra steps" di workflow kita atau kompromi untuk nulis ulang secrets yang sama di tempat yang berbeda untuk tujuan yang sama atas alasan "keamanan" yang kalaupun kita terapin itu gak serta merta kita aman juga.

Kesimpulan ku dari issue ini adalah, pihak github secara tidak langsung "lepas tangan" jika repository kita "vunerable".

asu kan?

[sakukode]

Apa bedanya event pull_request dengan pull_request_target pada option github workflow? (sudah coba referensi tapi masih belum terlalu yakin ).

[sakukode]

Aku ambil contoh masalah vulnerability dari artikel di atas. Jika vulnerability itu datangnya dari dependency suatu repo (baik itu dari ekosistem composer maupun npm). Aku juga belum punya pengalaman terkait ini karena belum pernah bikin package yang sampai dirilis ke publish lewat composer/npm. Cuma apakah dari kedua package manager di atas itu tidak ada semacam pengecekan keamanan pada suatu package apakah mengandung malicious code atau tidak?

[sakukode]

Dan balik lagi ke issue di atas, dimana yang aku tangkap, Kita bisa ngasih akses tertentu pada PR yang dibuat oleh dependabot jika sudah memastikan PR itu aman dan menjalankannya pada workflow? Cuma aku sendiri belum nangkep, bagaimana mekanisme untuk memastikan kalau PR itu aman (kesannya kaya malah butuh ekstra step aja)? Dari komennya sampean @feryardiant Itu terkesan seperti hal yang sia-sia, jika GitHub tetap lepas tangan atau tidak bisa memastikan kalau repository kita aman dari vulnerability.