Penguatan Keamanan Praktis untuk GitHub Actions

Beranda » Ular sanca » Penguatan Keamanan Praktis untuk GitHub Actions

GitHub Actions telah menjadi mesin CI/CD de‑facto untuk repositori yang dihosting di GitHub, yang mendukung segalanya, mulai dari pengujian unit hingga penerapan produksi dan perubahan infrastruktur. Kemudahan ini memiliki konsekuensi serius: alur kerja sering kali berjalan dengan hak istimewa yang luas, menangani token dan rahasia yang kuat, dan dapat langsung menjangkau sistem produksi. Jika Anda tidak sengaja memperkuatnya, Anda secara efektif memberikan jalur cepat bagi setiap kesalahan konfigurasi, bug dependensi, atau akun yang disusupi untuk masuk ke pipeline dan akun cloud Anda.

Panduan ini membahas daftar periksa yang luas dan beropini untuk mengamankan GitHub Actions dari awal hingga akhirCara menangani rahasia dengan benar, menghindari injeksi skrip, mengunci token dan pemicu, menilai tindakan pihak ketiga, mengelola runner, dan memanfaatkan fitur keamanan bawaan seperti pemindaian kode, OIDC, Dependabot, dan log audit. Tujuannya adalah untuk menyatukan berbagai praktik terbaik, pelajaran berharga dari insiden terkini, dan panduan penguatan GitHub sendiri menjadi satu referensi praktis yang dapat Anda terapkan dalam proyek nyata.

Profil risiko sebenarnya dari GitHub Actions

Pada tingkat tinggi, alur kerja GitHub Actions hanyalah file YAML di bawah .github/workflows yang mendefinisikan satu atau beberapa pekerjaan, masing-masing terdiri dari langkah-langkah. Langkah-langkah tersebut dapat menjalankan perintah shell atau memanggil tindakan yang dapat digunakan kembali yang dipublikasikan oleh GitHub atau komunitas. Alur kerja dipicu oleh peristiwa seperti push, pull request, aktivitas masalah, jadwal, atau pengiriman manual.

Dari perspektif keamanan, alur kerja tersebut berada tepat di atas rantai pasokan perangkat lunak AndaMereka membangun dan menandatangani artefak rilis, mendorong citra Docker, menyebarkan ke lingkungan cloud, menyediakan infrastruktur, menjalankan migrasi, dan banyak lagi. Jika penyerang dapat mengontrol kode, konfigurasi, atau lingkungan tempat alur kerja istimewa berjalan, mereka sering kali dapat:

• Artefak yang dikompilasi pintu belakang (biner, kontainer, paket) yang kemudian Anda kirimkan ke pelanggan.
• Mengekstraksi token dan rahasia yang kuat dan berumur panjang dari memori, log, cache atau artefak.
• Penyalahgunaan peran cloud istimewa diberikan kepada CI untuk menyebarkan layanan tambahan, mengubah jaringan, atau mengakses data.
• Proyek hilir racun dengan mengorbankan jalur rilis sumber terbuka dan mendistribusikan rilis yang mengandung virus Trojan.

Insiden dunia nyata baru-baru ini telah menggarisbawahi betapa menariknya GitHub Actions sebagai permukaan serangan. Penyerang telah menyalahgunakan alur kerja yang rentan untuk menyuntikkan penambang kripto ke dalam paket yang diterbitkan, dan tj-actions/changed-files Tindakan tersebut dikompromikan dalam serangan multi-tahap yang mencoba mencapai Coinbase. Kode berbahaya tersebut mengekstrak rahasia dari alur kerja dan menuliskannya ke dalam log build, menciptakan potensi serangkaian kompromi rantai pasokan lanjutan.

Ide utama yang perlu diingat adalah bahwa sebagian besar serangan GitHub Actions adalah tentang “probabilitas × dampak”Anda ingin mengurangi kemungkinan penerapan komponen berbahaya atau bermasalah (tindakan pihak ketiga, runner yang tidak aman, pemicu berisiko), dan sekaligus secara drastis membatasi radius serangan jika ada satu komponen yang disusupi.

Mengunci rahasia di GitHub Actions

