ARIANNA User Manual

Copyright © 2026 Security Pattern s.r.l. - All Rights Reserved

This document is private and confidential - Subject to N.D.A.

Introduction

ARIANNA is a Product Security platform that provides a comprehensive view of the security posture of IoT devices throughout their lifecycle.

It enables device manufacturers to implement an efficient and scalable Vulnerability Management Process while maintaining a complete model of the product's hardware, software, and security context.

To achieve this, the platform provides the following integrated capabilities:

• Device Model Management
• Continuous Vulnerability Monitoring
• Automatic Vulnerability Assessment
• Vulnerability Management
• Reporting and Security Insights

Device Model Management

ARIANNA enables the creation and management of a comprehensive Device Model that forms the foundation of Product Security activities. The Device Model includes the Hardware Bill of Materials (HBOM), the Software Bill of Materials (SBOM), together with assets, threats, mitigations, and security claims.

By combining architectural and security information into a single model, ARIANNA provides complete visibility into the product's security posture and supports vulnerability management, risk assessment, and regulatory compliance.

Continuous Vulnerability Monitoring

ARIANNA continuously monitors multiple external vulnerability intelligence sources to identify newly disclosed vulnerabilities and security advisories. Information collected from these sources is normalized, correlated, and consolidated into the ARIANNA Vulnerability Database, providing a trusted and continuously updated repository of vulnerability intelligence for subsequent assessment activities.

Automatic Vulnerability Assessment

The Automatic Vulnerability Assessment process correlates the Device Model (HBOM and SBOM) with the ARIANNA Vulnerability Database to identify vulnerabilities that may affect the device. ARIANNA automatically creates a Vulnerability Assessment Record and performs an initial applicability assessment by analyzing component versions, vendor advisories, applied patches, and other available evidence. This process eliminates non-applicable vulnerabilities, false positives, and assigns an initial assessment state, providing the basis for subsequent manual triage and remediation activities. This ensures that manufacturers are promptly notified when relevant vulnerabilities are discovered.

Vulnerability Management

Following the Automatic Vulnerability Assessment phase, ARIANNA supports the Vulnerability Triage, Addressing, and Closure activities. By combining information from the ARIANNA Vulnerability Database with the Device Model, the platform enables risk-based and exploitability-based prioritization of vulnerabilities. It also provides Security Experts with the information required to perform contextual analysis and to document the outcome of their assessment, including applicability decisions, accepted risks, remediation actions, mitigation measures, and the final vulnerability status.

Reporting and Security Insights

ARIANNA provides comprehensive reporting and security insights for both internal stakeholders and external parties, including customers, system integrators, auditors, certification bodies, and regulatory authorities. Based on the Device Model and the vulnerability management process, the platform generates reports that summarize all the evidence required to support Product Security activities and demonstrate compliance with applicable cybersecurity regulations and standards: the product's composition (HBOM and SBOM), security posture, risk assessments, vulnerability status, remediation and mitigation activities.

Basic Concepts

Device Model

ARIANNA, as a Product Security platform, shall provide a comprehensive view of the security posture of IoT devices throughout their lifecycle.

To achieve this, it is essential to create a Device Model that includes not only the software components (Software Bill of Materials, SBOM) but also the hardware components (Hardware Bill of Materials, HBOM).

Beyond the HBOM and SBOM, ARIANNA extends the Device Model with additional security-related information to provide a comprehensive representation of the product's security posture. These entities include:

• Assets. The resources and functions that require protection.
• Threats. Potential attacks that may compromise the assets.
• Mitigations. Security controls that reduce the likelihood or impact of threats and vulnerabilities.
• Security Claims. Verifiable statements describing the product's security properties, deployment assumptions, and operational characteristics, supporting risk assessments and regulatory compliance.

Components

The fundamental building block of a Device Model is the component. A component represents a hardware or software element that forms part of the device being modeled. Components are the entities against which vulnerability monitoring is performed. During the monitoring process, each component is analyzed to identify known vulnerabilities that may affect it.

Hardware Bill Of Material

Including hardware components in the Device Model through a Hardware Bill of Materials (HBOM) is essential for several reasons:

• Hardware components may also be affected by known vulnerabilities

• Hardware vulnerabilities are often more critical than software vulnerabilities because they typically affect the root of trust or fundamental system functionality.
• Unlike software vulnerabilities, hardware vulnerabilities often cannot be remediated through software updates and therefore require compensating mitigations to reduce the associated risk.

• The applicability and exploitability of software vulnerabilities may depend on the underlying hardware platform

• Some vulnerabilities can only be exploited when the affected software runs on a specific hardware architecture or processor family (e.g., ARM, RISC-V, or x86).

• Vulnerability management can be significantly improved by considering the hardware context in which the software is executed.

• The hardware context allows non-applicable attack vectors to be excluded during vulnerability assessment.
• It enables the identification of hardware components that manage critical assets or security-sensitive functions.
• It provides information about firmware update capabilities, including the available update mechanisms and the effort required to deploy a fix.

Software Bill Of Material

Once the main hardware blocks have been identified, the software associated with each block must be modeled and managed.

The Software Bill of Materials (SBOM) provides a structured inventory of all software components that compose a device. In the context of ARIANNA, its primary purpose is to support vulnerability management by accurately representing the software executed within the device.

Processing Unit

A Processing Unit (PU) is a logical construct that represents a hardware block together with the software executed on it, when applicable. It provides a structured representation of the device, enabling clear mapping of hardware and software components, their relationships, and the associated security information.

A PU defines a single execution or security environment and serves as the primary unit for vulnerability analysis. It is used to organize the components of a device according to their execution context and architectural boundaries.

A Processing Unit is not directly associated with vulnerabilities. Instead, vulnerabilities are associated with the individual hardware or software components contained within the Processing Unit. The PU provides the context required to assess the applicability, impact, and remediation of those vulnerabilities.

Group

To simplify device modeling and improve vulnerability management, the Device Model introduces the concept of Groups, a logical aggregation of components within a single Processing Unit (PU).

A Group represents a specific architectural layer, allowing related components to be evaluated as a single entity during vulnerability analysis.

Groups organize the hardware and software components of a Processing Unit according to the following layers:

• Hardware Layer. The base layer present in every Processing Unit (PU). It contains a single Group that aggregates all hardware components and physical interfaces belonging to the Processing Unit.
• Firmware Layer (for MCU-based systems). Contains one or more Groups, each representing a firmware image. Each Group aggregates all software components included in the corresponding firmware image.
• Operating System Layer (for MPU-based systems). Contains a single Group that aggregates the components belonging to the operating system, including the kernel, system libraries, drivers, and standard system utilities.
• Application Layer (for MPU-based systems). May contain one or more Groups, each corresponding to a specific customer application or software service. Each Group aggregates the software components required to build and execute that application.

Grouping components in this way improves the readability of the Device Model, simplifies the association of vulnerabilities with specific software artifacts, and enables vulnerability analysis and remediation activities to be performed at the appropriate architectural level.

Vulnerability

A vulnerability is a weakness, flaw, or defect present in a system component that could be exploited by a threat actor. Within the context of system architecture and security management, vulnerabilities may exist in both hardware and software elements.

In particular:

• A hardware vulnerability affects a component listed in the Hardware Bill of Materials (HBOM). It may arise from design flaws, implementation issues, misconfigurations, or undocumented behaviors in hardware elements such as processors, interfaces, controllers, or other physical components of the processing unit.
• A software vulnerability affects a component listed in the Software Bill of Materials (SBOM). These vulnerabilities may originate from coding errors, insecure libraries, outdated dependencies, improper configurations, or flaws in the operating system, firmware, or application software.

When exploited, a vulnerability can allow a threat actor to compromise one or more fundamental security properties of a system:

• Confidentiality, by gaining unauthorized access to sensitive data.
• Integrity, by modifying data, code, or system behavior in an unauthorized manner.
• Availability, by disrupting or preventing normal system operation.

Vulnerability Management Process

The Vulnerability Management Process is a structured and continuous process used by organizations to identify, assess, prioritize, remediate, and monitor security vulnerabilities in the hardware and software components included in a device. Its objective is to reduce security risks by ensuring that vulnerabilities are detected early and addressed in a timely and controlled manner.

ARIANNA envisions a four-stage vulnerability management process that covers the entire lifecycle, from vulnerability detection to final disclosure and communication:

