Astera Labs’ Intelligent Connectivity Platform for AI infrastructure is architected with end-to-end security features that are designed to provide mission-critical user data protection.
Astera Labs Security
Product Security Incident Response Team
Security is a top priority for Astera Labs products in today’s rapidly evolving threat and vulnerability landscape. Astera Labs’ Product Security Incident Response Team is responsible for the product vulnerability management process, coordination of customer product security incidents, and reporting security issues affecting our products and solutions.
Security is prioritized throughout the product lifecycle, from product conception to deployment for all our hardware and software offerings. We strive to adopt strong security practices and processes to ensure our products adhere to leading industry specifications.
Compliance
We practice rigorous product security architecture, testing and compliance processes. These processes are integral to our product development lifecycle and act as release criteria for firmware and software.
Industry Initiatives
We work closely with industry consortia, partners, academics, researchers, and end users in the ecosystem to identify opportunities to integrate what we believe are the highest level of product and platform level protection. We follow the CVE Numbering Authority (CNA) process and coordinated vulnerability disclosure practices so that we can respond quickly and appropriately to reported issues.
Incident Handling & Vulnerability Management Process
Our Product Security Incident Response Team (PSIRT) team is trained so that it can respond systematically to potential issues reported to Astera Labs and follows the procedure outlined below, wherever it is deemed appropriate:
Incident Intake Process
Vulnerability Disclosure Policy and Reporting Process
Astera Labs strongly believes in the principles of responsible vulnerability disclosure towards all parties involved. We welcome independent security researchers, vendors, customers, and other sources to responsibly and privately report security to us vulnerabilities affecting our product portfolio.
This policy outlines the recommended procedures for reporting vulnerabilities to Astera Labs, provides guidance to the vulnerability reporters and explains what you can expect once we receive your report.
Note: Astera Labs reserves the right to deviate from this policy whenever it deems, it its sole discretion, that it is appropriate or necessary.
If any concerned party needs to report a potential security vulnerability in any Astera Labs product, please use the below method:
To report a potential security vulnerability in any Astera Labs product and/or technology, please email your report to the Astera Labs Product Security Team at . Please note that Astera Labs subscribes to the Coordinated Vulnerability Disclosure (CVD) model and expects all security researchers who submit reports to do the same. Reports should contain the following information to allow for efficient triage and analysis:
- Name and version of the affected product or software
- Detailed instructions to replicate the vulnerability
- Proof-of-concept or exploit code
- Description of how the issue was found, the impact and any potential remediation
- Potential implications of the concern
- Public disclosure plans
Please note that missing or incomplete information may delay our ability to address the reported vulnerability. Security researchers who submit privately a valid report and adhere to Coordinated Vulnerability Disclosure (CVD) practices may be acknowledged in our published security bulletin. Once we receive the report, you can expect that our security team will confirm receipt, then begin the process of analysis, validation, and implementing corrective measures to resolve the issue. All information received in the report should be expected to be treated with the utmost care and is considered confidential. Such information should be anticipated to be shared only with the relevant stakeholders on a need-to-know basis.
Impact Assessment & CVE Assignments
Astera Labs PSIRT expects to assign security experts to assess the reported incident. Upon validation of the issue, as part of our objective to pursue transparency and help customers mitigate risk, Common Vulnerabilities and Exposure (CVE) identifiers are used for internally and externally found vulnerabilities across products with the Common Vulnerability Scoring System (CVSS) version 4.0 used to assess severity.
Remediation
After assessing the impact, it is expected that Astera Labs PSIRT will investigate and strive to identify the root cause of the issue. Where appropriate, mitigation measures will then be anticipated to be developed and provided to our customers, who will be expected to integrate the appropriate fix and deploy updated products.
In some cases, a coordinated response may be necessary, where certain elements of the mitigation are handled by Astera Labs, while others can be expected to be addressed by ecosystem partners.
Communication
Astera Labs requires adequate time between the initial vulnerability report and public disclosure to ensure thorough analysis and mitigation. Security Bulletins are envisioned to be the primary channel for communicating mitigations or guidance related to newly published CVEs.
In addition, Astera Labs PSIRT may notify customers and partners about potential vulnerabilities even when no CVE has been issued, or to provide updates and additional context on previously disclosed issues for which guidance has already been shared.
Note: The issuance of a Security Bulletin by Astera Labs does not necessarily indicate that any products are affected. Bulletins may also serve to share informational findings with our partners and customers.
The timing of disclosure is expected to be determined on a case-by-case basis, taking into account various factors, including the nature of the issue and the need to protect end users. While some disclosures may follow the standard 90-day embargo period, others may require more time due to factual circumstances, such as the complexity of the ecosystem and the effort needed to develop, integrate, and distribute effective mitigations. In such cases, an extended embargo period may be necessary to allow all stakeholders sufficient time to implement patches.
Feedback
As part of our commitment to continuously improving our security process, feedback received from customers and internal stakeholders are incorporated to update applicable changes in product architecture, procedures, and testing.