An organization's communications infrastructure and the tools that support that infrastructure are critical to the business' ability to function. That same importance also makes the infrastructure a high value target for malicious actors seeking to gain entry deeper into the organization or to exfiltrate sensitive intellectual property.

Arista Networks sees its role in security as a continuous process that begins at manufacturing and continues throughout the lifecycle of the product as vulnerabilities are detected, mitigated, and remediated.

The following document is intended to cover Arista's vulnerability management process. This process is broken down into four primary components: design choices for vulnerability avoidance, vulnerability detection, vulnerability communication, and security assessment testing.

Product security must also be complemented through best practice configuration during the installation and operation of the infrastructure. Arista provides regularly updated hardening guides and security recommendations through living documents available via EOS Central.

Design Choices

  • Safe Choices in Design and Runtime

    • Arista's product family encompasses a variety of software products including EOS, DANZ Monitoring Fabric (DMF), CloudVision (CV) and CloudVision Wi-Fi (CV Wi-Fi), each of which is designed with safe execution in mind. As a result, many types of common programming issues are caught during development or not able to occur due to the frameworks and policies in use.

      The following list provides some examples of fundamental design choices that form part of Arista's software design process:

      • Safe language choices ensure mitigation against common flaws such as buffer overflows, protection against access of uninitialised data and other memory management issues.
      • Use of highly audited libraries where necessary (e.g. common security protocols).
      • Prevention of resource leakage using safe memory operations, bounds checking, reference counting and Valgrind analysis.
      • Pipelined execution models organised around single threaded functions to avoid race conditions and deadlocks.
      • Strong input sanitization for internal and external APIs to prevent malformed data injection.
      • Memory-safe virtual machines and Containerized execution to provide process separation and abstraction from the underlying OS.
      • Principle of least privilege to limit the permissions given to processes and users, avoiding malicious escalation.
    • Both the design of new Arista features and maintenance of existing features are done with security as a goal.

      • Engineers are provided training on secure coding practices and how to implement them in their code. By having a series of guidelines and examples engineers can create features that are designed to be secure from the start and can recognize previously written insecure designs.

      • The usage of security critical open source libraries is limited to a few well understood libraries. This serves to limit the surface of attack as well as make analyzing the usage of said libraries in the codebase easier.

      • Awareness and review of common attack vectors and the associated mitigations is an important part of security at Arista. The PSIRT team makes sure to stay aware of common patterns in insecure code and how to detect them. Information on rising trends is integrated into the training as well as company wide announcements. By making sure to keep a dialogue open within the company on security, engineers on all teams are able to keep secure coding principles in mind when writing code.


Vulnerability Detection

This section describes examples of the tools, processes and testing procedures Arista undertakes to ensure awareness of emerging vulnerabilities:

  • Vulnerability Detection

    • CVE Scanner is an Arista automated process that searches for publicly disclosed vulnerabilities in the open source packages used in EOS(™), CloudVision(™) Portal, Danz Monitoring Fabric(™) and CloudVision(™) Wireless. It works by automatically downloading the database of known issues from the National Vulnerability Database and then cross-checking the version for each vulnerability against the versions of shipped code in all releases that have not yet reached end-of-life. Upon identifying a match for a vulnerability, a new bug is automatically filed and an engineer will investigate the potential problem. This automated process provides Arista with the ability to quickly uncover potential security vulnerabilities disclosed in the public domain.

    • Arista also keeps open lines of communication with its third-party vendors that provide software and hardware solutions to Arista products. In the event that a security issue is found with the 3rd party vendors product they are encouraged to reach out to Arista's PSIRT team and discuss the issue. Arista will treat these issues in the same manner as any other security issue discovered.

    • Arista PSIRT engineers conduct ongoing, detailed, security reviews of the Arista written code base to check for potential vulnerabilities and issues. Special attention is paid to areas of code believed to be at higher risk, such as those that parse user input or handle external packets.

    • Any potential security issue identified is reviewed for severity and potential impact. As part of this internal issues are scored using CVSSv3 scoring. If the usage of a publicly disclosed piece of vulnerable software differs significantly from the original reported usage, Arista may re-report the score with regards to how vulnerable Arista products are.

  • Security Assessment Testing

    • Arista performs regular internal security assessment testing on our software products. These internal tests are done for every major software release (multiple releases per year). Examples of internal security test cases are included below.
    • The findings of these tests are reviewed to find ways in which to improve or harden our software.
    • Example test cases include, but are not limited to:

      • External host fingerprinting for display of compromising information.
      • Automated vulnerability scanning for checking installed software against known CVEs.
      • Validation of automated scanning results by an Arista engineer who specializes in security.
      • Attempt Proof-of-Concept exploitation against running host, for vulnerabilities with documented ability to do so.
      • Internal host configuration review including the boot loader, kernel (hardware drivers, modules, patches, etc), ipv4 and ipv6 stack and other services running on the host.
      • Use of open-source tools such as nmap and gcov to ensure thorough coverage and understanding of the code deployed.
      • Testing to standards defined by the DoD DISA STIG configuration and best practices. Arista uses the DoD DISA standards as our baseline for secure computing since they provide a high level for initial entry and cover threats one would expect to find in a datacenter.

Vulnerability Avoidance/Mitigation

While many vulnerabilities are mitigated by implementing best practices, Arista also provides rapid response via advice and hotfixes as detailed below:

  • Publication of Best Practises

    • Review of product software architecture and design documentation, with a focus on external attack vectors, to identify design flaws from a security perspective.
    • Regular review of best practices for securing and hardening Arista products to ensure the security of the network. Best practices maintained in the Arista's Hardening Guides, which are living documents stored here: Hardening and Security
  • Vulnerability Mitigation on Running Systems

    • In the event of a vulnerability that affects Arista products, Arista is oftentimes able to provide a hotfix to mitigate the issue. This is an extension that can be installed on a running system and will fix the problem with a minimum of downtime. While not all fixes are available as a hotfix, here is an example of how this hotfix scenario could look:

      • The SSH Server is found to be vulnerable to a publicly disclosed CVE.
      • Arista creates a hotfix to resolve the problem.
      • The hotfix is installed on a switch, the SSH server goes down for approximately 1 second while it is restarted. No other services on the switch are affected.
      • The fix is in place and can persist across reboots of the switch until a newer image with the fix integrated can be loaded.

Vulnerability Communication

New vulnerabilities are made available as soon as possible via well known mechanisms:

  • If the issue impacts Arista products, an appropriate solution or set of solutions to the problem will be provided. The solutions can include a recommended configuration change, software patch, new software image, or other procedures that are appropriate to mitigate or fix the vulnerability.

  • Details of the security vulnerability and associated solutions are then documented publicly via a security advisory on the Arista website which can be accessed pro-actively as an RSS feed

    Advisories Notices

  • Customers deploying CloudVision benefit from automated alerting via the Compliance Dashboard. CloudVision is able to warn customers of both bugs and security vulnerabilities to help ensure the environment is kept secure.

  • Arista Networks follows best practices when it comes to making CVEs findable as well. All security issues have CVEs assigned by MITRE so that issues can be efficiently tracked across security scanners, advisories, and all other forms of security issue management procedures.



Arista goes to great lengths to ensure the ongoing security of its products and rapid mitigation of emerging threats, following industry best practices and leveraging close relationships with suppliers.

The effectiveness of these robust processes is demonstrated by extremely limited exposure to common security issues as well as rapid and usually impact-free solutions for remediation.

Arista customers following our recommended hardening steps can be confident that they have deployed the industry's leading secure networking solutions.