1. Vulnerability Identification. Discover and collect security vulnerabilities affecting the product from internal and external sources.
2. Vulnerability Triage. Assess, validate, and prioritize vulnerabilities based on risk, exploitability, and product impact.
3. Vulnerability Addressing. Plan, implement, verify, and track remediation or mitigation actions for identified vulnerabilities.
4. Vulnerability (Dis)Closure. Communicate the vulnerability status, disclose security information when appropriate, and formally close the case.

Vulnerability Identification

The process begins with the identification of vulnerabilities affecting the device or system.
At this stage, all discovered vulnerabilities are collected from different sources such as vulnerability databases and security advisories. These vulnerabilities represent the initial set of potential security issues that may affect the device.

Vulnerability Triage

Once vulnerabilities are identified, they enter the triage phase, where automatic analysis is combined with expert validation to determine the actual security impact on the device.

This combination of automated filtering and contextual human analysis ensures that remediation efforts are focused on vulnerabilities that represent a serious risk for important assets and business.

As a result of the triage process, vulnerabilities are classified into different outcomes:

• Applicable vulnerabilities that require further investigations to define a remediation or mitigation plan
• Not applicable vulnerabilities that do not affect the device and that do not require any further investigations
• Accepted vulnerabilities where the risk is formally accepted according to the organization's risk management policy and can be temporaly mantained within the device with no furter imemdiate actions

Automatic Triage

ARIANNA implement automatic procedure aimed to suppression of non-applicable vulnerabilities and false-positive reduction by eliminating findings:

• The affected component version is not present.
• The component has been updated to a non-vulnerable version.
• The vulnerable code has been patched during the build process or by the manufacturer.
• The affected component or vulnerable functionality has been removed.
• The vulnerability does not match the actual software composition of the device.
• that have been re-evaluated by the source (previously applicable)

This automated validation significantly reduces false positives and allows security teams to focus only on vulnerabilities that may require further analysis.

ARIANNA performs Automatic Applicability Analysis to suppress non-applicable vulnerabilities and minimize false positives before manual triage. Vulnerabilities are automatically discarded when:

• The affected component version is no more present in the device (after a firmware/software update).
• The component has been updated to a non-vulnerable version.
• The vulnerable code has been patched during the build process or by the manufacturer.
• The vulnerability has been re-evaluated by the original advisory source and is no longer considered applicable.

By automatically eliminating non-applicable findings, ARIANNA significantly reduces false positives and enables security teams to better focus their manual triage.

Manual Triage

Security experts then review the remaining vulnerabilities to determine:

• Whether the vulnerability actually affects the deployed device.
• The real risk considering the product architecture, configuration, deployment environment, and intended use.
• The remediation priority based on exploitability, business impact, and regulatory requirements.

Vulnerability Addressing

For vulnerabilities confirmed as applicable and requiring action, the next stage consists of addressing the vulnerability.

This may involve:

• Fixing the vulnerability by applying patches or updating components
• Removing the vulnerable component, if not fundamental to implement device functionalities
• Implementing mitigation measures to reduce the risk when a fix is not immediately available

At the end of this phase, vulnerabilities are typically marked as Fixed or Mitigated.

Vulnerability (Dis)Closure

The final stage consists of formally recording the outcome of the vulnerability management process and communicating the results to relevant stakeholders.

During the Vulnerability Triage and Vulnerability Addressing phases, the vulnerability status and supporting evidence are progressively determined and documented.

ARIANNA records this information in a format largely compatible with the CycloneDX Vulnerability Analysis model, including:

• State: The final analysis state of the vulnerability (e.g., exploitable, not affected, resolved, false positive).
• Justification: The rationale supporting the assigned state.
• Detail: A detailed description of the assessment, including the methods used and the evidence supporting the decision.

The Vulnerability (Dis)Closure phase then:

• Confirms the final vulnerability status and closes the vulnerability management record.
• Preserves the complete analysis and decision history for traceability and audit purposes.

This stage ensures that every vulnerability has a documented, traceable, and auditable outcome, maintaining a complete history of the decision-making process.

All this information can be used to communicate the outcome internally or externally, as required by organizational policies or supply chain stakeholders, while providing the traceability and evidence needed to demonstrate compliance with applicable standards and regulations.

ARIANNA Project

An ARIANNA Project represents the logical container used to monitor and manage the security of a specific product, device, or system over time.

Within a project, the security team can create Device Models, track vulnerabilities, and manage the entire vulnerability management lifecycle. It provides a collaborative environment where authorized users can review and triage vulnerabilities, update vulnerability statuses, assign risk levels, and document analysis activities.

By organizing security activities within projects, ARIANNA enables teams to maintain structured vulnerability tracking, prioritize remediation efforts, and ensure continuous monitoring throughout the product lifecycle.

Getting Started

Device description

Device description is performed during the first onboarding of a product to identify all Processing Units (PUs) that constitute the device architecture.

Accurately identifying and describing all the Processing Units is essential to correctly map the device architecture and to support subsequent security analysis activities.

Processing Unit identification and description

Each Processing Unit is uniquely identified and described by the following attributes:

• Unique Identifier. A unique identifier assigned by ARIANNA to distinguish the Processing Unit within the Device Model.
• Name. A human-readable name.
• Description. An optional description of the Processing Unit functionality and role.
• Type. The hardware category represented by the Processing Unit.
• System Type. The software execution environment associated with the Processing Unit (e.g. Windows, Linux, Real-Time Operating System (RTOS), Bare Metal, Third-Party Binary, ROM Code)
• Hardware Vendor. The manufacturer of the hardware.
• Hardware Part Number. The vendor-assigned part number identifying the hardware component or a family of hardware components.
• Interfaces. The communication interfaces available and active in the Processing Unit (e.g. Ethernet, CAN, UART, SPI, I²C, USB, BLE, Wi-Fi).

Processing Unit Type

Each Processing Unit is assigned one of the following types:

• Microcontroller (MCU). An integrated circuit combining a processor core, memory, and peripheral interfaces, optimized for embedded control applications.
• Microprocessor (MPU). A processor core, typically without integrated memory or peripherals, designed for general-purpose or high-performance computing.
• Memory. A hardware element (volatile or non-volatile) dedicated to storing instructions, data, or intermediate processing results.
• Hardware Model. A dedicated functional block or subsystem implemented in hardware to execute specific operations (e.g., digital signal processing, encryption acceleration, I/O control).
• Secure Element (SE). A tamper-resistant hardware component providing secure storage of cryptographic material and execution of sensitive operations.

Device Model creation

Device Model creation is performed during the first onboarding of a product to identify the initial Hardware Bill of Materials (HBOM) and Software Bill of Materials (SBOM) associated with each Processing Unit (PU) defined during the device description phase.

Whenever a new firmware or software version is deployed, the Device Model creation process is executed again to identify the updated set of software components (SBOM). Since the hardware architecture is unchanged, the existing HBOM is reused unless a new hardware revision of the device is introduced.

ARIANNA provides dedicated support for the creation and management of both the HBOM and the SBOM, enabling an accurate and up-to-date representation of the device architecture and its associated hardware and software components.

Hardware Bill Of Material creation

Hardware component identification relies on the information already provided during the device description, specifically the hardware vendor name and hardware part number of each Processing Unit. No additional analysis activities are required from the user.

Using this information, ARIANNA automatically queries its internal database to identify the corresponding hardware components and determine whether they include additional embedded or associated components, such as integrated modules, processing cores, memories, communication interfaces, or secure elements.

This automatic enrichment process expands the HBOM to provide a more complete and accurate representation of the device hardware architecture, forming the foundation for subsequent vulnerability analysis, risk assessment, and Product Security activities.

Software Bill Of Material creation

Software components are identified with different techniques, based on the software stack deployed on each Processing Unit (PU).

The complexity of the software component identification process varies according to the nature of the system running on each Processing Unit:

• In case the PU is a Hardware Module, the list of identifiable software components may be limited to the firmware binary provided by the module manufacturer. In such cases, the internal structure of the software stack may not be accessible, and the analysis may only reference the provided binary as a single software component.
• In case the PU is a Microcontroller Unit (MCU), the analysis may include all the software components provided by the silicon vendor, such as low-level drivers, Hardware Abstraction Layer (HAL) libraries, and the toolchain used to build the firmware. In addition, the analysis may also include third-party libraries integrated into the firmware to implement specific protocols or functionalities, such as a Bluetooth software stack or other communication and application libraries.
• In case the PU is a Microprocessor Unit (MPU) running a full operating system, the analysis becomes more complex. The identification of software components must include both the Operating System layer (e.g., kernel, system libraries, and standard utilities) and the application layer, which consists of all customer-developed or third-party applications running on top of the operating system.

