privacy-assessment-rails

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Privacy Assessment — Full Codebase Analysis

隐私评估 — 完整代码库分析

Prerequisite

前提条件

Dependency path: !

test -d "${CLAUDE_SKILL_DIR}/../privacy-by-design-rails" && echo "${CLAUDE_SKILL_DIR}/../privacy-by-design-rails" || echo "NOT_FOUND"

If the dependency path above is

NOT_FOUND

, stop and tell the user:

This skill depends on privacy-by-design-rails, which is not installed. Install it with:
npx skills add codeminer42/skills --skill privacy-by-design-rails
(add
-g
for global installation)

Do not proceed until the dependency is installed.

Before starting, warn the user: "This assessment is token-intensive — it runs a scanner, then reads and analyzes many files across your codebase. Are you sure you want to proceed?" Wait for confirmation before continuing.

依赖路径：!

test -d "${CLAUDE_SKILL_DIR}/../privacy-by-design-rails" && echo "${CLAUDE_SKILL_DIR}/../privacy-by-design-rails" || echo "NOT_FOUND"

如果上述依赖路径显示为

NOT_FOUND

，请停止操作并告知用户：

该Skill依赖privacy-by-design-rails，但它尚未安装。请使用以下命令安装：
npx skills add codeminer42/skills --skill privacy-by-design-rails
（添加
-g
参数进行全局安装）

在依赖安装完成前，请勿继续操作。

开始之前，请提醒用户："本次评估会消耗大量Token —— 它将运行扫描器，然后读取并分析代码库中的大量文件。您确定要继续吗？" 等待用户确认后再继续。

Step 0: Context Gathering

步骤0：上下文收集

Before running any analysis, ask the user:

Before I begin the assessment, are there any privacy particularities I should know about this application? For example:

Data that would normally be considered PII but is required by regulation (e.g., storing full IP addresses for legal compliance, retaining financial records for tax purposes)

Special categories of data the app handles (health data, biometric data, data from minors)

Third-party services that are contractually authorized to receive certain PII

Known trade-offs or accepted risks the team has already evaluated

Any other domain-specific context that might affect the assessment

What markets/countries does this application serve? (e.g., "Brazil only", "EU and US", "Global", specific country names). This determines which privacy regulations and government document types are relevant for PII classification.

Wait for the user's response. Store their answers as context — this may affect severity ratings, whether certain findings are flagged, and what recommendations are appropriate.

The generated report must begin with the following note, placed before the Disclaimer:

Note: This report was generated by an AI assistant. You can discuss any finding with the agent — ask for more context, challenge a severity rating, provide additional information about your use case, or request that findings be re-evaluated. The agent can also help you prioritize and implement the recommended fixes.

The generated report must also include the following disclaimer, placed before the Executive Summary:

Disclaimer: This report is a technical codebase analysis produced by an automated tool and AI assistant. It does not constitute legal advice, has no legal validity, and does not bind Codeminer42 or any party to its findings. This report should not be used in court or as evidence of compliance or non-compliance. All legal matters related to data protection, GDPR, LGPD, or any other privacy regulation should be discussed with a qualified lawyer.

在运行任何分析之前，请询问用户：

在开始评估之前，关于此应用是否有任何隐私相关的特殊情况我需要了解？ 例如：

通常被视为PII（个人可识别信息）但因法规要求必须存储的数据（如为合规存储完整IP地址、为税务目的保留财务记录）

应用处理的特殊类别数据（健康数据、生物识别数据、未成年人数据）

已通过合同授权接收特定PII的第三方服务

团队已评估过的已知权衡或可接受风险

可能影响评估的其他领域特定上下文

此应用服务于哪些市场/国家？（例如："仅巴西"、"欧盟和美国"、"全球"、特定国家名称）。这将决定哪些隐私法规和政府文档类型与PII分类相关。

等待用户回复。将他们的答案作为上下文存储 —— 这可能会影响严重程度评级、是否标记某些发现以及建议的适当性。

生成的报告必须在免责声明之前添加以下说明：

说明： 本报告由AI助手生成。您可以与Agent讨论任何发现 —— 询问更多上下文、质疑严重程度评级、提供有关您用例的额外信息，或请求重新评估发现。Agent还可以帮助您确定修复的优先级并实施建议的修复方案。

