Policy for the Swiss Post E-Voting public bug bounty programme

Latest News:
2026-02-24 Update: We've updated our reporting requirements (see below). Check them out to keep you reports valid!

2025-08-25 Update: The public intrusion test on e-voting this year has ended. We want to thank everyone, who participated!

2025-07-28 Seize the opportunity: The public intrusion test has once again started and will run until the 24th August. Explore and directly test the live infrastructure through the web interface. Details can be found in “C.4 Web application & infrastructure”

2025-05-16 Update: A new scope has been added to the program: the E-Voting Voting Print Service Source code! You can find the code here

2024-07-04 Update: The public intrusion test on e-voting this year has ended. We want to thank everyone, who participated!

2024-06-12 Seize the opportunity: The public intrusion test has once again started and will run until the 3th July. Explore and directly test the live infrastructure through the web interface. Details can be found in “C.4 Web application & infrastructure” Also, don’t miss out our new bounty grid, which increased and is active starting today.

2024-02-22 Update: We published a new major release of our e-voting system. Take a look at our repository!"

2023-07-31 Update: The public penetration test on e-voting this year has ended. We want to thank everyone, who participated!

2023-07-08 Don’t miss out: The public penetration test on e-voting will run until 31 July on "pit.evoting.ch". The scope is detailed below under “C.4 Web application & infrastructure (intrusion test)” Take your chance to check out and test the live infastructure directly through the webinterface!

