Why an SBOM Process Matters for CRA Compliance
Imagine a small software company developing a cloud-based time registration application for customers across Europe. The application is built primarily in C# using the .NET platform and has evolved over several years from a simple employee time-tracking solution into a broader workforce management platform. New customer requests arrive continuously, and development priorities are largely driven by delivering new functionality to remain competitive.
The development team consists of a handful of software engineers who work in short release cycles. Success is measured by how quickly new features are delivered, resulting in security activities often being postponed until later in the development process. While developers follow good coding practices where possible, there is no formal Secure Software Development Lifecycle (Secure SDLC), and “security by design” has not yet become part of the organization’s engineering culture.
Like many modern applications, the platform depends heavily on third-party software components. Open-source NuGet packages provide authentication, reporting, PDF generation, logging, database connectivity, and numerous utility functions. The application also integrates with several external services, including payroll providers, identity providers, cloud hosting platforms, email gateways, accounting systems, and HR management solutions. These suppliers themselves rely on additional subcontractors and software libraries, creating a complex ecosystem of third- and fourth-party dependencies that is largely invisible to the development team.
Authentication presents another challenge. The company relies on an external firewall and secure access provider to protect administrative access and remote connectivity. Although multi-factor authentication (MFA) has been enabled, the implementation is relatively weak and depends on a provider that has experienced recurring issues with OAuth authentication flows. These reliability problems have resulted in temporary workarounds, increased administrative overhead, and uncertainty about the resilience of the authentication architecture. While these issues may not directly violate the Cyber Resilience Act, they highlight the importance of understanding dependencies on external security providers and assessing the associated risks.
Risk management within the organization is similarly immature. Security risks are discussed informally during development meetings, but there is no structured product risk assessment, no documented threat modeling process, and no systematic evaluation of supply chain risks. Security controls are introduced reactively, typically after vulnerabilities are discovered or customer concerns are raised, rather than being identified through a formal risk management process.
As the Cyber Resilience Act approaches full applicability, the organization recognizes that this way of working is no longer sufficient. CRA introduces obligations that require manufacturers of software products to understand the components included in their products, manage vulnerabilities throughout the product lifecycle, maintain technical documentation, and demonstrate that cybersecurity has been considered from the earliest stages of development.
One of the first foundational capabilities the company needs is a Software Bill of Materials (SBOM) process. An SBOM provides a complete inventory of software components, versions, licenses, and suppliers used within the application. It enables the organization to identify affected products when new vulnerabilities are disclosed, assess supply chain exposure, support coordinated vulnerability management, and maintain the technical documentation required for regulatory compliance.
However, implementing an SBOM is only one element of a broader compliance journey. To meet CRA expectations, the organization must also establish a structured Secure SDLC, perform regular risk assessments, strengthen identity and access management, improve supplier governance, formalize security controls, and integrate security into every stage of software development. Together, these measures provide the evidence needed to demonstrate cybersecurity by design and enable continuous compliance throughout the product lifecycle.
Hello time to wake up
Business is growing rapidly, and management is pleased with the increasing customer base. Development follows an agile methodology with two-week sprints, where the primary success indicator is delivering customer features on time.
Security is considered important, but rarely urgent.
As one developer jokingly remarks:
“If it isn’t visible to the customer, it probably won’t make the sprint.”
Unfortunately, this mindset has gradually created technical debt that is largely invisible to both management and customers.
The application depends on more software than anyone realizes.
Developers routinely install NuGet packages to accelerate development.
Today the application contains more than 180 external packages including:
- Entity Framework
- Newtonsoft.Json
- Serilog
- AutoMapper
- Identity libraries
- Reporting components
- PDF generators
- Azure SDKs
- Email libraries
- Authentication frameworks
Many of these packages themselves depend on dozens of additional libraries. Nobody maintains a complete inventory. Nobody knows exactly which versions are running in production. Nobody knows which components are no longer maintained. When a vulnerability is published, developers manually search project files hoping they are not affected.
The Supply Chain Keeps Growing
TimeTrack Pro has become highly connected. The platform exchanges information with several external organisations.
Examples include:
- Microsoft Azure, Microsoft Entra ID, Payroll provider, HR platform, Accounting software, Payment provider, SMTP mail provider, SMS notification provider, Identity federation services, External API gateway
Each supplier introduces additional dependencies. Some suppliers themselves rely on cloud providers, managed services and open-source components that TimeTrack Solutions has never evaluated. This creates a growing network of third-party and fourth-party suppliers.
The assuming business disaster
Management assumes these vendors manage their own security.
No one has documented: supplier risks, contractual security requirements, vulnerability notification processes, software component ownership, supplier assurance
Secure Development Exists…Sort Of
Developers perform code reviews. But…. Occasionally. Some projects use static analysis, others do not. Security testing depends largely on the experience of individual developers. There is: no Secure SDLC, no documented secure coding standard, no threat modelling, no security gates, no dependency approval process, no secure architecture reviews, Security activities happen after development instead of during development.
When deadlines become tight, security tasks are postponed until “the next sprint.” Usually, the next sprint introduces new features instead.
Risk Management
When management is asked about cybersecurity risks, the response is encouraging.
“We know our risks.” When asked where they are documented…
Silence…. Risk assessments exist only as discussions during meetings. There is no documented methodology. No product risk register. No supplier risk register. No likelihood scoring. No impact assessment. No treatment plan. As a result, management cannot demonstrate that cybersecurity decisions are based on systematic analysis. “Can we provide your Software Bill of Materials and explain how you comply with the Cyber Resilience Act?”
The organization cannot confidently answer fundamental questions such as:
- What software is inside our product?
- Which supplier introduced this component?
- Which versions are vulnerable?
- Who owns the risk?
- Which customers are affected?
- How quickly can we respond?
Without these answers, demonstrating compliance with the Cyber Resilience Act becomes extremely difficult.
Beginning the Journey
Rather than attempting to solve every problem simultaneously, TimeTrack Solutions decides to adopt a structured approach.
The company introduces the CATS Framework:
- Classify what products, suppliers and software components exist.
- Assess the risks, maturity and compliance gaps.
- Track software components, vulnerabilities, evidence and technical documentation through an automated SBOM process.
- Sustain compliance through secure development, continuous monitoring and lifecycle management.
.
Embedding Security into Everyday Development
Over time, the most significant change was cultural rather than technical.
Security was no longer something performed after development had finished. It became part of development itself. New features started with lightweight threat modelling. Developers considered dependency risks before introducing new packages. Supplier reviews became part of procurement, while privileged authentication was strengthened with phishing-resistant MFA and improved identity governance. Every release automatically produced not only an SBOM, but also updated risk assessments, vulnerability reports, technical documentation and audit evidence.
A year later, during an internal Cyber Resilience Act readiness review, the auditor asked the same question that had once stopped the first meeting.
“Can you explain what software is contained within your product and how you manage its cybersecurity throughout its lifecycle?”
This time, nobody searched through spreadsheets or documentation. The architect opened a single compliance dashboard.
Within minutes, the current SBOM, associated risks, supplier information, lifecycle documentation, vulnerability status and supporting evidence were available. What had begun as a search for compliance had transformed into something much more valuable: a measurable, repeatable and continuously improving software governance process.
The company’s greatest lesson was that the SBOM itself had never been the objective.
The objective was to understand the software being built, the suppliers being trusted, the risks being accepted and the controls needed to reduce those risks. The CATS Framework provided the structure to achieve exactly that, turning compliance into an outcome of good engineering and good governance rather than an administrative exercise.
The CATS CRA Framework is more than a compliance methodology—it is a structured project guidance framework that helps organizations transform Cyber Resilience Act requirements into practical implementation activities. By combining software discovery, SBOM generation, objective risk assessment, supplier governance and continuous improvement, the framework provides management with clear visibility into cybersecurity risks and the controls needed to mitigate them. Rather than relying on assumptions or individual opinions, CATS establishes an evidence-based process that enables consistent decision-making, prioritizes investments based on business impact, and demonstrates that cybersecurity risks are being identified, evaluated and managed throughout the entire product lifecycle.
There is a warning from our experts below is a fingerpoint to discover a important missing piece in most CRA guidance. People often think:
SBOM → Done.
In reality, the SBOM is only one artifact in a much larger Software Supply Chain Risk Management Process.
For a CRA-compliant organization, I would divide the process into seven phases, each with distinct objectives, stakeholders, tools, and deliverables.
Complete SBOM & Risk Assessment Lifecycle
Product Development –> Discovery & Classification –> SBOM Generation –> Component Intelligence –> Risk Assessment –>
Risk Treatment –> Continuous Monitoring –> Governance & Continuous Improvement
Within the CATS CRA Framework, the Software Bill of Materials (SBOM) is never viewed as a standalone deliverable. Instead, it is the result of a structured journey that transforms technical information into business intelligence and objective risk management.
The journey begins with discovery. Before a single SBOM can be generated, the organization must understand exactly what it has built. Development repositories in GitHub or Azure DevOps are examined, project files and package managers are analysed, container definitions and Infrastructure-as-Code repositories are reviewed, and cloud services, APIs and third-party integrations are mapped. What initially appears to be a single software application soon reveals a complex ecosystem of software components, suppliers and cloud dependencies. This discovery phase produces much more than an inventory; it creates a complete picture of the organization’s software supply chain and establishes the foundation for CRA compliance.
Once the landscape has been identified, the organization can automate the generation of an SBOM using standards such as CycloneDX or SPDX. Build pipelines now create an accurate inventory of every software component, its version, supplier, license and cryptographic fingerprint. Yet this is not the end of the process. An SBOM simply answers one question: What is inside the product? It does not explain whether those components are trustworthy, supported or vulnerable.
The real investigation begins by enriching every software component with external intelligence. Public vulnerability databases, vendor advisories, open-source communities and software intelligence platforms are consulted to determine whether components are actively maintained, whether newer versions exist, whether vulnerabilities have been published and whether licensing or supplier concerns exist. A simple library reference such as Newtonsoft.Json 12.0.3 evolves into a comprehensive component profile describing its maintenance status, known vulnerabilities, publisher reputation, licensing obligations and overall risk profile.
This intelligence enables the next and perhaps most important phase: objective risk assessment. Many organizations mistakenly assume that every critical vulnerability automatically represents a critical business risk. In reality, the technical finding must first be evaluated within its operational context. Can the vulnerability actually be exploited? Is the vulnerable functionality used? Is the application exposed to the Internet? Are effective compensating controls already in place? What would be the operational and financial impact if exploitation occurred? Using established methodologies such as ISO 27005, NIST RMF, FAIR or the OWASP Risk Rating Methodology, every finding is translated into a measurable business risk. The outcome is no longer a vulnerability report but a prioritized risk register, supported by treatment plans and executive dashboards that allow management to make informed investment decisions rather than reacting to technical alerts alone.
Armed with objective evidence, management can determine the most appropriate response. Some risks are eliminated by upgrading or replacing vulnerable software, others are mitigated through stronger authentication, additional monitoring or improved supplier governance. Certain risks may be accepted when justified by business context, while others are transferred through contractual agreements or cyber insurance. Every decision is documented, assigned to an owner and tracked through an implementation roadmap, creating clear accountability across the organization.
The process does not end once the initial risks have been addressed. Software supply chains are dynamic by nature. New vulnerabilities emerge daily, suppliers change ownership, open-source projects become unmaintained and new dependencies are introduced with every software release. Continuous monitoring therefore becomes an integral part of the CATS framework. Automated tools continuously compare the organization’s SBOM against newly published vulnerabilities, license changes and software updates, notifying development teams whenever action is required. Instead of discovering issues during annual audits, the organization identifies them as part of its daily engineering activities.
Over time, these activities mature into an ongoing governance process. Supplier reviews become routine, threat modelling is incorporated into architecture decisions, Secure SDLC practices are embedded within development teams and management regularly reviews measurable indicators such as critical vulnerabilities, supplier risk scores, SBOM coverage and mean time to remediate. Compliance is no longer a project with a fixed end date but a continuous management process supported by objective evidence.
This illustrates why the CATS Framework treats the SBOM as a starting point rather than the final objective. The real value lies not in generating another document, but in creating a repeatable process that provides continuous visibility into the software supply chain, translates technical findings into business risks and enables management to make objective, defensible cybersecurity decisions throughout the entire software lifecycle.
As organizations across Europe prepare for the Cyber Resilience Act, it is worth remembering that compliance is rarely achieved by producing another document. It is achieved by building repeatable processes that transform technical information into informed business decisions.
The SBOM is simply where that journey begins.
Real support in the CRA Journey: From Software Developer to CRA-Compliant Manufacturer
Every organization starts its Cyber Resilience Act journey with the same assumption: we already know our software. TimeTrack Solutions believed exactly that. After years of developing a successful C# time registration platform, the development team knew every feature, every customer request and every sprint. Yet when the newly appointed Compliance Officer asked a simple question—“Can anyone tell me exactly what is inside our product?”—the room fell silent.
That single question became the beginning of the CATS Framework.
C – Classify: Discovering What You Really Build
The first phase was not about compliance; it was about discovery.
An inventory of the development environment quickly revealed a software ecosystem far larger than anyone had imagined. Hundreds of NuGet packages, cloud services, external APIs, authentication providers and third-party integrations had accumulated over years of feature-driven development. Every integration introduced another supplier, and every supplier introduced additional fourth-party dependencies that nobody had previously mapped.
The organization realised it could not protect software it did not understand.
Developers, architects, operations, procurement and product management worked together to create a Software Supply Chain Register, identifying software components, suppliers, authentication mechanisms, contractual responsibilities and the product’s obligations under the Cyber Resilience Act. For the first time, management had a complete picture of what the company actually manufactured.
A – Assess: Turning Information into Business Risk
Visibility immediately exposed a second challenge.
Knowing which components existed did not explain whether they represented a risk.
The company introduced an objective risk assessment process that evaluated every important finding against business impact, likelihood and existing controls instead of relying on intuition. During workshops, uncomfortable questions emerged. What if a payroll provider was compromised? What if a malicious update entered an open-source package? What if repeated OAuth authentication failures prevented administrators from responding during a security incident?
Technical issues that had previously been accepted as operational inconveniences suddenly became measurable business risks.
The assessment also highlighted weaknesses that had developed over time. Security reviews depended on individual developers, threat modelling was largely absent, supplier governance was informal and Secure SDLC practices had taken second place to feature delivery. Rather than assigning blame, the assessment produced something far more valuable: an objective roadmap showing management where investments would reduce the greatest risks.
T – Track: Making the Software Supply Chain Visible
With priorities established, the organization focused on automation.
Every software build now generated a Software Bill of Materials in CycloneDX format as part of the Azure DevOps pipeline. Rather than treating the SBOM as another compliance document, it became a living source of operational intelligence. Each build automatically triggered vulnerability analysis, license validation, dependency verification and policy compliance checks, creating a continuously updated view of the software supply chain.
The value of this approach became clear when a critical vulnerability was disclosed in a widely used software library. What had once required days of manual investigation now took minutes. The security dashboard immediately identified which product versions were affected, which customers were exposed and which development team owned the dependency. A rebuilt application generated a new SBOM confirming that the vulnerable component had been replaced, providing complete traceability from vulnerability disclosure to remediation.
The organization had moved beyond software inventories and into continuous software supply chain management.
S – Sustain: Embedding Security into Everyday Development
Over time, the most significant change was cultural rather than technical.
Security was no longer something performed after development had finished. It became part of development itself. New features started with lightweight threat modelling. Developers considered dependency risks before introducing new packages. Supplier reviews became part of procurement, while privileged authentication was strengthened with phishing-resistant MFA and improved identity governance. Every release automatically produced not only an SBOM, but also updated risk assessments, vulnerability reports, technical documentation and audit evidence.
A year later, during an internal Cyber Resilience Act readiness review, the auditor asked the same question that had once stopped the first meeting.
“Can you explain what software is contained within your product and how you manage its cybersecurity throughout its lifecycle?”
This time, nobody searched through spreadsheets or documentation.
The architect opened a single compliance dashboard.
Within minutes, the current SBOM, associated risks, supplier information, lifecycle documentation, vulnerability status and supporting evidence were available. What had begun as a search for compliance had transformed into something much more valuable: a measurable, repeatable and continuously improving software governance process.
The company’s greatest lesson was that the SBOM itself had never been the objective.
The objective was to understand the software being built, the suppliers being trusted, the risks being accepted and the controls needed to reduce those risks. The CATS Framework provided the structure to achieve exactly that, turning compliance into an outcome of good engineering and good governance rather than an administrative exercise.
