Supply chain নিরাপত্তা — dependency, SBOM, signing আর SLSA

১ · Supply chain কী — আপনার কোডের পেছনের লম্বা শিকল

একটি বিরিয়ানির দোকানের কথা ভাবুন। বাবুর্চি নিজে হাতে রান্না করেন, রান্নাঘর ঝকঝকে। কিন্তু চাল আসে আড়ত থেকে, মসলা আসে বাজার থেকে, মাংস আসে কসাইয়ের কাছ থেকে, আর খাবার পৌঁছায় ডেলিভারির ছেলের হাতে। এর যেকোনো এক জায়গায় ভেজাল ঢুকলে খারাপ খাবারের দায় পড়ে দোকানের নামে। ক্রেতা তো আড়তদারকে চেনেন না।

Software supply chain ঠিক এই পথ। আপনি হয়তো দুই হাজার লাইন কোড লিখেছেন, কিন্তু আপনার পণ্য চলে হাজার হাজার dependency-র লাখো লাইনের ওপর। সেগুলো এসেছে অচেনা মানুষের কাছ থেকে, চলেছে আপনার build মেশিনে, আর পৌঁছেছে আপনার গ্রাহকের কাছে। Supply chain attack মানে সরাসরি আপনাকে না ধরে এই পথের কোনো বিশ্বস্ত জোড়াকে ধরা। OWASP Top 10:2025-এ Software Supply Chain Failures তৃতীয় স্থানে আছে।

শিকলের পাঁচটি জোড়া মনে রাখুন। Source হলো আপনার repository. Dependency হলো বাইরে থেকে আসা package, যা আসে package registry থেকে। Build হলো CI/CD pipeline, যা কোড থেকে পণ্য বানায়। Artifact হলো সেই তৈরি পণ্য: package, container image বা binary. Deploy হলো সেটি production-এ বসানো আর update পৌঁছে দেওয়া।

কেন এই পথটি রক্ষকের জন্য কঠিন? পর্ব ৪-এর ভাষায়, প্রতিটি dependency একটি trust boundary পেরিয়ে আসে, অথচ চলে আপনার কোডের সমান অধিকারে। আপনার সার্ভারে বসা একটি ছোট date library-ও একই process-এ চলে, একই secret পড়তে পারে। আর সংখ্যার হিসাবটিও সরল। ধরি প্রতিটি package-এর বছরে আপস হওয়ার সম্ভাবনা ০.১% (অনুমিত সংখ্যা, মাপা তথ্য নয়), আর ঘটনাগুলো স্বাধীন। তাহলে অন্তত একটি আপসের সম্ভাবনা ১ − (১ − p)ⁿ:

বাস্তবে সম্ভাবনা সব package-এ সমান নয়, ঘটনাগুলো স্বাধীনও নয়। তবু চেহারাটি সত্য: dependency-র সংখ্যা attack surface-এর অংশ।

২ · আপসের পাঁচটি পথ — শিকল কোথায় ভাঙে

এখানে শুধু ধারণা। হামলাকারীর দৃষ্টিতে “কেন কাজ করে”, আর রক্ষকের দৃষ্টিতে “কীভাবে থামে আর কীভাবে ধরা পড়ে”। এর বাইরের কোনো ধাপ এই কোর্সে নেই।

Dependency confusion-এর ধারণাটি ২০২১ সালে একজন গবেষকের প্রকাশিত কাজের পর ব্যাপকভাবে আলোচনায় আসে। রোগটি নকশার: প্রাইভেট আর public দুটোই দেখা, তারপর যেটির version বড় সেটি নেওয়ার মতো আচরণ। ওষুধের দোকানে মালিকের নিয়ম হলো, হাসপাতালের স্টোর আর বাইরের পাইকার দুই জায়গাতেই খুঁজে যেটি নতুন সেটিই আনতে হবে। ভুল জিনিস ঢোকার রাস্তা এখানেই। সমাধানও নকশার: উৎস একটি, আর নামের মালিকানা স্পষ্ট।

Typosquatting ধরার একটি সরল উপায় edit distance: একটি নামকে আরেকটিতে বদলাতে কম করে কয়টি অক্ষর-বদল লাগে। fast-json থেকে fast-jsno হয় শেষের দুই অক্ষর অদলবদল করে। পাশাপাশি দুই অক্ষরের অদলবদলকে ১ ধরলে দূরত্ব ১. সাধারণ Levenshtein হিসাবে এটি ২, কারণ দুটি অক্ষরই বদলাতে হয়। নিচের কোড একটি রক্ষকের intake যাচাই: কেউ নতুন package চাইলে আগে এই দরজা পেরোতে হয়। সব নাম কাল্পনিক, কোনো registry-তে অনুরোধ যায় না।