生成的报告必须在执行摘要之前包含以下免责声明：

免责声明： 本报告是由自动化工具和AI助手生成的技术代码库分析报告。它不构成法律建议，不具备法律效力，也不对Codeminer42或任何相关方具有约束力。本报告不得用于法庭或作为合规或不合规的证据。所有与数据保护、GDPR、LGPD或任何其他隐私法规相关的法律事务，均应咨询合格律师。

Step 1: Scanner Baseline

步骤1：扫描器基线检查

ruby

is not found when running the commands below, ask the user how to run Ruby in their environment instead of trying to resolve it yourself.

Run the scanner to get a mechanical baseline. Include the

--markets

flag with the markets the user provided in Step 0 (e.g.,

br

for Brazil,

eu

for EU,

us

for US — comma-separated for multiple):

bash

ruby ${CLAUDE_SKILL_DIR}/../privacy-by-design-rails/scripts/scanner.rb --markets <markets>

The scanner outputs JSON. Parse it to extract:

findings
— pre-filled findings with severity, location, and confidence. Flag any
```
medium
```
-confidence findings for verification in Step 2.
inventory
— the scanner enumerates models, mailers, mailer templates, jobs, controllers, services, initializers, schema tables with PII columns, ransackable models, audit declarations, external API calls, and JSON endpoints. Use this inventory as the starting point for A3 in Step 2a — only supplement with manual discovery if you notice gaps.
checklist
— boolean pass/fail/null for each privacy check. You will update these during Step 2.

如果运行以下命令时未找到

ruby

，请询问用户如何在其环境中运行Ruby，不要自行尝试解决。

运行扫描器以获取机械基线。使用用户在步骤0中提供的市场信息添加

--markets

参数（例如：

br

代表巴西，

eu

代表欧盟，

us

代表美国 —— 多个市场用逗号分隔）：

bash

ruby ${CLAUDE_SKILL_DIR}/../privacy-by-design-rails/scripts/scanner.rb --markets <markets>

扫描器输出JSON格式结果。解析结果以提取：

findings
—— 预填充的发现项，包含严重程度、位置和可信度。标记所有可信度为
```
medium
```
的发现项，以便在步骤2中进行验证。
inventory
—— 扫描器会枚举模型、邮件器、邮件器模板、任务、控制器、服务、初始化器、包含PII列的模式表、可Ransack的模型、审计声明、外部API调用和JSON端点。将此清单作为步骤2a中A3部分的起点 —— 仅当发现存在遗漏时，才通过手动补充来完善。
checklist
—— 每个隐私检查项的布尔值结果：通过/失败/未检查。您将在步骤2中更新这些结果。

Step 2: Deep-Dive Analysis (Two-Pass)

步骤2：深度分析（两轮检查）

Read

${CLAUDE_SKILL_DIR}/assessment-reference.md

. The analysis proceeds in two mandatory passes:

阅读

${CLAUDE_SKILL_DIR}/assessment-reference.md

。分析需按以下两轮强制流程进行：

Step 2a: Discovery Pass

步骤2a：发现阶段

Process checklist items A1 through A4 only. This builds your complete codebase inventory and verification matrix.

Execute EVERY enumeration command in A3. Do not skip any.
Build the verification matrix in A4 with a row for every PII model.
Do NOT write any findings yet. Do NOT skip ahead to analysis.
Use ultrathink for extended reasoning about PII classification decisions, applying the Mandatory Classification Rules from
```
references/pii-definition.md
```
.

When A4 is complete, verify: does every model from the A3 enumeration that has PII columns have a row in the matrix? If not, go back and add the missing rows.

仅处理检查清单中的A1至A4项。这将构建您的完整代码库清单和验证矩阵。

执行A3中的每一个枚举命令，不得跳过任何命令。
在A4中构建验证矩阵，为每个PII模型创建一行。
暂不记录任何发现项，也不要提前进行分析。
使用ultrathink进行扩展推理，以确定PII分类，需遵循
```
references/pii-definition.md
```
中的强制分类规则。

