Privado traces personal data from the point of collection to the sink

A question-answering graph over sensitive data

Privado is an open source static code analysis tool to discover data flows in the code. It detects more than 110 personal data elements being processed, and it maps the data flow from the point of collection to sinks such as external third parties, databases, logs and internal APIs.

That is the core idea and it is a good one. Privacy work usually starts with a question, what personal data does this application collect, where does it go, and who else sees it, and the answer today is a spreadsheet that a team maintains by hand. A static analyser can produce the first draft mechanically, because the collection point and the sink are both visible in the code.

The mechanism is a knowledge graph. The documentation says Privado creates a knowledge graph during the scanning process that contextually answers thousands of questions about sensitive data. The point of a graph rather than a list is that a privacy question is rarely about one variable. A user identifier might be collected, stored in a database, copied into a log line, and forwarded to an analytics SDK, and each of those edges is a separate answer.

The audience is listed explicitly, and the list is a good indicator of who gets value from this. Privacy engineers, data protection engineers, data governance engineers, security engineers, mobile app developers and developers in general. What the tool gives them is the ability to ask contextual questions about the usage of sensitive data at scale.

The project is licensed LGPL-3.0, with the standard COPYING and COPYING.LESSER files in the repository root, and the last push was on 2026-10-14.

Installing the CLI and running the first scan

The quick start asks for Docker on your system first, and then three steps.

The CLI is installed with a one line script:

curl -o- https://raw.githubusercontent.com/Privado-Inc/privado-cli/main/install.sh | bash

The documentation recommends a sample app to try it against, a banking system backend, so you are not pointing the analyser at your own code on the first run:

git clone [email protected]:saurabh-sudo/BankingSystem-Backend.git

And the scan itself takes the source directory:

privado scan <source directory>

The result is written to a JSON file inside the scanned directory, at .privado/privado.json, and a preview is shown in the terminal. That path matters for two reasons. It means the output sits next to the code it describes rather than in a central service, and it means the file is easy to ignore, diff and archive in a repository.

The container image backs the analysis. The Dockerfile at the root of this repository is an Alpine base that copies the rules directory into the image and writes the version into a version.txt file, which is how the rules shipped with the analyser are versioned against the code that consumes them. The rules/ directory in the repository is therefore the interesting part if you want to know what the tool considers a data element or a sink.

The scan stays local, the optional sync does not

The privacy property that matters for an analyser like this is where the code goes, and the documentation is explicit about it. Privado can be run locally on your computer or in your CI/CD pipeline, and since the scan is local, you never have to worry about your code leaving your machine.

The results are a different matter, and the boundary is drawn carefully. After a scan completes, the tool asks for permission to synchronize the generated results with the Privado Cloud Dashboard, and it states that no code is sent to the cloud, only the JSON output generated by the scan. To visualize the results and generate reports, you create a free account.

So the flow is: the analysis happens on your machine, the artefact is a JSON file, and the cloud is an optional reporting layer that consumes that artefact. For a pipeline, that distinction is the difference between a tool you can run in an air-gapped build and one you cannot, and it is also the difference between an opt-in step and a mandatory one.

The practical advice is to treat the sync as opt-in in your CI, because the default behaviour of a tool that asks at the end of a successful run is to ask. A team that wants the JSON and nothing else needs to say so explicitly, and the file path is stable enough to archive as a build output.

What a scan produces and which reports come out of it

A scan discovers five categories of information and presents them for review in a dashboard: Data Elements, Data Flow Diagrams, Data Inventory, Code Analysis and Issues.

Those five outputs are what feed the reporting side, and the two reports the documentation describes are the Record of Processing Activity report and the Android Data Safety Report.

The RoPA report is the one European teams are asked for, since the use case list names RoPA and Article 30 reports, and the free cloud platform can generate them for one or more synced repositories.

The Data Safety Report is described in terms of the problem it removes. It is a privacy form needed to publish any Android app on the Play Store, and filling it out usually means developers asking around the team to find out what data is being collected, spending hours reading SDK documentation to see where information is shared, and then navigating a complex form. With the scan, the data types that are collected and shared are pre-filled, and a wizard walks through generating the report.

