วิธีรักษาความปลอดภัย NPM Dependencies คู่มือความปลอดภัยซัพพลายเชนสำหรับนักพัฒนา API

## TL;DR การโจมตีซัพพลายเชน NPM พุ่งสูงขึ้นเป็นกว่า 3,000 แพ็คเกจที่เป็นอันตรายในปี 2024 เพียงปีเดียว และการประนีประนอม Axios ในเดือนมีนาคม 2026 พิสูจน์ให้เห็นว่าแม้แต่แพ็คเกจ 10 อันดับแรกก็ยังไม่ปลอดภัย คู่มือนี้ครอบคลุมทุกระดับของการป้องกันที่นักพัฒนา API ต้องการ: การบังคับใช้ lockfile, การบล็อกสคริปต์ postinstall, การตรวจสอบที่มา, เครื่องมือวิเคราะห์พฤติกรรม และทางเลือกทางสถาปัตยกรรมที่ลดพื้นผิวการโจมตีของคุณ ## บทนำ การโจมตีซัพพลายเชน Axios เมื่อวันที่ 31 มีนาคม 2026 ไม่ใช่การประนีประนอม npm ครั้งแรก และจะไม่ใช่ครั้งสุดท้าย แต่ด้วยยอดดาวน์โหลด 83 ล้านครั้งต่อสัปดาห์และ RAT ข้ามแพลตฟอร์มที่ถูกใช้งานผ่านบัญชีผู้ดูแลระบบที่ถูกขโมยเพียงบัญชีเดียว มันคือการปลุกที่ดังที่สุดที่ระบบนิเวศ JavaScript เคยได้รับ นี่คือสิ่งที่ทำให้แตกต่างจากคำแนะนำ "อัปเดตการพึ่งพาของคุณ" ทั่วไป: การโจมตี Axios หลีกเลี่ยงการป้องกันแบบดั้งเดิมทุกรูปแบบ โค้ดที่เป็นอันตรายไม่ได้อยู่ใน Axios เอง แต่มันถูกฉีดผ่านการพึ่งพาแบบผีที่เรียกใช้ hook postinstall Lockfile ไม่ได้ช่วยอะไรถ้าคุณรัน `npm install` ในช่วงเวลาที่ถูกโจมตี การปักหมุดเวอร์ชันไม่ได้ช่วยอะไรถ้าคุณยังไม่ได้ปักหมุด นักพัฒนา API มีความเสี่ยงเป็นพิเศษ สคริปต์การทดสอบ, ไปป์ไลน์ CI/CD, เซิร์ฟเวอร์จำลอง และไคลเอนต์ HTTP ของคุณล้วนดึงมาจาก npm แพ็คเกจที่ถูกประนีประนอมเพียงแพ็คเกจเดียวในชุดเครื่องมือของคุณสามารถรั่วไหลคีย์ API, ข้อมูลประจำตัวฐานข้อมูล และโทเค็นคลาวด์จากเครื่องมือพัฒนาของคุณได้ 💡 Apidog ช่วยขจัดเวกเตอร์การโจมตีที่สำคัญหนึ่งข้อด้วยการจัดหาไคลเอนต์ HTTP ในตัวสำหรับการทดสอบ API ดังนั้นคุณจึงไม่จำเป็นต้องใช้ Axios, node-fetch หรือ got ในสแต็กการทดสอบของคุณ ดาวน์โหลด Apidog ฟรีเพื่อลดพื้นผิวการพึ่งพา npm ของคุณในขณะที่ปฏิบัติตามกลยุทธ์การป้องกันด้านล่าง button