Rahasia biasanya merupakan target yang paling menarik dalam sistem CI/CD apa punDalam GitHub Actions, mereka muncul sebagai rahasia repositori, organisasi, atau lingkungan, dan sebagai nilai ad-hoc yang mungkin secara tidak sengaja Anda masukkan ke dalam konfigurasi, log, cache, atau artefak.

Hal pertama yang harus diinternalisasi adalah model akses: siapa pun yang memiliki akses menulis ke repositori dapat secara efektif membaca semua rahasia tingkat repositoriMereka cukup memodifikasi alur kerja yang ada pada cabang yang tidak dilindungi, menyuntikkan kode logging atau eksfiltrasi, lalu menjalankan alur kerja tersebut untuk mencetak atau membocorkan rahasia. Penyamaran GitHub dalam log merupakan upaya terbaik, bukan jaminan mutlak.

Untuk menjaga rahasia tetap bertahan dalam model tersebut, ikuti aturan dasar berikut:

• Terapkan prinsip hak istimewa paling sedikitSetiap kredensial yang digunakan dalam alur kerja hanya boleh memiliki izin minimum yang benar-benar dibutuhkan. Hindari membagikan token admin umum sebagai rahasia alur kerja.
• Lebih memilih rahasia lingkungan daripada rahasia repositori atau organisasi untuk nilai sensitifRahasia lingkungan hanya tersedia untuk pekerjaan yang mendeklarasikan lingkungan tersebut, dan Anda dapat membungkusnya dalam perlindungan tambahan seperti peninjau yang diperlukan dan pembatasan cabang.
• Jangan pernah menyimpan rahasia dalam teks biasa di file YAML alur kerja atau dalam kode yang diperiksa di repositori. Semua hal yang sensitif harus melalui mekanisme Rahasia GitHub atau pengelola rahasia eksternal.
• Hindari penggunaan blob terstruktur (JSON, YAML, XML) sebagai nilai rahasia tunggalPenyamaran sangat bergantung pada pencocokan string yang tepat; blob multi-bidang jauh lebih sulit untuk disunting secara andal. Sebagai gantinya, pisahkan data sensitif menjadi beberapa entri rahasia khusus.
• Daftarkan semua rahasia turunan secara eksplisitJika Anda mengubah rahasia (Base64, URL-encode, penandatanganan JWT, dll.) dan hasilnya mungkin tercatat dalam log, daftarkan nilai yang diubah sebagai rahasianya sendiri agar GitHub dapat mencoba menutupinya.

Rotasi dan kebersihan sama pentingnya dengan konfigurasi awalTinjau secara berkala rahasia mana yang masih ada, siapa dan apa yang sebenarnya masih membutuhkannya, dan hapus atau rotasikan rahasia yang sudah usang. Setelah dugaan paparan apa pun (misalnya, rahasia yang dicetak tanpa diedit ke dalam log, atau digunakan dalam tindakan yang disusupi), segera hapus log yang terdampak, cabut kredensialnya, dan buat yang baru.

Menghindari injeksi skrip dan interpolasi yang tidak aman

Salah satu jenis bug GitHub Actions yang paling umum, namun tidak kentara, adalah injeksi skrip melalui ekspresiGitHub menyediakan “konteks” yang kaya seperti github, env, secrets dan muatan peristiwa, yang Anda referensikan dalam alur kerja menggunakan ${{ ... }} sintaksis. Ekspresi tersebut dievaluasi oleh GitHub sebelum langkah shell Anda berjalan.

Ketika Anda menanamkan konteks yang tidak tepercaya langsung ke dalam perintah shell, Anda mengundang injeksi perintahMisalnya, jika Anda melakukan:

run: echo "new issue ${{ github.event.issue.title }} created"

dan penyerang dapat mengendalikan judul masalah, mereka dapat mengirimkan judul seperti $(id)Setelah evaluasi ekspresi, langkahnya menjadi:

echo "new issue $(id) created"

yang mengeksekusi id pada pelari. Tak ada gunanya mengubah tanda kutip atau menambahkan validasi sederhana di shell untuk menyelamatkan Anda dari pola ini.

Pola aman yang direkomendasikan GitHub adalah menggunakan variabel lingkungan perantara:

env:
TITLE: ${{ github.event.issue.title }}
run: |
echo "new issue \"$TITLE\" created"

