CERT-In, or the Indian Computer Emergency Response Team, is the national agency responsible for responding to cybersecurity incidents in India. Established in 2004 and operating under the Ministry of Electronics and Information Technology (MeitY), CERT-In is tasked with improving the security of India's digital infrastructure. The organization plays a crucial role in preventing, detecting, and responding to cybersecurity threats that could affect Indian networks, government agencies, businesses, and citizens. CERT-In has also made it mandatory for certain sectors to report cybersecurity incidents within specified timelines to improve incident response and national security.
In October, CERT-in released SBOM technical guidelines for Indian public sector, government, essential services, organizations involved in software export and software services industry. This 7-chapter document focuses on outlining the value of SBOM, setting up proceses and practices and lists recommendations and best practices.
In this post, we capture the key aspects of the guidance.
SBOM Benefits and Use-Cases
CERT-In documents following key benefits of adopting an SBOM program:
- Effective Security Management
- Effective Incident Response
- Vulnerabilities identification and Patch Management
- Supply Chain Security
- Assists in Ensuring Compliance
- Improved Operational Efficiency
and recommends SBOM for use-cases spanning:
- Software Development and Maintenance
- (Software) Supply Chain Management
- Cybersecurity
- Regulatory Compliance
- Risk Management
- Interoperability and Compatibility
SBOM Implementation
The document includes an end-to-end implementation example for SBOM with the recommendation to updating it as new information become available even if the component itself has not changed. The SBOM build, ask and its fulfillment flow is shown in Figure 1. of the document. The responsibility of providing an accurate and compelte SBOM is left with the Software Developer rather than the Consumer.
SBOM Classification
The document classifies SBOM by the stage at which they are generated. Specifically:
- Design SBOM: components planned during the design phase
- Source SBOM: reflects development environment including source files and dependenices
- Build SBOM: as a result of build process
- Analyzed SBOM: by inspecting the final artifact
- Deployed SBOM: inventory of the software installed
- Runtime SBOM: monitoring active components in the SBOM
The details within the SBOM are also described in the levels of their completeness and its implication on the usage. Specifically:
- Top-Level SBOM: Provides a general summary of components
- n-Level SBOM: Includes deeper level (n-level) details
- Delivery SBOM: Includes every part, library and dependency that is being released or delivered
- Transitive SBOM: Includes direct, indirect and transitive dependencies
- Complete SBOM: Includes exhaustive list of all of its parts, dependencies and related metadata
SBOM Roadmap
CERT-in recommends building SBOM adoption through three phases of implementations: START, PROGRESS and ADVANCE.
START
SBOM Start is foundational stage to achieve the following:
- Identify critical assets
- Create project plan change management process
- Identify SBOM format and minimum requirements for it
- Identify security requirements and tooling for working with SBOM
- Add SBOM to the software procurement process
PROGRESS
SBOM Progress is the subsequent maturity level with focus on unique identification of component and integration of SBOM in SDLC.
- Create secure installation and operational guidance checklist
- Assign unique identifier to each component
- Map supplier's SBOM with consumer's internal SBOM
- Prepare SBOM by both supplier and consumer organization
- Integrate SBOM in each phase of the SDLC
- Implement access controls, encryption, audit cadence and secure configuration management
ADVANCE
SBOM Advance is the phase for mature and scalable SBOM management with focus on integrating with existing workflows such as vulnerability management and ncident response
- Implement vulnerability tracking processes
- Use SBOM to drive incident response
- Setup periodic review and analysis of existing SBOM
- Maintain awareness for emerging component and industry advancements
License Management with SBOM
As one of the SBOM specifications, SPDX evolved from software license management, the document outlines key practices specifically focused on softwawre license management. These include:
- Product and all of its component must include a license
- Use SPDX identifier for licenses
- Consider using alternate license databases - Scancode, LicenseDB, AboutCode, if the primary is not found
- Assign unique identifier when not detected in those databases
- Use SPDX License Expression for extending, modifying or creating exceptions
SBOM Preparation
This chapter deals with the key fields to populate in an SBOM and includes recommendation for Minimum Elements of the SBOM including specific Data Fields, Automation Support and Operational Practices.
Data Fields
- Component Name
- Component Version
- Component Description
- Component Supplier
- Component License
- Component Origin
- Component Dependencies
- Vulnerabilities
- Patch Status
- End-of-life (EOL) Date
- Criticality
- Usage Restrictions
- Checksums or Hashes
- Comments or Notes
- Author of SBOM Data
- Timestamp
- Executable Property
- Archive Property
- Structured Property
- Unique Identifier
Automation Support
Document outlines following benefits of using automated SBOM generation and its machine-readability using CycloneDX or SPDX SBOM formats.
- Component Discovery Automation
- Automated Version Tracking
- Dependency Analysis
- Automated Vulnerability Assessment
- License Compliance
- Automated SBOM generation
- DevSecOps integration
- Reporting and Visualization
- Integration with Security Orchestration Platforms
- Monitoring and Maintenance
Processes and Practices for SBOM
This chapter is foucsed on setting up key processes within the SBOM program to segment responsibilities, setting up governance while maximizing benefits.
Establish Roles and Responsibilities
- Identify key stakeholders
- Define responsibilities
- Assign roles and ownership
- Establish governance
- Enable collaboration
- Provide training and resources
- Monitor and refine
Roadmap for Navigating the Functions of SBOM
Secure SBOM Distribution
The section on SBOM distribution focuses on enumerating distribution option, roles and managing security and verification of hte data.
- Access Control
- Public and Private SBOM
- Secure Distribution Mechanisms
- Automated SBOM Generation and Updates
- SBOM Consumption and Verification
- Monitoring and Auditing
- Incident Response and Remediation
SBOM Sharing
The section on SBOM sharing focuses on implications and tooling for sharing SBOM outside the organization including with the regulators.
- Secure file sharing platforms
- API Integrations
- Collaboration tools
- Industry platforms and repositories
Vulnerability Tracking and Analysis in SBOM
The document recommends an SBOM vulnerability tracking and analysis fucntion using SBOM, Vulnerability Exchange Document (VEX) and Common Security Advisory Framework (CSAF).
VEX Document
Vulnerability Exploitability eXchange (VEX) (Incorrectly listed as Vulnerability Exchange Document) is recommended for standardized sharing of vulnerability information and must include one of the following statuses of the vulnerability status specific to the product:
- Not affected
- Affected
- Fixed
- Under Investigation
CSAF
Common Security Advisory Framework (CSAF) is recommended for publishing security advisories associated with the vulnerabilities. This must include vulnerability, description, affected product versions, severity assessments and recommended mitigation steps.
Diverse Vulnerability Databases
The document recommends integrating with diverse vulnerability databases for complete visibility and help with prioritized remediation.
Shift-Left in SDLC
In the Shift Left approach to building, it is encouraged to implement SBOM generation and analysis in earlier phases of SDLC such as build and packaging to ensure exploitabilie vulnerabilities are detected and mitigated even earlier.
SBOM Best Practices
The document closes with 15 recommendations and 16 best practices summarizing key aspects of SBOM covered earlier in the document. Indian federal departments and organizations are encouraged to make creating and providing a Software Bill of Materials (SBOM) a required standard practice for software procurement and development to strengthen security and reduce cyber risks.
Interlynk SBOM Platform
Interlynk SBOM Automation platform envisioned all of the recommendations and best practices suggested by CERT-in and is already ready to achieve the following recommendations:
✅ Integrate SBOM collection into Software Procurement
✅ Shift left SBOM generation into into pull request, build pipeline, package or release
✅ Track SBOM from multiple stages and when component is added it to the build
✅ Automated SBOM analysis for components origin, licenses and vulnerabilities
✅ Automated VEX generation and distribution
✅ Detect incompatible licenses and generate license notifications
✅ Detect malicious, outdated, end-of-life, end-of-server and tampered components
✅ Setup policies for component consumption and automatic notification for policy violations
✅ Role-based access control and complete audit log for changes to inventory
✅ Secure SBOM distribution and access log
✅ Human readable SBOM, associated metrics and customizable reports
✅ Audit against SBOM regulations including FDA, US Federal, OpenChain, PCI DSS and upcoming Cyber Resilience Act
Conclusion
The SBOM is foundational to automating application compliance and security and is gaining truly global traction. With India’s CERT-In now strongly advocating for SBOM adoption through detailed recommendations, this move paves the way for one of the world’s largest populations to expect SBOM as a standard in software development.
