# Sigstore และ Cosign คืออะไร? คู่มือ Container Supply Chain Security สำหรับ SME ไทย 2026
ในปี 2024-2025 เกิดเหตุการณ์ supply chain attack หลายครั้งที่ส่งผลกระทบระดับโลก ตั้งแต่ SolarWinds, Codecov, xz-utils backdoor จนถึง npm package ที่ถูก compromise กระทบ developer ทั่วโลก คำถามสำคัญคือ "คุณรู้ได้อย่างไรว่า container image ที่คุณ pull มาใช้ จริง ๆ แล้วมาจากผู้สร้างที่ถูกต้อง ไม่ได้ถูกแก้ระหว่างทาง?"
คำตอบคือ Sigstore โครงการ open-source ภายใต้ Linux Foundation ที่ให้บริการ "เซ็นชื่อดิจิทัล" (digital signing) ฟรี สำหรับ container images, binaries, SBOMs และ software artifacts ทุกชนิด โดยไม่ต้องบริหารจัดการ private key เอง และ Cosign คือ command-line tool หลักของ Sigstore ที่ใช้ทำ signing/verification ในทางปฏิบัติ
คู่มือนี้จะพา SME ไทยที่ใช้ container (Docker, Kubernetes) เข้าใจตั้งแต่ concept ของ software supply chain security, วิธีใช้ Cosign ในทางปฏิบัติ, การ integrate กับ CI/CD pipeline และ policy engine สำหรับ production
ทำไม SME ต้องให้ความสำคัญกับ Supply Chain Security
Software supply chain คือลำดับของ component, code, และ infrastructure ที่ใช้สร้าง deploy และ run software ของคุณ การโจมตีสามารถเกิดที่ช่วงใดก็ได้
ตัวอย่างช่องโหว่ที่พบบ่อย:
ผลกระทบกับธุรกิจ:
มาตรฐานและกฎหมายใหม่เช่น US Executive Order 14028, EU Cyber Resilience Act (CRA), และ SLSA framework ก็กำหนดให้ต้องมีระบบ provenance และ signing สำหรับ software artifacts
Sigstore คืออะไร
Sigstore เป็น ecosystem ของ tools และ services ที่ทำให้การ sign/verify artifact ทำได้ง่ายเหมือนการใช้ HTTPS โดยประกอบด้วย 3 component หลัก
1. Fulcio - Certificate Authority ที่ออก short-lived certificate (10 นาที) โดย verify ตัวตนจาก OIDC provider เช่น Google, GitHub, Microsoft แทนที่จะให้คุณเก็บ private key ยาวนาน
2. Rekor - Transparency log ที่บันทึกทุกการ sign แบบ append-only เหมือน Certificate Transparency ของ TLS ทำให้ตรวจสอบย้อนหลังได้และตรวจจับ key compromise
3. Cosign - CLI tool สำหรับ sign/verify artifacts และ interact กับ OCI registry
แนวคิดสำคัญคือ keyless signing คุณไม่ต้องมี private key ของตัวเอง Cosign จะขอ certificate ชั่วคราวจาก Fulcio โดยพิสูจน์ตัวตนผ่าน OIDC ของ CI/CD หรือ workstation แล้วใช้ sign ภายในเวลาไม่กี่นาที หลังจากนั้น key ก็ถูกทิ้ง ไม่มีอะไรให้รั่วไหล
Cosign ใช้งานเบื้องต้น
ติดตั้ง Cosign
```bash
# macOS
brew install cosign
# Linux
curl -O -L "https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64"
sudo mv cosign-linux-amd64 /usr/local/bin/cosign
sudo chmod +x /usr/local/bin/cosign
cosign version
```
Sign container image แบบ keyless
```bash
# Push image ก่อน
docker push myregistry.io/myapp:v1.0.0
# Sign แบบ keyless - browser จะเปิดให้ login OIDC
cosign sign myregistry.io/myapp:v1.0.0
```
Verify image ก่อน deploy
```bash
cosign verify myregistry.io/myapp:v1.0.0 \
--certificate-identity "team@yourcompany.com" \
--certificate-oidc-issuer "https://accounts.google.com"
```
ถ้า image ถูกแก้ไขหลังจาก sign หรือ signer ไม่ใช่คนที่คุณ expect Cosign จะ error และ kubectl ก็จะไม่ deploy
การ Integrate กับ CI/CD
GitHub Actions
```yaml
name: Build and Sign
on: [push]
permissions:
id-token: write
packages: write
contents: read
jobs:
build-sign:
runs-on: ubuntu-latest
steps:
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
run: |
docker build -t ghcr.io/${{ github.repository }}:${{ github.sha }} .
docker push ghcr.io/${{ github.repository }}:${{ github.sha }}
run: cosign sign --yes ghcr.io/${{ github.repository }}:${{ github.sha }}
```
workflow identity ของ GitHub Actions จะถูก embed ใน certificate ทำให้ verify ย้อนกลับได้ว่า image นี้ถูก build จาก repo, branch, และ workflow ใด
Policy Enforcement ใน Kubernetes
การ sign image อย่างเดียวไม่พอ ต้องมี admission controller บังคับว่า "Kubernetes จะไม่ deploy image ที่ไม่ได้ sign หรือ sign ไม่ถูกต้อง" เครื่องมือที่ใช้ได้
Kyverno + Sigstore policy
```yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-image-signature
spec:
validationFailureAction: Enforce
rules:
match:
any:
kinds: [Pod]
verifyImages:
attestors:
subject: "https://github.com/mycompany/*/.github/workflows/build.yaml@refs/heads/main"
issuer: "https://token.actions.githubusercontent.com"
```
Policy นี้บังคับว่า Pod ที่ใช้ image จาก ghcr.io/mycompany/* ต้องถูก sign จาก GitHub Actions workflow ชื่อ build.yaml บน branch main เท่านั้น
เปรียบเทียบกับวิธีเดิม
| Feature | Manual GPG Keys | Notary v1 | Cosign + Sigstore |
|---------|-----------------|-----------|-------------------|
| Key management | ยุ่งยาก เสี่ยง leak | ต้องตั้ง server | ไม่ต้องเก็บ key |
| Rotation | Manual | Manual | Auto (10 min TTL) |
| Transparency log | ไม่มี | ไม่มี | Rekor มี |
| CI/CD integration | ยุ่งยาก | จำกัด | ง่ายมาก |
| Cost | ฟรี | Self-host | ฟรี (public infra) |
| Adoption | น้อย | ลดลง | เพิ่มเร็ว (Kubernetes, GitHub, npm) |
SBOM และ Attestation
นอกจาก sign image Cosign ยังใช้สร้าง attestation คือ metadata ที่ลงชื่อ เช่น SBOM (Software Bill of Materials), vulnerability scan result, build provenance
```bash
# สร้าง SBOM ด้วย syft
syft myregistry.io/myapp:v1.0.0 -o spdx-json > sbom.spdx.json
# Attach SBOM เข้ากับ image พร้อม sign
cosign attest --yes --predicate sbom.spdx.json \
--type spdxjson myregistry.io/myapp:v1.0.0
```
ทีม security สามารถ query ได้ว่าที่ image นี้ contain library อะไรบ้าง CVE กี่ตัว สร้างจาก commit ไหน เหมาะกับการ audit และ incident response
Roadmap สำหรับ SME: เริ่มต้นอย่างไร
เดือนที่ 1: Foundations
เดือนที่ 2-3: Verification
เดือนที่ 4-6: Enforcement
เดือนที่ 7+: Continuous Improvement
สรุป
Sigstore และ Cosign ทำให้ supply chain security ไม่ใช่เรื่องยากอีกต่อไป จากเดิมที่ต้องมีทีม security ขนาดใหญ่และ key management infrastructure แพง ตอนนี้ SME ไทยสามารถเริ่ม sign และ verify container image ได้ภายในไม่กี่ชั่วโมง ฟรี และเข้ากับ CI/CD ที่มีอยู่แล้ว
ในปี 2026 ลูกค้าองค์กรใหญ่ (B2B) จะเริ่มถามหา signed artifact และ SBOM เป็นเงื่อนไขการซื้อ การเริ่มก่อนจึงเป็น competitive advantage
ต้องการคำปรึกษาเรื่อง DevSecOps, container security, หรือการ implement SLSA framework สำหรับธุรกิจของคุณ? ADS FIT มีทีมผู้เชี่ยวชาญที่ออกแบบ pipeline ความปลอดภัยตามมาตรฐานสากล [ติดต่อเรา](/contact) หรือดูบทความ security อื่น ๆ ที่ [Blog ADS FIT](/blog)