完成A4后，验证：A3枚举中所有包含PII列的模型，在矩阵中是否都有对应的行？如果没有，请返回补充缺失的行。

Step 2b: Analysis Pass

步骤2b：分析阶段

Process checklist items B1 through I2 sequentially. For each item:

Record the outcome: FINDING (with severity), PASS, or N/A
Update the verification matrix columns as you go (B1 updates
```
encrypts?
```
, B3 updates
```
filter_attributes?
```
, F1 updates
```
ransackable reviewed?
```
)
Do not move to the next item until the current one is resolved
Use ultrathink for extended reasoning about what is being checked

Additionally:

User context: Factor in the user's answers from Step 0. If they said certain data must be stored for regulatory reasons, note it as an accepted trade-off rather than a finding.

Read the rules in

${CLAUDE_SKILL_DIR}/../privacy-by-design-rails/rules/

and references in

${CLAUDE_SKILL_DIR}/../privacy-by-design-rails/references/

for correct patterns and context.

按顺序处理检查清单中的B1至I2项。对于每个项：

记录结果：发现项（含严重程度）、通过或不适用
处理过程中更新验证矩阵的列（B1更新
```
encrypts?
```
，B3更新
```
filter_attributes?
```
，F1更新
```
ransackable reviewed?
```
）
完成当前项后再处理下一项，不得跳过
使用ultrathink进行扩展推理，明确当前检查的内容

此外：

用户上下文： 考虑用户在步骤0中的回答。如果用户表示某些数据因法规要求必须存储，请将其标记为可接受的权衡，而非发现项。

阅读

${CLAUDE_SKILL_DIR}/../privacy-by-design-rails/rules/

中的规则和

${CLAUDE_SKILL_DIR}/../privacy-by-design-rails/references/

中的参考文档，以确保模式和上下文的正确性。

Step 2c: Completeness Gate

步骤2c：完整性检查

Step 3: Assemble Report

步骤3：组装报告

Merge scanner findings with your deep-dive findings into a single report.

For every finding, include:

Rule: rule name from
```
rules/
```
Location:
```
file:line
```
Description: what is wrong
Current code: actual code block from the codebase
Recommended fix: corrected code block from the rule/reference
Reference: reference file for deeper context

Important: For every recommended fix that includes code, read the corresponding reference file in

${CLAUDE_SKILL_DIR}/../privacy-by-design-rails/references/

and verify the API calls and configuration patterns are correct. Do not write library API calls from memory — copy patterns from the reference docs.

将扫描器发现项与深度分析发现项合并为一份报告。

每个发现项需包含：

规则：
```
rules/
```
中的规则名称
位置：
```
文件:行号
```
描述： 问题内容
当前代码： 代码库中的实际代码块
建议修复方案： 来自规则/参考文档的修正代码块
参考： 提供更深层次上下文的参考文件

重要提示： 对于每个包含代码的建议修复方案，请阅读

${CLAUDE_SKILL_DIR}/../privacy-by-design-rails/references/

中的对应参考文档，验证API调用和配置模式是否正确。请勿凭记忆编写库API调用 —— 请从参考文档中复制模式。

Finding Granularity

发现项粒度

To ensure consistent finding counts across runs, follow these grouping rules:

Unencrypted PII at rest: One finding per model (not per column). List all affected columns inside the finding. E.g., "User model: email, name, ip_address unencrypted" = 1 finding. Three models with unencrypted PII = 3 findings.
filter_attributes missing: One finding per model. Three models missing it = 3 findings.
filter_parameters: Always exactly one finding (the single initializer file), listing all missing fields.
Error reporters / APM tools: One finding per service (Rollbar = 1, NewRelic = 1).
External API leaks: One finding per external service (Slack webhooks = 1, OpenAI API = 1).
Email from:/subject:/body issues: One finding per mailer class (not per method or template). List all affected methods/templates inside the finding.
Job argument logging: One finding for the base class (
```
ApplicationJob
```
), plus one per child that explicitly re-enables. Dismiss children that inherit from a protected base.
Data minimization (ransackable_attributes, strong params): One finding per model. If both AdminUser and Staff expose sensitive ransackable_attributes, that's 2 separate findings, not 1 combined finding.
Audit/log column PII: One finding per audit mechanism (e.g.,
```
audited
```
gem = 1 finding covering all affected columns).
Structural safeguards: One finding per missing capability (consent = 1, DSAR = 1, retention = 1).
Security tooling: One finding per missing tool category (static analysis = 1, dependency scanning = 1, log redaction = 1, IP anonymization = 1).

