Product Documentation

ARIANNA User Manual

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 platform designed to help device manufacturers implement an efficient and scalable Vulnerability Management Process throughout the lifecycle of their products.

The platform provides a set of integrated capabilities that support the key activities required for effective vulnerability management:

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

Device Model Management (HBOM + SBOM)

ARIANNA enables the creation and management of a complete inventory of device components, including both the Hardware Bill of Materials (HBOM) and the Software Bill of Materials (SBOM). This structured representation of the device architecture allows manufacturers to maintain accurate visibility over all hardware and software components used in their products.

Continuous Vulnerability Monitoring

By correlating HBOM and SBOM information with multiple vulnerability intelligence sources, ARIANNA continuously monitors newly disclosed vulnerabilities that may affect the components used in the device. This ensures that manufacturers are promptly notified when relevant vulnerabilities are discovered.

Vulnerability Management

ARIANNA supports the full vulnerability management workflow, including vulnerability identification, prioritization, triage, and tracking of remediation or mitigation actions. The platform helps security teams focus on the most relevant vulnerabilities through risk-based and exploitability-based prioritization mechanisms.

Reporting and Security Insights

ARIANNA generates comprehensive reports intended for both customers and regulatory bodies, supporting transparency and compliance with cybersecurity requirements. These reports enable effective vulnerability tracking, risk evaluation, and informed decision-making throughout the entire vulnerability management lifecycle.


Vulnerability Management Project 

A Vulnerability Management Project in ARIANNA 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 vulnerability reports, perform triage, update vulnerability status, 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.

Basic Concepts

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 hardware, software, and systems. 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.

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. During this step, each vulnerability is analyzed and evaluated to determine:

  • Whether the vulnerability actually affects the device
  • The real risk level considering the device context
  • The priority for remediation

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

  • Applicable vulnerabilities that require remediation or mitigation
  • Not applicable vulnerabilities that do not affect the device
  • Accepted vulnerabilities where the risk is formally accepted according to the organization's risk management policy

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 closing or disclosing the vulnerability status.

This stage includes:

  • Recording the final resolution status (fixed, mitigated, accepted, or not applicable)
  • Documenting the analysis and decisions taken during triage
  • Communicating relevant information internally or externally when required

This step ensures traceability, documentation, and proper reporting of vulnerability management activities.

Device Model

A Device model is the list of components (hardware and software) used inside an IoT system, organized per Processing Units (PUs) and Groups.

ARIANNA is mainly focused on monitoring and supporting the management of vulnerabilities of IoT devices. For this reason it’s really important to create a model of the IoT device that takes into account not only the software parts Software Bill Of Material (SBOM) but also the hardware parts Hardware Bill Of Material (HBOM):

  • hardware components can be affected by known vulnerabilities
    • usually are more critical than software vulnerabilities
    • most of the time can’t be fixed, so their management requires the implementation of mitigations
  • vulnerabilities of software components can depend on the hardware where software is executed
    • some vulnerabilities can be exploited only if the hardware that executes the vulnerable software component has a specific architecture (i.e. the vulnerabilities can be triggered on RISC architectures, not on x86 architectures)
  • vulnerabilities management can be simplified by taking into account the hardware where the software is executed
    • some Attack Vector can be excluded
    • it’s possible to identify if the hardware is used to manage a critical asset or not 
    • it’s possible to identify if the hardware allows a firmware update (how and with which effort) 

Once the main hardware blocks have been identified, the complexity of the software part of each block must be managed. 

In many cases each hardware block executes a single software binary, while in other cases the software part is represented by multiple binaries executed by the same hardware block.

To make the device model more usable, and to simplify the vulnerability management, the device model is enriched with two additional elements:

  • Processing Units (PU)
  • Groups

Processing Unit

A Processing Unit is a discrete hardware component within a system that performs computational, control, storage, or security-related functions.

Within the ARIANNA framework, a Processing Unit is a logical construct used to group related hardware and/or software components. This grouping facilitates the structured representation of an IoT device under monitoring, enabling clearer mapping of components, their interactions, and any associated security considerations.

Processing Units are not, by definition, directly associated with specific known vulnerabilities. Instead, a Processing Unit represents a logical block comprising hardware and/or software components. These components are subject to monitoring, and any detected or reported vulnerabilities are associated with the relevant components contained within the Processing Unit.