// Defender's intake check on fictional names. No registry is contacted.
const approved = ['fast-json', 'date-lite', 'web-router', 'http-client'];
const requests = [
  { name: 'fast-json',   ageDays: 2900 },
  { name: 'fast-jsno',   ageDays: 3 },
  { name: 'fastjson',    ageDays: 12 },
  { name: 'web-rooter',  ageDays: 40 },
  { name: 'date-time',   ageDays: 3100 },
  { name: 'image-resize', ageDays: 1500 },
];
// Edit distance: insert, delete, replace, or swap two neighbours = 1 edit.
function dist(a, b) {
  const d = Array.from({ length: a.length + 1 }, (_, i) => [i]);
  for (let j = 0; j <= b.length; j++) d[0][j] = j;
  for (let i = 1; i <= a.length; i++) for (let j = 1; j <= b.length; j++) {
    const cost = a[i - 1] === b[j - 1] ? 0 : 1;
    d[i][j] = Math.min(d[i - 1][j] + 1, d[i][j - 1] + 1, d[i - 1][j - 1] + cost);
    if (i > 1 && j > 1 && a[i - 1] === b[j - 2] && a[i - 2] === b[j - 1])
      d[i][j] = Math.min(d[i][j], d[i - 2][j - 2] + 1);
  }
  return d[a.length][b.length];
}
const norm = s => s.replace(/[-_.]/g, '');
for (const r of requests) {
  if (approved.includes(r.name)) { console.log(`${r.name.padEnd(13)} APPROVED`); continue; }
  const near = approved.map(p => ({ p, e: Math.min(dist(r.name, p), dist(norm(r.name), norm(p))) }))
    .sort((x, y) => x.e - y.e)[0];
  let verdict = 'NEW: normal review';
  if (near.e <= 2) verdict = r.ageDays < 90 ? 'HOLD: human must check' : 'CHECK: old but similar';
  console.log(`${r.name.padEnd(13)} near ${near.p} edits=${near.e} age=${r.ageDays}d -> ${verdict}`);
}

fast-json     APPROVED
fast-jsno     near fast-json edits=1 age=3d -> HOLD: human must check
fastjson      near fast-json edits=0 age=12d -> HOLD: human must check
web-rooter    near web-router edits=1 age=40d -> HOLD: human must check
date-time     near date-lite edits=2 age=3100d -> CHECK: old but similar
image-resize  near date-lite edits=7 age=1500d -> NEW: normal review

৩ · প্রকাশিত পাঁচ ঘটনা আর তাদের শিক্ষা

নিচের তথ্য প্রকাশিত প্রতিবেদন আর advisory-র স্তরে। কে করেছে সেটি এখানে প্রশ্ন নয়, কারও নামও নেই। প্রশ্ন একটিই: কোন বাধা থাকলে ক্ষতি কমত?

ঘটনাগুলো একসাথে একটি নকশা দেখায়। SolarWinds আর xz-এ স্বাক্ষর বা hash যাচাই পাস করত, কারণ ক্ষতিকর অংশ আগেই ঢুকেছিল। Log4Shell-এ দরকার ছিল inventory আর দ্রুত patch. event-stream-এ দরকার ছিল সতর্ক update. অর্থাৎ কোনো একটি tool পাঁচটি ঘটনার সবকটি থামায় না। এখান থেকে একটি টানাপোড়েনও আসে: Log4Shell বলে দ্রুত update করুন, event-stream বলে ধীরে update করুন। এর সমাধান পরের অংশে।

৪ · Dependency-র পরিচ্ছন্নতা — lockfile, hash আর registry

রান্নাঘরের নিয়ম সহজ: চেনা আড়ত থেকে কিনুন, রসিদ রাখুন, প্রতিটি বস্তার সিল মিলিয়ে নিন, আর যা লাগে না তা কিনবেন না। Dependency-র নিয়মও এমন।

একটি lockfile দেখতে কেমন? npm-এর package-lock.json-এ প্রতিটি package-এর integrity মান থাকে, যা SRI-র মতো একটি hash (পর্ব ৪৪)। Python-এ pip-এর hash-checking mode প্রতিটি package-এ hash চায়। go.sum আর Cargo.lock-ও একই কাজ করে। নিচে দুটি উদাহরণ, মান কাল্পনিক:

# সব package একটি নিয়ন্ত্রিত proxy দিয়ে আসবে
registry=https://npm.internal.example/
# @shop scope-এর package শুধু ভেতরের registry-তে খোঁজা হবে
@shop:registry=https://npm.internal.example/
# Package বসানোর সময় script চলবে না (কিছু native package-এ আলাদা ছাড় লাগতে পারে)
ignore-scripts=true

# চালান: pip install --require-hashes -r requirements.txt
date-lite==2.1.4 \
    --hash=sha256:<64-hex-digest-from-your-lock-tool>
# একাধিক index মেশানো এড়িয়ে চলুন; --index-url একটিই রাখুন

নিচের Python কোড সত্যিকারের SHA-256 দিয়ে lock যাচাই করে, তবে bytes নকল আর মেমরির ভেতরে। একটি package-এ এক byte বদলানো হয়েছে, একটি lockfile-এ নেই। আর একটি package ইচ্ছা করে রাখা হয়েছে, যার খারাপ কোড lock করার সময়ই ছিল।

# Real SHA-256 on fake artifact bytes held in memory. Nothing is downloaded.
import hashlib

def sha256(data):
    return hashlib.sha256(data).hexdigest()

# Bytes the team reviewed and locked earlier.
reviewed = {
    "date-lite-2.1.4.tgz": b"fake package bytes: date-lite 2.1.4\n",
    "fast-json-3.4.0.tgz": b"fake package bytes: fast-json 3.4.0\n",
    "web-router-1.9.2.tgz": b"fake package bytes: web-router 1.9.2 (bad code nobody noticed)\n",
}
lock = {name: sha256(data) for name, data in reviewed.items()}

# Bytes the mirror serves today. One changed byte, one extra file.
served = dict(reviewed)
served["fast-json-3.4.0.tgz"] = b"fake package bytes: fast-json 3.4.0!\n"
served["left-util-1.0.0.tgz"] = b"fake package bytes: left-util 1.0.0\n"

failed = 0
for name, data in sorted(served.items()):
    got = sha256(data)
    want = lock.get(name)
    if want is None:
        status = "REJECT: not in lockfile"
    elif got != want:
        status = "REJECT: hash mismatch"
    else:
        status = "ok"
    failed += status != "ok"
    print(f"{name:22} {got[:16]}  {status}")
    if want and got != want:
        print(f"{'':22} {want[:16]}  (expected)")
print(f"failed={failed} of {len(served)}; install {'stopped' if failed else 'continues'}")

date-lite-2.1.4.tgz    cd2498d8c8da7d0a  ok
fast-json-3.4.0.tgz    5b5d866291310754  REJECT: hash mismatch
                       49e9f60e4e4c645d  (expected)
left-util-1.0.0.tgz    0e22845eb6c53d89  REJECT: not in lockfile
web-router-1.9.2.tgz   adfe0a70b7943d9e  ok
failed=2 of 4; install stopped

দ্রুত, না ধীরে? Update-এর টানাপোড়েন

নিয়মটি দুই ভাগে ভাগ করুন। সাধারণ update ধীরে আসুক: update bot pull request খুলবে, test চলবে, মানুষ দেখবে। কিছু tool-এ নতুন release নেওয়ার আগে কয়েক দিন অপেক্ষার setting আছে, যাকে এখানে release cooldown বলছি। অনেক ক্ষতিকর release প্রকাশের অল্প সময়ের মধ্যে ধরা পড়ে বলে প্রকাশিত ঘটনায় দেখা গেছে, তাই এই অপেক্ষা কাজের। নিরাপত্তা update আলাদা পথে আসুক: KEV বা নিশ্চিত reachable দুর্বলতায় cooldown বাদ, দ্রুত review, দ্রুত ধাপে ধাপে rollout. Bot-কে production-এ সরাসরি auto-merge করতে না দেওয়াই ভালো। নীতি লিখে রাখুন, যাতে সংকটের দিনে তর্ক করতে না হয়।

নতুন dependency নেওয়ার আগে নিজেকে জিজ্ঞেস করুন: এটি কি দশ লাইনে নিজে লেখা যায়? কতজন রক্ষণাবেক্ষণ করেন? শেষ release কবে? এটি কতগুলো transitive dependency আনে? install script আছে কি? OpenSSF Scorecard এখানে কাজে লাগে। এটি একটি open source project-এর branch protection, code review, pinned dependency, token permission, signed release ইত্যাদি স্বয়ংক্রিয়ভাবে দেখে ০ থেকে ১০ নম্বর দেয়। নম্বর অভ্যাসের ইঙ্গিত, নিরাপত্তার প্রমাণ নয়। কম নম্বর মানে আরও প্রশ্ন, বেশি নম্বর মানে পরীক্ষা বাদ নয়।

