Our blog features practical articles on cybersecurity and regulations, written in plain language that business owners and managers can understand. We cover specific topics such as NIS2, DORA and CRA requirements, ISO 27001 implementations, incident analysis, phishing, ransomware and best practices for SMEs.
Instead of technical jargon we offer actionable guidance that can be applied to your business straight away. We focus on content you can implement immediately: checklists, threat analyses, SME guides and regular updates on new regulations.
How to Prepare a Digital Product for Security Testing and Certification?
Preparing a digital product for security testing and certification requires more than giving testers access to an application. A company should organize product scope, architecture, test environment, technical documentation, SBOM, threat model, vulnerability process, Secure SDLC evidence and regulatory requirements, especially under the Cyber Resilience Act.
Prepared by: CCyber Editorial Team
A secure preparation process for testing and certification should cover the full product scope, architecture, test environment, documentation, tester access, test data, component list, SBOM, threat model, security requirements and vulnerability handling process. Security testing verifies the product’s technical resilience. Certification or conformity assessment also requires process evidence: product risk, Secure SDLC, updates, technical documentation, test results, risk decisions and post-release vulnerability handling.
July 2026
Preparing a product for security testing means organizing everything testers need to perform a reliable test without wasting time guessing how the product works.
In practice, this means:
A well-prepared test produces better results because testers can focus on product risks instead of searching for access, documentation and basic information.
Preparing for certification or formal conformity assessment means preparing the product, process and evidence for verification against a defined set of requirements. Depending on the goal, this may involve CRA conformity assessment, cybersecurity certification, customer requirements, supplier audit or an industry standard.
Certification usually requires more than a penetration test. It may require showing:
Simply put: security testing checks the product in practice, while certification or conformity assessment also checks whether the company has process, evidence and product accountability.
Security testing is a technical verification of a product, application, API, infrastructure or component. Its goal is to find vulnerabilities, misconfigurations, logic flaws and risks that could be exploited by an attacker.
Typical test output:
Certification or conformity assessment verifies a product against requirements from a specific scheme, regulation, standard or security profile. It may include technical testing, but usually also covers documentation, process, roles, evidence and formal decisions.
Typical output:
Under the CRA, a manufacturer of a product with digital elements must demonstrate that cybersecurity requirements are met. For many products, manufacturer self-assessment will be possible. For some important or critical products, a notified body or stricter procedure may be required.
This is why the company should not assume that “certification” always means the same thing. First determine the product, regulation, scheme, category and assurance level that apply.
First, answer why the product is being tested or certified. Preparing for an API penetration test is different from preparing for CRA conformity assessment, EUCC certification or a large customer’s security questionnaire.
Example goals:
Evidence to prepare: short description of the purpose, expected outcome and recipient of the report or certification.
Scope is one of the most important preparation elements. Unclear scope leads to weak testing, misunderstandings and problems interpreting results.
The scope should include:
Evidence to prepare: test or conformity assessment scope document with systems, versions and exclusions.
Testers and auditors must understand how the product works. Without architecture, testing will be more superficial and certification may get stuck because documentation is missing.
Prepare:
Evidence to prepare: current architecture and data flow diagram.
The test environment should be as close to production as possible, but without risk to real customers, data and business processes.
The environment should have:
Production should not be used for testing without very clear rules, approvals, limits and risk assessment.
Evidence to prepare: test environment description, access data, testing rules and state restoration plan.
Test data should support realistic testing, but should not expose real customer or employee data.
Prepare:
Evidence to prepare: test data set and confirmation that it contains no production or confidential data.
Testers should have access to roles that reflect real product use. If the test covers authorization, accounts with different permission levels are needed.
Prepare:
Evidence to prepare: test account list, permission scope and access expiration date.
A threat model helps focus testing on the most important risks. It does not need to be perfect, but it should show what the team considers the product’s most important threats.
The model should include:
Evidence to prepare: threat model or list of the most important risk scenarios.
If the product will be assessed under CRA or B2B customer requirements, component visibility is very important. SBOM helps check dependencies, vulnerabilities, licenses and the impact of new vulnerabilities on the product.
Prepare:
Evidence to prepare: SBOM linked to a specific product version.
Before external testing, remove obvious issues. This prevents test budget from being used on problems the company could have detected internally.
The internal review should cover:
Evidence to prepare: list of issues fixed before testing and status of open risks.
Security testing needs clear rules. Testers should know what is allowed, what is prohibited, when to test, who to contact and how to report critical vulnerabilities.
The rules should define:
Evidence to prepare: testing rules approved by product and security owners.
A test does not end with the report. The key is what the company does with findings: how vulnerabilities are assessed, who fixes them, when retesting happens and what evidence is kept.
The process should include:
Evidence to prepare: test results handling procedure and remediation register.
If the goal is certification, conformity assessment or CRA preparation, the company should prepare a broader evidence pack than the test report.
The pack may include:
Evidence to prepare: structured product evidence folder ready for a customer, audit, assessment body or authority.
Checks the web application from the perspective of a user, attacker and business logic. It covers authentication, authorization, sessions, forms, files, errors, configuration and data access.
This is especially important for SaaS products, mobile applications and B2B integrations. It should verify object authorization, roles, tokens, rate limits, input validation and abuse of business flows.
This should cover the application, API communication, on-device data storage, token protection, configuration, reverse engineering and mobile platform-specific risks.
Checks environment configuration, network, access, privileged accounts, logging, data storage, cloud service configuration and deployment security.
Checks repositories, pipelines, secrets, artifacts, dependencies, signing, permissions and the possibility of injecting malicious code or components.
Should cover firmware, updates, communication, hardware interfaces, default configuration, keys, protocols, mobile application and backend.
This can be a preliminary readiness assessment. The goal is not only to find vulnerabilities, but to check whether the product and documentation are ready for a formal process.
Not every certification fits every product. A SaaS product, mobile application, router, firewall, cryptographic module, IoT device and hardware component may require very different approaches.
Before starting, check:
EUCC is an EU certification scheme based on Common Criteria. It can apply to ICT products such as technological components, hardware and software. It is more formal than a normal penetration test and requires security requirements, documentation and assessment by appropriate entities.
Not every software house will need EUCC immediately. However, it is worth understanding this direction if the product has security functions, is used in regulated sectors, will be sold to large customers or may fall into a category requiring a higher assurance level.
Many companies should start not with certification itself, but with readiness assessment. This shows whether the product has sufficient documentation, testing, processes, evidence and version control.
Readiness assessment helps avoid starting a formal process too early and discovering gaps that could have been prepared earlier.
Unclear scope leads to disputes, testing gaps and a report that is difficult to use. The scope must identify product, version, modules, accounts, APIs, integrations and exclusions.
If the test environment differs significantly from production, the test results may be less valuable. Differences should be described and consciously accepted.
Without realistic accounts, roles and data, testers cannot properly verify authorization, data separation, business flows and multi-tenancy in SaaS.
A test report is not automatically a certificate. It can be technical evidence, but certification or conformity assessment usually requires broader documentation and process.
If there is no triage, owners, remediation deadlines and retesting after the test, the report does not translate into real security improvement.
For conformity assessment and certification, missing documentation is one of the biggest problems. A product may be technically good, but difficult to formally confirm.
CRA requires process, documentation and evidence. This cannot be prepared in the last week before assessment. It is best to start with readiness assessment and an action plan.
A SaaS company prepares a B2B platform for a security test required by a large customer. The team wants to order a penetration test immediately, but quickly discovers that there is no current architecture diagram, the test environment differs from production, accounts for different roles are missing and the API is not well documented.
The company first prepares for testing. It defines the scope, creates test accounts, prepares test data for two customers, documents the API, collects documentation and runs internal dependency and secret scanning.
As a result, the external test becomes more valuable. Testers do not waste time organizing access. They check real risks: authorization, customer data separation, API, administrator panel, data export and integrations.
After the test, the company performs triage, fixes vulnerabilities and completes retesting. Then it uses the report as part of a broader evidence pack: SBOM, threat model, vulnerability register, update process and technical documentation for CRA.
ccyber.io helps companies prepare digital products for security testing, certification, conformity assessment and B2B customer requirements. We do not start from the test alone. First, we check whether the product, environment, documentation and processes are ready.
We can support your organization with:
The best first step is a short product readiness assessment. It shows whether the product is ready for testing, what is missing before conformity assessment and which actions should be completed before involving external testers or an assessment body.
No. Security testing detects vulnerabilities and technical risks. Certification or conformity assessment checks the product against defined requirements and usually requires broader documentation, process and evidence.
No. A test report can be important evidence, but CRA requires a broader approach: risk assessment, technical documentation, vulnerability handling, updates, SBOM, support period and user information.
No. For many products, manufacturer self-assessment will be possible. However, some important or critical products may require a stricter procedure or notified body involvement.
Test scope, test environment, user accounts, test data, role description, API description, architecture, testing rules, contact persons and a findings handling process.
API documentation, accounts and tokens with different roles, sample requests, test data, rate limits, authorization description, business scenarios and test environment.
In many cases, yes. SBOM is very important for CRA, vulnerability management, component assessment, customer responses and product technical documentation.
It is the state where the product has not only test results, but also scope, documentation, processes, evidence, owners and version control needed for formal assessment.
The best starting point is readiness assessment: scope, architecture, test environment, accounts, data, API, basic scanning, threat model and test findings handling plan.
Preparing a digital product for security testing and certification requires organizing the product, process and evidence. Simply giving testers access to an application is not enough if scope, environment, data, documentation and findings handling process are missing.
For companies preparing for CRA or large customer requirements, the broader approach is essential: risk assessment, technical documentation, SBOM, vulnerability process, security updates, threat model and Secure SDLC evidence.
The best order is: readiness first, then testing, then remediation and retesting, and only later formal certification or conformity assessment if required.
Secure Updates: How to Prepare a Product Update Process for CRA Requirements?
Secure updates for a digital product are not only about releasing a patch. Under the Cyber Resilience Act, a manufacturer should have a process for detecting vulnerabilities, preparing fixes, testing, signing, secure distribution, user communication, deployment monitoring and evidence documentation throughout the product support period.
Prepared by: CCyber Editorial Team
A secure update process for CRA should cover the entire patch lifecycle: vulnerability detection, risk assessment, change preparation, testing, approval, artifact signing, secure distribution, user communication, deployment monitoring and evidence documentation. A manufacturer of a product with digital elements should also define the support period, provide security updates without undue delay, prepare automatic updates where applicable and separate security updates from functionality updates where technically feasible.
July 2026
Secure updates are the process of preparing, verifying and delivering product fixes in a way that reduces vulnerability risk, avoids introducing new issues and prevents attackers from substituting a malicious product version.
In practice, a secure update process answers:
A secure update is not only about code. It also concerns the build process, change control, signatures, distribution channels, documentation, user support and vulnerability response.
The Cyber Resilience Act introduces cybersecurity requirements for products with digital elements. One of the key areas is vulnerability handling throughout the product support period.
For manufacturers, this means the product should be designed and maintained so that the company can:
CRA therefore turns updates from a technical issue into a product, regulatory and business issue. The team must know not only how to release a fix, but also how to prove that the process works.
The manufacturer should have a process that makes it possible to respond to vulnerabilities and remediate them through security updates. This requires connecting vulnerability management, release process, testing, communication and documentation.
If the company is aware of a significant vulnerability, it should not delay a fix without justification. Priority should depend on risk, product exposure, active exploitation, customer impact and workaround availability.
A user should not be forced to install a large feature update only to receive a security fix if the two can be technically separated.
The CRA refers to automatic security updates in certain cases, especially for consumer products. At the same time, users should have a clear and easy mechanism to turn off automatic updates and temporarily postpone installation.
A security update should be accompanied by information explaining what it fixes, what the user should do and whether additional risk reduction actions are needed.
The user should know until when vulnerability handling and security updates can be expected. The support end date should be specified clearly, including month and year.
Updates cannot be managed well if the company does not know which products and versions are still supported. The first step is a product and version register.
The register should include:
Evidence to prepare: register of products, versions and support periods.
The update policy should define when the company releases a security fix, who makes the decision, how testing works and how users are informed.
The policy should include:
Evidence to prepare: security update policy approved by product and security owners.
A security update usually results from a vulnerability. The update process should therefore be connected with the vulnerability register, SBOM and risk assessment process.
For each important vulnerability, define:
Evidence to prepare: link between vulnerability, fix release and communication decision.
An attacker may try to replace the patch, compromise the build process, steal a signing key or inject malicious code into the release process. Update security therefore depends on development process security.
Check:
Evidence to prepare: build and release process description, approval logs and list of privileged users.
The user or system should be able to verify that the update comes from the correct manufacturer and has not been modified in transit.
In practice, this means:
Evidence to prepare: update signing procedure, key register and signature verification evidence.
The update distribution channel can be attacked. If an attacker compromises the update server, repository, administrator account or distribution system, they may try to deliver a malicious product version.
Security controls should cover:
Evidence to prepare: update channel diagram, access control, logs and contingency plan.
A security fix should not resolve one vulnerability while creating a new incident. Testing should cover both security and product stability.
Testing should include:
Evidence to prepare: update test report, release approval and list of known limitations.
For some products, automatic security updates are the best way to reduce risk. However, it is not always possible to install fixes automatically without affecting the user, production or integrations.
The process should define:
Evidence to prepare: description of the automatic update mechanism, user instruction and product decision register.
A security update should be understandable for the user. The communication does not need to disclose every technical detail before remediation, but it should clearly state what the user should do.
The communication may include:
Evidence to prepare: approved security advisory and communication channel list.
Releasing a fix does not mean that risk is gone. The company should know how many users installed the update, which versions remain vulnerable and whether problems appeared after the update.
Monitor:
Evidence to prepare: update adoption report and post-release issue list.
The CRA requires each security update made available to users during the support period to remain available after release for a minimum of 10 years or for the remainder of the support period, whichever is longer.
This means the manufacturer should plan:
Evidence to prepare: update retention policy and available version register.
Under CRA, security updates are part of the evidence that the manufacturer handles vulnerabilities and maintains the product securely. Evidence should be available in technical documentation or related registers.
Document:
Evidence to prepare: complete security update evidence pack.
In a SaaS model, the manufacturer usually controls the production environment and can deploy fixes faster. The challenge is change control, regression testing, customer communication and monitoring impact on integrations.
In SaaS, the following are especially important:
For software installed in the customer environment, the manufacturer often does not fully control the installation date. The update mechanism, notifications, instructions, compatibility and version monitoring where possible are therefore important.
Mobile applications depend on app stores, operating systems and user behavior. The company should plan how quickly the fix will reach the user and how to reduce risk for older versions.
In IoT and embedded systems, updates may involve firmware, resource-constrained devices, unstable connectivity and physical risk. Signatures, integrity verification, resilience to interrupted updates and safe recovery are particularly important.
If the company provides a component, library, SDK or API, it should prepare clear versioning, vulnerability advisories, update instructions and information for integrators. The customer must know how to safely update the component in their product.
If the company does not know which product versions it supports, it is difficult to decide which versions need a fix and which customers should be informed.
Time pressure after vulnerability discovery can lead to a rushed release. A security fix still needs testing, especially when it affects authentication, access, customer data or the installation process.
Unsigned or weakly protected updates can be replaced. For a digital product, the update mechanism is one of the most sensitive security elements.
An update may fail. The company should know how the product returns to operation, how data is protected and how the user receives support.
If the user must install a large feature change only to receive a security fix, delay and compatibility risk increase.
The user must know that an update is available, what it fixes and what they should do. Lack of communication extends exposure time.
If the company does not document tests, approvals, signatures, publication and communication, it is difficult to demonstrate compliance even if the update was done correctly.
A company develops a desktop application used by B2B customers in a regulated sector. The product has an update module, but no clear support policy, update signing is manual and customer communication is prepared only when a problem appears.
After a CRA analysis, the company realizes that it must organize the whole process. First, it creates a supported version register, defines the support period, assigns the update process owner and links vulnerabilities with fix releases.
Then the company introduces artifact signing, update installation tests, a failed update procedure and a security advisory template. It also adds an adoption report to see which customers still use older versions.
After 90 days, the company not only releases fixes faster, but also has evidence: who approved the fix, what was fixed, how it was tested, when it was published and how many customers installed it.
ccyber.io helps companies building digital products prepare a secure update process aligned with CRA requirements, Secure SDLC practices and the real way product teams work.
We can support your organization with:
The best first step is a short update process assessment. It helps determine which products require the most attention, where controls are missing and what should be implemented before CRA deadlines.
It is an update prepared, tested, signed, distributed and monitored in a way that reduces security risk without creating new risk for the user and product.
CRA refers to automatic security updates where applicable, especially for consumer products. Users should also have a clear opt-out mechanism and the ability to temporarily postpone installation.
CRA states that where technically feasible, security updates should be delivered separately from functionality updates. The goal is to avoid forcing the user to install a large feature change just to receive a security fix.
CRA indicates that security updates addressing identified security issues should be provided without delay and free of charge, unless otherwise agreed between the manufacturer and a business user for a tailor-made product.
CRA requires each security update made available to users during the support period to remain available after release for at least 10 years or for the remainder of the support period, whichever is longer.
Not always. The company should ensure a secure distribution channel, update integrity, user instructions, communication, testing, monitoring and evidence. Publishing the file alone may be insufficient.
Yes. The update process, vulnerability handling, testing, support and evidence should be linked to product technical documentation and conformity assessment.
The best starting point is a product and supported version register, security update policy, connection with the vulnerability register, update signing review and preparation of communications and evidence.
Secure updates are one of the most important parts of CRA compliance and real digital product security. A product that cannot be updated securely will be difficult to maintain, difficult to defend in front of customers and difficult to demonstrate in technical documentation.
The most important process elements are product register, support period, vulnerability management, testing, signing, secure distribution, automation where applicable, communication and update adoption monitoring.
Companies that prepare this process early will be better ready for CRA, customer questions, audits, incidents and situations where a critical security fix must be released quickly.
Vulnerability Management for Digital Products: Where Should You Start?
Vulnerability management for digital products does not end with scanning libraries or waiting for a penetration test report. Software companies should have a process for detecting, assessing, prioritizing, fixing, testing, communicating and documenting vulnerabilities throughout the product lifecycle, especially under the Cyber Resilience Act.
Prepared by: CCyber Editorial Team
Vulnerability management for digital products is a process for detecting, assessing, prioritizing, fixing, testing, communicating and documenting vulnerabilities in software, components, APIs, cloud, configuration, dependencies and the release process. A company should start with a product register, component register, vulnerability reporting channel, clear roles, risk classification, remediation deadlines, update process, SBOM, security testing and a reporting procedure under the Cyber Resilience Act.
July 2026
Vulnerability management for a digital product is an organized process for handling security weaknesses that may exist in the product, its components, configuration, libraries, APIs, cloud environment, release process or documentation.
In practice, the process answers the following questions:
Good vulnerability management does not mean that the company “has a scanner”. A scanner is only one source of information. The key is a process that turns vulnerability information into a decision, fix, test, communication and evidence.
A vulnerability is a weakness in a product, component, process or configuration that can be exploited to compromise security. It may affect code, dependencies, cloud settings, access control, business logic or the update process.
A bug is incorrect system behavior. Not every bug is a security vulnerability, but some bugs can lead to vulnerabilities. Example: an input validation bug may allow command injection or access control bypass.
Risk combines the likelihood of vulnerability exploitation and the impact on the company, product and customers. The same vulnerability may have a different risk level in different products.
An incident is an event that negatively affects or may negatively affect the security of a product, data or functions. A vulnerability can lead to an incident, but not every vulnerability means that an incident has already occurred.
The Cyber Resilience Act introduces cybersecurity requirements for products with digital elements. For software companies, this means securing the product across its lifecycle: design, development, release, updates, vulnerability handling and user communication.
Under the CRA, the manufacturer must be ready for:
From 11 September 2026, reporting requirements apply for actively exploited vulnerabilities and severe incidents through the Single Reporting Platform. This means companies should not wait until 2027 to build the process. Without a vulnerability register, owners, classification and escalation path, meeting reporting deadlines will be difficult.
You cannot manage vulnerabilities effectively if the company does not know which products, versions and components it maintains. The first step is a digital product register.
The register should include:
Evidence to prepare: product and version register with owners and support status.
A large part of digital product vulnerabilities affects third-party components: libraries, packages, container images, transitive dependencies and tools used in the build process.
The company should prepare an SBOM, or Software Bill of Materials, and link it to a specific product version.
An SBOM helps answer:
Evidence to prepare: SBOM for key products, component register and SBOM update process for releases.
Vulnerabilities can be detected in many ways. The company should define which sources it uses and who monitors them.
Typical sources:
Evidence to prepare: list of vulnerability sources, monitoring owners and review frequency.
A company creating a digital product should have a clear way to receive vulnerability reports. Without it, a researcher, customer or partner may not know where to report a problem.
Prepare:
Evidence to prepare: vulnerability disclosure policy, public contact channel and report handling procedure.
The vulnerability register is the center of the process. It should collect all vulnerabilities regardless of source: scanner, customer, penetration test, researcher, incident or supplier information.
The register should include:
Evidence to prepare: central vulnerability register with decision and action history.
Not every high-score vulnerability means the product is truly exposed. Conversely, a medium-score vulnerability may be critical if it affects a public feature, customer data or administrative access.
When assessing a vulnerability, consider:
Evidence to prepare: classification decision with justification, not only scanner score.
The company should have internal response and remediation timelines. Deadlines depend on vulnerability severity, product exposure, fix availability and real risk.
Example model:
Timelines should not be copied mechanically from the internet. They should follow risk appetite, customer requirements, regulations and team capacity.
Evidence to prepare: remediation timeline policy and history of meeting deadlines.
A good fix should not only change one line of code if the problem comes from a weak design pattern, missing tests or poor access control.
For every important vulnerability, ask:
Evidence to prepare: root cause description, fix, regression test and preventive actions.
A vulnerability fix should be tested. Otherwise, the company does not know whether the problem is really gone or whether a new issue was introduced.
Verification may include:
Evidence to prepare: retest result and confirmation of vulnerability closure.
If a vulnerability affects customers or users, communication must be planned. Not every vulnerability requires a public advisory, but every important vulnerability should have a communication decision.
A security advisory may include:
Evidence to prepare: approved advisory, recipient list, publication date and update history.
From 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents affecting product security through the Single Reporting Platform.
The process should specify:
Evidence to prepare: CRA reporting procedure, role list, note templates and reporting register.
Every serious vulnerability is an opportunity to improve the process. The company should analyze not only how quickly it fixed the issue, but why it appeared and whether similar mistakes can be prevented.
After an important vulnerability, run a short review:
Evidence to prepare: lessons learned note and improvement actions.
CVSS is a useful standard for technical severity assessment, but it should not be the only remediation priority criterion. A digital product has its own context: customers, data, exposure, architecture, mitigating controls and contractual obligations.
A vulnerability actively exploited by attackers should have higher priority than a theoretical vulnerability with a similar technical score. Under the CRA, active exploitation may trigger reporting obligations if it affects a product with digital elements.
EPSS can support the assessment of the probability that a vulnerability will be exploited in the near future. It does not replace team judgment, but helps distinguish vulnerabilities that are only “technically high” from those more likely to be exploited.
A vulnerability in an internet-facing feature has a different priority than a vulnerability in a component that is not externally reachable and is not used in the product.
If a vulnerability can lead to access to customer data, personal data, financial data, secrets, API keys or multi-tenant SaaS data, the priority should increase.
Sometimes a quick library update removes significant risk with low effort. In other cases, a fix requires architecture changes. Prioritization should consider both risk and a realistic remediation plan.
A scanner can find a vulnerability, but it will not define owner, priority, deadline, communication, customer impact or reporting obligations. The company needs a process, not only a tool.
If a vulnerability is not linked to a specific product version, it is difficult to determine which customers are exposed and whether the fix was deployed.
If a researcher or customer does not know where to report a vulnerability, the information may go to the wrong person, be ignored or be published without coordination.
CVSS is important, but not enough. Remediation priority must consider product, customers, exposure, active exploitation and fix availability.
Closing a task in a project system does not mean the vulnerability was effectively removed. Retesting or another form of confirmation is needed.
Not every vulnerability requires a public advisory, but lack of any communication decision can create chaos when a customer asks about risk.
Companies covered by CRA must be ready to report actively exploited vulnerabilities and severe incidents. Without procedures and roles, meeting deadlines will be difficult.
A SaaS company develops a platform for B2B customers. The product has a web application, API, reporting module, several integrations and hundreds of open-source dependencies. A regulated sector customer asks how the company handles vulnerabilities and how quickly it can respond to a new vulnerability in a popular library.
At first, the team checks vulnerabilities manually. Some dependencies are in different repositories, some in container images and some in build tools. There is no single vulnerability register and no clear decision on who approves customer communication.
The company implements a vulnerability management process. It creates a product register, generates an SBOM for the main application, starts dependency scanning, prepares a vulnerability reporting channel, defines remediation deadlines and prepares a security advisory template.
After 90 days, the company can answer the customer clearly: which products are covered by the process, how vulnerabilities are detected, how they are assessed, what remediation deadlines apply, how communication works and what evidence can be shown.
ccyber.io helps software companies implement a practical vulnerability management process for digital products, aligned with CRA, Secure SDLC, SBOM and B2B customer requirements.
We can support your organization with:
The best first step is a short vulnerability process assessment. It helps determine where the biggest gaps are, whether the company is ready for CRA and which actions should be implemented in the first 30, 60 and 90 days.
It is the process of detecting, assessing, prioritizing, fixing, testing, communicating and documenting vulnerabilities in a product, its components, configuration, APIs, cloud and release process.
No. A scanner helps detect issues, but it does not replace a process. Roles, decisions, priorities, deadlines, fixes, tests, communication and evidence are required.
A vulnerability is a weakness that can be exploited. An incident is an event that already affects or may affect the security of a product, data or functions.
It is useful to combine CVSS, active exploitation, EPSS, product exposure, data criticality, customer impact, fix availability and regulatory or contractual requirements.
Yes, especially for digital products. SBOM helps determine which components and versions are in the product and whether a new vulnerability affects a specific release.
CRA requires manufacturers of products with digital elements to handle vulnerabilities, document them, provide security updates and report actively exploited vulnerabilities and severe incidents according to defined timelines.
No. CRA focuses on actively exploited vulnerabilities and severe incidents affecting product security. The company should have a procedure to assess whether a reporting obligation exists.
The best starting point is a product register, vulnerability register, reporting channel, basic risk classification, dependency scanning, SBOM for the main product and clear remediation deadlines.
Vulnerability management for digital products is one of the most important elements of product security. Finding a vulnerability is not enough. It must be assessed, fixed, tested, documented and, where needed, communicated or reported.
For software companies, this process is becoming increasingly important from both business and regulatory perspectives. Customers want evidence, auditors want a process and the CRA strengthens manufacturer obligations for vulnerabilities, updates and reporting.
The best approach is to start simply: product register, SBOM, vulnerability register, owners, priorities, deadlines, tests and communication procedure. Automation, scaling and integration with the full Secure SDLC can come next.
Software Bill of Materials (SBOM): What Software Companies Must Prepare for CRA
An SBOM, or Software Bill of Materials, helps a company show which components, libraries and dependencies make up a digital product. Under the Cyber Resilience Act, software companies should prepare an SBOM generation process, dependency control, vulnerability management, technical documentation and a way to share information with customers, auditors and market surveillance authorities.
Prepared by: CCyber Editorial Team
An SBOM, or Software Bill of Materials, is a formal and structured record of components, libraries, dependencies and relationships that make up a digital product. Under the Cyber Resilience Act, software companies should prepare a process for generating SBOMs in a machine-readable format, link SBOMs to vulnerability management, technical documentation, security updates and compliance evidence.
July 2026
An SBOM is a structured record of components used in software. It can be compared to an ingredients list for a product. In physical manufacturing, a company knows which parts a device contains. In software, an SBOM plays a similar role.
An SBOM helps answer:
The most important point is that an SBOM is not a goal by itself. It is a tool for software supply chain visibility, vulnerability management, customer responses and compliance evidence.
The Cyber Resilience Act introduces cybersecurity requirements for products with digital elements. This includes hardware and software products made available on the EU market.
The CRA requires manufacturers to identify and document vulnerabilities and components contained in products with digital elements. It explicitly refers to drawing up an SBOM in a commonly used and machine-readable format, covering at least the top-level dependencies of the product.
In practice, a company creating a digital product should know what the product is made of. When a new vulnerability appears in a popular library, the company must quickly determine:
Without an SBOM, answering these questions often requires manual searching across repositories, pipelines, container images, documentation and assumptions about what actually reached the release.
The CRA states that manufacturers must identify and document vulnerabilities and components contained in products with digital elements, including by drawing up an SBOM. Such an SBOM should be in a commonly used and machine-readable format and cover at least the top-level dependencies of the product.
In practice, companies should treat SBOM as one of the key elements of CRA preparation, alongside:
Important: an SBOM does not automatically mean public disclosure of the full component list to every user. Under CRA, technical documentation, including the SBOM, may be requested by market surveillance authorities. If the manufacturer decides to make the SBOM available to users, information on where it can be accessed should be provided.
The minimum SBOM scope depends on the standard, tool and use case. For companies preparing for CRA, the SBOM should be practical, current, machine-readable and linked to a specific product version.
Top-level dependencies are components that the product uses directly. Example: an application directly uses a library for authentication, file handling, logging or database communication.
Transitive dependencies are components used by other components. Example: your application uses library A, and library A uses library B. Library B is a transitive dependency.
The CRA refers to at least top-level dependencies. However, from a real vulnerability management perspective, companies should aim to gain visibility into transitive dependencies as well. Many serious vulnerabilities appear in libraries that were not manually added by the team, but entered the product through other packages.
Practical recommendation for software companies:
SPDX is an open standard developed by the Linux Foundation. It is used to describe software components, licenses, dependencies and supply chain information. The SPDX specification is available as the international standard ISO/IEC 5962:2021.
SPDX works well where license compliance, customer exchange and interoperability between tools matter.
CycloneDX is an OWASP standard for bills of materials, designed with software supply chain cybersecurity in mind. It supports SBOM, SaaS bills of materials, cryptography bills of materials, hardware bills of materials and AI bills of materials.
CycloneDX is often used in DevSecOps teams for automatic SBOM generation, vulnerability analysis and integration with security tools.
There is no single answer for every company. More important than the format itself is whether the SBOM is current, machine-readable, generated repeatedly, linked to a product version and used in vulnerability management.
In practice, choose a format supported by the company’s tools, customer requirements and future regulatory needs. In many organizations, supporting both SPDX and CycloneDX can be useful if tools and processes allow it.
An SBOM has the greatest value when it is used operationally. A file stored in a repository does not reduce risk if nobody analyzes it.
A good process should work as follows:
An SBOM may show that a product contains a vulnerable component. This does not always mean the vulnerability is exploitable in the product. The team should assess context: whether the vulnerable function is used, whether the component is reachable, whether a mitigating control exists and whether the product is exposed to the internet.
This is why VEX is increasingly used alongside SBOM. VEX is a way of communicating whether a vulnerability actually affects a specific product.
SBOM answers the question: which components make up the product?
VEX answers the question: does a specific vulnerability in a component affect this product in practice?
Example:
For companies selling B2B software, combining SBOM and VEX can significantly reduce chaotic customer questions after a new vulnerability is disclosed in a popular library.
SBOM should not be only one developer’s task. It is part of product security, vulnerability management and compliance. The owner may be product security, DevSecOps, CTO, security engineer or the team responsible for product quality.
Evidence to prepare: SBOM process owner, responsibility scope and supporting people.
At the beginning, not everything needs to be covered. Start with products that are most important for the business, covered by CRA, sold to B2B customers or containing sensitive data.
Priority:
Evidence to prepare: list of products and versions covered by the SBOM process.
Choose a format supported by the team’s tools and customer requirements. In most cases, SPDX or CycloneDX should be considered.
When choosing a tool, check:
Evidence to prepare: decision on format, tool and SBOM generation scope.
Manual SBOM creation quickly stops working. The product changes with every release, and dependencies are updated frequently. The SBOM should be generated automatically during build or release.
Automation should cover:
Evidence to prepare: automatic SBOM generation configuration and sample file for a product release.
An SBOM that is not linked to a product version has limited value. When a customer asks about a vulnerability in a specific version, the company must know which SBOM applies to that version.
Link SBOM to:
Evidence to prepare: product release register with assigned SBOM.
After an SBOM is generated, it should be used to assess vulnerabilities. The SBOM alone is not enough. Component analysis against vulnerability information sources is needed.
The process should include:
Evidence to prepare: vulnerability report, triage decisions, remediation tasks and remediation confirmation.
An SBOM may be incomplete, incorrect or inconsistent. Tools do not always detect components in the same way. This is why quality review is needed.
Check:
Evidence to prepare: SBOM quality checklist and validation result.
An SBOM may contain sensitive business or technical information. The company should define who receives it, when and at what level of detail.
Possible models:
Evidence to prepare: SBOM sharing policy, approval path and customer response template.
An SBOM must change together with the product. If the product has a new release, new dependencies or a new container image, the SBOM should also be updated.
If it is not clear which SBOM applies to which product version, answering a customer or authority question becomes difficult. SBOM must be tied to a specific release.
Generating the file alone does not reduce risk. SBOM should feed vulnerability assessment and update processes.
Tools may produce different results. SBOM should be validated and checked for completeness, correctness and usefulness.
An SBOM may reveal information about architecture, dependencies and potential product weaknesses. The company should define who receives this information and at what level of detail.
If nobody owns SBOM, the process will quickly fall apart. An owner is needed in product security, DevSecOps, engineering or security.
In B2B products, some components may come from a customer, integrator or supplier. It is important to define who is responsible for describing them, tracking vulnerabilities and applying updates.
SBOM should be linked to product technical documentation. Under CRA, technical documentation should show how the product was designed, developed and maintained from a cybersecurity perspective and how the manufacturer handles vulnerabilities.
In the documentation, connect SBOM with:
A good SBOM also helps with customer communication. When a new vulnerability appears, the company does not need to answer generally. It can check the impact on specific products and versions.
The company has the first component list, but the process is manual, irregular and not connected with product releases.
The company uses a tool to generate SBOM for a selected product, but does not always do it for every release.
SBOM is generated automatically at release, linked to product version and stored as evidence.
SBOM feeds vulnerability management. The team can quickly answer whether a new vulnerability affects the product.
SBOM becomes part of technical documentation, CRA processes, customer responses, audits and software supply chain risk management.
A SaaS company develops a B2B platform. The product uses hundreds of open-source components, several container images, a web application, API and reporting module. A regulated sector customer asks whether the company can identify which component versions are in the product and whether a vulnerability in a popular library affects their environment.
At first, the team checks dependencies manually. It turns out that different repositories use different library versions, containers contain additional packages and documentation does not show which components reached a specific release.
The company implements an SBOM process. First, it generates SBOMs for the main application and container images. Then it links SBOMs to product versions, adds vulnerability scanning, prepares a procedure for sharing information with customers and includes SBOM in product technical documentation.
After several weeks, the company can answer customer questions faster and manage vulnerabilities better. SBOM stops being an audit document and becomes an operational tool.
ccyber.io helps software companies prepare an SBOM process in a practical way aligned with CRA, vulnerability management and the real product development process.
We can support your organization with:
The best first step is a short SBOM readiness assessment. It helps determine which products need SBOMs, what tools are available, how the release process works and what must be prepared before the CRA deadlines.
An SBOM is a formal record of components and supply chain relationships in software. It shows which libraries, packages, modules and dependencies make up a digital product.
The CRA states that manufacturers must identify and document vulnerabilities and components in products with digital elements, including by drawing up an SBOM in a commonly used and machine-readable format, covering at least top-level dependencies.
The CRA refers to at least top-level dependencies. From a practical perspective, however, visibility into transitive dependencies is valuable because many vulnerabilities appear there.
Not always. An SBOM may be internal or shared with customers or authorities under defined conditions. The company should define sharing rules because an SBOM may contain sensitive information.
SPDX or CycloneDX are the most common options to consider. The choice should depend on tools, customer requirements, CI/CD process, vulnerability analysis needs and future regulatory requirements.
No. SBOM shows components and dependencies, but it does not replace application testing, code review, API testing, threat modeling or architecture assessment.
SBOM shows what is in the product. VEX helps communicate whether a specific vulnerability actually affects a product and its usage context.
The best starting point is one pilot product: choose a format, generate the first SBOM, link it to a product version, check vulnerabilities and prepare an update and sharing procedure.
SBOM is becoming one of the key elements of digital product security. Under CRA, it is not enough to know that a product “uses open-source libraries”. The company must be able to show which components are in the product, how they are documented, how they are monitored and how they support vulnerability management.
The best approach is to treat SBOM as a process, not a one-time file. SBOM should be generated automatically, linked to a product version, analyzed for vulnerabilities and stored as part of technical documentation.
Companies that prepare the SBOM process early will be better ready for CRA, customer requirements, audits, vulnerability incidents and growing expectations around software supply chain transparency.
Threat Modeling: A Practical Guide for Product Teams
Threat modeling helps product teams identify security problems during design, before they reach code and production. Learn how to run a practical session, what questions to ask, how to use STRIDE, how to document results and how to turn threats into concrete tasks for the team.
Prepared by: CCyber Editorial Team
Threat modeling is a practical method for analyzing a product, feature or architecture to understand what can go wrong from a security and privacy perspective. Product teams should start with four questions: what are we working on, what can go wrong, what are we going to do about it and did we do a good enough job? The outcome of a good session is not only a diagram, but a list of risks, decisions, security requirements, tests and implementation tasks.
July 2026
Threat modeling is the analysis of a product, feature, process or architecture from the perspective of possible threats. The goal is to find security and privacy problems before they become embedded in code, configuration, integration or a business process.
In practice, threat modeling helps answer four questions:
Well-run threat modeling is not an academic exercise. It is a workshop designed to improve design, reduce risk and create tasks the team can actually implement.
Product teams make decisions that directly affect security: how login works, who can access data, how the API behaves, where customer boundaries exist in SaaS, what integrations can access the system and how the product handles errors.
If security appears only during a penetration test before release, many architecture decisions are already hard to change. Threat modeling moves the discussion earlier, where fixes are cheaper and less painful.
Threat modeling helps:
The best moment is during concept, architecture or first version planning. At that stage, the team can still change the approach to data, authentication, integrations and permissions without high cost.
Not every small change requires a full session. Threat modeling is especially useful for features that have higher security impact.
Examples of high-risk features:
Threat modeling is useful during cloud migration, identity provider changes, new API deployment, microservices adoption, data model changes or new integrations.
If the company had an incident or found a serious vulnerability, threat modeling helps determine whether the problem was isolated or caused by weak design assumptions.
Threat modeling can support preparation for CRA, NIS2, ISO/IEC 27001, SOC 2, customer requirements or product conformity assessment.
The most common mistake is a scope that is too broad. A session called “let’s model the whole system” can quickly become chaotic and produce no actionable result. It is better to start with a specific feature, service, module or data flow.
Good scope examples:
Evidence to prepare: short description of session scope and modeling objective.
Threat modeling should not be a solo security exercise. The best results come when people who understand the product, architecture, data, users and business risk participate.
Typical session participants:
The goal is not a large group. The goal is the right group. A 5-7 person session often works better than a full department meeting.
Evidence to prepare: participant list, roles and owner of session outputs.
The model does not need to be perfect. It should help the team see how the system works. A data flow diagram, architecture diagram or process map is usually enough.
The model should show:
Evidence to prepare: system diagram or data flow diagram with trust boundaries.
Not all data has the same risk level. The team should know which data is public, internal, confidential, personal, financial, medical, technical or covered by business secrecy.
Useful questions:
Evidence to prepare: data list, classification and processing locations.
A trust boundary is a place where data or a request crosses between areas with different levels of control. This is often where important risks appear.
Examples of trust boundaries:
Evidence to prepare: diagram with trust boundaries and description of controls at those boundaries.
First, the team must understand the scope together. The product owner explains the feature, the architect shows the model, developers add details and security helps identify risk areas.
Define:
At this stage, the team identifies threats. You can use STRIDE, an OWASP checklist, previous incidents, customer requirements, MITRE ATT&CK or simple brainstorming.
Example questions:
STRIDE helps organize the discussion. It is not the only method, but it is practical and works well with product teams.
STRIDE includes:
For each element of the model, ask which STRIDE categories are relevant. This does not have to be mechanical for every field. The goal is to find real threats, not to fill in a table.
Not every threat is equally important. After threats are identified, decide which require action now, which can be planned later and which can be consciously accepted.
When assessing risk, consider:
In practice, a simple scale is enough: critical, high, medium, low. The important thing is that the team understands why a risk has a given priority.
For every significant threat, define a response. The most common options are: mitigate the risk, remove the feature or risk source, transfer responsibility or consciously accept the risk.
Good mitigation actions should be concrete:
If the response does not lead to a task, requirement or test, it is probably too general.
The biggest value appears when threat modeling outputs enter the team’s work. Risks should become backlog tasks, security requirements, tests, decisions or risk acceptances.
For every significant threat, define:
At the end of the session, the team should check whether the model makes sense and whether outputs are useful.
Control questions:
In SaaS, customer data separation is critical. One of the most important questions is: can customer A accidentally or intentionally see customer B’s data?
Check:
The administrator panel is often high risk because it provides broad permissions. The model should check who can access it, how it is protected and what actions can be performed from it.
Check:
In SaaS, APIs are often the main attack surface. Authorization errors, no rate limits, overly broad tokens and unsafe integrations can lead to serious incidents.
If the product uses AI or agents that automate actions, threat modeling should include new risks: prompt injection, data disclosure from context, excessive agent permissions and overreliance on AI output.
If threat modeling happens after the feature is built, the team may discover problems that require major architecture changes. It is better to do it early.
Trying to model the entire platform in one session usually leads to shallow analysis. It is better to model smaller parts more thoroughly.
Security and developers may not know the full business context. Product owners help explain how the feature should work, what matters to customers and which risks are most important.
Tools can help, but they do not replace thinking. Threat modeling is mainly about conversation, understanding the system and making decisions.
If the session produces no tasks, requirements or tests, threat modeling does not affect the product. Outputs must enter the development process.
The product changes. The threat model should be updated after major architecture changes, new integrations, new data types and new high-risk features.
The diagram should support the conversation, not become a work of art. A simple diagram the team understands is better than a perfect model nobody uses.
A SaaS company is planning a new customer data export feature through API. The feature will allow customers to download large reports and integrate with external analytics systems.
The product team organizes a 90-minute threat modeling session. The diagram shows the user, API, authorization service, database, job queue, file storage and external customer system.
During the session, the team identifies several risks: a customer may download another customer’s report, the API token may have overly broad permissions, the export may reveal data in logs, the feature may be abused to overload the system and the report link may remain valid for too long.
The session outputs go into the backlog: object-level access control, shorter link lifetime, rate limiting, removal of sensitive data from logs, authorization tests and monitoring of unusual exports.
As a result, the team finds problems before most of the code is written. A later penetration test confirms that the key risks were already reduced during design.
ccyber.io helps product teams, software houses and SaaS companies run threat modeling in a practical, lightweight way connected with the team’s real work.
We can support your organization with:
The best first step is a pilot workshop for one high-risk feature. This lets the team quickly see the value of the method and implement a simple, repeatable process without unnecessary bureaucracy.
No. The best threat modeling involves product owners, developers, architects, DevOps, testers and security. Security can facilitate, but product and technology context must come from the team.
No. At the beginning, a diagram, whiteboard, document and simple template are enough. Tools can help later when the company wants more repeatability and scale.
For one high-risk feature, 60-90 minutes is often enough. For a larger system, it is better to run several smaller sessions than one very long meeting.
No. STRIDE is a popular and practical structure, but it is not the only method. Teams can also use other approaches, checklists, attack scenarios, MITRE ATT&CK, OWASP ASVS or a custom method suited to the organization.
It should be done before development of high-risk features, during architecture changes, new integrations, new data flows, AI features, administrator panels and APIs.
The output should include concrete threats, risk assessment, decisions, security requirements, backlog tasks, tests, owners and deadlines.
Yes. CRA requires product security across the lifecycle. Threat modeling helps prepare product risk assessment, security requirements, documentation and design evidence.
No. Threat modeling does not replace testing. It helps find problems earlier and plan tests better. The best approach combines threat modeling, code review, automated testing and manual testing.
Threat modeling is one of the most practical tools for product teams that want to build more secure software without waiting for a penetration test at the end of the project.
The key is a simple approach: define scope, understand the system, mark data and trust boundaries, identify threats, choose responses, turn outputs into tasks and return to the model when major changes happen.
Good threat modeling does not create documentation for its own sake. It creates better product decisions, better security requirements, better tests and lower risk for customers and the company.
We write about regulations such as NIS2, DORA, CRA and ISO 27001, cybersecurity for SMEs and critical infrastructure, as well as cyber hygiene, emerging threats and building security awareness within organisations.
Every article delivers practical knowledge - no jargon, just concrete steps you can act on to effectively protect your data, people and business continuity.