为确保每次运行的发现项数量一致，请遵循以下分组规则：

静态存储的未加密PII： 每个模型一个发现项（而非每个列一个）。在发现项中列出所有受影响的列。例如："User模型：email、name、ip_address未加密" = 1个发现项。三个模型存在未加密PII = 3个发现项。
缺失filter_attributes： 每个模型一个发现项。三个模型缺失该配置 = 3个发现项。
filter_parameters： 始终只有一个发现项（单个初始化器文件），列出所有缺失的字段。
错误报告器/APM工具： 每个服务一个发现项（Rollbar = 1个，NewRelic = 1个）。
外部API泄露： 每个外部服务一个发现项（Slack webhooks = 1个，OpenAI API = 1个）。
Email发件人/主题/内容问题： 每个邮件器类一个发现项（而非每个方法或模板一个）。在发现项中列出所有受影响的方法/模板。
任务参数日志： 基类（
```
ApplicationJob
```
）一个发现项，加上每个显式重新启用该功能的子类一个发现项。忽略从受保护基类继承的子类。
数据最小化（ransackable_attributes、强参数）： 每个模型一个发现项。如果AdminUser和Staff都暴露了敏感的ransackable_attributes，则为2个独立的发现项，而非合并为1个。
审计/日志列中的PII： 每个审计机制一个发现项（例如：
```
audited
```
gem = 1个发现项，涵盖所有受影响的列）。
结构保障缺失： 每个缺失的功能一个发现项（同意机制 = 1个，DSAR = 1个，数据保留 = 1个）。
安全工具缺失： 每个缺失的工具类别一个发现项（静态分析 = 1个，依赖扫描 = 1个，日志脱敏 = 1个，IP匿名化 = 1个）。

PII Master List

PII主列表

During Step 2a (Discovery Pass), collect all identified PII fields into a single PII master list. Reuse this exact list consistently across all remediation recommendations —

filter_parameters

scrub_fields

filter_attributes

, and

ransackable_attributes

exclusions should all reference the same canonical set of PII field names.

在步骤2a（发现阶段）中，将所有识别出的PII字段收集到一个PII主列表中。在所有修复建议中统一复用此列表 ——

filter_parameters

、

scrub_fields

、

filter_attributes

和

ransackable_attributes

的排除项都应引用同一组标准PII字段名称。

Remediation Defaults

修复默认规则

When writing recommended fixes, follow these defaults for consistency:

audited
gem: Always recommend an allowlist approach (
```
audited only: [...]
```
) over expanding the denylist (
```
except: [...]
```
)
filter_parameters
: Always list specific field names (e.g.,
```
:email, :name, :cpf
```
). Never use regex patterns or partial-match wildcards.
ransackable_attributes
: Always recommend a minimal allowlist of only the fields genuinely needed for admin search.
scrub_fields
(error reporters): Include all fields from the PII master list.

编写建议修复方案时，请遵循以下默认规则以确保一致性：

audited
gem：始终建议使用允许列表方式（
```
audited only: [...]
```
），而非扩展拒绝列表（
```
except: [...]
```
）
filter_parameters
：始终列出具体字段名称（例如：
```
:email, :name, :cpf
```
）。请勿使用正则表达式模式或部分匹配通配符。
ransackable_attributes
：始终建议使用最小允许列表，仅包含管理员搜索真正需要的字段。
scrub_fields
（错误报告器）：包含PII主列表中的所有字段。

Authorized External Integrations

授权的外部集成

When the user confirms an external integration is authorized (Step 0), it must still be a numbered finding — never a separate "Accepted Trade-Offs" or "Context-Dependent" section. Handle as follows:

The finding exists because PII is being sent to a third party — that fact doesn't change with authorization.
Severity stays CRITICAL (per the severity table) since PII is leaving the infrastructure. In the description, note that the integration is authorized by the team.
Focus the recommended fix on data minimization: does the payload include more fields than the service actually needs? Recommend removing unnecessary fields, adding audit logging, and ensuring a Data Processing Agreement (DPA) is in place.
Do not create ad-hoc sections like "Accepted Trade-Offs", "Context-Dependent Findings", or "Team Evaluation Required". All findings go in the numbered findings list under their severity.

当用户确认某个外部集成已获得授权（步骤0）时，它仍需作为编号发现项 —— 不要放入单独的"可接受权衡"或"上下文相关"部分。处理方式如下：

由于PII被发送到第三方，因此该发现项仍然存在 —— 授权并不会改变这一事实。
严重程度保持为CRITICAL（根据严重程度表），因为PII正在离开基础设施。在描述中注明该集成已获得团队授权。
修复建议重点关注数据最小化：请求负载是否包含服务实际不需要的字段？建议移除不必要的字段、添加审计日志，并确保已签署数据处理协议（DPA）。
请勿创建诸如"可接受权衡"、"上下文相关发现项"或"团队评估需求"等临时部分。所有发现项均按严重程度列入编号发现项列表。

Finding Order

发现项排序

Within each severity level, order findings using these categories. When multiple findings share a category, use alphabetical order by model/service name as the tiebreaker:

PII to external services (alphabetical by service name)
Unencrypted PII at rest (alphabetical by model name)
filter_parameters (always exactly one finding)
filter_attributes missing (alphabetical by model name)
Logs/cache/queue — base class first, then children alphabetical, then cache, then session
Email (alphabetical by mailer class name)
Audit/versioning columns (alphabetical by mechanism name)
Structural gaps — consent, then DSAR, then retention (fixed order)
Tooling gaps — static analysis, dependency scanning, log redaction, IP anonymization (fixed order)

在每个严重程度级别内，按以下类别排序发现项。当多个发现项属于同一类别时，以模型/服务名称的字母顺序作为平局决胜规则：

发送到外部服务的PII（按服务名称字母顺序）
静态存储的未加密PII（按模型名称字母顺序）
filter_parameters（始终只有一个发现项）
缺失filter_attributes（按模型名称字母顺序）
日志/缓存/队列 —— 基类优先，然后是子类字母顺序，接着是缓存、会话
Email（按邮件器类名称字母顺序）
审计/版本控制列（按机制名称字母顺序）
结构缺失 —— 同意机制、DSAR、数据保留（固定顺序）
工具缺失 —— 静态分析、依赖扫描、日志脱敏、IP匿名化（固定顺序）

Finding Numbering

发现项编号

Use severity-prefixed sequential numbers: C-1, C-2, ... for critical, H-1, H-2, ... for high, M-1, M-2, ... for medium. Do not use plain sequential numbers (1, 2, 3, ...) or unprefixed labels. Use this format in headings (

#### Finding C-1: ...

), cross-references, and the recommendations section.

Dismissed findings (false positives from the scanner) should not be counted in the totals. List them in a separate "Dismissed Findings" section after the severity sections. Each dismissed scanner finding must appear as a separate row in the Dismissed Findings table, even if multiple findings share the same dismissal reason. Do not group or summarize dismissed findings — one row per scanner finding.

使用带严重程度前缀的连续编号：C-1、C-2... 代表严重，H-1、H-2... 代表高，M-1、M-2... 代表中。请勿使用纯连续数字（1、2、3...）或无前缀标签。在标题（

#### 发现项 C-1: ...

）、交叉引用和建议部分使用此格式。

已驳回的发现项（扫描器产生的误报）不应计入总数。在严重程度部分之后的单独**"已驳回发现项"部分列出它们。每个已驳回的扫描器发现项必须在已驳回发现项表中作为单独行**显示，即使多个发现项的驳回原因相同。请勿对已驳回发现项进行分组或汇总 —— 每个扫描器发现项对应一行。

Report Sections

报告章节