এবার একটি package-কে registry থেকে production পর্যন্ত অনুসরণ করুন। “পরে” চাপুন, আর প্রতিটি ধাপে কোন যাচাই হচ্ছে দেখুন। সব মান কাল্পনিক।

package    date-lite 2.1.4
published  41 days ago
maintainers 3
install script: none

name similarity  exact match on approved list
known advisories 0
scorecard (toy)  7.4 / 10
proxy copy       stored in npm.internal.example
decision: allowed

+ date-lite 2.1.4
+ integrity sha512-<example-value>
new transitive packages: 0
reviewer: approved

npm ci --ignore-scripts   integrity ok
tests                     212 passed
SCA findings              0 reachable
SBOM                      generated

image   shop-api@sha256:64f28b2e...
sign    short-lived certificate
log     transparency log entry saved
attach  provenance + SBOM

signature          valid
builder identity   expected workflow
source             example/shop-api v1.4.2
decision: deploy to 5% first

৫ · SCA আর transitive ঝুঁকি — কোনটি আসলে আপনাকে ছোঁয়

SCA (Software Composition Analysis) tool আপনার lockfile পড়ে, আর প্রতিটি package-কে advisory তালিকার সাথে মেলায়। উদাহরণ হিসেবে npm audit, pip-audit, OSV-Scanner, OWASP Dependency-Check, Trivy বা Grype-এর নাম করা যায়। এটি অনেকটা গ্রাহকের তালিকা নিয়ে ব্যাংকের কালো তালিকা মেলানোর মতো। একটি সীমা শুরুতেই মনে রাখুন: SCA জানা সমস্যা খোঁজে। নতুন ক্ষতিকর package, আর কপি করে বসানো কোড সে ধরতে নাও পারে।

আসল ঝুঁকি থাকে গভীরে। আপনি ৩টি package যোগ করেছেন, সেগুলো আরও অনেক এনেছে। Advisory এলে দুটি প্রশ্ন: এটি আমার সিস্টেমে কোন পথে এসেছে? আর দুর্বল function কি আমি ডাকছি? দ্বিতীয় প্রশ্নের নাম reachability. নিচের walker একটি খেলনা lockfile ঘুরে এই উত্তর বের করে।

// Toy lockfile and toy advisory. All names and ids are fictional.
const lock = {
  'shop-api@1.0.0':   ['web-router@1.9.2', 'report-kit@4.0.1', 'date-lite@2.1.4'],
  'web-router@1.9.2': ['path-match@0.8.0'],
  'report-kit@4.0.1': ['pdf-make@2.2.0', 'date-lite@2.1.4'],
  'pdf-make@2.2.0':   ['xml-lite@1.2.0'],
  'date-lite@2.1.4':  [],
  'path-match@0.8.0': ['report-kit@4.0.1'],   // second road to report-kit
  'xml-lite@1.2.0':   [],
};
const advisory = { id: 'TOY-2026-0042', pkg: 'xml-lite', bad: ['1.2.0'], func: 'parseEntity' };
const appCalls = { 'xml-lite': ['parseText'] };   // toy call graph
const root = 'shop-api@1.0.0';
const paths = [], seen = new Set();
function walk(node, path) {
  if (path.includes(node)) return;             // never loop forever on a cycle
  const next = [...path, node];
  seen.add(node);
  const [name, ver] = node.split('@');
  if (name === advisory.pkg && advisory.bad.includes(ver)) paths.push(next);
  for (const dep of lock[node] || []) walk(dep, next);
}
walk(root, []);
const direct = lock[root].length, total = seen.size - 1;
console.log(`packages: ${total} (direct ${direct}, transitive ${total - direct})`);
console.log(`${advisory.id} in ${advisory.pkg}: ${paths.length} path(s)`);
for (const p of paths) console.log(`  depth ${p.length - 1}: ` + p.map(x => x.split('@')[0]).join(' > '));
const inManifest = lock[root].some(d => d.startsWith(advisory.pkg + '@'));
console.log('listed in your manifest:', inManifest);
const reach = (appCalls[advisory.pkg] || []).includes(advisory.func);
console.log(`${advisory.func} called by app:`, reach);
console.log('priority:', paths.length && reach ? 'fix now' : paths.length ? 'plan fix, record reason' : 'none');