Di sini nilai yang berpotensi bermusuhan tetap berada di memori sebagai variabel lingkungan, dan cangkangnya hanya melihat $TITLE, bukan baris perintah yang dibangun secara dinamis. Anda tetap memerlukan kebersihan shell yang normal (mengutip variabel, menghindari eval yang tidak diperlukan, dll.), tetapi langkah interpolasi yang berbahaya dihilangkan.

Kapan pun Anda tergoda untuk menanamkan ${{ github.* }} atau data lain yang dikontrol pengguna secara langsung ke run: blok, berhenti dan dorong env: sebagai gantinyaKebiasaan ini menghilangkan berbagai masalah penyuntikan skrip di seluruh alur kerja Anda.

Mengonfigurasi izin dan token dengan aman

The GITHUB_TOKEN yang disuntikkan GitHub ke dalam setiap alur kerja sangatlah hebat jika dibiarkan dengan pengaturan defaultIa dapat membaca dan menulis konten, membuka dan memperbarui permintaan tarik, serta berinteraksi dengan repo dalam berbagai cara. Secara historis, banyak organisasi yang secara default menggunakan fungsi baca-tulis tanpa menyadarinya.

Langkah pengerasan pertama Anda adalah mengatur izin token alur kerja default menjadi hanya-baca di tingkat organisasi dan/atau repositori. Terdapat pengaturan khusus untuk ini dalam konfigurasi Tindakan. Dari sana, Anda secara selektif memberikan izin tambahan per alur kerja atau per pekerjaan, misalnya:

permissions:
contents: read
pull-requests: write

Model “tolak secara default, izinkan jika diperlukan” ini secara drastis mengurangi apa yang dapat dilakukan penyerang dengan alur kerja yang disusupiHal ini juga memaksa penulis untuk memikirkan kapabilitas apa saja yang sebenarnya dibutuhkan oleh pekerjaan mereka, alih-alih mewarisi token yang bersifat umum.

Jika organisasi Anda dibuat sebelum awal tahun 2023, Anda harus mengaudit default ini secara eksplisitBanyak organisasi lama masih memiliki token alur kerja yang mendukung penulisan karena token tersebut sudah ada sebelum standar yang lebih aman dan tidak pernah menyetujui perubahan tersebut.

Selain cakupan token, berhati-hatilah dengan pengaturan yang memungkinkan GitHub Actions menyetujui atau membuat permintaan tarikMembiarkan alur kerja menyetujui PR membuka jalur penyalahgunaan di mana pekerjaan yang disusupi menggabungkan kode berbahaya tanpa tinjauan manusia. Kecuali Anda memiliki kasus penggunaan yang kuat dan aturan yang ketat, nonaktifkan fitur tersebut.

Memilih dan menyematkan tindakan pihak ketiga

Setiap tindakan eksternal yang Anda gunakan adalah bagian kode jarak jauh yang berjalan dengan hak istimewa yang sama dengan pekerjaan Anda lainnyaJika tindakan tersebut berubah menjadi berbahaya, disusupi, atau ditinggalkan dengan dependensi yang rentan, tindakan tersebut akan menjadi pijakan yang siap pakai di dalam alur kerja Anda.

Ada beberapa lapisan pertahanan yang dapat Anda terapkan saat mengonsumsi tindakan pihak ketiga:

• Mulailah dari daftar putih kecil yang tepercayaTindakan yang dikelola GitHub (seperti actions/checkout, actions/setup-node) dan tindakan marketplace dari kreator terverifikasi biasanya merupakan dasar yang lebih aman daripada repositori acak. Banyak organisasi menerapkan hal ini melalui "Izinkan tindakan tertentu dan alur kerja yang dapat digunakan kembali" di tingkat organisasi.
• Dukung tindakan yang populer dan dipertahankan secara aktifRiset menunjukkan bahwa banyak tindakan di marketplace memiliki skor OpenSSF Scorecard yang rendah, hanya memiliki satu pengelola, dan akun pemilik yang berumur pendek atau sangat muda. Tindakan yang banyak digunakan cenderung mengumpulkan lebih banyak pengawasan dan perbaikan yang lebih cepat.
• Perhatikan sejumlah besar PR Dependabot terbuka di repo tindakan. Hal ini sering kali menjadi tanda bahwa pengelola tidak menerapkan pembaruan keamanan, sehingga kerentanan transitif tidak ditambal.
• Lebih suka tindakan dengan lebih dari satu pengelola dan basis kode aktif yang tidak diarsipkanRatusan tindakan di pasar diarsipkan, yang berarti tidak ada perbaikan baru atau pembaruan kompatibilitas dan risiko yang terus meningkat seiring waktu.