คู่มือนี้ครอบคลุมเจ็ดชั้นของการป้องกัน ตั้งแต่สุขอนามัย lockfile พื้นฐาน ไปจนถึงการวิเคราะห์พฤติกรรมขั้นสูง ## Layer 1: การบังคับใช้ lockfile ### ทำไม lockfile ถึงสำคัญ lockfile บันทึกเวอร์ชันที่แน่นอนของทุกแพ็คเกจและการพึ่งพาเชิงส่งต่อ ณ เวลาที่ติดตั้ง หากไม่มี lockfile, `npm install` จะแก้ไขเวอร์ชันล่าสุดที่ตรงกับช่วง semver ของคุณ หาก `package.json` ของคุณระบุ `"axios": "^1.14.0"` และมี `1.14.1` ที่เป็นอันตรายอยู่บนรีจิสทรี คุณจะได้รับเวอร์ชันที่เป็นอันตราย ### กฎเกณฑ์ **ต้อง commit lockfile ของคุณเสมอ** ไม่ว่าจะเป็น `package-lock.json` (npm), `yarn.lock` (Yarn), `pnpm-lock.yaml` (pnpm) หรือ `bun.lock` (Bun) มันเป็นส่วนหนึ่งของการควบคุมเวอร์ชัน **ใช้การติดตั้งแบบ frozen ใน CI/CD** ห้ามรัน `npm install` ในสภาพแวดล้อมอัตโนมัติ ใช้การติดตั้งแบบ frozen lockfile ที่เทียบเท่า: ```bash # npm npm ci # yarn yarn install --frozen-lockfile # pnpm pnpm install --frozen-lockfile # bun bun install --frozen-lockfile ``` `npm ci` จะลบ `node_modules` และติดตั้งอย่างเคร่งครัดจาก lockfile หาก lockfile ไม่ตรงกับ `package.json` มันจะล้มเหลว สิ่งนี้จะป้องกันความประหลาดใจในการแก้ไข **ตรวจสอบความแตกต่างของ lockfile ใน pull requests** เมื่อ PR แก้ไข `package-lock.json` ให้ตรวจสอบว่ามีอะไรเปลี่ยนแปลง การพึ่งพาใหม่, การเพิ่มเวอร์ชัน และการเปลี่ยนแปลง URL ของรีจิสทรี ล้วนสมควรได้รับการตรวจสอบ เครื่องมืออัตโนมัติเช่น Socket.dev สามารถแจ้งเตือนการเปลี่ยนแปลง lockfile ที่น่าสงสัยในการตรวจสอบ PR ได้ ### ช่องว่างของ lockfile Lockfile ป้องกันการแก้ไขเวอร์ชันที่ไม่คาดคิด แต่ไม่ได้ป้องกันการติดตั้งครั้งแรก หากคุณเริ่มต้นโปรเจกต์หรือเพิ่มการพึ่งพาใหม่ในช่วงเวลาที่ถูกโจมตี เวอร์ชันที่เป็นอันตรายจะถูกล็อคไว้ นี่คือเหตุผลที่ lockfile เป็น Layer 1 ไม่ใช่ชั้นเดียว ## Layer 2: ปิดใช้งานสคริปต์ postinstall ### เวกเตอร์การโจมตีหลัก การโจมตี Axios, การโจมตี ua-parser-js, การโจมตี event-stream และอื่นๆ อีกมากมาย ล้วนใช้กลไกเดียวกัน: สคริปต์ `postinstall` ที่รันโค้ดตามอำเภอใจระหว่าง `npm install` hook นี้จะทำงานก่อนที่โค้ดแอปพลิเคชันของคุณจะรัน ก่อนที่คุณจะตรวจสอบแพ็คเกจ และก่อนที่เครื่องมือรักษาความปลอดภัยรันไทม์ใดๆ จะสามารถเข้าแทรกแซงได้ ### บล็อกสคริปต์ทั่วโลก เพิ่มสิ่งนี้ลงใน `.npmrc` ของคุณ: ```ini ignore-scripts=true ``` หรือตั้งค่าผ่าน CLI: ```bash npm config set ignore-scripts true ``` สิ่งนี้จะป้องกันไม่ให้สคริปต์วงจรชีวิตทั้งหมด (`preinstall`, `install`, `postinstall`, `prepare`) ทำงานระหว่างการติดตั้งแพ็คเกเกจ ### จัดการแพ็คเกจที่ต้องการสคริปต์ บางแพ็คเกจต้องการสคริปต์ postinstall สำหรับการคอมไพล์เนทีฟ (เช่น `bcrypt`, `sharp` หรือ `sqlite3`) คุณมีสองทางเลือก: **ทางเลือกที่ 1: รันสคริปต์แบบเลือกสรรหลังจากติดตั้ง** ```bash npm ci --ignore-scripts npm rebuild bcrypt sharp ``` **ทางเลือกที่ 2: ใช้ allowlist (npm 10+)** สร้างไฟล์ `.scriptsrc.json` ที่อนุญาตเฉพาะแพ็คเกจที่เชื่อถือได้เท่านั้นให้รันสคริปต์: ```json { "allowScripts": { "bcrypt": true, "sharp": true } } ``` **ทางเลือกที่ 3: ใช้ binaries ที่คอมไพล์ไว้ล่วงหน้า** แพ็คเกจจำนวนมากที่เคยต้องการการคอมไพล์เนทีฟ ตอนนี้มี binaries ที่คอมไพล์ไว้ล่วงหน้าแล้ว ตัวอย่างเช่น `sharp` มี binaries ที่คอมไพล์ไว้ล่วงหน้าสำหรับแพลตฟอร์มส่วนใหญ่ ทำให้ไม่จำเป็นต้องคอมไพล์หลังการติดตั้ง ตรวจสอบการพึ่งพาของคุณ; คุณอาจต้องการข้อยกเว้นสคริปต์น้อยกว่าที่คุณคิด ### คำเตือน PackageGate ในเดือนมกราคม 2026 นักวิจัยเปิดเผยช่องโหว่ zero-day หกรายการที่เรียกว่า "PackageGate" ซึ่งส่งผลกระทบต่อ npm, pnpm, vlt และ Bun การค้นพบหนึ่งคือ: การพึ่งพา Git-based สามารถมีไฟล์กำหนดค่าที่เปิดใช้งานการรันโค้ดได้แม้ในขณะที่สคริปต์วงจรชีวิตถูกปิดใช้งาน หาก `package.json` ของคุณอ้างอิง URL ของ Git สำหรับการพึ่งพา, `ignore-scripts` เพียงอย่างเดียวไม่เพียงพอ ปักหมุดการพึ่งพาเหล่านั้นไปยัง commit hashes ที่เฉพาะเจาะจงและตรวจสอบเนื้อหาของ repository ## Layer 3: ปักหมุดเวอร์ชันที่แน่นอน ### หยุดใช้ช่วง semver พฤติกรรมเริ่มต้นของ `npm install --save` จะเพิ่มแพ็คเกจที่มีเครื่องหมาย caret นำหน้า: ```json { "axios": "^1.14.0" } ``` เครื่องหมาย `^` หมายถึง "เข้ากันได้กับ 1.14.0" ซึ่งจะแก้ไขเป็นเวอร์ชัน 1.x.x ล่าสุด ในระหว่างการโจมตี Axios นั่นหมายถึงการแก้ไขเป็น 1.14.1 ปักหมุดเวอร์ชันที่แน่นอนแทน: ```json { "axios": "1.14.0" } ``` กำหนดค่า npm ให้บันทึกเวอร์ชันที่แน่นอนโดยค่าเริ่มต้น: ```ini # .npmrc save-exact=true save-prefix='' ``` ### ใช้ overrides สำหรับการพึ่งพาเชิงส่งต่อ การพึ่งพาโดยตรงของคุณมีการพึ่งพาของตัวเอง หากการพึ่งพาเชิงส่งต่อถูกประนีประนอม การปักหมุดการพึ่งพาโดยตรงของคุณไม่ช่วยอะไร ใช้ overrides เพื่อควบคุมการแก้ไขเชิงส่งต่อ: ```json { "overrides": { "axios": "1.14.0", "plain-crypto-js": "npm:empty-npm-package@1.0.0" } } ``` สำหรับ Yarn: ```json { "resolutions": { "axios": "1.14.0" } } ``` สำหรับ pnpm: ```json { "pnpm": { "overrides": { "axios": "1.14.0" } } } ``` ### ข้อแลกเปลี่ยน การปักหมุดที่แน่นอนหมายความว่าคุณจะไม่ได้รับการอัปเดตแพตช์อัตโนมัติ คุณจะต้องอัปเดตเวอร์ชันด้วยตนเอง ซึ่งทำให้เกิดภาระในการบำรุงรักษา ข้อแลกเปลี่ยนนี้เป็นการตัดสินใจโดยเจตนา: คุณกำลังเลือกการอัปเดตที่ควบคุมได้มากกว่าการอัปเดตอัตโนมัติ สำหรับโปรเจกต์ที่คำนึงถึงความปลอดภัย ข้อแลกเปลี่ยนนี้คุ้มค่า ## Layer 4: ตรวจสอบที่มาของแพ็คเกจ ### ที่มาหมายถึงอะไร การรับรองที่มาของ npm เชื่อมโยงแพ็คเกจที่เผยแพร่กับซอร์สโค้ดและสภาพแวดล้อมการสร้างโดยใช้ลายเซ็น Sigstore ที่บันทึกไว้ในสมุดบัญชีความโปร่งใสสาธารณะ เมื่อแพ็คเกจถูกเผยแพร่จากไปป์ไลน์ CI/CD ที่เปิดใช้งานที่มา แพ็คเกจจะรวมหลักฐานทางเข้ารหัสของ: *   ถูกสร้างขึ้นจาก repository ต้นทางใด *   ระบบ CI/CD ใดที่สร้างขึ้น *   commit ใดที่กระตุ้นการสร้าง ### วิธีตรวจสอบที่มา ```bash npm audit signatures ``` สิ่งนี้จะตรวจสอบว่าแพ็คเกจที่ติดตั้งมีการรับรองที่มาที่ถูกต้องหรือไม่ แพ็คเกจที่เผยแพร่ด้วยตนเองจากเครื่องของนักพัฒนาจะไม่มีที่มา เวอร์ชัน Axios ที่เป็นอันตรายขาดการผูกที่มา OIDC และไม่มี GitHub commits ที่สอดคล้องกัน หากการตรวจสอบที่มาอัตโนมัติเป็นแนวปฏิบัติมาตรฐาน การโจมตีจะถูกตั้งธงทันที ### เปิดใช้งานที่มาสำหรับแพ็คเกจของคุณเอง หากคุณเผยแพร่แพ็คเกจ npm ให้เปิดใช้งานที่มาใน CI/CD ของคุณ: ```yaml # ตัวอย่าง GitHub Actions - uses: actions/setup-node@v4 with: node-version: 20 registry-url: https://registry.npmjs.org - run: npm publish --provenance env: NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} ``` เพิ่มสิ่งนี้ลงใน `.npmrc` ของคุณ: ```ini provenance=true ``` ### ข้อจำกัด ที่มาเป็นแบบ opt-in แพ็คเกจ npm ส่วนใหญ่ยังไม่มี และที่มาเพียงแค่พิสูจน์ว่าแพ็คเกจถูกสร้างขึ้นที่ไหน ไม่ได้พิสูจน์ว่าซอร์สโค้ดปลอดภัย ไปป์ไลน์ CI/CD ที่ถูกประนีประนอมอาจเผยแพร่แพ็คเกจที่เป็นอันตรายพร้อมที่มาที่ถูกต้อง ## Layer 5: ใช้เครื่องมือวิเคราะห์พฤติกรรม ### เหนือกว่าการสแกนช่องโหว่ เครื่องมือดั้งเดิมเช่น `npm audit` และ Snyk ตรวจสอบกับฐานข้อมูลช่องโหว่ที่รู้จัก (CVEs) พวกมันจะจับปัญหาที่รายงาน แต่พลาดการโจมตี zero-day การประนีประนอม Axios ไม่ได้อยู่ในฐานข้อมูล CVE ใดๆ เมื่อมันถูกเผยแพร่ เครื่องมือวิเคราะห์พฤติกรรมจะตรวจสอบว่าแพ็คเกจทำอะไร ไม่ใช่สิ่งที่ถูกรายงานเกี่ยวกับพวกมัน ### Socket.dev Socket วิเคราะห์พฤติกรรมของแพ็คเกจระหว่างการติดตั้งและรันไทม์ มันจะแจ้งเตือน: *   คำขอเครือข่ายระหว่างการติดตั้ง *   การเข้าถึงระบบไฟล์นอกไดเรกทอรีแพ็คเกจ *   การรันคำสั่ง shell *   การเก็บเกี่ยวตัวแปรสภาพแวดล้อม *   รูปแบบโค้ดที่ถูกปิดบัง