The rest of the use case list shows how far the same graph is pushed: automating data flow diagrams, identifying and removing data leaks, improving storage security by finding insecure practices, finding unaccounted third party sharing of data, establishing and enforcing data protection policies, incorporating GDPR, CCPA, SOC, ISO, HIPAA and PCI controls, continuous monitoring for privacy and data issues, and implementing privacy by design.

Java and Python only in the open source edition

The language coverage is the clearest boundary in the project, and the documentation does not soften it.

Java and Python are supported in general availability. The enterprise offering covers all programming languages, and the project says it is working on adding support for more languages to the open source edition, with support for JavaScript and TypeScript coming soon.

That is a meaningful constraint for adoption, because the tool's headline use case includes mobile apps, and mobile teams often have a JavaScript or TypeScript codebase somewhere in the stack even when the server side is Java. For a mixed codebase, the open source edition gives you a partial map, and a partial map is still useful, since the flows it finds in the server code are the flows that matter for a data safety form, but it is not the whole picture.

The second limitation follows from the first and is more mundane. Because the analyser is built around rules that describe what a data element and a sink look like in a given language, the quality of the output is a property of those rules. The repository ships a rules/ directory for exactly that reason, and a team with unusual patterns in its own code will find that the interesting work is tuning the rules rather than running the scan.

The other practical point is the output itself. The JSON file is the interface, so anything you want to build on top of the results, a dashboard of your own, a policy check, a report in your own format, is a job for something that reads that file rather than for the analyser.

Rules, a GitBook manual and a CodeBuild spec

The repository layout shows what this project is made of, and it is not a typical application repository.

The rules/ directory is the analyser's knowledge base, the descriptions of data elements and sinks that make the graph mean something. The config/ directory holds configuration. The Dockerfile packages the rules into an Alpine image, copying the tree into the image under a rules directory and appending the build version to a version.txt file, so the rules carry the version of the code that consumes them.

Documentation is a GitBook site, with a .gitbook/ directory and a .gitbook.yaml configuration at the root, and the published version is at docs.privado.ai. A SUMMARY.md file sits alongside it, which is how a GitBook table of contents is expressed.

Two other files point at how the tool is meant to be operated. The PRIVACY.md file is the project's own privacy statement, which is a reasonable thing to expect from a privacy tool and a useful signal about how the authors think about it. The trufflehog/ directory suggests that secret detection is part of the rule set rather than something bolted on separately.

There is also a buildspec.yml, the AWS CodeBuild specification, which is a reminder that this is designed to run in a pipeline as much as on a laptop, and a SECURITY.md alongside a CODE_OF_CONDUCT.md for the usual reporting and conduct routes.

Release cadence and what the licence means for a scanner

The release history shows a project that ships often. The three most recent tags are v1.3.92 on 2026-10-14, v1.3.91 on 2025-11-10 and v1.3.90 on 2025-10-27, and the last push to the main branch was on 2026-10-14.

The gap between v1.3.90 and v1.3.91 is about two weeks, and then there is a longer pause before v1.3.92, which is a year later. The version numbers sit in the 1.3 line throughout, so there is no major version jump to plan around, which is the kind of stability you want in a tool you wire into a build.

The licence is LGPL-3.0, with COPYING and COPYING.LESSER in the repository root. For a scanner that is run as a tool against a codebase rather than linked into a product, the practical effect is modest, but it is worth being precise about the shape of the obligation. The scan results, the JSON file and the knowledge graph your team derives from them are yours. The tool itself is used as a separate program, so the copyleft reaches modifications to the tool rather than your application.

The cloud side is a separate question from the licence, and the documentation treats it that way. The open source scanner runs locally and produces a JSON file, and the visualisation and reporting layer is a hosted product with a free account. If your requirement is that the reporting layer also runs on your own infrastructure, that is the part to raise with the project rather than assume from the scanner's licence.

Editorial conclusion

Privado suits a privacy or security team that needs an inventory of personal data in a Java or Python codebase and a starting point for a data safety form, and it is the wrong tool for a team with a polyglot codebase, since only Java and Python are generally available and other languages are covered by the enterprise offering. Before adopting it, run it on one repository to see the JSON at .privado/privado.json, and decide up front whether the optional synchronisation to Privado Cloud is acceptable in your pipeline.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. Privado-Inc/privado on GitHub
3. Project website
4. README
5. Releases