Penyematan versi adalah topik penting lainnyaJika Anda menentukan tindakan hanya dengan tag, seperti some-org/some-action@v2, Anda yakin bahwa tag tersebut tidak akan pernah berpindah ke kode berbahaya. Tag dapat ditargetkan ulang jika akun pengelola atau repositori diretas.

Pendekatan paling defensif saat ini adalah dengan menyematkan SHA ke komitmen penuh:

uses: some-org/some-action@247835779184621ab13782ac328988703583285a

Penyematan ke SHA membuat kode tersebut secara efektif tidak dapat diubah dari perspektif Anda (singkatnya, serangan tabrakan SHA‑1 pada objek Git). Kelemahannya terletak pada operasionalnya: Anda harus memperbarui SHA ketika menginginkan fitur atau perbaikan baru, dan alur kerja yang berbeda dapat beralih ke SHA yang berbeda jika Anda tidak berhati-hati.

Untuk meringankan masalah tersebut, beberapa tim memusatkan penggunaan tindakan pihak ketiga ke dalam alur kerja bersama atau gabunganRepo individual merujuk alur kerja bersama tersebut berdasarkan tag, sementara alur kerja bersama menyematkan tindakan yang mendasarinya ke SHA yang telah diverifikasi dan diperbarui secara berkala, terkadang dengan perkakas yang membuka PR untuk SHA baru.

Apapun strategi yang Anda pilih, ingatlah bahwa penyematan bukanlah tembok api ajaib. Suatu tindakan masih dapat mengambil kode secara dinamis saat runtime (misalnya melalui curl | bash pola) dan melewati PIN Anda. Anda tetap perlu memeriksa sumbernya untuk pola yang jelas-jelas tidak aman sebelum mempercayai tindakan dengan rahasia atau token yang dapat ditulis.

Merancang alur kerja dan pekerjaan yang lebih aman

Cara Anda menyusun alur kerja dan pekerjaan sangat memengaruhi radius ledakan kompromiAnti-pola umum adalah satu pekerjaan raksasa yang memeriksa kode, membangun, menguji, mengemas, dan menyebarkan, semuanya dengan izin dan akses luas ke rahasia produksi.

Membagi pekerjaan menjadi pekerjaan terpisah dan bahkan alur kerja terpisah memberikan isolasi dan kejelasanMisalnya, Anda mungkin memiliki:

• A membangun dan menguji pekerjaan yang berjalan dengan izin minimal dan tanpa rahasia penerapan.
• A pekerjaan paket yang menghasilkan artefak bertanda tangan tetapi masih tidak berbicara dengan produksi.
• A menyebarkan pekerjaan yang bergantung pada yang lain dan merupakan satu-satunya yang diizinkan untuk mengakses rahasia lingkungan dan mengambil alih peran cloud.

Pada pelari yang dihosting GitHub, setiap pekerjaan dalam alur kerja berjalan di VM baru, yang memberi Anda tingkat isolasi antar pekerjaan. Ini tidak setara dengan sandbox yang diperkuat, dan terdapat vektor lintas pekerjaan yang diketahui (seperti cache cabang bersama), tetapi membagi pekerjaan tetap memaksa penyerang untuk bekerja lebih keras dan mengurangi kebocoran rahasia yang tidak disengaja ke langkah-langkah yang tidak terkait.

Gunakan lingkungan untuk menghubungkan langkah-langkah sensitif ke perlindunganPekerjaan penerapan mungkin mendeklarasikan:

environment: production

dan production lingkungan kemudian dapat dikonfigurasi untuk hanya menerima penerapan dari cabang yang dilindungi, mungkin dengan persetujuan manual wajib. Menggabungkan hal ini dengan aturan perlindungan cabang yang ketat (peninjauan wajib, tidak ada dorongan cepat, penolakan persetujuan yang basi) akan semakin mendekati prinsip empat mata untuk perubahan produksi.

