SBOM Management: সফটওয়্যার সাপ্লাই চেইন সুরক্ষিত রাখতে থার্ড-পার্টি উপাদানের পূর্ণাঙ্গ তালিকা!

SBOM হলো একটি সফটওয়্যারে ব্যবহৃত সমস্ত component এবং সেগুলোর metadata-র formal, machine-readable inventory। একটি food product-এর gradient list-এর সাথে এর তুলনা করা যায়—আপনি যা খাচ্ছেন, তার প্রতিটি ingredient জানা আপনার অধিকার।

একটি comprehensive SBOM-এ থাকে: প্রতিটি component-এর নাম এবং version, সরবরাহকারী বা publisher, unique identifier (যেমন PURL বা CPE), cryptographic hash, license information, dependency relationship, এবং producer-এর তথ্য।

SBOM শুধু direct dependency নয়, transitive dependency-ও কভার করে। আপনি যদি library A use করেন এবং A library B-র উপর নির্ভরশীল, তবে B-ও আপনার SBOM-এ থাকা উচিত। কারণ B-তে vulnerability থাকলে সেটি আপনার application-কেও affect করে।

SBOM-এর গুরুত্ব বাড়ার পিছনে কয়েকটি driver আছে।

প্রথমত, supply chain attack-এর বৃদ্ধি। SolarWinds, Codecov, ua-parser-js, event-stream, colors.js—গত কয়েক বছরে এক ডজনের বেশি high-profile supply chain incident ঘটেছে। প্রতিটি ঘটনায় ভিকটিম-দের প্রধান প্রশ্ন ছিল: "আমরা কি affected?" SBOM ছাড়া এই প্রশ্নের উত্তর কয়েক দিন বা সপ্তাহ সময় নেয়।

দ্বিতীয়ত, regulatory pressure। ২০২১-এ US President Biden-এর Executive Order 14028 federal government-এ supplier-দের জন্য SBOM provide করা mandatory করেছে। EU-র Cyber Resilience Act (CRA) similar requirement আনছে। FDA medical device-এর জন্য, NTIA software-এর জন্য, এবং অসংখ্য industry-specific regulator SBOM-কে compliance requirement-এ অন্তর্ভুক্ত করছে।

তৃতীয়ত, license compliance। Open-source license violation legally এবং financially costly। GPL, AGPL, এবং অন্যান্য copyleft license-এর obligation track না করলে inadvertent violation সম্ভব। SBOM license inventory-র অপরিহার্য উপাদান।

চতুর্থত, vulnerability management efficiency। নতুন CVE আসলে কোন কোন product affected, কোন কোন customer-কে notify করতে হবে, কোন কোন product patch করতে হবে—এই decision instantly নিতে SBOM crucial।

বর্তমানে তিনটি প্রধান SBOM format industry-তে standard হিসেবে গৃহীত।

SPDX (Software Package Data Exchange) Linux Foundation-এর initiative। ISO/IEC 5962:2021 standard হিসেবে অনুমোদিত। এটি license compliance-এ ঐতিহাসিকভাবে strong, এবং mature tooling সাপোর্ট। JSON, YAML, RDF, এবং tag-value format-এ available।

CycloneDX OWASP-এর initiative। বিশেষভাবে cybersecurity use case-এর জন্য designed। CISA-র SBOM minimum element-এর সাথে closely aligned। JSON এবং XML format-এ available। Vulnerability data এবং exploitability information-এর জন্য better support।

SWID (Software Identification) tag ISO/IEC 19770-2 standard। মূলত asset management context-এ ব্যবহৃত। SBOM এর সাথে complementary, কিন্তু standalone হিসেবে কম জনপ্রিয়।

NIST এবং CISA সাধারণত format-agnostic approach নেয়—যেকোনো standard format acceptable। তবে CycloneDX এর momentum গত কয়েক বছরে স্পষ্ট, বিশেষ করে security-focused use case-এ।

SBOM generation বিভিন্ন stage-এ হতে পারে।

Build-time generation সবচেয়ে accurate। Build process-এর সময় ব্যবহৃত প্রতিটি dependency identify করে এবং SBOM-এ record করে। Maven, Gradle, npm, pip, Cargo—এই package manager-এর সাথে integrate করে।

Source-code analysis মাধ্যমে static analysis tool dependency declaration (package.json, pom.xml, requirements.txt) থেকে SBOM তৈরি করে। দ্রুত কিন্তু কম accurate, কারণ runtime-এ inject হওয়া component miss হতে পারে।

Binary analysis—যখন source code নেই, তখন executable, container image, বা firmware থেকে component extract করা হয়। Syft, Tern, Binwalk-এর মতো tool এই কাজ করে।

Container image-এর জন্য Anchore Syft অত্যন্ত popular। এটি Docker image scan করে এবং SPDX বা CycloneDX format-এ SBOM output করে। Trivy এবং Grype-এ similar capability আছে।

GitHub-এর dependency graph automatic SBOM generation provide করে for hosted repository। GitLab-এও similar feature আছে। CI/CD pipeline-এ এই tool integrate করে প্রতি build-এ SBOM generate করা সাধারণ practice।

SBOM আপনাকে বলে "আমার সফটওয়্যারে কী আছে।" কিন্তু সেটি অপ্রতুল। যখন CVE প্রকাশিত হয়, প্রশ্ন হয় "এই CVE কি actually আমার product-কে affect করে?" এই প্রশ্নের উত্তর দেয় VEX (Vulnerability Exploitability eXchange)।