เมื่อรวมเข้ากับ GitHub, Socket จะแสดงความคิดเห็นใน PRs เมื่อการพึ่งพาใหม่แสดงพฤติกรรมที่น่าสงสัย การพึ่งพา `plain-crypto-js` ของการโจมตี Axios จะเรียกใช้การแจ้งเตือนของ Socket หลายรายการ: โค้ดที่ถูกปิดบัง, คำขอเครือข่ายระหว่าง postinstall, และการเขียนระบบไฟล์นอกไดเรกทอรีแพ็คเกจ ```bash # ติดตั้ง Socket CLI npm install -g @socketsecurity/cli # สแกนโปรเจกต์ของคุณ socket scan ``` ### Snyk Snyk ให้การจัดการช่องโหว่พร้อมคะแนนความเสี่ยง, ข้อมูลความพร้อมในการใช้ประโยชน์, และคำแนะนำในการแก้ไข มันแข็งแกร่งกว่าสำหรับช่องโหว่ที่รู้จัก แต่ด้อยกว่าสำหรับการตรวจจับพฤติกรรม zero-day ```bash # ติดตั้ง Snyk CLI npm install -g snyk # ทดสอบโปรเจกต์ของคุณ snyk test ```

### แนวทางแบบหลายชั้น ใช้ทั้งสองอย่าง Socket ตรวจจับความผิดปกติทางพฤติกรรมที่ Snyk พลาดไป Snyk ตรวจจับช่องโหว่ที่รู้จักพร้อมบริบทที่สมบูรณ์กว่าที่ Socket ให้ไว้ เพิ่ม `npm audit` เป็นพื้นฐาน: ```bash # พื้นฐาน npm audit # การวิเคราะห์พฤติกรรม socket scan # การจัดการช่องโหว่ snyk test ``` รันทั้งสามอย่างใน CI/CD เป็นเกต การค้นพบที่สำคัญใดๆ ควรบล็อกการสร้าง ## Layer 6: ลดพื้นผิวการพึ่งพาของคุณ ### คำถามที่ลึกซึ้งกว่า ทุกแพ็คเกจใน `node_modules` ของคุณคือการตัดสินใจเชื่อถือ การโจมตี Axios ประนีประนอมแพ็คเกจที่มีการดาวน์โหลด 83 ล้านครั้งต่อสัปดาห์ โปรเจกต์ Node.js โดยเฉลี่ยมีการพึ่งพาเชิงส่งต่อหลายร้อยรายการ แต่ละรายการคือเวกเตอร์การโจมตีที่เป็นไปได้ การป้องกันที่มีประสิทธิภาพที่สุดคือการมีส่วนพึ่งพาน้อยลงเพื่อป้องกัน ### ตรวจสอบโครงสร้างการพึ่งพาของคุณ ```bash # นับการพึ่งพาทั้งหมดของคุณ npm ls --all | wc -l # ตรวจสอบรายการซ้ำ npm ls --all | sort | uniq -c | sort -rn | head -20 ``` ถามคำถามเหล่านี้สำหรับแต่ละการพึ่งพา: *   **ภาษานั้นๆ หรือรันไทม์นั้นๆ มีสิ่งนี้ในตัวหรือไม่?** Node.js 18+ มี `fetch`, `crypto`, `URL`, `FormData`, และยูทิลิตี้มากมายที่เคยต้องการแพ็คเกจ *   **การพึ่งพาตัวนี้ดึงการพึ่งพาเชิงส่งต่อมากมายหรือไม่?** แพ็คเกจเดียวที่มี 50 sub-dependencies จะเพิ่มพื้นผิวการโจมตีของคุณ 50 เท่า *   **คุณสามารถจัดหาได้หรือไม่?** สำหรับแพ็คเกจยูทิลิตี้ขนาดเล็ก การคัดลอกซอร์สโค้ดลงในโปรเจกต์ของคุณจะกำจัดความเสี่ยงของซัพพลายเชนทั้งหมด ### ทางเลือกเนทีฟสำหรับแพ็คเกจทั่วไป