packages: 6 (direct 3, transitive 3)
TOY-2026-0042 in xml-lite: 2 path(s)
  depth 5: shop-api > web-router > path-match > report-kit > pdf-make > xml-lite
  depth 3: shop-api > report-kit > pdf-make > xml-lite
listed in your manifest: false
parseEntity called by app: false
priority: plan fix, record reason

এবার অগ্রাধিকারের হিসাব। ধরি একটি service-এ SCA ১২০টি finding দিল, আর প্রতিটি যাচাইয়ে ৩০ মিনিট লাগে (অনুমিত সংখ্যা)। সব দেখতে ১২০ × ০.৫ = ৬০ ঘণ্টা। Reachability আর পর্ব ৩২-এর EPSS ও KEV দিয়ে ছেঁকে ১৫টি থাকলে ৭.৫ ঘণ্টা। সাশ্রয় ৮৭.৫%. বাকি ১০৫টি মুছে যায় না, পরের নিয়মিত update-এ সারে। Transitive package সরাসরি update করা না গেলে npm-এর overrides বা Yarn-এর resolutions-এর মতো ব্যবস্থায় version বদলানো যায়, তবে তা test করে আর লিখে রেখে করুন।

৬ · SBOM আর VEX — উপকরণের তালিকা আর তার ব্যাখ্যা

বিস্কুটের প্যাকেটের গায়ে উপাদানের তালিকা থাকে। কোনো উপাদানে সমস্যা পাওয়া গেলে আপনি প্যাকেট পড়েই জানবেন এটি আপনার ঘরে আছে কি না। SBOM (Software Bill of Materials) software-এর সেই তালিকা। Log4Shell-এর সময় যাঁদের তালিকা ছিল, তাঁরা অনুসন্ধান চালিয়েই উত্তর পেয়েছিলেন। যাঁদের ছিল না, তাঁরা সার্ভার ধরে ধরে খুঁজেছেন।

SBOM কখন বানাবেন? সবচেয়ে কাজের সময় build-এর মধ্যে, lockfile আর তৈরি artifact দেখে। Syft বা CycloneDX-এর নিজস্ব tool এমন কাজ করে। নিচে কিছু নিয়ম, যা পরে অনেক ঝামেলা বাঁচায়। প্রতিটি release-এর জন্য আলাদা SBOM রাখুন, আর artifact-এর সাথে স্বাক্ষরসহ যুক্ত করুন। হাতে লেখা SBOM দ্রুত পুরোনো হয়। Package চেনাতে purl ব্যবহার করুন। SBOM যাচাই করুন, কারণ tool base image বা copy-করা ফাইল বাদ দিতে পারে। আর SBOM একটি index-এ রাখুন, যাতে “এই package কোন কোন service-এ আছে” এক প্রশ্নেই জানা যায়। আমেরিকার NTIA ২০২১ সালে SBOM-এর ন্যূনতম উপাদানের একটি তালিকা প্রকাশ করে, CISA জুলাই ২০২৬-এ তার হালনাগাদ রূপ আনে, আর ইউরোপের Cyber Resilience Act-ও পণ্য-নির্মাতাদের জন্য SBOM-এর বাধ্যবাধকতা আনছে। এই আইনগুলো ধাপে ধাপে কার্যকর হচ্ছে, তাই আপনার ক্ষেত্রে কী প্রযোজ্য তা বর্তমান পাঠ্য দেখে নিন।

SBOM-এর পাশে একটি সমস্যা আছে। Scanner SBOM দেখে বলবে “এখানে একটি দুর্বল library আছে”। কিন্তু হয়তো দুর্বল অংশটি আপনার পণ্যে চলেই না। VEX (Vulnerability Exploitability eXchange) সেই ব্যাখ্যা। এতে চারটি অবস্থা থাকে: not_affected, affected, fixed আর under_investigation. not_affected লিখলে কারণও দিতে হয়, যেমন দুর্বল কোড চলার পথে নেই। CISA-র ন্যূনতম প্রয়োজনের নথি (২০২৩) এই কাঠামোই বলে। VEX হলো ডাক্তারের লেখা নোট: “রিপোর্টে এটি লাল দেখালেও এই রোগীর ক্ষেত্রে সমস্যা নয়, কারণ…”।

