Privitect – An Automated Privacy Threat Detection Tool

Design Privacy In. Architect Out The threat.

Privacy Threat Modeling (PTM) is critical to engineering Privacy by Design into an application, just as security threat modeling is essential for the secure software development lifecycle. Within PTM, privacy threat analysis identifies technical data vulnerabilities during the design phase, helping engineers mitigate privacy risks before an application is built.

However, manual analysis is a cognitively heavy task that scales poorly. This bottleneck is driven by the sheer volume of modern data assets, complex cross-application data flows, and the highly context-dependent nature of privacy rules.

To address this limitation, Privitect provides an automated privacy threat detection tool that offers self-service capabilities for developers and advanced analytical support for privacy architects. By extending Threagile, an open-source agile threat modeling toolkit, Privitect introduces a suite of 12 privacy rules that automatically detect technical privacy threats directly within a system architecture model.

Privitect's privacy rules are directly aligned with the LINDDUN privacy threat modeling framework and the risks outlined in the OWASP Top 10 Privacy Risks 2021.

By analyzing a system architecture model defined in a YAML file, Privitect automatically flags potential privacy threats across core LINDDUN threat categories, including Linking, Identifying, Data Disclosure, Unawareness, and Non-compliance.

Privitect provides:

• A suite of 12 privacy rules implemented in Go, executing concurrently alongside Threagile's built-in security rules.
• Direct architectural mappings for each rule to LINDDUN Threat Tree categories, the OWASP Top 10 Privacy Risks, or both.
• Pre-configured, YAML-based test models to validate rule behavior against predefined threat scenarios.
• A Docker-based quickstart environment for the immediate evaluation of your architecture models.

📖 Background

LINDDUN

LINDDUN is a privacy threat modeling framework designed to help identify and mitigate privacy threats in software systems and IT landscapes. It provides a structured and systematic approach to analyze potential privacy issues early in the development lifecycle, supporting the principles of privacy-by-design.

The name LINDDUN is an acronym representing seven key privacy threat categories:

1. Linking: Threats related to combining different pieces of data, potentially from various sources, to build a more comprehensive picture of an individual, even if the individual's identity isn't directly revealed.
2. Identifying: Threats where an individual's identity can be determined from data that is not intended to be identifying.
3. Non-repudiation: Threats where an individual cannot deny having performed a specific action because there is irrefutable evidence linked to them.  
4. Detecting: Threats related to discovering the existence of data or an event, even if the content of the data is not revealed. This can still be sensitive information.
5. Data Disclosure: Threats involving the unauthorized or excessive exposure of personal data.  
6. Unawareness: Threats where individuals are not sufficiently informed about how their data is being processed or lack control over it.  
7. Non-compliance: Threats arising from the failure to comply with relevant privacy regulations, policies, or legal requirements.  

🔍 Privacy Rules

The privacy rules are implemented as Go files in pkg/risks/privacy. Each rule is encapsulated in a struct providing:

• Category() — Defines the rule's metadata: title, description, and detection logic.
• GenerateRisks(model *types.Model) ([]*types.Risk, error) — Analyzes the system model and generates potential threats.
• createRisk(...) — Creates a risk object with details about the identified issue.

List of Rules

1. Data Disclosure by Unnecessary Propagation (custom-privacy-data-disclosure-by-unnecessary-propagation-rule.go) Detects threats where personal data (PI) is unnecessarily propagated to technical assets that do not require it, violating data minimization principles. (LINDDUN DD3.2)

2. Data Disclosure by Unnecessary Retention (custom-privacy-data-disclosure-by-unnecessary-retention-rule.go) Identifies threats where personal data (PI) is retained beyond its operational need, violating data retention policies. (LINDDUN DD3.4)

3. Data Minimization and Destruction (custom-privacy-data-minimization-and-destruction-rule.go) Detects threats where personal data (PI) is received but not sent, stored, or processed, violating data minimization principles. (LINDDUN DD1.1)