Software Composition Analysis (SCA) Tool

To automate the extraction of software components information and help generate an accurate Software Bill of Materials (SBOM), ARIANNA provides proprietary Software Composition Analysis (SCA) tools solutions.

Since the creation of the Software Bill of Materials (SBOM) is primarily oriented toward vulnerability management, the usage of ARIANNA SCA tools is aimed to significantly improve the accuracy and effectiveness of vulnerability correlation and security analysis.

The tools enforce precise and standardized component naming, which is essential for correctly correlating identified components with known vulnerabilities. Without consistent naming conventions, mapping software components to vulnerability databases would be unreliable or, in some cases, impossible.

Environment-Specific SCA Tools

Since the complexity of the software component identification process varies according to the nature of the framework used to build the firmware, ARIANNA provides multiple SCA tools, each one implementing a different analysis technique designed for a specific technology stack or execution environment.

Examples include:

• Operating System analysis (e.g., Debian, Ubuntu, Alpine, YOCTO, Buildroot, OpenWRT, Windows, Android)
• Application layer analysis (e.g., .NET, Python, PHP, JavaScript)
• MCU SDK analysis (e.g., Espressif ESP-IDF, STMicroelectronics STM32Cube SDK, NXP MCUXpresso SDK, Zephyr)
• Cloud and container environments analysis

This modular approach ensures accurate component identification across a wide range of heterogeneous frameworks.

SCA Tools design

The ARIANNA process for SBOM creation is designed to minimize impact on the development workflow and on the target device.

For this reason ARIANNA SCA Tools are designed to be lightweight, with no external dependencies, easy to be integrated into CI/CD pipelines.

ARIANNA SCA tools are delivered as on-premise scripts (Python, Bash, or PowerShell) that can be executed either in the development environment or directly on the target system. The appropriate execution environment is determined by the build framework and the location of the artifacts required to accurately identify the software components that compose the firmware.

In particular:

• Source code disclosure is not required, allowing manufacturers to maintain full control over proprietary software assets.
• No reverse engineering of binaries is performed, avoiding the generation of inaccurate SBOMs that may include missing components or incorrectly identified versions.
• No agents are installed on target devices, ensuring a non-invasive approach that does not interfere with firmware or software maintenance.

Agent-based approaches can introduce operational complexity, as such agents would need to be maintained and updated throughout the device lifecycle. ARIANNA avoids this issue by relying on external analysis tools executed in the development environment.

SCA Tool Output

The output of an ARIANNA SCA Tool is a structured text file containing the list of software components identified within the analyzed firmware or software. At a minimum, the output includes the following information for each component:

• Component vendor
• Component name
• Component version

Whenever supported by the target build framework and its available metadata, the SCA Tool also extracts additional information, including:

• Component license
• Applied patches
• Component dependencies
• Enabled and disabled features

The extracted information is used by ARIANNA to build or update the Software Bill of Materials (SBOM) associated with the corresponding Processing Unit (PU).

Integration into Development Workflows

ARIANNA SCA Tools can be executed either as standalone utilities or integrated into automated software development workflows.

In standalone mode, the generated output file can be uploaded to the ARIANNA platform through the Web User Interface to create or update the Device Model.

In integrated mode, SCA Tools are executed automatically as part of the CI/CD pipeline, and the generated output is submitted to ARIANNA through its REST APIs. Typical integration scenarios include:

• Automatically executing SCA Tools after each firmware or software release.
• Automatically uploading the generated output file to create or update an existing Device Model.
• Automatically triggering the Automatic Vulnerability Assessment process for the new software version.

This integration enables continuous Product Security monitoring by ensuring that every firmware or software release is automatically analyzed and assessed against the latest vulnerability intelligence available in the ARIANNA Vulnerability Database.

Component identification and description

Each Software and Hardware Component is uniquely identified and described by the following attributes:

• Unique Identifier. A unique identifier assigned by ARIANNA to distinguish the component within the Device Model.
• Ecosystem. The software ecosystem to which the component belongs (e.g., Debian, Ubuntu, YOCTO, python, Java, ESP-IDF).
• Type. The component type (e.g., hardware, firmware, operating system, library, application).
• Vendor Name. The organization or individual responsible for producing the component.
• Name. The component name.
• Version. The specific version or release of the component.
• License. The software license associated with the component, where applicable.
• Group. The Group within the Processing Unit to which the component belongs.

Component Type

Each component is assigned a type that identifies its role within the Device Model. Component types are derived from the CycloneDX specification and adapted where necessary to support IoT device modeling:

• Device (HW). Assigned to hardware components
• Firmware (FW). Assigned to firmware images provided as binary code (usually distributed by hardware vendors or third parties)
• Library (LIB). Assigned to software libraries, middleware, and third-party applications.
• Application (APP). Assigned to customer-developed application software.
• Operating System (OS). Assigned to Operating Systems.

Component Status

The component status tracks the lifecycle of components across Device Model versions. It indicates whether a component is present in the current version of the Device Model or has been removed as a result of a firmware or software update:

• Active. The component is present in the current version of the Device Model. This is the default status when the component is created or identified.
• Not Active. The component is no longer present in the current version of the Device Model, typically because it has been removed following a firmware or software update. Thai status is automatically set by ARIANNA during the Device Model update process.

Automatic Vulnerability Assessment

Vulnerability Assessment records are automatically generated by ARIANNA on a daily basis to provide continuous visibility into the security posture of the analyzed device.

ARIANNA performs daily vulnerability monitoring for every device under analysis based on its Device Model, relying on an internal database that maps hardware and software components to their associated vulnerabilities. By correlating the HBOM and SBOM information with vulnerability intelligence sources, ARIANNA can automatically detect newly disclosed vulnerabilities that may affect the monitored devices.

To maintain up-to-date vulnerability intelligence, ARIANNA continuously monitors several public vulnerability databases, including:

• NIST National Vulnerability Database (NVD)
• CVE.org
• GitHub Security Advisories
• European Vulnerability Database (EUVD)

For each identified vulnerability, ARIANNA also collects additional security intelligence to support vulnerability prioritization and risk evaluation. This includes information such as:

• Known Exploited Vulnerabilities from the CISA KEV Catalog
• Exploit availability and exploit maturity level (e.g., Proof-of-Concept exploit or verified weaponized exploit)
• EPSS (Exploit Prediction Scoring System) index, which estimates the probability of exploitation
• CWE (Common Weakness Enumeration) classification information

By aggregating and correlating these data sources, ARIANNA enables effective vulnerability prioritization and risk assessment, helping security teams focus on vulnerabilities that pose the greatest risk to the device.

Device Model lifecycle management

A Device Model represents a specific combination of hardware and software deployed in the field. For this reason, during the device lifecycle, the Device Model must be periodically updated or adjusted:

• The HBOM typically remains constant, since the hardware architecture of the device does not change during its lifecycle.
• The SBOM must instead be updated every time a new firmware or software version is released, such as in the case of operating system updates, application updates, or firmware updates.

ARIANNA allows manufacturers to create and manage multiple versions of a Device Model, while keeping track of their evolution over time. To maintain clear control over the different Device Models, it is important to define a consistent versioning strategy. Common approaches include:

• Semantic Versioning: uses a three-part version number (MAJOR.MINOR.PATCH). The different fields indicate breaking changes, new features, or bug fixes.
• Calendar Versioning: Uses dates (for example YY.MM or Year.Release) to indicate versions, reflecting the device model creation time.

When a new version of a Device Model is created, the SBOM may change in several ways:

• New components may be added
• Existing components may be updated
• Existing components may be removed

As a consequence, the vulnerability status associated with the device may also change:

• New vulnerabilities may be reported

• if a new component is introduced
• if an existing component is updated

• Existing vulnerabilities may maintain their status or be automatically closed

• if the affected component is updated to a non-vulnerable version
• if the affected component is removed from the system

These updates and vulnerability status adjustments are automatically handled by the ARIANNA platform, ensuring that vulnerability assessments records remain accurate and aligned with the current device configuration.

Vulnerability Assessment records

Each Vulnerability Assessment record produced by ARIANNA provides all the information to support the continuous vulnerability management process, enabling organizations to monitor newly disclosed vulnerabilities, assess their impact on the device, and prioritize appropriate mitigation or remediation actions.