A Processing Unit may operate autonomously or in coordination with other units and may be programmable or fixed-function. For the purposes of this specification, a Processing Unit encompasses the following categories:

Microcontroller Unit (MCU)

An integrated circuit combining a processor core, memory, and peripheral interfaces, optimized for embedded control applications.

Microprocessor Unit (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 Module

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.

Stored information

A Processing Unit is identified by:

  • Unique identifier
  • Name
  • Description
  • Type
    • Microprocessor
    • Microcontroller
    • Hardware Module
    • Secure Element
    • Memory
  • System Type
    • Windows
    • Linux
    • Third-party binary
    • ROM Code
    • Real Time OS
    • Bare Metal
  • Hardware Vendor name & Part number
  • Interfaces

Components

The basic element that composes a Device Model is the component.

A component can represent a hardware or software resource identified within the service or the device to be monitored. During monitoring, each component of the device model is used to identify relevant vulnerabilities.

A SW or HW Component is identified by:

  • Unique Identifier
  • Ecosystem
  • Type
  • Vendor name
  • Name
  • Version
  • License
  • Group

Types

Component types are derived from CycloneDX specifications.

TYPE

LABEL

USAGE

device

HW

Hardware components. It includes ROM code that can’t be updated, is considered hardware (NIST identify ROM code as “o”)

firmware

FW

Binary code provided by third parties.

library

LIB

Software libraries (custom or from third parties) and applications from third parties

application

APP

Customer application

operating-system

OS

Operating system (kernel, windows, linux, freertos …)

Status

STATUS

USAGE

CONTROL

ACTIVE

Active component

Default status

NOT ACTIVE

Removed component (after update)

Set by ARIANNA after Device Model update

Group

A Group is an aggregation of components within the same Processing Unit. Such aggregations are defined according to the specific layer to which the components belong:

  • Hardware layer: it contains a single group that collects all the hardware components of the processing unit, such as the MCU or MPU, all the active hardware interfaces, processing cores, and other physical elements.
  • Firmware layer (for MCU-based systems): this layer includes a group that aggregates all software components contained within the firmware binary. If multiple firmware binaries are present, separate groups are defined for each binary.
  • OS layer (for MPU-based systems): this layer includes a group that collects all the components included in the operating system, such as the kernel, system libraries, and standard applications.
  • Application layer (for MPU-based systems): this layer may consist of multiple groups, each corresponding to a specific customer application. Each group includes the software components used by the customer to develop and implement that application.

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.

Getting Started


Device description

This stage is performed once during the initial analysis phase of the device under evaluation. The objective of this activity is to identify all Processing Units (PUs) that compose the device and, for each PU, determine the type of software environment executed on top of it.

A Processing Unit represents any hardware element capable of executing code or managing device functionality, such as microcontrollers, application processors, secure elements, or dedicated hardware modules. Accurately identifying and describing these units is essential to correctly map the device architecture and to support subsequent security analysis activities.

For each identified Processing Unit, the following attributes must be specified:

  • Name: A descriptive identifier assigned to the Processing Unit (PU). The name should clearly reflect the role or function of the PU within the device architecture (e.g., Main Application Processor, Connectivity MCU, Security Controller). It is used to easily reference the Processing Unit throughout the project documentation and during the security analysis process.
  • Description: A brief functional description of the role performed by the PU within the device architecture (e.g., communication controller, main application processor, secure authentication module).
  • Hardware Type: Classification of the hardware category of the PU, such as MCU (Microcontroller Unit), MPU (Microprocessor Unit), Memory, Secure Element, or Hardware Module.
  • System Type: The type of system or execution environment running on the Processing Unit. Examples include Bare Metal, Real-Time Operating System (RTOS), Linux-based system, Windows-based system, Android system, Third-Party Binary, or ROM Code.
  • Hardware Vendor Name and Part Number: Identification of the manufacturer and the specific component model used for the Processing Unit. This information is important for traceability and for correlating hardware components with known vulnerabilities.
  • Communication Interfaces: A list of hardware or logical communication channels used by the PU to interact with other components within the device or with external systems. Examples include UART, SPI, I²C, Ethernet, BLE, or other wired and wireless interfaces.
  • Application Layer Description (if present): A description of the technologies or frameworks used to develop the application layer running on the Processing Unit. Examples may include programming languages and frameworks such as PHP, Python, JavaScript, or other runtime environments.

Device Model creation

This procedure is executed each time a new firmware version is deployed. Its objective is to identify all hardware and software components (HBOM and SBOM) present in every Processing Unit (PU) within the device.

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

Hardware components (HBOM)

The HBOM is typically defined once during the initial device analysis and remains unchanged unless a hardware revision of the device is introduced.

Hardware components are identified based on the information collected during the Device Description stage. This information typically includes the names of the active hardware interfaces, the vendor name and the part numbers of the main hardware elements such as the MCU, MPU, Secure Element (SE), or other hardware modules present in the device.

At this stage, no additional analysis activities are required from the user: the identification of hardware components relies on the information already provided during the device description phase.

Using the information available in the ARIANNA Database, each identified component is then automatically analyzed in order to determine whether it includes additional internal or associated components. This process allows the system to expand the hardware component list by identifying embedded elements, subcomponents, or integrated modules that may not be explicitly declared in the initial device description.

This automated enrichment step ensures a more complete representation of the device hardware architecture, which is necessary for subsequent security and vulnerability analysis activities.

Software components (SBOM)

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

To support this activity, ARIANNA provides dedicated Software Composition Analysis (SCA) tools that can be executed either in the build environment or directly in the target environment, depending on the system configuration and the availability of the software artifacts.

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

  • In the case of 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 the case of 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 the case of 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.

Each System Type and application framework is supported by a specific SCA tool or analysis script. These tools automate the extraction of software component information and help generate an accurate Software Bill of Materials (SBOM).

The generated list of software components typically includes detailed information such as:

  • Component vendor and name
  • Component version
  • Component license
  • Component dependencies
  • Group name
  • List of patched CVEs

This information is essential for subsequent vulnerability identification and risk assessment activities, as it enables the correlation of software components with publicly known security vulnerabilities.

Since the creation of the Software Bill of Materials (SBOM) is primarily oriented toward vulnerability management, the use of ARIANNA SCA tools ensures accurate component identification. In particular, these tools are designed to identify only relevant components, namely those that can be associated with entries in public vulnerability databases.

Additionally, 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.

As a result, the use of ARIANNA SCA tools significantly improves the accuracy and effectiveness of vulnerability correlation and security analysis.



Software Composition Analysis (SCA) tools 

ARIANNA provides a set of Software Composition Analysis (SCA) tools designed to support the accurate creation of the Software Bill of Materials (SBOM) without requiring access to proprietary source code or performing intrusive analysis on target devices.

Execution Model

The ARIANNA SCA tools are delivered as scripts (Python, Bash, or PowerShell) that can be executed directly within the development or build environment according to the system under analysis.

These scripts analyze the software environment and generate an output file in CSV format, containing the list of identified software components.

The generated CSV file must then be uploaded to the ARIANNA platform, either through the Web User Interface or via REST APIs. Once uploaded, ARIANNA processes the data and automatically generates the final SBOM.

Benefits

The ARIANNA methodology is designed to minimize impact on the development workflow and the deployed device. 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.

Environment-Specific Analysis Tools

Because different software environments require different analysis techniques, ARIANNA provides multiple SCA tools, each 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 software ecosystems.

CI/CD Integration

ARIANNA SCA tools can be easily integrated into CI/CD pipelines, enabling automated SBOM generation as part of the software development lifecycle.

For example:

  • SCA scripts can be automatically executed after each firmware or software release.
  • Using the ARIANNA REST APIs, it is possible to:
    • Upload the generated CSV output files to update an existing device model
    • Automatically trigger the generation of a new vulnerability report

This integration enables continuous vulnerability monitoring, ensuring that each new firmware or software release is immediately evaluated against the latest vulnerability intelligence.

Vulnerability Report creation

Vulnerability Reports 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 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 reports remain accurate and aligned with the current device configuration.


Vulnerability Report

Each report includes the following information:

  • Device Model: 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.

These reports provide 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.

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 management pipeline. Each stage of this pipeline is represented by a specific label that users can assign to identified vulnerabilities, indicating their current status within the process. All actions are logged to maintain a detailed record of both open and closed vulnerabilities, ensuring traceability and demonstrating compliance with standards and regulations during audits.

Allowed Actions

Users can take multiple actions on vulnerabilities:

  • change vulnerability status
  • add notes
  • change risk class

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.

Status change

The security team can update the status of a vulnerability to reflect its current stage in the vulnerability management pipeline. This ensures that the vulnerability tracking accurately represents the progress of analysis, mitigation, and remediation activities.

The security team can take one of the following action to update the vulnerability status:

  • 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
  • NOT APPLICABLE
  • REMEDIATED
    • COMPONENT PATCHED
  • ACCEPTED

In case of patch, component upgraded, component removed or false positive the vulnerability status is automatically changed by ARIANNA.

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 Engin 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.

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 pre-triage engine can automatically prioritize vulnerabilities that:

  • Are present in the ARIANNA KEV catalogue (Known Exploited Vulnerabilities)
  • Show a high probability of exploitation in the near future, according to the EPSS (Exploit Prediction Scoring System)For example, vulnerabilities with EPSS scores above a defined threshold (e.g., EPSS > 10%) may be prioritized for immediate triage.
  • Can realistically be exploited on the target device according to the attack vector

The ARIANNA Known Exploited Vulnerabilities (KEV) catalogue aggregates vulnerabilities for which evidence of active exploitation exists.

This catalogue includes vulnerabilities identified from multiple authoritative and intelligence sources, such as:

  • Publicly reported vulnerabilities listed in the CISA Known Exploited Vulnerabilities (KEV) catalogue
  • Vulnerabilities that are actively exploited, as observed through canary systems or honeypot servers
  • Vulnerabilities with verified exploitation evidence referenced in the European Vulnerability Database (EUVD)
  • Vulnerabilities for which weaponized or verified exploits have been identified through ARIANNA intelligence sources

By aggregating information from these sources, the catalogue provides enhanced visibility into vulnerabilities that are actively exploited or highly likely to be exploited in real-world environments.

By aggregating multiple data sources, the ARIANNA KEV catalogue provides broader and faster coverage of actively exploited vulnerabilities compared to individual public databases.

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.

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.


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.

Type of Users

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

System Administrator

The System Administrator role, typically assigned to ARIANNA personnel, is responsible for platform management and can perform administrative actions to support regular users and maintain the proper functioning of the system.

Regular User

The Regular User is the standard ARIANNA platform user. it can be assigned to one or more vulnerability management projects active on the platform with different roles.

ARIANNA distinguishes between three roles for Regular Users, each with unique authorizations and permissions:

  • Project Owner 
  • Project Member
  • Project Observer

This distinction ensures that each type of user has access only to the features necessary for their function, supporting a secure and well-organized platform environment.

Project Owner

This role has full administrative privileges within a vulnerability management project, including the ability to manage project settings, invite or remove users, assign roles, access vulnerability reports and actively take actions on identified vulnerabilities.

Project Member

This role has only access to vulnerability reports and can actively take actions on identified vulnerabilities, but does not have any administrative privileges like managing project settings and managing project users.

Project Observer

This role allows users to view the project and its information but does not grant the ability to make any changes to project configuration and project content.

User lifecycle

The ARIANNA platform provides a controlled process for user creation and user status management, ensuring secure and regulated access.

User creation

Only the System Administrator can create new user accounts through the platform’s administrative interface.

To reduce the exposure of personal data, the account creation process requires only a minimal set of information, such as the username and the contact email.

Once the account is created, the user information is stored in the ARIANNA database, a random password is automatically generated, and an email is sent to the user with the account credentials.

User role management

System Administrator can:

  • assign Project Owner role to a Regular Users for all vulnerability management projects
  • assign Project Member role to a Regular Users for all vulnerability management projects
  • assign Project Observer role to a Regular Users for all vulnerability management projects

Project Owner os be able to:

  • assign Project Owner role to a Regular Users for the owned project
  • assign Project Member role to a Regular Users for the owned project
  • assign Project Observer role to a Regular Users for the owned project

Project Member and Project Observer can’t manage Users roles in any conditions.

User allowed actions

ADMIN

USER



OWN

MEM

OBS

Add user to ARIANNA platform





Create project





Activate/Deactivate project





Add/Remove User from the list of Project Owners of a specific Project


*



Add/Remove User from the list of Project Members of a specific Project


*



Add/Remove User from the list of Project Observers of a specific Project


*



Change policy & Configure prioritization Engine





Create new device model version





Upload device model data





Deactivate device model version monitoring





Download report





Access & Navigate report - Device Model





Access & Navigate report - Vulnerabilities





Access & Navigate report - Vulnerabilities details





Access & Navigate report - Bookmarks





*Only for specific projects

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.