4. Data Minimization and Exclusion (custom-privacy-data-minimization-and-exclusion-rule.go) Identifies threats where personal data is received but not used, violating data minimization and exclusion principles. (LINDDUN Nc1.1.2)

5. Disclosure by Publishing (custom-privacy-disclosure-by-publishing-rule.go) Flags threats where personal data is published or stored in internet-facing systems, leading to potential disclosure. (LINDDUN DD4.2)

6. Improper PI Management (custom-privacy-improper-pi-management-rule.go) Detects threats when the organization lacks proper data lifecycle management, flagging all personal data assets as improperly managed. (LINDDUN Nc.2)

7. Insecure Data Storage (custom-privacy-insecure-data-storage-rule.go) Identifies threats where personal data is stored without encryption in persistent storage systems. (OWASP Top 10 Privacy: Operator-Side Data Leakage)

8. Insufficient Access Management (custom-privacy-insufficient-access-management-rule.go) Flags threats where personal data is transferred without proper authentication or authorization. (OWASP Top 10 Privacy: Operator-Side Data Leakage)

9. Lack of Data Access Mechanism (custom-privacy-lack-of-data-access-mechanism-rule.go) Detects threats when the system does not provide mechanisms for users to access their personal data. (LINDDUN U2.2)

10. Linking Through Unique or Quasi-Identifier Combination (custom-privacy-linking-through-unique-or-quasi-identifier-combination-rule.go) Identifies threats where data subjects can be linked using direct identifiers (DI) or combinations of quasi-identifiers (QI) exceeding a threshold. (LINDDUN L1.1, L2.1.1, L2.1.2)

11. Receiving Identifying Data (custom-privacy-receiving-identifying-data-rule.go) Flags threats where non-authenticating or non-network-management systems receive direct identifiers (DI) or quasi-identifiers (QI). (LINDDUN I1, I2.1)

12. Storing Identifying Data (custom-privacy-storing-identifying-data-rule.go) Detects threats where technical assets store direct identifiers (DI) or combinations of quasi-identifiers (QI) exceeding a threshold. (LINDDUN I.2)

Test models (YAML) for each rule are located in demo/privacy/. More details are available in docs/privacy-rules.md.

🚀 Quickstart

Prerequisites

• Docker

Steps

1. Build the Docker image:

   docker build --no-cache --platform linux/x86_64 --pull --rm -f "Dockerfile.local" -t privitect:privacy20250501 "."

2. Start the server:

   docker run --rm -it --shm-size=256m -p 8080:8080 --name threagile-server \
     --mount 'type=volume,src=threagile-storage,dst=/data,readonly=false' \
     privitect:privacy20250501 server 8080

3. Open the browser: Navigate to http://localhost:8080.

4. Analyze your model: Click Choose File, select a YAML model file (test models are in demo/privacy/), then click Analyze.

5. Review results: A threagile-result.zip will be downloaded. Unzip and open risks.xlsx to view detected privacy (and security) threats.

🤝 Contribution

We welcome all kinds of contributions to this repository! Please have a look at CONTRIBUTING.md for more information and guidelines.

👥 Contributors

• Nitish M. Uplavikar — Research Engineer, Comcast Cable Communications (nitish_uplavikar@comcast.com)
• Jayati Dev — Research Engineer, Comcast Cable Communications (jayati_dev@comcast.com)
• Bahman Rashidi — Director, Comcast Cable Communications (bahman_rashidi@comcast.com)
• Vaibhav Garg — Director, Comcast Cable Communications (vaibhav_garg@comcast.com)
• Nuray Baltaci Akhuseyinoglu — Researcher

---

About Threagile

Privitect is built on top of Threagile — an open-source toolkit for agile threat modeling. Threagile allows you to model an architecture with its assets as a YAML file directly inside the IDE. Upon execution, all standard threat rules (and any custom rules) are checked against the model.

For more information on using Threagile directly, see:

• Model schema
• Commands
• Flags
• Configuration
• Includes
• Macros
• How-to guides
• Releases