Vulnerability Assessment Records are organized into multiple sections:

• Overview & Statistics section
• Device Model section. The specific device model to which the analysis applies, with a structured inventory of all identified components, organized by Processing Unit (PU) and Groups
• Identified Vulnerabilities. A list of vulnerabilities associated with the device model, based on the correlation between the identified components and publicly available vulnerability databases.
• Vulnerability Details. Relevant information associated with each vulnerability, such as identifiers, severity, affected components, and references.
• Vulnerability Management Status. The current management status of each identified vulnerability
• Highlights and Prioritization Advice. Key findings and recommendations to support the prioritization of remediation activities.

Overview & Statistics section

This section of the report contains charts and graphs that provide a visual overview of the current security status of the device under analysis. These visual indicators help stakeholders quickly understand the vulnerability landscape and monitor the evolution of security risks over time.

The dashboard typically includes the following metrics:

• Number of Open and Closed Vulnerabilities: A summary of vulnerabilities that are currently unresolved versus those that have been closed.
• Risk Associated with Open Vulnerabilities: An aggregated representation of the overall risk level associated with currently open vulnerabilities.
• Priority Level of Open Vulnerabilities: A classification of open vulnerabilities based on their remediation priority (high or low).
• Justification Associated with Closed Vulnerabilities: Documentation of the reasons for closing vulnerabilities, such as components removed, patched or updated, risk accepted, not applicable or false positives.
• Number of Open Vulnerabilities Over Time: A trend chart showing how the total number of unresolved vulnerabilities evolves over time.
• Risk Level of Open Vulnerabilities Over Time: A graphical representation of how the overall risk associated with open vulnerabilities changes throughout the monitoring period.
• New Vulnerability Notifications and Vulnerability Closures Over Time: A timeline showing the rate at which new vulnerabilities are identified and existing vulnerabilities are resolved.

These visual metrics support continuous monitoring and decision-making, enabling security teams to track vulnerability trends, evaluate the effectiveness of remediation activities, and prioritize security efforts accordingly.

Device Model section

This section describes the Device Model, listing all hardware and software components identified during the Device Model creation stage.

Components are organized according to the Processing Units (PUs) that compose the device. Each PU is described in a dedicated subsection, providing a clear view of the components associated with that specific processing unit.

Within each Processing Unit, components are further organized into groups, which aggregate components according to their origin or functional layer (for example, operating system components, customer applications, firmware components, or third-party libraries).

For each component, it is possible to review the associated vulnerabilities, enabling a detailed understanding of the security posture of the device.

Component Type

Specifies the category of the component, such as software library, hardware component, binary, or application.

Component Vendor Name

Identifies the supplier or manufacturer of the component.

Component Name

The unique name of the component as defined by the vendor.

Component Version

Indicates the specific version or build of the component currently used in the device.

Component License

Provides information about the licensing model of the component (e.g., GPL, MIT, proprietary).

Component Status

Indicates whether the component is currently ACTIVE or NOT ACTIVE within the device configuration.

Component Group

Specifies the group to which the component belongs, allowing components to be aggregated based on their origin or functional role (e.g., operating system, firmware, customer application).

Component Dependencies

Provides information about dependencies between components, helping to understand the relationships within the software stack.

Component Vulnerability counters

Each component is associated with vulnerability counters that indicate:

• the number of open vulnerabilities, classified by risk level
• the number of closed vulnerabilities

This structure makes it possible to sort and analyze components based on the number of open vulnerabilities, enabling users to quickly identify components that represent the most critical security risks within the device.

Component Warnings

Each component may be associated with a set of warnings that provide additional information about its status or highlight situations that may require attention from the security team.

Informative Warnings

Informative warnings indicate changes in the component status between different versions of the Device Model. These warnings help track the evolution of the software across device model versions:

• New Component: indicates that the component has been added in the current version of the Device Model.
• Updated Component: indicates that the component has been updated to a new version in the current Device Model.
• Downgraded Component: indicates that the component has been replaced with an older version compared to the previous Device Model.
• Removed Component: indicates that the component has been removed from the current Device Model.

Warnings Requiring Special Attention

Some warnings may require manual verification or corrective actions by the security team:

• Unmapped Component: indicates that the component is not present in the ARIANNA internal database. As a result, ARIANNA cannot currently identify vulnerabilities associated with that component. This situation may occur if the component does not appear in public vulnerability databases and therefore is not yet tracked in ARIANNA. In such cases, the absence of vulnerabilities may be legitimate, but the component should still be reviewed to confirm its identification.
• Unversioned Component: indicates that the component version was not provided during the Device Model creation stage. This may happen for several reasons:

• The SCA tool was not able to automatically retrieve the version information from the development environment.
• The version information is not available in the analyzed context.

When the version is unknown, ARIANNA reports all vulnerabilities potentially associated with the component, regardless of the version. This conservative approach ensures that no relevant vulnerabilities are missed, but it may also generate false positives. For this reason, the security team should attempt to manually retrieve and specify the correct version whenever possible.

Vulnerabilities section

This section provides a complete list of vulnerabilities affecting the device under analysis.

While the Device Model section presents vulnerabilities organized by component, this section displays them as a flat list, offering a consolidated view of all vulnerabilities associated with the device.

To provide a clearer understanding of the current status of the vulnerability management process, the vulnerabilities are organized into several subsections that reflect the different stages of the management workflow:

• Unmanaged: vulnerabilities that have been notified but have not yet been evaluated by the security team.
• In Triage: Vulnerabilities for which the triage process is currently ongoing, including analysis of applicability, impact, and risk level.
• In Progress: Vulnerabilities for which remediation or mitigation activities are currently being implemented.
• Planned Closure: Vulnerabilities for which remediation or mitigation activities have been completed, but whose final resolution will be delivered in the next software or firmware release. If the resolution involves actions such as component updates, patches, or component removal, ARIANNA will automatically detect and confirm the closure in the first vulnerability report generated for the next version of the Device Model.
• Closed: Vulnerabilities that have already been successfully managed and resolved, either through remediation, mitigation, risk acceptance, or confirmation of non-applicability.
• Reopened: Vulnerabilities that were previously closed but have been reopened, either manually by the security team or automatically by ARIANNA, for example due to new vulnerability information or changes in the device configuration.

The vulnerability information included in the report is designed to provide the necessary metrics and intelligence to support prioritization, enabling the security team to efficiently manage triage, remediation, and mitigation activities within the vulnerability management process.

Vulnerability External ID

This refers to the unique identifier assigned to a vulnerability in the public database where it was disclosed. In most cases, this identifier is a CVE (Common Vulnerabilities and Exposures) ID, which is used to uniquely identify a specific vulnerability.

The usage of a well known identifier enables a vulnerability to be consistently referenced across different platforms, tools, and security sources, ensuring a common and standardized way to track and discuss vulnerabilities.

Creation Date

The date when the vulnerability was first reported or discovered in external databases. This date helps track how long a vulnerability has been known in the security community and may be used to prioritize updates and remediation efforts.

Update Date

The most recent date when information about the vulnerability was updated in external databases, whether it’s new patches, mitigations, or any changes in its severity or status.

Description

A detailed description of the vulnerability, including how it works, the systems it affects, and its potential impact. This helps security professionals understand the nature of the vulnerability and its relevance to their environment.

Remediations

List of known mitigations and fixes:

• Mitigations are steps or measures that can be taken to reduce the likelihood or impact of the vulnerability. This might include configuration changes, temporary workarounds, or specific guidance on preventing exploitation.
• Fixes are patches or component updates released by vendors to address the vulnerability.

Exploits

List of known exploits and their maturity level. It refers to any documented attempts, tools, or techniques that can actively exploit the vulnerability.

The maturity level indicates how developed and usable the exploit is:

• Exploit Ready: The exploit is fully weaponized and ready to be used by automated tools or attack frameworks.
• Exploit Verified: Public exploit code exists and has been verified by a trusted source.
• Proof of Concept (PoC): Public exploit code is available, but it has not yet been verified by a trusted source.

When available, links to the exploit code or related resources may also be included to help the security team better understand the exploit technique, attack method, and potential impact.

Weakness Class (CWE)

The Common Weakness Enumeration (CWE) is a classification system used to categorize software weaknesses and vulnerabilities. It provides a standardized taxonomy that helps identify the underlying type of flaw in software or hardware, such as improper input validation, buffer overflows, or authentication issues.

By mapping vulnerabilities to a CWE category, security teams can better understand the root cause of the issue, support risk analysis, and identify appropriate mitigation strategies.