// Minimal SBOM + VEX filter on toy data. Clock is fixed; names are fictional.
const lock = [
  ['web-router', '1.9.2'], ['date-lite', '2.1.4'], ['xml-lite', '1.2.0'], ['fast-json', '3.4.1'],
];
const sbom = {
  bomFormat: 'CycloneDX', specVersion: '1.6', version: 1,
  metadata: { timestamp: '2026-10-31T00:00:00Z', component: { name: 'shop-api', version: '1.0.0' } },
  components: lock.map(([name, version]) =>
    ({ type: 'library', name, version, purl: `pkg:npm/${name}@${version}` })),
};
console.log('SBOM components:', sbom.components.map(c => c.purl).join(' '));

const advisories = [   // a scanner matched these against the SBOM
  { id: 'TOY-2026-0042', purl: 'pkg:npm/xml-lite@1.2.0', sev: 'high' },
  { id: 'TOY-2026-0077', purl: 'pkg:npm/fast-json@3.4.1', sev: 'critical' },
  { id: 'TOY-2026-0090', purl: 'pkg:npm/date-lite@2.1.4', sev: 'medium' },
  { id: 'TOY-2026-0101', purl: 'pkg:npm/old-cache@0.1.0', sev: 'high' },
];
const vex = {   // statements written by the team that owns shop-api
  'TOY-2026-0042': { status: 'not_affected', justification: 'vulnerable_code_not_in_execute_path' },
  'TOY-2026-0090': { status: 'under_investigation' },
};
const inSbom = new Set(sbom.components.map(c => c.purl));
const rows = advisories.filter(a => inSbom.has(a.purl))
  .map(a => ({ ...a, status: (vex[a.id] || { status: 'affected' }).status,
    why: (vex[a.id] || {}).justification || '-' }));
for (const r of rows) console.log(`${r.id} ${r.sev.padEnd(8)} ${r.status.padEnd(19)} ${r.why}`);
const act = rows.filter(r => r.status !== 'not_affected');
console.log(`matched ${rows.length} of ${advisories.length}; action queue: ${act.length}`);
console.log('queue:', act.map(r => r.id).join(', '));

SBOM components: pkg:npm/web-router@1.9.2 pkg:npm/date-lite@2.1.4 pkg:npm/xml-lite@1.2.0 pkg:npm/fast-json@3.4.1
TOY-2026-0042 high     not_affected        vulnerable_code_not_in_execute_path
TOY-2026-0077 critical affected            -
TOY-2026-0090 medium   under_investigation -
matched 3 of 4; action queue: 2
queue: TOY-2026-0077, TOY-2026-0090

৭ · Signing আর provenance — কে বানাল, কীভাবে বানাল

পর্ব ১১-এ দেখেছেন, digital signature প্রমাণ করে কোন private key দিয়ে স্বাক্ষর হয়েছে, আর ফাইল তারপর বদলায়নি। পোস্ট অফিসের সিলমোহরের মতো। Code signing-এর পুরোনো সমস্যা ছিল key: দীর্ঘদিন রাখতে হয়, চুরি হতে পারে, আর ছোট project-এ সামলানো কঠিন।

Sigstore এই সমস্যার একটি উত্তর, যা OpenSSF-এর অধীনে চলে। মূল অংশ তিনটি। Fulcio একটি certificate authority, যা OIDC login-এর পরিচয় দেখে প্রায় ১০ মিনিটের short-lived certificate দেয়। Rekor একটি transparency log, পর্ব ১২-এর Certificate Transparency-র মতো শুধু যোগ করার খাতা। আর cosign স্বাক্ষর ও যাচাইয়ের tool. একে keyless signing বলে, যদিও key থাকে: কাজের সময় তৈরি হয়, কাজ শেষে ফেলে দেওয়া হয়। Certificate-এর মেয়াদ পেরিয়ে গেলেও স্বাক্ষর যাচাই করা যায়, কারণ log প্রমাণ করে স্বাক্ষরটি মেয়াদের ভেতরেই হয়েছিল।

Provenance আরেক ধাপ এগোয়। স্বাক্ষর বলে “কে”। Provenance বলে “কীভাবে”: কোন repository, কোন commit, কোন build system, কোন build-এর নির্দেশ। এটি একটি build attestation, সাধারণত in-toto ফরম্যাটে, ঠিক ওষুধের প্যাকেটের ব্যাচ নম্বরের মতো: কোন কারখানা, কোন তারিখ, কোন উপাদান। npm আর PyPI-র মতো কিছু registry এখন package-এর সাথে provenance বা trusted publishing-এর সুবিধা দেয়।

নিচের ধাপগুলো একটি artifact-এর পূর্ণ যাচাই। Digest দুটি আসল SHA-256, নকল bytes-এর ওপর আমাদের চালানো। সময় আর পরিচয় কাল্পনিক।

