Chuỗi cung ứng phần mềm

1. Lý thuyết cốt lõi / Core theory

1.1. Supply Chain Attack Case Studies (SolarWinds / Log4Shell / XZ Utils)

SolarWinds (2020): Kẻ tấn công (APT29/Cozy Bear) compromise build pipeline của SolarWinds → inject backdoor (SUNBURST) vào legitimate update của Orion platform → 18,000+ organizations install update → attacker có persistent access vào US government agencies và Fortune 500. Bài học: build environment security là critical; sign and verify artifacts; monitor for unexpected network connections từ trusted software. Log4Shell (CVE-2021-44228): zero-day trong Log4j 2 (Java logging library) được sử dụng bởi hàng trăm ngàn applications — JNDI injection cho phép RCE. Bài học: SBOM quan trọng vì organizations không biết họ đang dùng Log4j; SCA tools phải luôn chạy. XZ Utils backdoor (2024): attacker dành 2 năm xây dựng trust trong open-source project, cuối cùng inject backdoor vào release tarball (không trong git source). Bài học: verify tarball vs git source; reproducible builds; code signing không đủ nếu build process bị compromise.

1.2. SLSA Framework (Supply chain Levels for Software Artifacts)

SLSA (Google) — framework 4 levels để đảm bảo build provenance: L1 (Provenance exists): generate và publish provenance document (who built, what source, what build system); L2 (Hosted build, signed provenance): build trên hosted platform (GitHub Actions, Google Cloud Build), provenance signed bởi build service; L3 (Hardened build): build platform không cho phép user modify build process, provenance unforgeable; L4 (Two-party review): all changes reviewed bởi ≥2 parties, hermetic build (không access internet), reproducible. Mục tiêu thực tế: hầu hết projects bắt đầu với L1-L2; L3+ cho critical infrastructure.

1.3. SBOM — Software Bill of Materials (SPDX / CycloneDX)

SBOM là danh sách đầy đủ tất cả components trong phần mềm: libraries, frameworks, OS packages, licenses — tương tự "ingredient list" của thuốc. Bắt buộc bởi US Executive Order 14028 (2021) cho phần mềm bán cho US government. Hai format phổ biến: SPDX (Software Package Data Exchange — Linux Foundation, ISO standard), format: JSON/YAML/RDF/TV; CycloneDX (OWASP, XML/JSON) — phổ biến hơn trong AppSec community vì lightweight và tool ecosystem tốt. SBOM usage: khi Log4Shell xuất hiện, organizations có SBOM có thể query trong vòng phút để biết họ bị ảnh hưởng ở đâu; không có SBOM → mất days/weeks.

1.4. Code Signing & Package Security (Sigstore / cosign / Dependency Confusion)

Sigstore: open-source project (Google/Red Hat/Purdue) tạo ra keyless signing infrastructure cho OSS. cosign: tool để sign và verify container images: cosign sign myimage:latest → sign với OIDC identity; cosign verify myimage:latest → verify trước khi deploy. Rekor: transparency log (immutable) lưu tất cả signing events — có thể audit ai đã sign gì và khi nào. Dependency confusion attack prevention: publish internal package names lên public registry (với empty content hoặc placeholder) để "claim" the name; configure package manager để ưu tiên private registry; dùng namespace scope (@mycompany/package); verify package hashes trong lockfiles.

1.5. NIST SSDF & OSS Security (NIST SP 800-218 / OpenSSF)

NIST SSDF (Secure Software Development Framework, SP 800-218): 4 practice groups: Prepare the Organization (PO) — policies, roles, tooling; Protect the Software (PS) — protect source code, build, distribution; Produce Well-Secured Software (PW) — design, code, test; Respond to Vulnerabilities (RV) — identify, disclose, fix. OpenSSF (Open Source Security Foundation): scorecard tool để đánh giá OSS project security: CI/CD security, dependency management, branch protection, code review, signed releases. Dùng để evaluate OSS trước khi adopt: scorecard github.com/org/repo. OSS license compliance: GPL (copyleft — derivative work must be OSS), MIT/Apache (permissive), LGPL (library use OK). License scanner: FOSSA, TLDR Legal, licensee.

2. Bài thực hành / Hands-on labs

Lab 1 — SBOM Generation & Vulnerability Correlation (PowerShell)

OS: Windows 11 · Tool: PowerShell 7 + Microsoft SBOM Tool.

# Lab: Generate SBOM và phân tích dependencies
Write-Host "=== SBOM Generation & Analysis ===" -ForegroundColor Cyan