KEV

This field is a boolean value indicating whether the vulnerability is classified as a Known Exploited Vulnerability (KEV) according to one of the authoritative intelligence sources monitored by ARIANNA.

Examples of these sources include:

• Publicly reported vulnerabilities listed in the CISA Known Exploited Vulnerabilities (KEV) catalog
• Vulnerabilities with verified exploitation evidence referenced in the European Vulnerability Database (EUVD)

By aggregating information from these sources, this metric provides greater visibility into vulnerabilities that are known to be actively exploited in real-world environments.

Severity

The Common Vulnerability Scoring System (CVSS) provides a numeric score (ranging from 0 to 10) that represents the severity of a vulnerability. The CVSS provides a way to capture the principal characteristics of a vulnerability, and produce a numerical score reflecting its severity, as well as a textual representation of that score. The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes.

CVSS is not used as a measure of risk.

Attack Vector

This metric reflects the context by which vulnerability exploitation is possible. Can have the following values:

• Network: a vulnerability exploitable with network access means the vulnerable component is bound to the network stack and the attacker's path is through OSI layer 3 (the network layer). Such a vulnerability is often termed "remotely exploitable" and can be thought of as an attack being exploitable one or more network hops away (e.g. across layer 3 boundaries from routers). An example of a network attack is an attacker causing a denial of service (DoS) by sending a specially crafted TCP packet from across the public Internet.
• Adjacent: A vulnerability exploitable with adjacent network access means the vulnerable component is bound to the network stack, however the attack is limited to the same shared physical (e.g. Bluetooth, IEEE 802.11), or logical (e.g. local IP subnet) network, and cannot be performed across an OSI layer 3 boundary (e.g. a router). An example of an Adjacent attack would be an ARP (IPv4) or neighbor discovery (IPv6) flood leading to a denial of service on the local LAN segment. See also CVE 2013 6014.
• Local: A vulnerability exploitable with Local access means that the vulnerable component is not bound to the network stack, and the attacker's path is via read/write/execute capabilities. In some cases, the attacker may be logged in locally in order to exploit the vulnerability, otherwise, she may rely on User Interaction to execute a malicious file.
• Physical: A vulnerability exploitable with Physical access requires the attacker to physically touch or manipulate the vulnerable component. Physical interaction may be brief (e.g. evil maid attack) or persistent. An example of such an attack is a cold boot attack which allows an attacker to access to disk encryption keys after gaining physical access to the system, or peripheral attacks such as Firewire/USB Direct Memory Access attacks.

EPSS

The Exploit Prediction Scoring System (EPSS) is a data-driven effort for estimating the likelihood (probability) that a software vulnerability will be exploited in the wild. The goal is to better prioritize vulnerability remediation efforts. While other industry standards have been useful for capturing innate characteristics of a vulnerability and provide measures of severity, they are limited in their ability to assess threats. EPSS fills that gap because it uses current threat information from CVE and real-world exploit data. The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

Risk

This metric represents the risk associated with a vulnerability, and is defined by the customer (according to the procedure defined internally to the company). By default its value is set equal to severity class. It can have one of the following values:

• Undefined
• Low
• Medium
• High
• Critical

Age

This value represents the time passed since the first notification by ARIANNA.

Status

This value indicates the detailed status of the vulnerability within the ARIANNA vulnerability management pipeline.

A vulnerability can be in one of these status:

• Open

• UNMANAGED
• IN TRIAGE
• IN PROGRESS
• PLANNED CLOSURE

• PLANNED MITIGATION

• Mitigation will be implemented to reduce risk (before moving to ACCEPTED)

• PLANNED REMOVAL

• Vulnerability will be REMEDIATED by removing the component

• PLANNED UPDATE

• Vulnerability will be REMEDIATED by updating the component

• PLANNED PATCH

• Vulnerability will be REMEDIATED by patching the component

• Closed

• NOT APPLICABLE

• Vulnerable feature or component not used
• Vulnerability associated to the wrong component
• Vulnerability associated to the wrong component version

• REMEDIATED

• COMPONENT REMOVED

• Vulnerability no more present in the system after component removal

• COMPONENT UPDATED

• vulnerability no more present in the system after component update

• COMPONENT PATCHED

• vulnerability no more present in the system after component patch

• FALSE POSITIVE

• Vulnerability re-assesed after initial notification

• ACCEPTED

• Vulnerability threat accepted due to low risk (low impact or low likelihood)

Triage & assessment information

A set of information provided to support the triage process. These details help the security team assess the vulnerability more effectively, enabling a better understanding of its impact, relevance, and priority within the vulnerability management process.

Action history

Record of all actions performed during the vulnerability management process. It includes the history of status changes, notes, and risk updates made by the security team.

The action history serves as evidence of the analysis and decisions taken over time, ensuring traceability and transparency in the vulnerability assessment and management activities.

Prioritization section

In this section, vulnerabilities are automatically classified as High or Low priority by the ARIANNA Pre-Triage & Prioritization Engine. This initial classification helps the security team quickly identify the vulnerabilities that require immediate attention, supporting a more efficient triage and remediation process.

Highlights section

In this section, vulnerabilities are automatically classified according to different criteria to improve visibility and help the security team focus on the most relevant items.

The following categories are used:

• New Vulnerabilities: Vulnerabilities that have been recently notified.
• Latest Actions: Vulnerabilities for which a recent status change has been performed.
• Expired: Vulnerabilities that have not yet been closed and whose remediation deadline, defined in the vulnerability management policy, has already passed.
• Expiring: Vulnerabilities that are still open and approaching the deadline defined by the vulnerability management policy.
• Top CWE: Vulnerabilities associated with a CWE included in widely recognized risk lists, such as the Mitre Top 25 or the OWASP Top 10. These weaknesses are commonly linked to high-impact or frequently exploited security issues.

Features

Device Model lifecycle management

SBOM & HBOM creation

ARIANNA provides dedicated SCA tools to create a precise model of the device to be monitored. Such Device Model includes both software and hardware components (SBOM & HBOM), proprietary or from third parties. Once the first device model has been created, users can keep it up to date after changes to the software stack or after addition/removal of components.

Device Model update

Device Model evolves during the device lifecycle

• HBOM remains constant
• SBOM must be updated every time a new FW / SW is released

When a new version of the Device Model is created, ARIANNA allows to maintain a link with an old Device Model, to keep valid the Triage activities already done:

• Old Vulnerabilities maintain the status or could be automatically closed

• If the affected component is UPDATED
• If the affected component is REMOVED

• New Vulnerabilities could be notified

• If a new component is added
• If an old component is UPDATED

Continuous Vulnerability monitoring

ARIANNA monitors all relevant vulnerability and exploit databases daily, implementing continuous monitoring and reporting of known vulnerabilities.

Vulnerability Management Process support

ARIANNA supports a comprehensive vulnerability management process through the implementation of a predefined Vulnerability Management Pipeline.

The pipeline consists of the following four stages:

1. Identification
2. Triage
3. Addressing
4. Closure

Each stage is associated with one or more vulnerability states that represent the current status of a Vulnerability Assessment Record within the management process pipeline.

The transition between states may be performed automatically by ARIANNA or manually by a Security Expert, depending on the available information.

Every state transition is recorded in the vulnerability history together with the associated metadata, ensuring complete traceability of the decision-making process throughout the lifecycle of each vulnerability. This audit trail provides evidence of all assessment, prioritization, remediation, mitigation, and closure activities, supporting regulatory compliance and security audits.

ARIANNA supports a comprehensive vulnerability management process through the implementation of a predefined Vulnerability Management Pipeline.

ARIANNA envisions a four-stage vulnerability management process that covers the entire lifecycle, from vulnerability detection to final disclosure and communication:

1. Vulnerability Identification. Discover and collect security vulnerabilities affecting the product from internal and external sources.
2. Vulnerability Triage. Assess, validate, and prioritize vulnerabilities based on risk, exploitability, and product impact.
3. Vulnerability Addressing. Plan, implement, verify, and track remediation or mitigation actions for identified vulnerabilities.
4. Vulnerability (Dis)Closure. Communicate the vulnerability status, disclose security information when appropriate, and formally close the case.

Vulnerability Identification

The process begins with the identification of vulnerabilities affecting the device or system.
At this stage, all discovered vulnerabilities are collected from different sources such as vulnerability databases and security advisories. These vulnerabilities represent the initial set of potential security issues that may affect the device.