নিজের artifact-এ যাচাই দেখতে এমন হয়। এই command-গুলো আমরা চালাইনি, তাই নিচের ফলটি নমুনা। Tool-এর version অনুযায়ী flag বদলাতে পারে, ব্যবহারের আগে official docs দেখুন।

# নিজের image: tag নয়, digest দিয়ে
cosign verify registry.example.com/shop/api@sha256:<digest> \
  --certificate-identity https://ci.example.com/shop/api/release.yml@refs/tags/v1.4.2 \
  --certificate-oidc-issuer https://ci.example.com

# নিজের release ফাইলের provenance
slsa-verifier verify-artifact shop-api-1.4.2.tgz \
  --provenance-path shop-api.intoto.jsonl \
  --source-uri github.com/example/shop-api \
  --source-tag v1.4.2

নমুনা আউটপুট — version-ভেদে আলাদা হতে পারে
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority certificates

৮ · SLSA আর build শক্ত করা

SLSA (উচ্চারণ “সালসা”, Supply-chain Levels for Software Artifacts) একটি ধাপে ধাপে উন্নতির কাঠামো, এখন OpenSSF-এর অধীনে। ২০২৬ সালের অক্টোবরে slsa.dev-এ অনুমোদিত সংস্করণ v1.2. এতে দুটি track: Build আর Source. Source track অনুমোদিত অংশ হিসেবে যুক্ত হয়েছে v1.2-তে। পুরোনো লেখায় L4 পর্যন্ত এক সিঁড়ি দেখলে বুঝবেন সেটি v0.1-এর কথা। v1.0-তে কাঠামো বদলেছে।

Source track: L1 version control, L2 ইতিহাস রক্ষা আর source provenance, L3 ধারাবাহিক technical control, L4 দুইজনের review. Git নিরাপত্তা আর code review-এর পর্বগুলো এই কাজের ভিত্তি।

Build pipeline শক্ত করার নিয়ম

Build মেশিন কারখানার মতো: এখানে যা ঢোকে, তাতেই আপনার সিল পড়ে। গভীর আলোচনা আছে DevSecOps আর container registry-র পর্বে। এখানে নিরাপত্তার মূল নিয়মগুলো:

• Ephemeral runner: প্রতিটি job নতুন মেশিনে, কাজ শেষে মুছে যায়, তাই আগের job-এর কিছু টিকে থাকে না
• Token-এ least privilege: ডিফল্ট শুধু read, দরকারি job-এ আলাদা করে বেশি অধিকার
• দীর্ঘদিনের secret নয়: Workload identity দিয়ে স্বল্পায়ু credential (secret আর KMS)
• Pinned action: বাইরের step পূর্ণ commit hash দিয়ে বাঁধা, tag দিয়ে নয়
• Test আর release আলাদা job: বাইরের pull request-এর কোড secret দেখতে পায় না
• Runner-এর egress সীমিত: শুধু proxy আর দরকারি গন্তব্য
• Workflow ফাইল বদলাতে review লাগে: pipeline নিজেও কোড

Pinned action কেন? Tag একটি নামফলক, যা নতুন commit-এর দিকে সরানো যায়। ২০২৫ সালের মার্চে tj-actions/changed-files নামের একটি জনপ্রিয় GitHub Action-এর আপসে এমন tag সরানোর প্রতিবেদন আসে, আর build log-এ secret উন্মুক্ত হওয়ার ঝুঁকি দেখা দেয়। CISA এটি নিয়ে সতর্কবার্তা দেয় (CVE-2025-30066). Commit hash বদলানো যায় না, তাই পূর্ণ hash-এ বাঁধা থাকলে সেই সরানো আপনাকে ছোঁয় না। নিচে একটি GitHub Actions-এর উদাহরণ। ধারণাটি অন্য CI-তেও একই।

# উদাহরণ: হ্যাশটি নিজের যাচাই করা commit থেকে নিন
permissions:
  contents: read          # ডিফল্ট: শুধু পড়া

jobs:
  build:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
      id-token: write     # শুধু keyless signing-এর পরিচয়ের জন্য
    steps:
      - uses: actions/checkout@<full-40-char-commit-sha>  # v4
        with:
          persist-credentials: false
      - run: npm ci --ignore-scripts
      - run: npm test