# Option 1: Microsoft SBOM Tool (dotnet global tool)
# Install: dotnet tool install -g Microsoft.Sbom.DotNetTool
if (Get-Command sbom-tool -ErrorAction SilentlyContinue) {
    Write-Host "Generating SBOM với Microsoft SBOM Tool..."
    sbom-tool generate -b . -bc . -pn "MyApplication" -pv "1.0.0" -ps "MyOrg" -nsb "https://myorg.com" 2>$null
    if (Test-Path "_manifest/spdx_2.2/manifest.spdx.json") {
        $sbom = Get-Content "_manifest/spdx_2.2/manifest.spdx.json" | ConvertFrom-Json
        Write-Host "SBOM generated: $($sbom.packages.Count) packages" -ForegroundColor Green
        $sbom.packages | Select-Object -First 10 name, versionInfo, licenseConcluded | Format-Table
    }
} else {
    Write-Host "sbom-tool not installed. Simulating SBOM analysis..." -ForegroundColor Yellow
}

# Simulate SBOM package list và vulnerability correlation
Write-Host "`n=== Dependency Vulnerability Check (simulation) ===" -ForegroundColor Yellow
$packages = @(
    [PSCustomObject]@{ Name="log4j-core";    Version="2.14.1"; CVE="CVE-2021-44228"; Severity="CRITICAL"; Fix="2.17.1" },
    [PSCustomObject]@{ Name="spring-core";   Version="5.3.15"; CVE="CVE-2022-22965"; Severity="CRITICAL"; Fix="5.3.18" },
    [PSCustomObject]@{ Name="jackson-databind"; Version="2.13.0"; CVE="None";        Severity="OK";       Fix="N/A"    },
    [PSCustomObject]@{ Name="commons-text";  Version="1.9";    CVE="CVE-2022-42889"; Severity="CRITICAL"; Fix="1.10.0" }
)

$packages | Format-Table Name, Version, CVE, Severity, Fix -AutoSize
$critical = $packages | Where-Object { $_.Severity -eq "CRITICAL" }
Write-Host "`nCritical vulnerabilities found: $($critical.Count)" -ForegroundColor Red
Write-Host "If this were Log4Shell scenario, SBOM let you find affected apps in minutes vs days." -ForegroundColor Cyan

Lab 2 — SBOM với Syft + Vulnerability Scan với Grype (Bash)

OS: Ubuntu 22.04 · Tool: Bash + Syft (SBOM generator) + Grype (vulnerability scanner).

# Cài Syft và Grype (Anchore tools)
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin 2>/dev/null || \
    echo "Syft: already installed or install manually from github.com/anchore/syft"

curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin 2>/dev/null || \
    echo "Grype: already installed or install manually from github.com/anchore/grype"

echo "=== Step 1: Generate SBOM with Syft ==="
# Generate SBOM từ current directory (Python project)
mkdir -p /tmp/supply-chain-demo
cat > /tmp/supply-chain-demo/requirements.txt << 'EOF'
flask==2.0.1
requests==2.25.1
pyyaml==5.3.1
cryptography==3.4.6
pillow==8.2.0
EOF

syft /tmp/supply-chain-demo/ -o cyclonedx-json 2>/dev/null | python3 -c "
import json, sys
try:
    bom = json.load(sys.stdin)
    comps = bom.get('components', [])
    print(f'Components in SBOM: {len(comps)}')
    for c in comps[:8]:
        print(f'  {c.get(\"name\",\"?\")} @ {c.get(\"version\",\"?\")} ({c.get(\"type\",\"?\")})')
except Exception as e:
    print(f'Syft output: {e}')
" 2>/dev/null

echo ""
echo "=== Step 2: Scan SBOM for Vulnerabilities with Grype ==="
# Grype scan filesystem
grype /tmp/supply-chain-demo/ 2>/dev/null | grep -E "Critical|High|NAME" | head -20 || \
    echo "Grype found: pyyaml 5.3.1 → CVE-2020-14343 (CRITICAL), pillow 8.2.0 → CVE-2021-25287 (HIGH)"

echo ""
echo "=== Step 3: pip-audit as alternative ==="
pip install pip-audit 2>/dev/null
pip-audit --requirement /tmp/supply-chain-demo/requirements.txt 2>/dev/null | head -20 || \
    pip-audit -r /tmp/supply-chain-demo/requirements.txt 2>/dev/null

3. Tình huống doanh nghiệp / Real-world scenario

4. Tự kiểm tra / Knowledge check

1. Dependency confusion attack hoạt động như thế nào? Cách ngăn chặn cụ thể trong npm và pip?
2. SLSA Level 2 yêu cầu gì khác so với Level 1? Tại sao signed provenance quan trọng?
3. SBOM có hai format chính là gì? Format nào phổ biến hơn trong AppSec và tại sao?
4. XZ Utils backdoor 2024 dạy chúng ta bài học gì về "releasing from tarball vs git"?
5. NIST SSDF có mấy practice groups? Nhóm nào liên quan đến vulnerability response?