Vulnerability Triage

Once vulnerabilities are identified, they enter the triage phase, where automatic analysis is combined with expert validation to determine the actual security impact on the device.

This combination of automated filtering and contextual human analysis ensures that remediation efforts are focused on vulnerabilities that represent a serious risk for important assets and business.

As a result of the triage process, vulnerabilities are classified into different outcomes:

• Applicable vulnerabilities that require further investigations to define a remediation or mitigation plan
• Not applicable vulnerabilities that do not affect the device and that do not require any further investigations
• Accepted vulnerabilities where the risk is formally accepted according to the organization's risk management policy and can be temporaly mantained within the device with no furter imemdiate actions

Automatic Triage

ARIANNA implement automatic procedure aimed to suppression of non-applicable vulnerabilities and false-positive reduction by eliminating findings:

• The affected component version is not present.
• The component has been updated to a non-vulnerable version.
• The vulnerable code has been patched during the build process or by the manufacturer.
• The affected component or vulnerable functionality has been removed.
• The vulnerability does not match the actual software composition of the device.
• that have been re-evaluated by the source (previously applicable)

This automated validation significantly reduces false positives and allows security teams to focus only on vulnerabilities that may require further analysis.

ARIANNA performs Automatic Applicability Analysis to suppress non-applicable vulnerabilities and minimize false positives before manual triage. Vulnerabilities are automatically discarded when:

• The affected component version is no more present in the device (after a firmware/software update).
• The component has been updated to a non-vulnerable version.
• The vulnerable code has been patched during the build process or by the manufacturer.
• The vulnerability has been re-evaluated by the original advisory source and is no longer considered applicable.

By automatically eliminating non-applicable findings, ARIANNA significantly reduces false positives and enables security teams to better focus their manual triage.

Manual Triage

Security experts then review the remaining vulnerabilities to determine:

• Whether the vulnerability actually affects the deployed device.
• The real risk considering the product architecture, configuration, deployment environment, and intended use.
• The remediation priority based on exploitability, business impact, and regulatory requirements.

Vulnerability Addressing

For vulnerabilities confirmed as applicable and requiring action, the next stage consists of addressing the vulnerability.

This may involve:

• Fixing the vulnerability by applying patches or updating components
• Removing the vulnerable component, if not fundamental to implement device functionalities
• Implementing mitigation measures to reduce the risk when a fix is not immediately available

At the end of this phase, vulnerabilities are typically marked as Fixed or Mitigated.

Vulnerability (Dis)Closure

The final stage consists of formally recording the outcome of the vulnerability management process and communicating the results to relevant stakeholders.

During the Vulnerability Triage and Vulnerability Addressing phases, the vulnerability status and supporting evidence are progressively determined and documented.

ARIANNA records this information in a format largely compatible with the CycloneDX Vulnerability Analysis model, including:

• State: The final analysis state of the vulnerability (e.g., exploitable, not affected, resolved, false positive).
• Justification: The rationale supporting the assigned state.
• Detail: A detailed description of the assessment, including the methods used and the evidence supporting the decision.

The Vulnerability (Dis)Closure phase then:

• Confirms the final vulnerability status and closes the vulnerability management record.
• Preserves the complete analysis and decision history for traceability and audit purposes.

This stage ensures that every vulnerability has a documented, traceable, and auditable outcome, maintaining a complete history of the decision-making process.

All this information can be used to communicate the outcome internally or externally, as required by organizational policies or supply chain stakeholders, while providing the traceability and evidence needed to demonstrate compliance with applicable standards and regulations.

Automatic Management

ARIANNA automatically updates the state of a vulnerability whenever it collects objective evidence demonstrating that the vulnerability is no longer applicable to the analysed product version.

Typical examples include:

• The vulnerable component has been updated to a non-vulnerable version.
• The vulnerable component has been patched.
• The vulnerable component has been removed from the product.
• The vulnerability analysis published by the vulnerability source has been updated (e.g., the vulnerability is reclassified as a false positive or no longer affects the component).

When such evidence is identified, ARIANNA automatically updates the vulnerability state accordingly without requiring manual intervention.

Manual Management

If ARIANNA cannot automatically determine the appropriate closure of a vulnerability, the vulnerability shall be reviewed by a Security Expert.

The Security Expert can update the status of a vulnerability to reflect its current stage in the vulnerability management pipeline.

• IN TRIAGE. The vulnerability is under analysis to determine its applicability, impact, exploitability, and remediation priority.
• IN PROGRESS. Remediation or mitigation activities have started and are currently in progress.
• Planned Mitigation. A mitigation has been planned to reduce the associated risk. Once implemented and verified, the vulnerability status can be set to Accepted Risk since the residual risk is considered acceptable.
• Planned Removal. Remediation has been planned by removing the affected component or functionality
• Planned Update. Remediation has been planned by updating the affected component to a non-vulnerable version.
• Planned Patch. Remediation has been planned by updating the affected component to a non-vulnerable version.
• Not Applicable. The vulnerability does not affect the product. The decision shall be supported by one or more verified Security Claims and documented assessment evidence.
• Accepted. The vulnerability affects the product, but the residual risk is considered acceptable. The decision shall be supported by one or more Mitigations and/or verified Security Claims.
• REMEDIATED

• COMPONENT PATCHED

Every manual disposition shall be documented together with the supporting evidence to ensure traceability, repeatability and auditability of the security assessment throughout the product lifecycle.

Not Applicable Vulnerabilities

A vulnerability is classified as Not Applicable when it can be demonstrated that the conditions required for exploitation do not exist in the product.

The disposition shall be supported by one or more verified Security Claims describing characteristics of the delivered product that prevent the vulnerability from being applicable.

Typical examples include:

• The vulnerable component is not used in the product.
• The vulnerable code is not present in the released firmware.
• The affected feature is permanently disabled.
• The required dependency is not included.
• The vulnerable interface is not exposed.
• The attack vector is not present.

Security Claims shall be verified by the Manufacturer before the product is released and demonstrate that the vulnerability cannot affect the delivered product.

Accepted Vulnerabilities

A vulnerability is classified as Accepted when it remains applicable but the residual risk is considered acceptable.

The disposition shall be supported by:

• one or more Mitigations that reduce the likelihood and/or impact of exploitation.
• one or more verified Security Claims describing characteristics of the product, its deployment or its operation that ensure the residual risk remains acceptable.

Typical examples include:

• The device is deployed only on isolated operational networks.
• Remote maintenance is disabled except during approved maintenance windows.
• Legacy protocols are enabled only within trusted internal networks.
• Physical access to the device is restricted to authorised personnel.
• Security logs are periodically reviewed by the operator.

Mitigations and Security Claims shall be verified by the Manufacturer or by another actor in the supply chain, including the Integrator, Maintainer, Operator or Final Customer.

Additional Actions

Users can take additional actions on vulnerabilities like

• adding notes
• change risk class
• assign a vulnerability to a bookmark

Notes

Any annotation added by the security team that is relevant to the vulnerability management process. These notes may include analysis details, decisions, assumptions, or additional context that support the evaluation, prioritization, or remediation of the vulnerability.

Risk

The vulnerability risk level is initially determined based on its severity. After the triage and risk assessment process, the security team may adjust the risk classification to better reflect the actual impact and relevance of the vulnerability in the specific context of the device under analysis.

Bookmark

Pre-Triage & Automatic Prioritization

To support accurate risk prioritization, ARIANNA aggregates and correlates information from multiple vulnerability intelligence sources.

The ARIANNA Pre-Triage & Prioritization Engine is designed to support an efficient and scalable vulnerability management process by automatically pre-triaging identified vulnerabilities and prioritizing them according to risk level and exploitability criteria.

Given the potentially large number of vulnerabilities associated with modern software and hardware supply chains, the pre-triage process enables organizations to focus their analysis efforts on the vulnerabilities that represent the highest security risk for the device under analysis.

The objective of the pre-triage engine is therefore to reduce the operational effort required for manual vulnerability triage, while ensuring that vulnerabilities with the greatest potential impact are promptly analyzed and addressed.

Vulnerability Classification

The prioritization engine analyzes several security indicators associated to each vulnerability, including:

• Attack Vector
• Known Exploited Vulnerabilities (KEV)
• Exploit Maturity
• Exploit Prediction Scoring System (EPSS)
• Vulnerability Severity Scores

Based on customer-specific configuration, the pre-triage engine automatically classifies identified vulnerabilities into two categories:

• High Priority: Vulnerabilities that are considered to present an immediate threat and therefore require prompt triage and analysis. These vulnerabilities should be assessed by the security team in order to determine a more accurate risk level and to define and implement the appropriate remediation or mitigation actions.
• Low Priority: Vulnerabilities that are considered to present a lower or less immediate threat. For these vulnerabilities, detailed triage and remediation activities may be temporarily postponed, allowing the security team to focus on higher-priority issues.

This classification mechanism helps organizations optimize resource allocation within the vulnerability management process.

It is important to note that the ARIANNA Pre-Triage & Prioritization Engine does not perform any automatic mitigation or remediation actions. It only provides decision-support information, while the final evaluation and risk acceptance decisions remain under the responsibility of the security team.

ARIANNA KEV Catalogue

The ARIANNA Known Exploited Vulnerabilities (KEV) Catalogue aggregates vulnerabilities for which there is evidence of active exploitation. The catalogue combines information from multiple authoritative and threat intelligence sources, including:

• Vulnerabilities published in the CISA Known Exploited Vulnerabilities (KEV) Catalogue.
• Vulnerabilities identified as actively exploited in the European Vulnerability Database (EUVD).
• Vulnerabilities confirmed as actively exploited through canary systems and honeypot infrastructure.
• Additional verified exploitation intelligence collected by ARIANNA.

By correlating these sources, the ARIANNA KEV Catalogue provides broader coverage and often earlier visibility into actively exploited vulnerabilities than relying on a single public source.

Prioritization Criteria

The ARIANNA Pre-Triage & Prioritization Engine supports multiple prioritization strategies that can be configured according to the organization’s vulnerability management policy.

Risk-Based Prioritization

Vulnerabilities may be prioritized based on their initial risk level. The initial risk level is determined according to the severity score provided by the source that reported the vulnerability, such as public vulnerability databases or security advisories.

A typical configuration consists of prioritizing only CRITICAL and HIGH-risk vulnerabilities for immediate triage and analysis.

Following the triage process, the risk level can be reassessed and refined. This refined evaluation takes into account not only the characteristics of the vulnerability but also the specific context of the device, including:

• the operational environment in which the device is deployed
• the assets and functionalities impacted
• any existing mitigations or security controls already implemented in the system

This contextual analysis allows the security team to determine a more accurate risk level and then to define the most appropriate vulnerability management strategy. Once the risk level has been reassessed and refined, a vulnerability may be reclassified as low priority. In such cases, corrective actions may be postponed or scheduled according to the organization’s risk management policy.

Exploitability-Based Prioritization

Vulnerabilities may also be prioritized based on their likelihood of exploitation.

The ARIANNA pre-triage engine can automatically prioritize vulnerabilities that meet one or more of the following conditions:

• They are included in the ARIANNA Known Exploited Vulnerabilities (KEV) Catalogue.
• A verified exploit has been identified through ARIANNA threat intelligence sources.
• A Proof-of-Concept (PoC) exploit has been identified through ARIANNA threat intelligence sources.
• They have a high probability of being exploited in the near future, according to the Exploit Prediction Scoring System (EPSS)
• They are considered reachable and realistically exploitable on the target device based on the attack vector.

ARIANNA allows users to define their own criteria for determining whether a vulnerability should be considered exploitable. However, to ensure that actively exploited threats are never overlooked, the following vulnerabilities are always classified as exploitable, regardless of the configured rules:

• Vulnerabilities included in the ARIANNA KEV Catalogue.
• Vulnerabilities for which verified exploitation evidence has been identified by ARIANNA.

This guarantees that vulnerabilities with confirmed real-world exploitation are consistently prioritized for remediation while allowing organizations to tailor the prioritization of all other vulnerabilities according to their own risk appetite.

Benefits

The ARIANNA Pre-Triage Engine & Prioritization provides several operational benefits:

• Reduced manual triage effort
• Faster identification of high-risk vulnerabilities
• Improved prioritization of remediation activities
• Continuous monitoring of vulnerability intelligence sources
• Lower operational costs associated with vulnerability management

By automating the early stages of vulnerability prioritization, ARIANNA enables organizations to maintain an efficient, scalable, and proactive vulnerability management process.

Automatic Notification

When a vulnerability report is created, new High-priority vulnerabilities are notified by email to all users that can access the report, ensuring that the relevant stakeholders are promptly informed and can take the necessary actions.

Advanced vulnerability & component search engine

An advanced search engine that enables users to identify and analyze components and vulnerabilities in a report.

• Component Filtering: Components within a Device Model can be filtered based on criteria such as type, status, or name, making it easier to quickly locate specific components.
• Vulnerability Filtering: Vulnerabilities within a report can be filtered according to their associated attributes, allowing the security team to efficiently focus on relevant vulnerabilities during analysis and triage.

Vulnerability Management Policy

Users can ensure that vulnerabilities are addressed within the required remediation timeframes, whether defined by internal policies or by external regulations and standards.

The remediation policy is based on the vulnerability risk level, ensuring that higher-risk vulnerabilities are resolved within shorter and stricter timeframes.

The system also notifies users when a vulnerability is approaching its resolution deadline, enabling the security team to take timely action and maintain compliance with the defined policy.

Vulnerability Assessments Reports for auditing

Security teams can export formal reports to demonstrate that a consistent and effective vulnerability management process is in place within the organization.

Device Model reports (including SBOM and HBOM) and vulnerability reports can be exported with different levels of detail in widely adopted machine-readable formats, such as CycloneDX, SPDX, and VEX, enabling integration with other security and compliance tools.

Reports can also be exported in human-readable formats, such as PDF, to support review, documentation, and sharing with stakeholders.

Internal Vulnerabilities Assessments management

Not all vulnerabilities affecting a device are publicly disclosed or available through external vulnerability intelligence sources. ARIANNA therefore supports the manual creation of Vulnerability Assessment Records for vulnerabilities identified through other channels, including:

• Vulnerabilities discovered by third parties and communicated through a responsible disclosure process.
• Vulnerabilities due to incorrect system configurations or implementation flaws in customer-developed software identified during penetration testing, security assessments, or code reviews.
• Any other security issue identified internally by the manufacturer.

Since these vulnerabilities are not available from public vulnerability databases, they cannot be identified automatically by ARIANNA. Instead, the platform provides a guided user interface that allows Security Experts to manually create a Vulnerability Assessment Record and capture all relevant information required for subsequent triage, remediation, and reporting.

By supporting both automatically identified and manually created Vulnerability Assessment Records, ARIANNA provides a centralized repository for all product security issues. This enables organizations to manage vulnerabilities through a single, consistent vulnerability management process, regardless of how the vulnerability was discovered.

Integrations with External Issue Trackers

ARIANNA supports integration with external issue tracking systems to simplify the coordination of vulnerability remediation activities between Product Security and Development teams.

When remediation or mitigation is required, a Vulnerability Assessment Record can be exported to supported issue tracking platforms, such as Jira, Redmine, and GitHub Issues. During the export process, ARIANNA automatically creates a corresponding issue containing the information required by the development team, including:

• Vulnerability identifier and summary
• Affected component
• Severity
• Recommended remediation or mitigation actions
• References to external security advisories
• A direct link to the corresponding Vulnerability Assessment Record in ARIANNA

This integration allows each team to continue working in its preferred environment:

• Product Security teams use ARIANNA to perform vulnerability assessment, prioritization, risk evaluation, and compliance activities.
• Development teams use their existing issue tracking system to plan, implement, and track remediation or mitigation activities.

ARIANNA continuously synchronizes the status of the external issue with the corresponding Vulnerability Assessment Record. When the issue is updated or closed, ARIANNA notifies the Product Security team so that remediation can be verified and the vulnerability management process can continue.

Likewise, when a Vulnerability Assessment Record requires development activities, ARIANNA informs the appropriate development team and provides direct access to the relevant security information through the linked assessment record.

By synchronizing Product Security and development workflows while allowing each team to operate within its preferred tools, ARIANNA ensures end-to-end traceability and maintains a single, consistent vulnerability management process without disrupting existing development practices.

Vulnerability & Component databases

ARIANNA maintains an internal vulnerability database that is updated daily by aggregating and consolidating data from multiple public vulnerability sources. In addition to this external data, some vulnerabilities and associated information are curated or created directly by the ARIANNA team to ensure accuracy and completeness.

At present, ARIANNA daily imports vulnerabilities from the following public vulnerability databases:

• NIST National Vulnerability Database (NVD): This is a comprehensive and widely used database maintained by the National Institute of Standards and Technology (NIST) in the United States. It provides detailed information about publicly disclosed vulnerabilities, including severity scores, descriptions, and references to other sources. The ARIANNA platform imports vulnerabilities from the NVD to ensure it has access to critical information about known security issues.
• Github Security Advisory (GHSA): is a standardized identifier system used by GitHub to catalog and track security vulnerabilities in open-source software packages. Each advisory receives a unique GHSA ID (e.g., GHSA-xxxx-xxxx-xxxx) and contains details about the affected versions, severity, and recommended fixes.
• CVE.org (MITRE): CVE (Common Vulnerabilities and Exposures) is a publicly available list of known cybersecurity vulnerabilities and exposures. Managed by MITRE, CVE provides a standardized identification system for vulnerabilities. ARIANNA imports vulnerabilities from CVE.org to align with this widely recognized standard for identifying and categorizing security issues.

Each vulnerability source can identify vulnerability using different unique identifiers. For example:

• NIST NVD and CVE.org use CVE
• GHSA use GHSA ID

In case ARIANNA detects that two external identifiers are referring to the same vulnerability, the two identifiers are linked to the same vulnerability. It means that in ARIANNA DB there will be only one vulnerability with two different external identifiers.

By importing vulnerabilities information from well-known and authoritative databases, ARIANNA ensures its internal vulnerability database remains comprehensive and up-to-date with the latest security information available to the broader security community.

Vulnerability enrichment procedure

In order to enhance the quality and comprehensiveness of the vulnerability report, ARIANNA implements a process of enriching vulnerability data. This is achieved by retrieving additional information from various trusted external sources (CISA KEV catalog, exploits databases, EPSS values).

By importing vulnerabilities information from well-known and authoritative databases, ARIANNA ensures its internal vulnerability database remains comprehensive and up-to-date with the latest security information available to the broader security community.

CISA KEV catalog

CISA Known Exploited Vulnerabilities (KEV) are used as an authoritative source to identify vulnerabilities that are actively exploited in real-world attacks.

By systematically retrieving all CVEs listed in the CISA KEV catalog, ARIANNA platform ensures immediate visibility into vulnerabilities that present a proven and ongoing threat, rather than a theoretical risk.

Inclusion in the KEV list indicates that exploitation has been confirmed by government-backed intelligence and observed across multiple threat campaigns.

Mapping internal vulnerability findings against the KEV catalog enables rapid prioritization of issues that require urgent remediation, mitigation, or compensating controls.

This capability supports an exploit-first risk assessment model, where vulnerabilities with confirmed exploitation are elevated regardless of their original severity score.

Leveraging CISA KEV data strengthens both operational security and regulatory alignment by demonstrating continuous monitoring of trusted threat-intelligence sources and timely response to vulnerabilities with demonstrated real-world impact.

ExploitDB & Metasploit

ExploitDB and Metasploit are leveraged as complementary threat-intelligence sources to systematically retrieve and correlate all known exploits associated with identified CVEs.

By ingesting ExploitDB records, we gain visibility into publicly disclosed, proof-of-concept, and weaponized exploits published by the security research community, providing concrete evidence that a vulnerability can be practically abused.

Metasploit further strengthens this assessment by indicating whether an exploit has been operationalized into a reusable, automated attack module, significantly lowering the attacker’s effort and skill threshold.

The association of CVEs with exploits from these repositories allows vulnerabilities to be evaluated not only on theoretical severity, but on real-world exploit availability and maturity.

This approach supports an exploitability-driven prioritization model, enabling faster identification of vulnerabilities that pose an immediate and credible risk.

As a result, remediation efforts can be focused on issues with demonstrated attack feasibility, improving both risk reduction effectiveness and regulatory defensibility.

Exploit Prediction Scoring System (EPSS)

The Exploit Prediction Scoring System (EPSS), managed by FIRST, is an open-source framework designed to estimate the probability (with a score from 0 to 1, or 0-100%) that a specific software vulnerability (CVE) will be actively exploited in the wild within a 30-day period. This score is updated daily and is a crucial tool for organizations, as it helps you to properly prioritize patch management activities.

Advanced topic

CI/CD pipeline integration

ARIANNA provides a set of powerful APIs that enable security teams to build automation and integrate vulnerability management into their development workflows.

The ARIANNA API allows seamless integration of automated security checks within CI/CD pipelines by offering programmatic access to key vulnerability management functions.

Through dedicated endpoints, pipelines can automatically create new Device Model versions, upload the information required to generate SBOMs, trigger the creation of new vulnerability reports, and retrieve the latest report for a specific Device Model version. The API also allows teams to filter and retrieve only high-priority vulnerabilities, enabling faster and more efficient security decision-making during the development process.

User management

The ARIANNA platform distinguishes between two types of users, each with specific roles and permissions: Administrator and Regular User.

Administrator

The Administrator is assigned to at least one user for each customer. Its purpose is to perform administrative activities that support users and manage projects, ensuring the correct configuration and proper operation of the platform.

Regular User

The Regular User role is assigned to users who interact with the ARIANNA platform as part of their Product Security and Vulnerability Management activities. Each Regular User is created by an Administrator and can be assigned to one or more Vulnerability Management Projects with different project-specific roles.

ARIANNA defines the following project roles for Regular Users:

• Project Owner
• Project Member
• Project Observer

These roles determine the permissions granted within each project, ensuring that users have access only to the functions and information required for their responsibilities, while supporting secure and effective project collaboration.

A Regular User may be assigned a different role for each Vulnerability Management Project to which they belong.

Project Owner

This role has full administrative privileges within a Vulnerability Management Project. Project Owners can manage project settings, invite and remove users, assign project roles, access all project information and vulnerability assessment records, perform vulnerability management activities, including triage, remediation tracking, mitigation, and risk acceptance.

Project Member

This role has access to vulnerability assessment records and can actively perform vulnerability management activities, including triage, remediation tracking, mitigation, and risk acceptance. However, it does not have administrative privileges, such as managing project settings, users, or role assignments.

Project Observer

This role provides read-only access to vulnerability assessment records. Observers can view project data but cannot modify the project configuration, vulnerability management data, or any other project content.

User allowed actions

*Only for specific projects

User lifecycle

The ARIANNA platform provides a controlled user lifecycle to ensure secure and regulated access to the platform and its Vulnerability Management Projects.

User creation

Only an Administrator can create new user accounts through the platform's administrative interface.

To minimize the processing and exposure of personal data, the account creation process requires only a limited set of information, including:

• Username
• Contact email address

Once the account has been created:

• The user information is stored in the ARIANNA database.
• A random temporary password is automatically generated.
• An email containing the account credentials and login instructions is sent to the user.

User role management

User permissions are determined by the project roles assigned to each user. Since roles are project-specific, the same user may have different roles in different Vulnerability Management Projects.

An Administrator may, for any Vulnerability Management Project:

• Assign the Project Owner role to one or more Regular Users
• Assign the Project Member role to one or more Regular Users
• Assign the Project Observer role to one or more Regular Users

A Project Owner may, within projects for which they are the owner:

• Assign the Project Owner role to one or more Regular Users
• Assign the Project Member role to one or more Regular Users
• Assign the Project Observer role to one or more Regular Users

Project Members and Project Observers cannot assign, modify, or revoke user roles under any circumstances.

Password management

Password strength rules are crucial for ensuring the security of user accounts in the ARIANNA system. These rules help protect against unauthorized access and potential breaches.

Password strength rules

Below are the required password strength rules for the ARIANNA users:

• Minimum Length

• Passwords must be at least 8 characters long. This ensures a basic level of complexity.

• Maximum Length

• Passwords should be no longer than 64 characters to prevent excessively long passwords that may complicate storage or processing.

• Character Variety

• Must include at least one uppercase letter (A-Z).
• Must include at least one lowercase letter (a-z).
• Must include at least one digit (0-9).
• Must include at least one special character from the set (e.g., !, @, #, $, %, ^, &, *, (, )).

Passwords that don’t meet the strength requirements are rejected during account creation or password change attempts.

The system does not impose an expiration date on valid passwords.

By enforcing these password strength rules, the ARIANNA platform can significantly improve the overall security of user accounts, making it harder for attackers to compromise accounts through weak or common passwords.

Password recovery

In case of forgotten passwords, users can initiate a password reset through a secure process that involves a verification code sent via email, to confirm the user's identity.