Report a vulnerability or security issue

You can report any vulnerability to our products, services, websites and solutions including integrated components to us.

Purpose of This Process

This Vulnerability Disclosure Process (VDP) defines how security-relevant findings can be reported, assessed, and handled in a controlled, legally safe, and technically meaningful way.

Its objectives are to:

• Enable responsible reporting of genuine security weaknesses
• Ensure findings are assessed based on real-world risk, not theoretical exposure
• Protect researchers acting in good faith
• Prevent misunderstandings caused by raw, uncontextualized scanner output
• Provide a clear interface for security, audit, and governance stakeholders

This process is designed for:

• Security researchers and penetration testers
• Internal and external security teams
• Auditors, assessors, and governance functions
• Anybody who want to contribute to product or service security at sematicon

Scope of Accepted Reports

We accept reports of actual security vulnerabilities in systems under our responsibility, including:

• Software products and firmware
• Product-integrated services
• Web applications and public-facing websites
• Backends, APIs, and management interfaces
• Integrated or bundled components where exploitation impacts our products

Out of Scope

The following are explicitly not considered vulnerabilities unless proven exploitable in context:

• Presence of outdated libraries without a reachable attack path
• CVEs in unused or unreachable code paths
• Theoretical weaknesses without practical impact
• Policy or compliance observations without security relevance

Responsible Disclosure & Safe Harbor

We encourage good-faith security research.

If you:

• Limit activities to what is required to identify and demonstrate a vulnerability
• Avoid accessing or modifying real customer or production data
• Do not disrupt services
• Follow this disclosure process

then your actions are considered authorized for security research, and we will not pursue legal action.

Traffic Light Protocol (TLP) – Information Handling

All information exchanged as part of this Vulnerability Disclosure Process is handled in accordance with the Traffic Light Protocol (TLP).

By submitting a vulnerability report or otherwise engaging in this process, you acknowledge and agree that all shared information, findings, reports, and related communication are classified as TLP:AMBER+STRICT.

Accordingly:

• Information is restricted to Sematicon’s internal security and response teams and, where strictly necessary, to directly involved parties responsible for validation and remediation.
• Information must not be shared publicly, redistributed, or disclosed to third parties without explicit prior written consent.
• We do not publicly disclose vulnerability reports, technical findings, or assessment results, as premature or uncontrolled disclosure could negatively impact the security and operational stability of our customers.

Any disclosure beyond this defined scope requires explicit coordination and prior approval.

Reporting Channel

• Please use the following E-Mail-Address: srt@sematicon.com

• We recommend encrypting all information by using our PGP-Key

-----BEGIN PGP PUBLIC KEY BLOCK-----

mDMEZbJMERYJKwYBBAHaRw8BAQdAqI2Qdm3zL8Pzei2BPOHuGe+ScDzdA0ava//w
Z5RDNYG0NHNlbWF0aWNvbiBTZWN1cml0eSBSZXNwb25zZSBUZWFtIDxzcnRAc2Vt
YXRpY29uLmNvbT6ImQQTFgoAQRYhBN8B7XQAWF0EZHPcHHbJiC4rMMkeBQJlskwR
AhsjBQkFpN8fBQsJCAcCAiICBhUKCQgLAgQWAgMBAh4HAheAAAoJEHbJiC4rMMke
37AA/0U/Ra4rYVdvLq4Ai+vy88WfODgAXpBoaYyuRKCJF/nMAPwIYKEdG8dyJZuv
/csJgnisosd6zBsTO6Q0SYottagWALg4BGWyTBESCisGAQQBl1UBBQEBB0DeaSxH
tisejDdNGsKtKxn1s7ErBMJI/D9szuT2alRhUgMBCAeIfgQYFgoAJhYhBN8B7XQA
WF0EZHPcHHbJiC4rMMkeBQJlskwRAhsMBQkFpN8fAAoJEHbJiC4rMMkek+cBAK8V
Laoav85+jmFp0LyratUTjfWUTKDkZY90qfSdxBiKAQD3q9nEGGz5NfhSf9SkQZmk
swhgu6gvmoSXymC0QxIcCg==
=I55f
-----END PGP PUBLIC KEY BLOCK-----

Reporting Requirements

Please provide at least the following information:

• The name of the affected component, including the component manufacturer or supplier. If the component is not our own product or is provided by a third-party vendor, please clearly state whether contact with the manufacturer or vendor has already been established.
• The name of the affected product and the exact version number(s) that were tested.
• A clear and concise description of how the vulnerability was identified, including the methodology and any tools used. Where appropriate, supporting material such as screenshots or other images should be provided to improve traceability.
• An assignment of the vulnerability to the OWASP Top 10 2021. If none of the listed categories apply, the vulnerability must be classified as OTHER and described in more detailed technical terms.
• A proof-of-concept (PoC) code snippet or clear, reproducible instructions demonstrating how the vulnerability can be exploited.
• A description of the environment and prerequisites required to reproduce the vulnerability, including relevant configuration details, deployment assumptions, authentication or authorization requirements, and any constraints that affect practical exploitability.
• An (informal) declaration of consent for the inclusion of a name or alias in our Hall of Fame.
• A risk assessment that takes the technical circumstances into account to determine the severity of the vulnerability, for example by providing a CVSS score and the associated vector and rating (preferably using the latest available CVSS version).
• A concise description of the impact of the reported vulnerability, or alternatively a threat model describing a realistic and relevant attack scenario.

We would like to thank everyone who helps us to ensure the safety of our products and our customers. Thank you for your efforts!

Important note on automated scanner reports

Automated vulnerability scanners (e.g. container, image, or dependency scanners) provide technical raw data that can be useful as an internal input. However, sending raw scanner reports to us does not constitute a valid vulnerability report and does not trigger a technical assessment or response for our side.

Why raw scanner reports are not sufficient

Automated scanners have well-known and unavoidable limitations:

• Findings are typically signature- or package-based, regardless of whether the affected component is actually used.
• Scanner results do not consider runtime conditions, architecture, isolation mechanisms, or real attack paths.
• Severity is usually derived from CVSS base scores only, without product- or deployment-specific exploitability.
• Compensating controls (e.g. isolation, lack of privileges, missing exposure) are not taken into account.
• Aggregated CVE counts do not represent a security risk assessment.

As a result, raw scanner outputs are not suitable for a qualified, traceable, or audit-proof security evaluation. This is a general limitation of automated scanners and is independent of the specific tool used.

Our position

• We take scanner results into account as raw input only.
• We do not provide responses, confirmations, or remediation commitments based solely on unfiltered scanner reports.
• The responsibility for contextual risk assessment (product, architecture, runtime, threat model) lies exclusively with the manufacturer.

What we do assess

We assess and respond to:

• Well-structured vulnerability reports submitted according to our
  Vulnerability Disclosure Process.
• Findings from penetration tests, provided they are reported and documented in compliance with our defined rules.
• Internally validated issues supported by context-aware evidence (e.g. exploitability within the actual product and deployment).

All assessments are performed context-, architecture-, and risk-based, including the use of SBOM and VEX, in line with established standards and BSI-aligned processes.

We understand that the use of automated vulnerability scanners is common practice and that sharing such results is well-intentioned. However, handling vulnerabilities based on unqualified raw data would lead to inaccurate risk assessments and potentially incorrect conclusions. Our approach ensures that all security decisions are technically sound, traceable, and aligned with recognized standards. This is essential to maintain product security, operational stability, and regulatory compliance for all customers.