Terakhir, berhati-hatilah dengan artefak, cache, dan logIni adalah cara yang praktis untuk berbagi data antar pekerjaan dan alur kerja, tetapi:

• Jangan kumpulkan rahasia ke dalam cache, terutama lokasi yang tidak terlalu terkenal seperti ~/.docker/config.json yang mungkin berisi kredensial Docker biasa.
• Hindari pencatatan rahasia atau membuang seluruh konteks ke dalam log, karena hal ini dapat menggagalkan penyamaran atau mengungkap nilai turunan yang tidak diketahui GitHub untuk disunting.
• Ingat bahwa siapa pun yang memiliki akses baca ke repo biasanya dapat mengunduh artefak dan menelusuri log, termasuk kolaborator luar jika Anda memberi mereka akses.

OIDC dan kredensial cloud jangka pendek

Salah satu perubahan paling berdampak yang dapat Anda lakukan adalah berhenti menyimpan kredensial penyedia cloud jangka panjang sebagai rahasia GitHub sama sekali. Sebagai gantinya, gunakan OpenID Connect (OIDC) untuk mendapatkan token berjangka pendek dan bercakupan luas yang terikat pada identitas alur kerja tertentu.

Aliran tingkat tinggi itu sederhana:

• Penyedia cloud Anda (AWS, Azure, GCP, dll.) dikonfigurasi untuk memercayai penyedia OIDC GitHub.
• Anda mendefinisikan kebijakan identitas yang menyatakan “hanya menerima token dari organisasi/repo/cabang atau lingkungan ini”.
• Selama pekerjaan, GitHub dapat meminta token OIDC dan alur kerja Anda menggunakan tindakan khusus cloud (misalnya aws-actions/configure-aws-credentials) untuk menukarnya dengan token akun layanan atau peran jangka pendek.

Kondisi kepercayaan adalah tempat Anda bisa mendapatkan informasi yang sangat terperinciUntuk AWS, kebijakan umum mungkin mencakup:

"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:Org/Repo:ref:refs/heads/main"
}

Hal ini memastikan hanya alur kerja dari repo dan cabang tertentu yang dapat mengambil peran tersebutJika Anda menginginkan cakupan yang lebih ketat, Anda dapat mengikat peran ke lingkungan tertentu, alih-alih cabang, lalu mewajibkan lingkungan tersebut hanya untuk pekerjaan deploy. Tindakan pihak ketiga yang disusupi dalam pekerjaan non-deploy akan mengakibatkan panggilan OIDC gagal.

Penggunaan OIDC tidak menghilangkan kebutuhan akan kebijakan peran hak istimewa paling rendah di cloud, tetapi menghilangkan kunci akses statis yang ada di Rahasia GitHub, yang dapat dicuri dan digunakan kembali tanpa batas waktu dari luar GitHub.

Perlindungan cabang, rangkaian aturan, dan lingkungan bekerja sama

Banyak jalur serangan yang menakutkan di GitHub Actions bermuara pada “penyerang menyuntikkan perubahan berbahaya ke dalam cabang yang dilindungi”Perlindungan cabang dan rangkaian aturan adalah garis pertahanan utama Anda di sana.

Di cabang seperti main or production, Anda biasanya menginginkan setidaknya:

• Memerlukan permintaan tarik sebelum penggabungan – melarang dorongan langsung.
• Memerlukan setidaknya satu (seringkali lebih) tinjauan yang menyetujui dari seseorang selain penekan terakhir.
• Tolak persetujuan yang sudah tidak berlaku lagi ketika komitmen baru ditambahkan – sehingga penyerang tidak dapat menyelinapkan kode setelah ditinjau.
• Memerlukan persetujuan dari dorongan terbaru yang dapat ditinjau – mencegah penyerang membajak PR milik orang lain, mengirimkan kode yang buruk, dan menyetujuinya sendiri.

Anda kemudian dapat menghubungkan perlindungan ini ke lingkungan. Misalnya, a production lingkungan mungkin hanya menerima penerapan dari main cabang, dan mungkin juga memerlukan persetujuan manual dari sekelompok kecil peninjau (dengan mengaktifkan "cegah peninjauan mandiri"). Dengan demikian, satu akun kontributor yang disusupi tidak dapat mengirimkan kode sembarangan ke tahap produksi tanpa keterlibatan eksplisit dari pihak lain.

