Why code visibility has become the new security perimeter in telecom
According to the ENISA Threat Landscape 2025 report, digital infrastructure and services accounted for approximately 27.7% of data breaches between July 2024 and June 2025. For telecom operators, this indicates a critical supply chain vulnerability. While the network perimeter is typically protected, the internal architecture of BSS/OSS systems often remains a "blind spot" due to a mix of legacy code and modern cloud components, complicating timely vulnerability detection.
SBOM as an architectural passport: from monoliths to API-first systems
The transition to the TM Forum Open Digital Architecture (ODA) replaces monoliths with a componentized, API-first architecture. This creates flexibility but significantly expands the number of third-party dependencies. A Software Bill of Materials (SBOM) serves as a security "passport," allowing operators to instantly identify affected components during Zero-day attacks, shifting security from reactive to architectural.
Practical steps for inventory: starting with legacy systems
Working with legacy modules requires a phased approach. It is recommended to start with automated scanning of binary files and containers to build a registry of third-party libraries. It is important to focus on identifying components with access to payment logic or personal data. This approach supports NIS2 requirements regarding supply chain security transparency.
Automating vulnerability control: from manual audit to CI/CD
Effective control is only possible through the integration of SBOM into the CI/CD pipeline. Using standardized formats such as CycloneDX or SPDX allows for automatic code verification with every deployment. This helps prevent vulnerable libraries from entering the production environment and provides architects with up-to-date data on system status.
Security at the architectural level: implementation experience in BSS/OSS
For mission-critical systems where security is part of the architectural core, using platform foundations is justified. Specifically, solutions built on the UnityBase platform utilize a unified Domain metadata model. It allows for the implementation of dependency control and RBAC/RLS mechanisms at the architectural core level, rather than through external "patches." This approach ensures the necessary level of control and regulatory compliance for on-premises deployments, which is critical for telecom operators.
Checklist for SBOM implementation in BSS/OSS
- Audit of the current stack: identification of all third-party libraries and vendor modules.
- Implementation of a standardized format (e.g., CycloneDX or SPDX).
- Integration of automated component scanning into the deployment process.
- Creation of an up-to-date dependency registry for legacy modules.
- Configuration of automatic notifications for new vulnerabilities (CVE).
FAQ
How does SBOM help meet NIS2 directive requirements?
SBOM provides the necessary supply chain transparency, allowing operators to identify and manage risks from third-party components, which is a direct NIS2 requirement for critical infrastructure.
Is it possible to implement SBOM for legacy BSS systems without a complete overhaul?
Yes, through automated scanning of binary files and the creation of a dependency registry, which allows for security control without radical code changes.
What is the difference between asset inventory and using SBOM for vulnerability management?
Asset inventory typically focuses on infrastructure (servers, devices), whereas SBOM details software libraries within the code, allowing for the detection of vulnerabilities at the codebase level.