2023-05-25 Update: We published a new release with new source code components and actualized our E2E environment. Take a look at our repository and stay up to date by signing up for our [infomail]
(https://swisspost-digital.ch/en/evoting-community/community-programme/infomail).

2022-12-16 Update: We published a new release and actualized our E2E environment. Take a look at our repository and stay up to date by signing up for our infomail.

A. Introduction

A.1 About the Programme and this Policy

This bug bounty programme is a permanent and public programme that is a dedicated part of the Swiss Post e-voting community programme (hereinafter ECP): https://swisspost-digital.ch/evoting-community

The goal of this programme is to continuously improve the security of the Swiss Post e-voting system.

By participating for the ECP public bug bounty, you agree to comply with this Policy and with the Code of Conduct for the ECP (hereinafter CoC). In case of conflict between this Policy and the CoC, the Policy has priority. If you do not accept this policy and the CoC, please do not participate in the ECP public bug bounty.

Please read carefully the programme policy, especially the indications regarding the different scopes of this programme and the corresponding reporting requirements. Please also follow our Code of Conduct.

A.2 About Swiss Post

Swiss Post’s services make everyday life easier for people in Switzerland – in both the physical and digital worlds. When it comes to e-voting, Swiss Post is digitizing what it does best: the secure transport of confidential information.

In order to meet highest quality standards, we are constantly mitigating security issues on multiple levels.
We appreciate any contribution that helps to improve the security of our systems and we will pay a fair reward for it.

A.3 About the Swiss Post E-Voting system

The developers, cryptographic experts and other specialists from Swiss Post are continuously improving the future e-voting system with universal verifiability. For information about the stage of development and our solution visit https://swisspost-digital.ch/evoting-community

In 2019, Swiss Post disclosed the source code of an earlier version of its e-voting system. Since then, we have continued to develop the system while improving the accompanying documentation and auditability. The feedback from those who took part provided us with a key basis for designing the current disclosure process, in particular with regard to the options for cooperating with interested parties. We have updated the process accordingly: the system is disclosed iteratively and transparently. Active dialogue with experts is a core component of the disclosure process, which forms part of the e-voting community programme.

A.4 Source code and other programme material

The source code , specifications, documentation and additional material for this programme are available in the public repositories under https://gitlab.com/swisspost-evoting

These repositories will provide you with the possibility of compiling the source code and running the whole Swiss Post E-Voting system in Docker on your local machine or in your lab to simulate an election event.

We will update the repositories frequently - make sure to stay on the latest version of the master branch of the source code and other programme material when carrying out your research.

B. General Programme Rules

Participants are permitted to perform any tests and investigations on the systems as long as they act in good faith and as long as they respect the scopes and rules described below.

B.1 Eligibility and Coordinated Vulnerability Disclosure policy

We are happy to thank everyone who submits valid reports. This helps us to improve the security of the Swiss Post E-Voting system. However, only those that meet the following eligibility requirements may receive a monetary reward:

• You must be the first reporter of a vulnerability.
• The vulnerability is found in the latest version of the source code & documentation at the time of your report.
• The vulnerability must be a qualifying vulnerability (see below)
• Any vulnerability found must be reported as soon as possible after discovery through yeswehack.com.
• You must send a clear textual description of the report along with steps to reproduce the issue, include attachments such as screenshots or proof of concept code as necessary (refer to the reporting requirements of the corresponding scope).
• You must avoid tests that could cause degradation or interruption of our service (refrain from using automated tools, and limit yourself about requests per second).
• You must comply with the Coordinated Vulnerability Disclosure policy (see below).

Our security analysts examine reports about vulnerabilities. During our analysis, we will consider a worst case scenario and keep that in mind when defining the reward we are paying.

Any vulnerability disclosure follows the Coordinated Vulnerability Disclosure policy defined in the Code of Conduct.

Our aim is to provide the highest possible level of transparency. Therefore, all accepted findings are also published on our Gitlab. This includes the summary of the report, as well as comments. The reporter of the findings will be credited if the reporter agrees to its publication. If you want to stay anonymous or use an alias, please let us know in the report.

B.2 Legal safe harbour: consequences of complying with these programme rules

Swiss Post interprets activities by participants in public intrusion tests that comply with the programme rules as authorized access under the Swiss Penal Code and other anti-hacking and anti-circumvention laws. This includes Swiss Penal Code Articles 143, 143bis and 144bis. Swiss Post will only file a complaint about a violation of the programme rules if the code or the other materials or parts thereof are used commercially or productively. If legal action is initiated by a third party against a participant and the participant has complied with the programme rules as outlined in this document, Swiss Post will take the necessary measures to make it known to the authorities that such participant's actions have been conducted in compliance with this policy.

Any non-compliance with the programme rules may result in exclusion from the e-voting community programme.

C. Scopes & Peculiarities

This programme aims at hardening the e-Voting system in depths. For this reason, not only the web application and its infrastructure will be considered part of the scope, but also its source code, the cryptographic protocols in use as well as the specification and documentation.

To cover each and every aspect, you have access to the following elements to complete your research and testing:

• Application source code
• Protocol of the Swiss Post Voting System
• System Specification and documentation

In addition, periodical public intrusion tests lasting about 4 weeks each temporarily complements the e-voting community bug bounty programme.

We appreciate any contribution that helps to improve the security of our systems and we will pay a fair reward for it.

C.1 Scenarios with special bounties

There are some specific scenarios we are particularly interested in, for which we offer special bounties (reward grid +++). Those Bounties apply to all scopes and will be paid out instead of the CVSS based reward (not additional). During our analysis, we will consider a worst case scenario and keep that in mind when defining the reward we are paying:

• Manipulation that goes undetected by the voter and the system (70'000 - 230'000 EUR):
  • Manipulation of individual votes (without being detected by the proofs and logs generated by the e-voting protocol)
  • Manipulation of the tallying process (manipulating the results) without voters and auditors detecting it
• Manipulation that goes undetected by the voter but not by the system (50'000 - 70'000 EUR):
  • Manipulation of individual votes while maintaining universal verifiability mechanism (detected by trusted auditor)
  • Modifying the results of the election without being detected by a voter
• Voting privacy outside the voting client (40'000 - 50'000 EUR):
  • The privacy of a vote is broken (what he or she voted) on the server
• Vote corruption (30'000 - 40'000 EUR):
  • A vote is stored in the ballot box and that vote cannot be decrypted
  • A vote is stored in the ballot box in a way that gives the voter an unfair advantage

Any scenario described has to be achieved with respect to the trust assumptions of the Federal Chancellery Ordinance on Electronic Voting (VEleS) in order to qualify for a reward. For a summary of the assumptions see Chapter 1-2 of the Protocol of the Swiss Post Voting System.

C.2 Application source code

C.2.1 OBJECTIVES

• Identification of exploitable/demonstrable vulnerabilities in the e-voting system
• Identification of security issues without current evidence of exploitability in the e-voting system:
  • e.g. Unsecure functions in use, ...
• Identification of bad deviations from the System Specification which could lead to exploitation
• To be eligible for a reward, findings must have a measurable (or at least hypothetical and documented) impact on the e-voting system and its Confidentiality/Integrity/Availability and not be part of the ‘non-qualifying vulnerabilities’ (see list below)

C.2.2 REPORTING REQUIREMENTS

Please make sure to complete your report with the following details:

• Source code references:
  • implicated file(s)
  • implicated line(s) of code
  • any other information that might help us identify the vulnerable parts
• External references:
  • Academic references on the matter
  • Technical studies on the matter
  • Conference papers
  • Any other information that might help us understand the vulnerability
• Attack scenarios with their potential impact

C.2.3 REWARD POLICY

All qualifying vulnerabilities reported on the ‘Application source code’ scope will be analysed by our security team. Following this analysis, the impact of the vulnerability will be assessed and definitively scored using CVSS 3.1 or the scenarios with special bounties.
Based on the final scoring of the reported vulnerability, the bounty will be calculated in regard of the applicable reward grid (++ or +++).

C.3 Protocol, System Specification and documentation

C.3.1 OBJECTIVES

• Identification of security issues without current evidence of exploitability in the available e-voting system
  • e.g. implementation errors that prove to lead to exploitation independently of the current or future implementation
  • e.g. identification of deprecated protocols that prove to lead to exploitation independently of the current or future implementation
• Identification of bad deviations from the cryptographic proof, which prove to lead to exploitation independently of the current or future implementation
• To be eligible for a reward, findings must have a measurable (or at least hypothetical and documented) impact on the e-voting system and its Confidentiality/Integrity/Availability and not be part of the ‘non-qualifying vulnerabilities’ (see list below)

C.3.2 REPORTING REQUIREMENTS

Please make sure to complete your report with the following details:

• References to the documentation and the source code:
  • implicated protocols/algorithms
  • implicated pages/paragraphs
  • implicated line(s) of code (when relevant)
  • any other information that might help us identify the vulnerable parts
• External references:
  • Academic references on the matter
  • Technical studies on the matter
  • Conference papers
  • Any other information that might help us understand the vulnerability
• Attack scenarios with their potential impact

C.3.3 REWARD POLICY

All qualifying vulnerabilities reported on the ‘Protocol, System Specification and documentation’ scope will be analysed by our security team. Following this analysis, the impact of the vulnerability will be assessed and definitively scored using CVSS 3.1 or the scenarios with special bounties.
Based on the final scoring of the reported vulnerability, the bounty will be calculated in regard of the applicable reward grid (++ or +++).

C.4 General Reporting Requirements

• Indicate at which phase(s) and which step(s)/algorithm(s) of the protocol your attack occurs (with links to the concerned
  documentation and/or lines of code involved, if any), as defined in our Protocol of the Swiss Post Voting System - Computational Proof of Complete Verifiability and Privacy.

• Indicate all parties involved in your attack, and which are malicious and which are not. You should respect and understand our threat model as defined in our Protocol of the Swiss Post Voting System - Computational Proof of Complete Verifiability and Privacy.

• Indicate the entry point that your malicious party will use, which explicitly conforms to our described threat model

• Indicate any required preconditions, if any.

• A clear, concrete impact of the attack must be provided, hypothetical and overly vague risks are insufficient. Simply stating there is a CVE or a potential bug is useless.:

  • what are the technical impact(s)?
  • On which components do they apply?
  • How does this impact other components?
  • What are the business impact(s) of the obtained technical impact, in the context of the e-voting protocol?
  • On which component(s) is this impact obtained?

  • Demonstrate that you have done your due diligence in verifying that the vulnerable behaviour you point to is not mitigated by security measures implemented elsewhere. This can be done by:

  • providing a proof of concept and proof of exploitation (see below), or

  • Providing a code or specification analysis (see below
    A lot of security mesures implemented out of the code render most of the attacks extremely unrealistic or simply invalid. Like for example REST endpoint authentication, offline applications and operational measures.
  • Note that this includes the verifier

Failure to do any of the above may result in your report being rejected without further analysis from our team.

C.4.1 Vulnerability dependent on real operating conditions

When a proof of concept and proof of exploitation is not provided, we may refuse reports whose vulnerability's plausibility is heavily dependent on and affected by real operating conditions, such that their feasibility cannot be determined through static code inspection alone.

Reports in this category typically include, but are not limited to, the following classes of attacks:

• DoS / algorithmic complexity / deadlocks / starvation, or any other related reports involving abuse of limited resources
• Timing and side-channel attacks, including attacks requiring statistical distinguishability or other reliability-dependent techniques.
• Race conditions, TOCTOU, lock-ordering issues
• Attacks requiring probabilistic triggering
• Software vulnerabilities that are almost entirely context-dependent: for instance, path traversals, XXEs, query, command, argument, template injections, arbitrary file read/write, deserialisation issues, etc

C.4.2 Code or Specification Analysis

When providing any static code/specification analysis, you must:

• Provide links to the specific line range of the vulnerable code you point to, clearly identifying which commit you performed your analysis on.
• Trace (providing links) in a step-by-step manner the execution of your attack scenario across the components from its entry-point to its concrete impact, identifying the code paths taken (if any), files, functions, and relevant control-flow decisions, and showing how your attacker-controlled input/action or conditions propagate through the system, as well as demonstrating how they evade security measures, if any are encountered.
• When pointing to a particular part of the documentation, you must provide links to the documentation and clearly identify which version of the document you performed your analysis on.

C.4.3 Proof of Concepts

• When providing a proof of concept, you must additionally provide a proof of exploitation (such as screenshots or videos) demonstrating you successfully ran the proof of concept.
• Your PoC must exploit an actual instance of the e-voting system, such as the one we occasionally provide on https://demo.evoting.ch/ or your own (see here for building instructions (note that other components have other building instructions provided in other repositories)).
• PoCs based on partial builds are acceptable, provided they contain enough of the affected component to demonstrate the vulnerability under conditions representative of normal operation, and are accompanied by analysis explaining how the demonstrated behavior applies to the full system. PoCs that heavily emulate relevant parts of the vulnerable component will be considered insufficient.

C.4.4 General best practices

Reports that merely recommend adherence to general security best practices, without demonstrating a concrete weakness in the project’s design or implementation, are out of scope.

Reports that demonstrate, through thorough analysis, that an expected security control or mitigation is missing, inconsistent with existing protections, and directly relevant to the e-voting system’s defined threat model, are in scope.

C.5 Peculiarities

• We reserve the right to use a "OneFixOneReward" rule, i.e., if two or more endpoints/forms use the same code base and a single fix can be deployed to fix all the ensuing flaws, only one report will be considered as eligible for a reward and other reports will be closed as informative. However, all reports will be reviewed edge by edge.