### สำหรับการทดสอบ API โดยเฉพาะ เวิร์กโฟลว์การทดสอบ API โดยทั่วไปจะขึ้นอยู่กับไลบรารีไคลเอนต์ HTTP, ไลบรารีการยืนยัน, test runners และเซิร์ฟเวอร์จำลอง การพึ่งพาแต่ละรายการคือพื้นผิวการโจมตี

Apidog แทนที่สแต็กทั้งหมดด้วยแพลตฟอร์มเดียว: *   **ไคลเอนต์ HTTP**: ในตัว ไม่จำเป็นต้องพึ่งพา npm *   **การยืนยัน**: ตัวสร้างการทดสอบด้วยภาพพร้อมการยืนยันในตัว *   **Test runner**: สถานการณ์การทดสอบอัตโนมัติพร้อมการรวม CI/CD ผ่าน Apidog CLI *   **เซิร์ฟเวอร์จำลอง**: Smart mock พร้อมการตอบสนองแบบไดนามิก ไม่ต้องใช้ Express หรือไลบรารี mock ของบุคคลที่สาม *   **เอกสารประกอบ**: สร้างขึ้นโดยอัตโนมัติจากข้อกำหนด API ของคุณ การย้ายเวิร์กโฟลว์การทดสอบ API ของคุณไปยัง Apidog จะช่วยขจัดส่วนพึ่งพา npm หลายสิบรายการจากโครงสร้างพื้นฐานการทดสอบของคุณ การพึ่งพาน้อยลงหมายถึงการตัดสินใจเชื่อถือน้อยลงและเวกเตอร์การโจมตีน้อยลง ลองใช้ Apidog ฟรีเพื่อรวมสแต็กการทดสอบ API ของคุณ button ## Layer 7: การตรวจสอบเครือข่ายและรันไทม์ ### บล็อกโดเมนที่ไม่ดีที่รู้จัก หลังจากการโจมตีซัพพลายเชนใดๆ ให้บล็อกโครงสร้างพื้นฐานคำสั่งและควบคุมที่ระดับเครือข่าย: ```bash # เพิ่มลงใน /etc/hosts echo "0.0.0.0 sfrclak.com" | sudo tee -a /etc/hosts ``` สำหรับสภาพแวดล้อม CI/CD ให้จำกัดการเข้าถึงเครือข่ายขาออกเฉพาะโดเมนที่เชื่อถือได้เท่านั้น กระบวนการสร้างส่วนใหญ่ต้องการการเข้าถึงรีจิสทรี npm, โฮสต์ git ของคุณ และเป้าหมายการปรับใช้ของคุณเท่านั้น สิ่งอื่นๆ ทั้งหมดควรถูกบล็อกโดยค่าเริ่มต้น ### ใช้ StepSecurity Harden-Runner สำหรับ CI/CD Harden-Runner ของ StepSecurity ตรวจสอบเวิร์กโฟลว์ GitHub Actions แบบเรียลไทม์ มันตรวจพบ Axios dropper ที่ติดต่อ C2 ภายใน 1.1 วินาทีหลังจาก `npm install` เริ่มต้น เครื่องมือนี้ให้: *   การตรวจสอบเครือข่ายขาออกสำหรับ GitHub Actions *   การติดตามการรันกระบวนการ *   การตรวจสอบความสมบูรณ์ของไฟล์ *   การแจ้งเตือนอัตโนมัติสำหรับพฤติกรรมที่ผิดปกติ ```yaml # GitHub Actions - uses: step-security/harden-runner@v2 with: egress-policy: audit  # หรือ 'block' สำหรับโหมดเข้มงวด ``` ### การตรวจสอบกระบวนการรันไทม์ สำหรับเครื่องมือพัฒนา ให้พิจารณาเครื่องมือ Endpoint Detection and Response (EDR) ที่แจ้งธงกระบวนการย่อยที่น่าสงสัยซึ่งสร้างขึ้นโดย Node.js Axios RAT สร้าง `osascript` (macOS), `cscript` (Windows), และ `python3` (Linux) จากภายในกระบวนการติดตั้ง npm รูปแบบกระบวนการย่อยเหล่านี้สามารถตรวจจับได้ ## การกำหนดค่า .npmrc ที่แนะนำ นี่คือไฟล์ `.npmrc` ที่มีความปลอดภัยสูงซึ่งรวมเลเยอร์ข้างต้น: ```ini # ปักหมุดเวอร์ชันที่แน่นอน save-exact=true save-prefix= # ปิดใช้งานสคริปต์วงจรชีวิต ignore-scripts=true # เปิดใช้งานที่มาสำหรับการเผยแพร่ provenance=true # ใช้รีจิสทรีอย่างเป็นทางการ registry=https://registry.npmjs.org/ # กำหนดให้ใช้ 2FA สำหรับการเผยแพร่ auth-type=web # ระดับการตรวจสอบเกณฑ์ audit-level=moderate ``` Commit ไฟล์นี้ไปยัง repository ของคุณเพื่อให้สมาชิกในทีมทุกคนใช้การตั้งค่าความปลอดภัยเดียวกัน ## ตัวอย่างไปป์ไลน์ความปลอดภัย CI/CD นี่คือเวิร์กโฟลว์ GitHub Actions ที่บังคับใช้ทั้งเจ็ดเลเยอร์: ```yaml name: Secure Build on: [push, pull_request] jobs: security-check: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: step-security/harden-runner@v2 with: egress-policy: audit - uses: actions/setup-node@v4 with: node-version: 22 # Layer 1+2: Frozen lockfile, no scripts - run: npm ci --ignore-scripts # Layer 3: ตรวจสอบไม่มีเวอร์ชันที่ไม่คาดคิด - run: npm ls --all > deps.txt # Layer 4: ตรวจสอบที่มา - run: npm audit signatures # Layer 5: การวิเคราะห์พฤติกรรม - run: npx socket scan # Layer 5: สแกนช่องโหว่ - run: npx snyk test # Layer 1: ตรวจสอบพื้นฐาน - run: npm audit --audit-level=moderate # สร้าง native deps ที่อนุญาตใหม่เท่านั้น - run: npm rebuild sharp bcrypt ``` ## มีอะไรใหม่เกี่ยวกับความปลอดภัย npm ### การรับรองที่มาภาคบังคับสำหรับแพ็คเกจยอดนิยม npm กำลังพิจารณาที่จะกำหนดให้มีการรับรองที่มาสำหรับแพ็คเกจที่มียอดดาวน์โหลดสูงกว่าเกณฑ์ที่กำหนด ซึ่งจะป้องกันการเผยแพร่ด้วยตนเองที่ใช้โทเค็นซึ่งทำให้การโจมตี Axios เกิดขึ้นได้ ### การอนุมัติการเผยแพร่แบบสองคน เช่นเดียวกับธุรกรรมทางการเงินที่ต้องการการอนุมัติสองชั้น แพ็คเกจที่มีการดาวน์โหลดสูงอาจต้องการผู้ดูแลระบบคนที่สองเพื่ออนุมัติการเผยแพร่ บัญชีที่ถูกประนีประนอมเพียงบัญชีเดียวจะไม่เพียงพอ ### การกำหนดขอบเขตสิทธิ์รันไทม์ Deno จำกัดสิ่งที่สคริปต์สามารถเข้าถึงได้ (เครือข่าย, ระบบไฟล์, ตัวแปรสภาพแวดล้อม) เว้นแต่จะได้รับอนุญาตอย่างชัดเจน Node.js กำลังสำรวจโมเดลสิทธิ์ที่คล้ายกัน เมื่อสิ่งนี้ถูกนำมาใช้ สคริปต์ postinstall จะต้องได้รับอนุญาตอย่างชัดเจนในการส่งคำขอเครือข่ายหรือเข้าถึงระบบไฟล์ ### การรวมตัวของผู้จัดการแพ็คเกจ โมเดลการแยกส่วนที่เข้มงวดของ pnpm (แพ็คเกจสามารถเข้าถึงเฉพาะการพึ่งพาที่ประกาศไว้เท่านั้น) ป้องกันการโจมตีแบบ dependency confusion จำนวนมาก เมื่อ npm นำความเข้มงวดที่คล้ายกันมาใช้ พื้นผิวการโจมตีก็จะลดลง ## คำถามที่พบบ่อย ### การโจมตีซัพพลายเชนใน npm คืออะไร? การโจมตีซัพพลายเชนใน npm กำหนดเป้าหมายไปที่ห่วงโซ่การพึ่งพาซอฟต์แวร์แทนที่จะเป็นแอปพลิเคชันของคุณโดยตรง ผู้โจมตีจะประนีประนอมบัญชีผู้ดูแลแพ็คเกจ ฉีดโค้ดที่เป็นอันตรายเข้าไปในแพ็คเกจยอดนิยม หรือเผยแพร่แพ็คเกจ typosquat ที่มีชื่อคล้ายกัน เมื่อคุณติดตั้งหรืออัปเดตการพึ่งพา โค้ดที่เป็นอันตรายจะทำงานบนเครื่องของคุณหรือในไปป์ไลน์ CI/CD ของคุณ ขโมยข้อมูลประจำตัว ติดตั้งแบ็คดอร์ หรือรั่วไหลข้อมูล ### `npm audit` เพียงพอที่จะป้องกันการโจมตีซัพพลายเชนหรือไม่? ไม่ `npm audit` ตรวจสอบกับฐานข้อมูลช่องโหว่ที่รู้จัก (CVEs) การโจมตี zero-day เช่นการประนีประนอม Axios ไม่ได้อยู่ในฐานข้อมูล CVE ใดๆ เมื่อมันเกิดขึ้น คุณต้องการเครื่องมือวิเคราะห์พฤติกรรมเช่น Socket.dev ที่ตรวจสอบว่าแพ็คเกจทำอะไร ไม่ใช่สิ่งที่ถูกรายงานเกี่ยวกับพวกมัน ใช้ `npm audit` เป็นพื้นฐาน ไม่ใช่การป้องกันเดียวของคุณ ### ฉันควรหยุดใช้ npm ทั้งหมดหรือไม่? ไม่ npm ยังคงเป็นระบบนิเวศแพ็คเกจที่ใหญ่ที่สุด และแพ็คเกจส่วนใหญ่ปลอดภัย เป้าหมายคือการลดความเสี่ยงของคุณผ่านการปักหมุดเวอร์ชันที่แน่นอน การบังคับใช้ lockfile การบล็อกสคริปต์ และการลดการพึ่งพา พิจารณาว่าการพึ่งพาแต่ละรายการจำเป็นหรือไม่ และใช้ทางเลือกเนทีฟเมื่อเป็นไปได้ ### Apidog ช่วยลดความเสี่ยงของซัพพลายเชน npm ได้อย่างไร? Apidog ให้ไคลเอนต์ HTTP ในตัว, test runner, เซิร์ฟเวอร์จำลอง และตัวสร้างเอกสารประกอบสำหรับการพัฒนา API สิ่งนี้ช่วยขจัดความจำเป็นในการใช้แพ็คเกจ npm เช่น Axios, node-fetch, Jest, Express (สำหรับ mocks) และการพึ่งพาการทดสอบอื่นๆ การพึ่งพา npm ที่น้อยลงหมายถึงเวกเตอร์การโจมตีน้อยลงในเวิร์กโฟลว์การพัฒนา API ของคุณ ### ที่มาของแพ็คเกจใน npm คืออะไร? ที่มาของแพ็คเกจใช้ Sigstore เพื่อเชื่อมโยงแพ็คเกจที่เผยแพร่กับ repository ต้นทางและสภาพแวดล้อมการสร้าง CI/CD โดยใช้การเข้ารหัส มันพิสูจน์ว่าแพ็คเกจถูกสร้างขึ้นที่ไหนและอย่างไร คุณสามารถตรวจสอบที่มาด้วย `npm audit signatures` แพ็คเกจที่เผยแพร่ด้วยตนเองจากเครื่องของนักพัฒนาจะขาดที่มา ซึ่งเป็นธงแดงสำหรับแพ็คเกจที่มีการดาวน์โหลดสูง ### มีแพ็คเกจ npm ที่เป็นอันตรายกี่แพ็คเกจ? Snyk ระบุแพ็คเกจ npm ที่เป็นอันตรายกว่า 3,000 รายการในปี 2024 ภายในไตรมาสที่ 4 ปี 2025 Sonatype บล็อกการโจมตีมัลแวร์ 120,612 ครั้งในไตรมาสเดียวทั่วทั้ง npm, PyPI และรีจิสทรีอื่นๆ จำนวนนี้กำลังเพิ่มขึ้น แพ็คเกจที่เป็นอันตรายส่วนใหญ่เป็น typosquats ที่มีการดาวน์โหลดต่ำ แต่การประนีประนอมที่มีชื่อเสียงเช่น Axios พิสูจน์ว่าแพ็คเกจยอดนิยมก็ไม่รอดพ้น ### ช่องโหว่ PackageGate คืออะไร? PackageGate คือชุดของช่องโหว่ zero-day หกรายการที่เปิดเผยในเดือนมกราคม 2026 ซึ่งส่งผลกระทบต่อ npm, pnpm, vlt และ Bun การค้นพบหนึ่งแสดงให้เห็นว่าการพึ่งพา Git-based สามารถมีไฟล์กำหนดค่าที่เปิดใช้งานการรันโค้ดได้แม้ในขณะที่สคริปต์วงจรชีวิตถูกปิดใช้งาน ซึ่งหมายความว่า `ignore-scripts` เพียงอย่างเดียวไม่เพียงพอหากการพึ่งพาของคุณอ้างอิง repository ของ Git ปักหมุดการพึ่งพา Git ไปยัง commit hashes ที่เฉพาะเจาะจง ## ประเด็นสำคัญ *   การบังคับใช้ Lockfile เป็นรากฐานของคุณ แต่จะไม่ป้องกันการติดตั้งครั้งแรกในช่วงเวลาที่ถูกโจมตี *   ปิดใช้งานสคริปต์ postinstall ทั่วโลกด้วย `ignore-scripts=true` ใน `.npmrc` *   ปักหมุดเวอร์ชันที่แน่นอนด้วย `save-exact=true` เพื่อป้องกันความประหลาดใจจากช่วง semver *   ตรวจสอบที่มาของแพ็คเกจด้วย `npm audit signatures` เพื่อตรวจจับการอัปโหลดด้วยตนเอง *   ใช้ Socket.dev (การวิเคราะห์พฤติกรรม) ร่วมกับ Snyk (ช่องโหว่ที่รู้จัก) และ `npm audit` (พื้นฐาน) *   ลดจำนวนการพึ่งพาของคุณโดยใช้ Node.js native APIs และแพลตฟอร์มแบบรวมเช่น Apidog *   ตรวจสอบการส่งออกเครือข่าย CI/CD ด้วย StepSecurity Harden-Runner ทุกการพึ่งพาคือการตัดสินใจเชื่อถือ ยิ่งคุณมีการพึ่งพาน้อยลง พื้นผิวการโจมตีของคุณก็จะเล็กลง ยิ่งคุณใช้การตรวจสอบหลายชั้นมากเท่าไร ผู้โจมตีก็จะยิ่งยากที่จะแทรกซึมได้มากขึ้น สร้างการป้องกันของคุณแบบหลายชั้น ไม่ใช่แบบแยกส่วน button