The final report must use exactly these sections in this order: Header → Note → Disclaimer → Executive Summary → Findings by Severity → Dismissed Findings → Checklist Summary → Recommendations. The Note and Disclaimer (defined in Step 0) are inserted between the Header and Executive Summary. Do not add, rename, or reorganize sections beyond this. Specifically, do not create ad-hoc sections such as "Context-Dependent Findings", "Accepted Trade-Offs", "Team Evaluation Required", "PII Field Inventory", "User-Provided Context", or "Domain Context". User-provided context from Step 0 should inform finding descriptions and recommended fixes, not get its own section. All findings go in the numbered findings list under their severity.

Executive Summary: X verified findings total (Y critical, Z high, W medium). 2-3 sentences with overall assessment. If false positives were dismissed, add a separate line: "N scanner findings were reviewed and dismissed as false positives — see the Dismissed Findings section for details."
Checklist Summary: Use these labels for the checklist table: All PII fields encrypted, filter_parameters complete, filter_attributes on models, Job arguments suppressed, No PII in job payloads, No PII in email bodies, No PII in cache, Consent model with PURPOSES, RequiresConsent enforcement, DSAR workflow complete, Exports on-demand (no PII at rest), DSAR vs processing exports separated, force_ssl enabled, logstop configured, IP anonymization, Error reporter scrubbing, Data retention jobs scheduled, Security audit gems present. Update statuses based on your deep-dive (some N/A items may become FAIL; some FAIL items may become PASS after manual verification).
Recommendations: prioritized action list grouped by severity.

最终报告必须严格按照以下顺序使用这些章节：标题 → 说明 → 免责声明 → 执行摘要 → 按严重程度分类的发现项 → 已驳回发现项 → 检查清单摘要 → 建议。说明和免责声明（步骤0中定义）插入在标题和执行摘要之间。请勿添加、重命名或重新组织这些章节之外的内容。特别注意，请勿创建诸如"上下文相关发现项"、"可接受权衡"、"团队评估需求"、"PII字段清单"、"用户提供的上下文"或"领域上下文"等临时部分。步骤0中用户提供的上下文应体现在发现项描述和建议修复方案中，而非单独成节。所有发现项均按严重程度列入编号发现项列表。

执行摘要： 共X个已验证发现项（Y个严重、Z个高、W个中）。2-3句话的总体评估。如果存在已驳回的误报，请添加单独一行："已审查并驳回N个扫描器发现项（误报）—— 详情请见已驳回发现项部分。"
检查清单摘要： 检查清单表使用以下标签：所有PII字段已加密、filter_parameters完整、模型已配置filter_attributes、任务参数已屏蔽、任务负载中无PII、Email内容中无PII、缓存中无PII、带PURPOSES的同意模型、RequiresConsent已生效、DSAR流程完整、按需导出（无静态存储PII）、DSAR与处理导出分离、force_ssl已启用、logstop已配置、IP匿名化、错误报告器脱敏、数据保留任务已调度、安全审计gem已存在。根据深度分析结果更新状态（部分不适用项可能变为失败；部分失败项经手动验证后可能变为通过）。
建议： 按严重程度分组的优先操作列表。

Step 4: Save and Offer Fix Plan

步骤4：保存并提供修复计划选项

Ask the user where to save the report (default:

privacy-assessment.md

at project root).

Then offer fix plan strategies:

Highest priority first — CRITICAL > HIGH > MEDIUM
Low-hanging fruit — easiest fixes first regardless of severity
Critical only — just CRITICAL findings
Everything — all findings ordered by severity
Custom — user picks specific findings

For encryption changes on existing data, reference

${CLAUDE_SKILL_DIR}/../privacy-by-design-rails/references/encryption.md

for brownfield migration phases.

询问用户将报告保存到何处（默认：项目根目录下的

privacy-assessment.md

）。

然后提供以下修复计划策略选项：

最高优先级优先 —— CRITICAL > HIGH > MEDIUM
低难度修复优先 —— 先处理最容易修复的问题，无论严重程度
仅处理严重问题 —— 只处理CRITICAL级别的发现项
处理所有问题 —— 所有发现项按严重程度排序
自定义 —— 用户选择特定发现项

对于现有数据的加密更改，请参考

${CLAUDE_SKILL_DIR}/../privacy-by-design-rails/references/encryption.md

中的遗留系统迁移阶段说明。