Berhati-hatilah dengan aturan lingkungan yang bergantung pada penerapan itu sendiri (misalnya, "wajibkan penerapan berhasil sebelum mengizinkan pembaruan tag"). Jika terstruktur dengan buruk, Anda dapat menciptakan dependensi melingkar atau pseudo-kontrol yang dapat dilewati kolaborator dengan mengedit alur kerja. Pola yang paling aman tetap: perlindungan cabang yang kuat → lingkungan dengan cakupan yang ketat → penggunaan eksplisit lingkungan tersebut hanya pada pekerjaan minimal yang benar-benar membutuhkannya.

Mengelola pelari: GitHub‑hosted vs self‑hosted

Pelari adalah mesin yang benar-benar menjalankan alur kerja AndaRunner yang dihosting GitHub adalah VM sementara yang dikelola oleh GitHub; runner yang dihosting sendiri adalah mesin atau kontainer yang Anda sediakan dan kendalikan.

Pelari yang dihosting GitHub umumnya jauh lebih aman secara default:

• Mereka bersifat sementara dan diatur ulang untuk setiap pekerjaan, jadi tidak ada kompromi yang terus-menerus di seluruh proses.
• GitHub menerbitkan SBOM untuk gambar standar (Ubuntu, Windows, macOS), yang memungkinkan Anda menganalisis perangkat lunak prainstal untuk mengetahui kerentanannya.
• Host berbahaya tertentu diblokir secara langsung (misalnya kumpulan penambangan kripto yang dikenal) melalui /etc/hosts konfigurasi.

Pelari yang menjadi tuan rumah sendiri itu kuat tetapi berbahaya jika Anda tidak memperlakukannya seperti server produksi:

• Biasanya tidak bersifat sementara kecuali Anda membangunnya sendiri, sehingga alur kerja berbahaya apa pun dapat mencoba persistensi, pergerakan lateral, atau pencurian data.
• Mereka sering memiliki akses jaringan yang lebih luas dan rahasia lokal (kunci SSH, CLI cloud, layanan metadata), yang meningkatkan risiko kompromi apa pun.
• Repositori publik hampir tidak boleh menggunakan runner yang dihosting sendiri, karena siapa pun dapat membuka permintaan tarik yang akhirnya mengeksekusi kode pada infrastruktur Anda.

Jika Anda harus menggunakan pelari yang dihosting sendiri, bagilah mereka berdasarkan batasan kepercayaanGunakan grup dan batasan pelari sehingga:

• Proyek publik dan swasta tidak pernah berbagi kumpulan pelari yang sama.
• Repo dengan sensitivitas tinggi (misalnya infrastruktur produksi) memiliki runner yang dikontrol ketat.
• Hanya repositori atau organisasi tertentu yang dapat mengirim pekerjaan ke grup tertentu.

Anda dapat mengurangi risiko lebih lanjut dengan pelari just‑in‑time (JIT) yang disediakan melalui REST APIPelari ini terdaftar secara dinamis, menjalankan maksimal satu pekerjaan, lalu dihapus secara otomatis. Anda tetap perlu memastikan host yang mendasarinya dibersihkan atau dihancurkan, tetapi hal ini mempersempit peluang di mana pekerjaan yang disusupi dapat memengaruhi pekerjaan berikutnya.

Perlakukan pelari yang dihosting sendiri seperti sistem produksi lainnya: memantau aktivitas proses, mengunci jalur jaringan keluar, menjaga OS dan peralatan tetap tertambal, dan menganggap setiap pengguna yang memiliki izin untuk memicu alur kerja secara efektif memiliki eksekusi kode pada mesin tersebut.

Fitur keamanan bawaan: pemindaian kode, Kartu Skor, dan Dependabot

GitHub mengirimkan sejumlah fitur kelas satu yang secara khusus ditujukan untuk mengatasi risiko alur kerja dan ketergantungan, dan sepadan dengan biaya pemasangan yang kecil.