VEX একটি machine-readable document যা specific product-এ specific vulnerability-র status declare করে। চারটি প্রধান status: not_affected (vulnerability exist করে না বা reachable নয়), affected (vulnerability present এবং exploitable), fixed (patch প্রয়োগ করা হয়েছে), under_investigation (review চলছে)।

VEX-এর সবচেয়ে মূল্যবান use case হলো "not_affected" justification। একটি library-তে CVE থাকলেও যদি আপনার application সেই vulnerable code path call না করে, তাহলে আপনি customer-কে formally জানাতে পারেন যে product safe। এতে অযথা patch panic এড়ানো যায়।

CSAF (Common Security Advisory Framework) VEX-এর enabling framework। OASIS-র standard, যা security advisory publication-এর জন্য structured format provide করে।

SBOM generation থেকে শুরু করে storage, querying, এবং vulnerability mapping—এই পুরো lifecycle manage করার জন্য specialized tool আছে।

Dependency-Track OWASP-এর free এবং open-source platform। SBOM ingest করে, NVD এবং OSV-এর সাথে correlate করে vulnerability identify করে, এবং policy enforcement প্রদান করে।

Anchore Enterprise, Snyk, Sonatype Nexus Lifecycle commercial offering-এ comprehensive SBOM lifecycle management আছে। এদের সাথে CI/CD integration, vulnerability prioritization, এবং compliance reporting বিল্ট-ইন।

GitHub Advanced Security এবং GitLab Ultimate-এও SBOM এবং dependency vulnerability features আছে, যা native development workflow-এর সাথে integrated।

CycloneDX এর own toolchain (cdxgen, bom-tool) এবং SPDX এর tool suite open-source SBOM operation-এর জন্য foundation।

একটি ছোট SaaS startup এর উদাহরণ ভাবুন। তাদের একটি Node.js based backend, React frontend, এবং কয়েকটি microservice আছে। প্রতিটি service-এর container image deploy হয় Kubernetes-এ।

তাদের SBOM strategy এভাবে হতে পারে: CI pipeline-এ প্রতিটি build-এ CycloneDX format-এ SBOM generate, container registry-তে image-এর সাথে SBOM publish, Dependency-Track-এ ingest, এবং SOC 2 audit-এ vendor management evidence হিসেবে present।

যখন নতুন CVE আসে, যেমন একটি new npm package vulnerability, তখন তারা Dependency-Track-এ search করে instantly জানতে পারে কোন service affected। Slack-এ alert আসে, ticket auto-create হয়, এবং remediation track হয়।

একটি বড় enterprise-এর approach আরও জটিল। তারা multiple programming language, legacy COBOL থেকে modern serverless, on-prem এবং cloud—সব mix করে। তাদের জন্য centralized SBOM repository, integration with CMDB, এবং role-based access control essential।

SBOM সবকিছুর সমাধান নয়। কিছু limitation আছে যা বুঝে রাখা গুরুত্বপূর্ণ।

প্রথমত, SBOM-এর accuracy depend করে generation tool-এর quality এবং completeness-এর উপর। কোনো tool কোনো specific dependency miss করতে পারে, বিশেষ করে dynamically loaded বা runtime-injected component।

দ্বিতীয়ত, SBOM static। Runtime behavior, configuration, এবং actual code path execution এর reflect করে না। একটি package present কিন্তু uncalled থাকলেও SBOM-এ দেখাবে।

তৃতীয়ত, hardware এবং firmware coverage তুলনামূলকভাবে immature। Application-level SBOM mature হলেও embedded এবং IoT context-এ standard এখনও evolving।

চতুর্থত, SBOM-এর storage এবং sharing-এর জন্য standardized protocol এখনও fully mature নয়। কারা কাকে SBOM দেবে, কীভাবে authenticate হবে, কীভাবে private এবং public element বজায় থাকবে—এই questions-এ industry এখনও কাজ করছে।

SBOM কার্যকর করার জন্য কিছু best practice মেনে চলা জরুরি।

প্রতিটি build-এ automated SBOM generation নিশ্চিত করুন। Manual SBOM সর্বদা stale হয়ে যায়।

SBOM-কে আপনার product-এর সাথে অবিচ্ছেদ্য artifact হিসেবে treat করুন—docker image-এর label, software package-এর metadata, বা release-এর attachment হিসেবে publish করুন।

Sigstore বা অনুরূপ technology ব্যবহার করে SBOM digitally sign করুন। অন্যথায় SBOM-এর integrity verify করার উপায় থাকবে না।

VEX-এর সাথে SBOM pair করুন। শুধু component list-এর চেয়ে actionable vulnerability status অনেক বেশি valuable।

OSV (Open Source Vulnerabilities) database-এর সাথে integration করুন। এটি ecosystem-aware vulnerability data provide করে, যা generic CVE-র চেয়ে actionable।

Supplier-এর কাছ থেকে SBOM চাওয়া শুরু করুন। আপনার vendor management process-এ SBOM requirement add করুন।

Internal asset inventory-র সাথে SBOM correlate করুন। কোন কোন server-এ কোন কোন application running, এবং সেই application-এ কোন component—এই end-to-end visibility incident response-এ অমূল্য।