# SecureDrop: the whistleblower submission platform newsrooms install themselves > SecureDrop is a self-hosted whistleblower submission system that media organizations run on their own infrastructure to accept documents from anonymous sources. This review covers what the repository actually ships, how to bring up a local development instance, and where the project's focus has moved. **freedomofpress/securedrop** — GitHub repository for the SecureDrop whistleblower platform. Do not submit tips here! - Repository: https://github.com/freedomofpress/securedrop - Website: https://securedrop.org/ - Stars: 3,887 · Forks: 723 - Language: Python - License: NOASSERTION - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/freedomofpress-securedrop ## What SecureDrop solves, and who the README says it is for The README describes SecureDrop as "an open-source whistleblower submission system that media organizations can use to securely accept documents from, and communicate with anonymous sources." That sentence sets the audience precisely: newsrooms, not individual bloggers and not product teams. The problem it addresses is that a source who wants to hand over documents needs a channel that does not leave a trail back to them, and a newsroom needs to receive those documents without exposing the source's identity through the receiving infrastructure. The project was originally created by Aaron Swartz and is managed by the Freedom of the Press Foundation. That governance detail matters for adoption decisions, because it means the roadmap is set by an organization whose stated mission is press freedom rather than by a commercial vendor with a support contract to sell. The repository itself is the server-side platform, and the README is explicit that this is not the place to submit tips: the first line of the description reads "Do not submit tips here!" The README also points out that SecureDrop is "a stable, mature project that is actively in use in newsrooms across the globe." Note what follows that sentence: most feature development is now directed at SecureDrop Workstation, SecureDrop Client and SecureDrop Protocol, and this repository "continues to receive security and bug fixes in the meantime." Anyone evaluating the codebase should read that as a statement about where engineering attention goes, not as an abandonment notice. ## How the codebase is put together: Python application, Rust redwood, Ansible install files The top-level layout tells you most of what you need to know about the architecture. The securedrop/ directory holds the Python application, which the repository topics label a flask-application. The install_files/, molecule/, ossec/ and tails_files/ directories are the deployment and hardening layer. Cargo.toml declares a workspace whose only member is redwood, so there is a Rust component in the tree alongside the Python server. The admin/, devops/, builder/ and utils/ directories hold the tooling that supports installation and maintenance. The Python side is configured through pyproject.toml, which sets requires-python to ">=3.12" and enables a long list of Ruff lint rules. Two entries in that file are worth reading as design statements rather than style preferences. The ignore list includes "S104" with the comment "yes, we bind to 0.0.0.0", and it includes the hardcoded-password checks S105 and S106 as "lots of false positives." A project that documents why it is suppressing a security lint is a project whose maintainers have thought about the suppression. The Makefile is the front door for anyone working on the code. It defines SDROOT from git rev-parse --show-toplevel, selects docker or podman based on the USE_PODMAN variable, and exposes targets for virtualenv provisioning, requirement updates, and static analysis. STABLE_VER is read from molecule/shared/stable.ver, which is how the test tooling knows which released version to compare against. The wordlists that generate source passphrases live in securedrop/wordlists/, with en.txt derived from the EFF's Diceware list and fr.txt derived from Matthieu Weber's translated list plus a French list from trezor/python-mnemonic. ## Installing SecureDrop locally with make dev The README's Installation Guide for production lives at docs.securedrop.org, and the repository does not reproduce those steps. What it does document is the developer quickstart, which is the fastest way to see the system run. Docker is the only prerequisite: Docker Engine on Linux, or Docker Desktop on Windows and macOS. With Docker running, one target brings up both interfaces: ```bash make dev ``` The README states that this starts the source interface on 127.0.0.1:8080 and the journalist interface on 127.0.0.1:8081, and that the login credentials are printed in the terminal. That is the first thing to look for after the containers settle: the credentials appear in the command output, not in a file you have to hunt for. Logging into the journalist interface has an extra step. The README says you must also generate a two-factor code, and links to the developer documentation at developers.securedrop.org for the credentials page. Expect to have that page open in a second tab before you try the login. If you want to work on the Python application rather than just run it, the README gives a second command for provisioning an environment: ```bash make venv && source ./venv/bin/activate ``` Note the discrepancy: the README's quickstart writes ./venv/bin/activate, while the Makefile's venv target prints "Make sure to run: source .venv/bin/activate". Those are two different paths. Check which directory actually exists after the target finishes before sourcing anything. It is a small documentation inconsistency, but it is exactly the kind of thing that costs a newcomer ten minutes. ## Where SecureDrop is the wrong tool SecureDrop is not a secure contact form you drop into an existing website. The README's own framing, a system that media organizations use, implies an organization that can own dedicated infrastructure, publish a Tor hidden service, and staff the receiving end. If you want an anonymous tip box bolted onto a WordPress site, this is a heavier answer than the question. The production installation is not a single command. The README routes you to an external Installation Guide, and the repository carries install_files/, molecule/ scenarios, ossec/ configuration, and tails_files/ for a reason: the deployment involves provisioning, hardening and verification steps that the code repository does not compress into one target. Budget for the operational work, not just the software. The project's own status section is the other boundary. Feature development is concentrated in SecureDrop Workstation, SecureDrop Client and SecureDrop Protocol. If the capability you want is a Workstation-side improvement, filing it against this repository is the wrong place, and the README points to the "Future directions for SecureDrop" blog post for the reasoning. The changelog and release history here reflect a maintenance posture: 2.16.1 in July 2026, 2.16.0 in June 2026, 2.15.1 in April 2026. Finally, security reports have a separate channel. The README asks that security issues go to the Bugcrowd bug bounty rather than the public issue tracker, and non-security issues to GitHub Issues. If your team's habit is to open a public issue the moment something looks wrong, that habit conflicts with this project's disclosure protocol. ## SecureDrop compared with building on a general anonymity network yourself The obvious alternative is to assemble your own submission pipeline: a Tor hidden service in front of a web application you write, with your own storage and your own access controls. The difference in approach is where the security decisions live. With a custom build, you make every choice about how the source's session is isolated, how submitted documents are stored, how journalists retrieve them, and how the two sides of the system are kept apart. SecureDrop ships those decisions as a product with an installation guide, a hardening layer in install_files/ and ossec/, and a documented separation between the source interface and the journalist interface. You inherit a threat model that has been argued about by people whose job is press freedom, and you inherit its constraints too. That trade is not automatically in SecureDrop's favor. A custom build can be simpler if your requirements are narrower, and it avoids the operational weight of the full platform. What it does not give you is the accumulated review. The repository carries a SECURITY.md, a .semgrep/ directory for static analysis rules, a supply-chain/ directory, and a bug bounty hosted by Bugcrowd. Those are artifacts of a project that expects adversarial attention. The other realistic alternative is to treat the newer components as the thing you evaluate. SecureDrop Workstation and SecureDrop Client are where the README says feature development is focused, and SecureDrop Protocol is named alongside them. If your interest is in how journalists handle submissions day to day, those repositories, not this one, describe the current direction. ## Licence, upgrade cost and what the repository does not tell you The README states that SecureDrop is released under the GNU Affero General Public License v3, and the LICENSE file sits at the repository root. The GitHub metadata for the repository reports the licence as NOASSERTION, which is a metadata classification rather than a contradiction of the README; the README's own sentence is the clearer statement. AGPLv3 matters if you plan to modify the server and offer it to users over a network, because that triggers source-availability obligations. This is a description of the licence, not legal advice, and any organization weighing those obligations should read the LICENSE file directly. Upgrade cost is visible in the release cadence: 2.15.1 in April 2026, 2.16.0 in June 2026, 2.16.1 in July 2026. That is a steady stream of point releases, and the README's statement that the project "continues to receive security and bug fixes" means you should expect to apply them. The Makefile exposes update-pip-requirements, update-admin-pip-requirements and update-python3-requirements targets for keeping dependencies current during development, and the venv target runs hooks. Those targets are for contributors; they are not a production upgrade procedure, and the README does not document one here. The pyproject.toml uv configuration sets exclude-newer to "7 days", a supply-chain measure that refuses dependency versions published within the last week. That is a real policy choice with a real cost: urgent upstream fixes are also held back for seven days unless someone overrides the setting. What the README does not cover is rollback. There is no documented procedure for reverting a failed production upgrade in this repository, and anyone planning a deployment should confirm that with the Installation Guide before committing to a schedule. ## Conclusion Adopt SecureDrop if you are a newsroom with the operational capacity to run dedicated hardware and a Tor hidden service, and if you accept that most new feature work now happens in the Workstation, Client and Protocol repositories rather than here. Do not adopt it as a general secure contact form or a drop-in file upload for a web product; the threat model assumes an adversary with network-level reach and the install is not a one-command deploy. Verify first that your organization can follow the Installation Guide at docs.securedrop.org, that you can commit to the upgrade cadence implied by releases such as 2.16.1, and that you know which repository owns the component you actually need before filing an issue. ## FAQ ### Is SecureDrop safe to use? The README describes SecureDrop as a stable, mature project in use in newsrooms worldwide, and security issues are handled through a Bugcrowd bug bounty rather than the public tracker. Safety in practice depends on the deployment being installed and maintained according to the Installation Guide, not on the code alone. ### How do I use SecureDrop? The README links separate documentation for using it as a source and as a journalist, both under docs.securedrop.org. For local development it gives make dev, which starts the source interface on 127.0.0.1:8080 and the journalist interface on 127.0.0.1:8081. ### What is SecureDrop? It is an open-source whistleblower submission system that media organizations use to securely accept documents from, and communicate with, anonymous sources. It was originally created by Aaron Swartz and is managed by the Freedom of the Press Foundation. ### Is SecureDrop free? Yes. The README states that SecureDrop is open source and released under the GNU Affero General Public License v3, with the LICENSE file at the repository root. Free refers to the licence; running a production instance still requires the infrastructure and staffing the Installation Guide describes. ### What are the alternatives to SecureDrop? The README does not name competing products. The realistic in-project alternative is to evaluate the components where development is focused, SecureDrop Workstation, SecureDrop Client and SecureDrop Protocol, rather than this server repository. Building your own Tor-hidden-service submission pipeline is the other approach, at the cost of designing every security decision yourself. ## Sources - [freedomofpress/securedrop on GitHub](https://github.com/freedomofpress/securedrop) - [Issues](https://github.com/freedomofpress/securedrop/issues) - [Project website](https://securedrop.org/) - [README](https://github.com/freedomofpress/securedrop/blob/develop/README.md) - [Releases](https://github.com/freedomofpress/securedrop/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/freedomofpress-securedrop