Hash-এ বাঁধলে একটি দাম আছে: নিজে থেকে update আসে না। তাই update bot দিয়ে hash আপডেট করুন, যাতে নিরাপত্তা-সংশোধনও পৌঁছায়। একই যুক্তি container image-এ: :latest নয়, @sha256:…. Reproducible build সবচেয়ে শক্ত যাচাই: দুটি আলাদা build ব্যবস্থায় একই bit এলে একটি ব্যবস্থার আপস ধরা পড়ে। এটি কঠিন, তবে Debian-এর মতো কিছু project এই পথে অনেক দূর এগিয়েছে।

৯ · Vendor software, standard আর আপস হলে কী করবেন

কেনা software-ও শিকলের অংশ

SolarWinds ছিল কেনা পণ্য, npm package নয়। কেনা software-এর ক্ষেত্রে আপনি lockfile দেখতে পান না, তাই প্রশ্ন করেই জানতে হয়। পূর্ণ প্রক্রিয়া আসবে পর্ব ৭১-এ। Intake-এর জন্য ছোট তালিকাটি এমন:

দুটি NIST নথি এখানে চিনে রাখুন। NIST SP 800-161 Rev. 1 (২০২২, ২০২৪ সালে হালনাগাদ) হলো প্রতিষ্ঠানের স্তরের C-SCRM নির্দেশিকা: সরবরাহকারী বাছাই, চুক্তি, পর্যবেক্ষণ। SSDF, NIST SP 800-218 (v1.1, ২০২২) নির্মাতার দিকের নির্দেশিকা, চারটি দলে: প্রতিষ্ঠান প্রস্তুত করা (PO), software রক্ষা করা (PS), ভালোভাবে নিরাপদ software তৈরি (PW), আর দুর্বলতায় সাড়া দেওয়া (RV). ২০২৫ সালের ডিসেম্বরে v1.2-এর একটি খসড়া (Rev. 1) প্রকাশিত হয়। নভেম্বর ২০২৬-এর শুরুতেও NIST-এর পাতায় এটি খসড়া, তাই চালু সংস্করণ v1.1. সর্বশেষ অবস্থা সেখানে দেখে নিন।

একটি dependency আপস হলে

ঘটনা ঘটলে মনে রাখুন, প্রশ্ন শুধু “কোন version” নয়। Install-এর সময় কোড চলতে পারে, তাই build মেশিন আর তার secret-ও ঝুঁকিতে পড়তে পারে। নিচে একটি কাল্পনিক সকাল। বড় কাঠামো আছে পর্ব ৬১ আর পর্ব ৬২-এ, আর incident management-এ।

Detection আগে থেকে সাজিয়ে রাখুন। ভালো সংকেত হলো: একই version-এর hash বদলানো, review ছাড়া lockfile বদলানো, অচেনা install script, স্বাক্ষরহীন image-এর deploy চেষ্টা, আর build runner থেকে অচেনা গন্তব্যে সংযোগ। শেষটির একটি Sigma-ধাঁচের উদাহরণ (কেন্দ্রীয় log থাকতে হবে, বিস্তারিত পর্ব ৫৬-এ):

title: Build runner connects to an unapproved host
status: experimental
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    ComputerName|startswith: 'build-'
    Initiated: 'true'
  approved:
    DestinationHostname|endswith:
      - '.internal.example'
  condition: selection and not approved
falsepositives:
  - A new mirror that is not on the approved list yet
level: high

১০ · AI-এর যুগে supply chain

AI এই শিকলে নতুন একটি জোড়া যোগ করেছে। AI কোড লিখতে গিয়ে এমন package-এর নাম দিতে পারে, যার অস্তিত্বই নেই। কেউ সেই নামে package প্রকাশ করলে পরের জন যিনি কোডটি হুবহু চালাবেন, তিনি সেটি বসিয়ে ফেলবেন। এই ঝুঁকিকে অনেকে “slopsquatting” বলছেন। মডেলের ফাইল আর AI agent-এর tool-ও এখন dependency, যা পর্ব ৫১-এ আসবে।

AI-এর পরামর্শ নেওয়ার চেকলিস্ট

• প্রতিটি নতুন package-এর অস্তিত্ব, বয়স আর মালিক নিজে দেখেছি
• প্রতিটি CVE নম্বর আর standard প্রাথমিক উৎসে মিলিয়েছি
• কোনো পরামর্শে hash, TLS বা signature যাচাই বন্ধ হচ্ছে না
• Prompt-এ secret, token, গ্রাহকের তথ্য বা ভেতরের URL নেই
• Lockfile আর workflow-এর diff মানুষ পড়েছেন, আর not_affected-এর সিদ্ধান্ত মানুষের