Pemindaian kode (misalnya dengan CodeQL) sekarang dapat menganalisis alur kerja GitHub Actions sendiri, bukan hanya sumber aplikasi Anda. Aturan seperti “Excessive Secrets Exposure” dapat mendeteksi pola di mana GitHub tidak dapat menentukan rahasia mana yang diperlukan (misalnya dinamis secrets[myKey] penggunaan dalam pembuatan matriks), yang menyebabkannya memuat lebih banyak rahasia daripada yang diperlukan ke dalam memori pekerjaan.

OpenSSF Scorecards dan tindakan Scorecards menambahkan lapisan lain dengan menilai postur keamanan dependensi AndaUntuk tindakan di pasar, Kartu Skor dapat menandai praktik rantai pasokan yang tidak aman seperti:

• Tidak menyematkan dependensi.
• Hilangnya perlindungan cabang atau persyaratan peninjauan kode.
• Kurangnya kebijakan keamanan atau proses respons kerentanan.

Dependabot memainkan dua peran di sini:

• Peringatan Dependabot memperingatkan Anda ketika ketergantungan tindakan atau alur kerja Anda memiliki kerentanan yang diketahui, berdasarkan Basis Data Penasihat GitHub.
• Pembaruan versi dan keamanan Dependabot dapat secara otomatis membuka PR untuk meningkatkan versi tindakan dan menambal rilis yang rentan.

Grafik ketergantungan untuk alur kerja adalah fitur lain yang kurang dihargaiGitHub memperlakukan file alur kerja Anda sebagai manifes dan dapat menunjukkan kepada Anda:

• Tindakan dan alur kerja yang dapat digunakan kembali mana yang Anda andalkan.
• Akun atau organisasi mana yang memilikinya.
• Versi atau SHA apa yang telah Anda sematkan.

Hal ini memudahkan untuk menjawab pertanyaan seperti “Di mana kita menggunakan tindakan yang dikompromikan ini?” saat peringatan baru turun, dan untuk merencanakan perbaikan massal.

Pemantauan, audit dan tata kelola

Keamanan tidak berakhir pada konfigurasi; Anda juga memerlukan visibilitas terhadap apa yang terjadi dari waktu ke waktuGitHub menyediakan log audit dan log keamanan di tingkat pengguna dan organisasi.

Dari sudut pandang Tindakan, ada beberapa hal yang perlu dilacak:

• Peristiwa yang berhubungan dengan rahasia, Seperti org.update_actions_secret atau perubahan rahasia repositori. Ini menunjukkan pembuatan, pembaruan, atau penghapusan kredensial sensitif.
• Perubahan alur kerja dan aturan: siapa yang mengubah aturan perlindungan, siapa yang mengedit alur kerja penerapan, siapa yang mengubah perlindungan lingkungan.
• Tindakan pasar baru atau yang dimodifikasi dan Aplikasi GitHub dipasang di organisasi, terutama yang diberi repositori atau cakupan organisasi yang luas.

Anda dapat melengkapi kontrol GitHub sendiri dengan aplikasi penegakan kebijakan seperti Allstar dari OpenSSF, yang terus-menerus memeriksa apakah repositori mematuhi dasar keamanan organisasi Anda (perlindungan cabang, pemindaian kode diaktifkan, tinjauan yang diperlukan, dll.).

Pada sisi “alur kerja yang berjalan”, perhatikan pola yang mungkin menunjukkan adanya penyalahgunaan: lonjakan waktu proses pekerjaan yang tidak biasa, lalu lintas keluar yang tidak terduga dari pelari, atau pekerjaan yang sering gagal di sekitar langkah-langkah yang menangani rahasia atau token OIDC. Hal-hal ini tidak selalu berbahaya, tetapi merupakan titik awal yang baik untuk investigasi.

Menggabungkan semua ini berarti menganggap GitHub Actions sebagai bagian dari permukaan produksi inti Anda, bukan sekadar "skrip perekat". Dengan rahasia dan token yang dicakup dengan cermat, perlindungan cabang dan lingkungan yang ketat, penggunaan tindakan pihak ketiga yang konservatif, runner yang diperkuat, dan pemantauan berkelanjutan dengan alat seperti CodeQL, Scorecard, dan Dependabot, Anda memberi organisasi Anda peluang untuk melawan kelas serangan CI/CD dan rantai pasokan yang terus berkembang, yang secara eksplisit menargetkan alur kerja GitHub itu sendiri.