@cubis/foundry 0.3.82 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sadd/references/verification-patterns.md

@@ -1,135 +0,0 @@
-# Verification Patterns Reference
-
-Load this when cross-referencing implementation against specifications.
-
----
-
-## Verification vs. Validation
-
-| Concept | Question | How |
-|---------|----------|-----|
-| **Verification** | "Did we build the thing right?" | Check implementation against specification. |
-| **Validation** | "Did we build the right thing?" | Check specification against user needs. |
-
-SADD focuses on verification. Validation is a product management concern.
-
----
-
-## Verification Strategies
-
-### Strategy 1: Assertion-Based Verification
-
-Compare the specification text directly to test assertions.
-
-**Specification:** "The system must return HTTP 429 when rate limit is exceeded."
-
-**Verification check:**
-- Does a test exist that triggers the rate limit?
-- Does the test assert HTTP 429 (not just "error")?
-- Does the test verify the rate limit threshold matches the spec?
-
-### Strategy 2: Behavioral Comparison
-
-Run the same inputs through the specification model and the implementation, then compare outputs.
-
-```
-Spec says: deposit($100) -> balance increases by $100
-Test does: deposit($100) -> assert balance == previous + 100
-Code does: balance += amount (after validation)
-
-Verdict: Aligned ✓
-```
-
-### Strategy 3: Contract Testing
-
-For API specifications, generate contract tests that verify request/response shapes.
-
-```markdown
-| Endpoint | Method | Request Schema Valid? | Response Schema Valid? | Status Codes Match? |
-|----------|--------|----------------------|----------------------|-------------------|
-| /users   | POST   | Yes                  | Yes                  | 201, 400, 409 ✓  |
-| /users   | GET    | Yes                  | No (missing pagination) | 200 ✓, 404 missing |
-```
-
----
-
-## Common Verification Failures
-
-### Off-by-One Errors
-
-**Spec:** "Maximum 10 items per page."
-**Implementation:** `if (items.length > 10)` (allows 11 items because > should be >=10 with slice)
-
-**Detection:** Boundary tests at exactly the specified limit.
-
-### Partial Implementation
-
-**Spec:** "Return error with code and message."
-**Implementation:** Returns error with code only; message field is always null.
-
-**Detection:** Assert on every field specified, not just the primary one.
-
-### Hardcoded Value Drift
-
-**Spec:** "Session timeout: 30 minutes."
-**Implementation:** `SESSION_TIMEOUT = 1800` (correct) but another code path uses `setTimeout(3600000)` (60 minutes).
-
-**Detection:** Search for all references to the configured value; verify consistency.
-
-### Error Path Omission
-
-**Spec:** "Return 404 when resource not found, 403 when unauthorized, 429 when rate-limited."
-**Implementation:** Handles 404 and 403; returns 500 for rate limit (unhandled exception).
-
-**Detection:** Verify every specified error code has a corresponding handler and test.
-
----
-
-## Verification Report Template
-
-```markdown
-## Verification Summary
-
-### Scope
-- Specification: [document reference]
-- Implementation: [repository and commit]
-- Date: [verification date]
-
-### Results
-| Category | Count |
-|----------|-------|
-| Requirements verified | X |
-| Requirements with failures | Y |
-| Requirements untestable | Z |
-| Specification gaps found | W |
-
-### Detailed Findings
-[One section per failure or gap with REQ ID, expected vs. actual, and recommended fix]
-
-### Verdict
-[PASS / CONDITIONAL_PASS / FAIL]
-[Conditions for conditional pass or blockers for fail]
-```
-
----
-
-## Automating Verification
-
-### For Machine-Readable Specs
-
-| Spec Format | Auto-Verification Tool |
-|------------|----------------------|
-| OpenAPI/Swagger | Schemathesis, Dredd, Prism |
-| Protocol Buffers | buf lint, buf breaking |
-| JSON Schema | ajv, jsonschema |
-| GraphQL | Apollo schema validation |
-| Database migrations | Schema diff tools |
-
-### For Human-Readable Specs
-
-Automation is limited, but you can:
-
-1. Tag requirements in the spec with IDs.
-2. Tag tests with `@req(REQ-XXX)` annotations.
-3. Run a script that cross-references tags to produce a coverage report.
-4. Integrate the coverage report into CI as a quality gate.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sadd/references/verification.md

@@ -1,150 +0,0 @@
-# Verification Strategies
-
-Load this when verifying an implementation against extracted specifications and detecting drift.
-
----
-
-## Verification Levels
-
-| Level | What it checks | Confidence |
-|-------|---------------|------------|
-| **Static** | Code structure matches spec expectations (types, function signatures, error codes) | Medium |
-| **Dynamic** | Tests pass and cover spec assertions | High |
-| **Behavioral** | System behavior matches spec under realistic conditions | Highest |
-
----
-
-## Static Verification
-
-### Type-Level Checks
-
-Compare the specification's data model against the implementation's types.
-
-```
-Spec: "Order must have status: pending | processing | shipped | delivered | cancelled"
-
-Verify:
-- Does the code define an OrderStatus type or enum?
-- Does it include all 5 values?
-- Are there any additional values not in the spec? (drift)
-```
-
-### API Contract Checks
-
-For API specifications, verify request/response shapes.
-
-```
-Spec: POST /api/orders returns 201 with { orderId: string, status: string }
-
-Verify:
-- Does the route handler return 201?
-- Does the response schema include both fields?
-- Are field types correct?
-- Are there additional fields not in the spec? (feature drift)
-```
-
----
-
-## Dynamic Verification
-
-### Running the Spec Test Suite
-
-Execute all tests generated from specifications and map results:
-
-```markdown
-| Spec ID | Test ID | Result | Notes |
-|---------|---------|--------|-------|
-| SPEC-001 | TEST-001 | Pass | -- |
-| SPEC-002 | TEST-002 | Fail | Returns 200 instead of 201 |
-| SPEC-003 | -- | No Test | Test generation needed |
-```
-
-### Failure Classification
-
-| Failure Type | Meaning | Action |
-|-------------|---------|--------|
-| Test fails, spec correct | Implementation bug | Fix the code |
-| Test fails, spec wrong | Spec needs updating | Update spec, re-derive test |
-| Test passes, wrong assertion | Test does not actually check the spec | Rewrite test |
-| No test exists | Untested specification | Generate and run test |
-
----
-
-## Detecting Specification Drift
-
-Drift occurs when the implementation's behavior diverges from the specification over time.
-
-### Common Drift Patterns
-
-1. **Feature Drift** -- Code does more than the spec says. New behaviors were added without updating the specification.
-
-2. **Regression Drift** -- Code stopped doing what the spec says. A refactoring or dependency update broke specified behavior without being caught by tests.
-
-3. **Configuration Drift** -- Behavior varies by environment. The spec says "timeout after 30 seconds" but production config says 60 seconds.
-
-4. **Silent Drift** -- Tests pass but don't actually verify the spec. The test asserts `response.ok` instead of checking the specific status code the spec requires.
-
-### Drift Detection Technique
-
-1. Re-read the specification with fresh eyes.
-2. For each spec clause, write a new, independent verification test.
-3. Run the new tests without looking at existing tests.
-4. Compare new test results with existing test results.
-5. Discrepancies indicate drift.
-
----
-
-## Verification Report Structure
-
-```markdown
-## Verification Summary
-
-| Metric | Value |
-|--------|-------|
-| Total specifications | N |
-| Verified (pass) | X |
-| Failed | Y |
-| Untested | Z |
-| Drifted | W |
-
-## Detailed Findings
-
-### Passed Specifications
-[List with evidence]
-
-### Failed Specifications
-[Each with root cause and recommended fix]
-
-### Untested Specifications
-[Each with recommended test approach]
-
-### Detected Drift
-[Each with spec vs. actual comparison]
-```
-
----
-
-## Continuous Verification
-
-### In CI/CD Pipeline
-
-```yaml
-steps:
-  - name: Run spec verification
-    run: npm run test:spec
-
-  - name: Check spec coverage
-    run: node scripts/spec-coverage.js --threshold 95
-
-  - name: Detect drift
-    run: node scripts/drift-check.js --baseline specs/
-```
-
-### On Requirement Change
-
-When a specification changes:
-1. Mark affected matrix entries as "needs re-verification."
-2. Update or regenerate affected tests.
-3. Run verification.
-4. Update matrix with new results.
-5. Include matrix diff in the PR.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sanitize-pii/SKILL.md

@@ -1,107 +0,0 @@
----
-name: sanitize-pii
-description: "Detect and sanitize personally identifiable information (PII) in code, logs, databases, and data pipelines. Covers PII identification, redaction strategies, data masking, GDPR/CCPA compliance, and audit trail implementation."
-license: MIT
-metadata:
-  author: cubis-foundry
-  version: "3.0"
-compatibility: "Claude Code, Codex, GitHub Copilot"
----
-# Sanitize PII — PII Detection and Sanitization
-
-## Purpose
-
-Guide the detection, classification, and sanitization of personally identifiable information across application code, log outputs, database schemas, and data pipelines. This skill ensures that PII handling meets GDPR, CCPA, and other privacy regulation requirements through systematic identification, consistent redaction, reversible masking where needed, and auditable compliance controls.
-
-## When to Use
-
-- Scanning log output or application telemetry for accidental PII exposure
-- Implementing data masking for non-production environments
-- Building PII redaction into data pipelines or ETL processes
-- Conducting a GDPR or CCPA compliance review of data handling
-- Designing audit trails for PII access and processing
-- Reviewing code for patterns that inadvertently persist or transmit PII
-
-## Instructions
-
-1. **Define the PII taxonomy for the project** — Enumerate all PII categories relevant to the application (names, emails, phone numbers, SSNs, IP addresses, geolocation, biometrics, financial data, health records) because the definition of PII varies by jurisdiction and incomplete taxonomy leads to incomplete protection.
-
-2. **Map PII data flows** — Trace each PII category from point of collection through storage, processing, transmission, and deletion to identify every location where PII exists because you cannot sanitize data you have not located.
-
-3. **Classify PII by sensitivity tier** — Assign each category a sensitivity level (direct identifiers like SSN/passport = critical; quasi-identifiers like ZIP+DOB = high; general contact info = standard) because sensitivity drives the required protection strength and breach notification obligations.
-
-4. **Scan source code for PII patterns** — Use regex patterns and AST analysis to find logging statements, string interpolation, serialization, and debug output that may include PII fields because developers frequently log user objects without redacting sensitive fields.
-
-5. **Scan log output and telemetry** — Review structured and unstructured logs for PII leakage including email addresses in error messages, user IDs in URLs, and stack traces containing request bodies because logs are often stored with weaker access controls than databases.
-
-6. **Implement field-level redaction** — Apply deterministic redaction (consistent replacement tokens) or destructive redaction (irreversible removal) to PII in logs, exports, and non-production data because redaction prevents PII from reaching unauthorized storage while preserving data utility.
-
-7. **Implement data masking for non-production environments** — Use format-preserving encryption, tokenization, or synthetic data generation to create realistic but non-identifying datasets because developers and testers need representative data without real PII.
-
-8. **Build PII-aware logging utilities** — Create or configure logging middleware that automatically redacts known PII fields before writing because relying on individual developers to remember redaction is unreliable at scale.
-
-9. **Implement right-to-erasure (GDPR Article 17) support** — Design deletion workflows that remove or anonymize all instances of a data subject's PII across all storage systems including backups, caches, and derived datasets because GDPR requires complete erasure upon valid request.
-
-10. **Implement data subject access requests (DSAR)** — Build the ability to export all PII associated with a data subject in a portable format because GDPR Article 15 and CCPA Section 1798.100 require this capability.
-
-11. **Configure consent and purpose tracking** — Record the legal basis (consent, legitimate interest, contract) and processing purpose for each PII collection point because GDPR Article 6 requires a lawful basis and purpose limitation for all personal data processing.
-
-12. **Set up PII access audit trails** — Log every read, write, export, and deletion of PII with actor identity, timestamp, purpose, and data categories accessed because audit trails demonstrate compliance and enable breach impact assessment.
-
-13. **Implement retention and auto-deletion policies** — Configure time-based or event-based deletion for each PII category according to the data retention schedule because storing PII beyond its purpose violates the storage limitation principle.
-
-14. **Validate PII sanitization with automated tests** — Write tests that assert PII fields are redacted in log output, masked in non-production exports, and absent from API responses that should not contain them because manual verification does not scale.
-
-15. **Document the PII handling architecture** — Produce a data protection impact assessment (DPIA) or privacy design document covering data flows, protection measures, retention periods, and compliance mapping because documentation is itself a regulatory requirement.
-
-16. **Establish breach notification procedures** — Define the workflow for identifying, assessing, and reporting PII breaches within the 72-hour GDPR window including impact assessment, authority notification, and data subject communication because delayed notification incurs significant regulatory penalties.
-
-## Output Format
-
-```
-## PII Sanitization Report
-
-### PII Taxonomy
-| Category | Sensitivity | Locations Found | Protection Method |
-|----------|------------|-----------------|-------------------|
-| Email | Standard | user_service, logs, analytics | Redact in logs, encrypt at rest |
-| SSN | Critical | payroll_service | Tokenize, vault storage |
-
-### Data Flow Map
-[Collection → Processing → Storage → Transmission → Deletion per category]
-
-### Findings
-
-| # | Location | PII Type | Issue | Severity | Remediation |
-|---|----------|----------|-------|----------|-------------|
-| 1 | logger.js:42 | Email | Logged in plaintext | High | Add to redaction filter |
-
-### Compliance Status
-| Requirement | GDPR Article | Status | Gap |
-|-------------|-------------|--------|-----|
-| Right to erasure | Art. 17 | Partial | Backups not covered |
-
-### Remediation Plan
-[Priority-ordered action items with implementation guidance]
-
-### Audit Trail Configuration
-[What is logged, where, retention period]
-```
-
-## References
-
-| Topic | Reference | Load When |
-|-------|-----------|-----------|
-| PII Detection Patterns | `references/pii-detection.md` | Scanning code or logs for PII |
-| Redaction Strategies | `references/redaction-strategies.md` | Implementing field-level redaction |
-| Data Masking Techniques | `references/data-masking.md` | Creating non-production datasets |
-| GDPR/CCPA Compliance | `references/compliance.md` | Reviewing regulatory requirements |
-| Audit Trail Design | `references/audit-trails.md` | Implementing PII access logging |
-
-## Copilot Platform Notes
-
-- Skill files are stored under `.github/prompts/` (prompt files) and `.github/instructions/` (instruction files).
-- Copilot does not support subagent spawning — all skill guidance executes within the current conversation context.
-- User arguments are provided as natural language input in the prompt, not through a `$ARGUMENTS` variable.
-- Frontmatter keys `context`, `agent`, and `allowed-tools` are not supported; guidance is advisory only.
-- Reference files can be included via `#file:references/<name>.md` syntax in Copilot Chat.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sanitize-pii/evals/assertions.md

@@ -1,25 +0,0 @@
-# Eval Assertions — Sanitize PII
-
-## Eval 1: PII Detection in Log Output
-
-**ID:** `pii-detection-log-output`
-
-| # | Assertion Type | Expected Value | Rationale |
-|---|---------------|----------------|-----------|
-| 1 | content_matches_regex | `email\|john\\.doe@\|email address` | Must identify the email address in the UserService log line as PII requiring redaction. |
-| 2 | content_matches_regex | `credit card\|card number\|PAN\|4111\|CVV\|payment card` | Must identify the full credit card number and CVV as critical PII — a PCI DSS violation. |
-| 3 | content_matches_regex | `SSN\|Social Security\|123-45-6789` | Must identify the SSN as critical PII with the highest sensitivity classification. |
-| 4 | content_matches_regex | `redact\|mask\|filter\|sanitiz\|replace\|\\*{3,}\|\\[REDACTED\\]` | Must recommend a specific redaction or masking technique rather than just flagging the issue. |
-| 5 | content_matches_regex | `API key\|sk_live\|secret\|credential\|token` | Must identify the exposed Stripe API key as both a PII and credential leak requiring rotation. |
-
-## Eval 2: GDPR-Compliant Data Masking
-
-**ID:** `gdpr-data-masking`
-
-| # | Assertion Type | Expected Value | Rationale |
-|---|---------------|----------------|-----------|
-| 1 | content_matches_regex | `GDPR\|Article\|regulation\|data protection\|lawful` | Must ground the masking strategy in GDPR requirements since the application serves EU customers. |
-| 2 | content_matches_regex | `email.*mask\|mask.*email\|fake.*email\|synthetic.*email\|anonymiz` | Must specify a concrete masking strategy for email addresses that preserves format but removes identity. |
-| 3 | content_matches_regex | `format.preserv\|tokeniz\|synthetic\|faker\|fake data\|realistic` | Must recommend format-preserving masking or synthetic data generation for realistic non-production data. |
-| 4 | content_matches_regex | `free.text\|support_ticket\|body\|unstructured\|ticket.*body\|agent.*notes` | Must address free-text fields which cannot be masked with simple find-replace and require NLP or full replacement. |
-| 5 | content_matches_regex | `referential integrity\|foreign key\|user_id\|relationship\|consistent` | Must address referential integrity to ensure masked data remains consistent across related tables. |

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sanitize-pii/evals/evals.json

@@ -1,68 +0,0 @@
-[
-  {
-    "id": "pii-detection-log-output",
-    "title": "Detect PII in application log output",
-    "description": "Given log samples containing various PII types, the skill should identify each instance, classify it, and recommend redaction approaches.",
-    "prompt": "Review these application log samples for PII exposure and recommend sanitization:\n\n```\n2025-01-15 10:23:45 INFO  UserService: Created user john.doe@example.com with ID 12345\n2025-01-15 10:23:46 DEBUG PaymentService: Processing payment for card ending 4242, full number 4111111111111111, CVV 123\n2025-01-15 10:23:47 ERROR AuthService: Login failed for user SSN=123-45-6789, IP=192.168.1.100\n2025-01-15 10:23:48 INFO  OrderService: Shipping to John Doe, 123 Main St, Springfield IL 62704, phone (555) 123-4567\n2025-01-15 10:23:49 WARN  APIGateway: Rate limit exceeded for API key sk_live_abc123def456ghi789\n```",
-    "assertions": [
-      {
-        "type": "content_matches_regex",
-        "value": "email|john\\.doe@|email address",
-        "description": "Must identify email address PII in the UserService log line"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "credit card|card number|PAN|4111|CVV|payment card",
-        "description": "Must identify full credit card number and CVV as critical PII"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "SSN|Social Security|123-45-6789",
-        "description": "Must identify SSN as critical PII requiring immediate remediation"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "redact|mask|filter|sanitiz|replace|\\*{3,}|\\[REDACTED\\]",
-        "description": "Must recommend specific redaction or masking approach"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "API key|sk_live|secret|credential|token",
-        "description": "Must identify the exposed API key as a secret/credential leak"
-      }
-    ]
-  },
-  {
-    "id": "gdpr-data-masking",
-    "title": "Design GDPR-compliant data masking for a non-production environment",
-    "description": "Given a database schema with PII fields, the skill should produce a GDPR-compliant masking strategy for creating safe non-production datasets.",
-    "prompt": "Design a GDPR-compliant data masking strategy for our staging environment. Here is the database schema:\n\n```sql\nCREATE TABLE users (\n  id SERIAL PRIMARY KEY,\n  email VARCHAR(255) NOT NULL,\n  first_name VARCHAR(100),\n  last_name VARCHAR(100),\n  date_of_birth DATE,\n  phone VARCHAR(20),\n  ssn_encrypted BYTEA,\n  address_line1 VARCHAR(255),\n  city VARCHAR(100),\n  postal_code VARCHAR(10),\n  country VARCHAR(2)\n);\n\nCREATE TABLE orders (\n  id SERIAL PRIMARY KEY,\n  user_id INT REFERENCES users(id),\n  total_amount DECIMAL(10,2),\n  shipping_address TEXT,\n  payment_token VARCHAR(255)\n);\n\nCREATE TABLE support_tickets (\n  id SERIAL PRIMARY KEY,\n  user_id INT REFERENCES users(id),\n  subject VARCHAR(255),\n  body TEXT,\n  agent_notes TEXT\n);\n```\n\nStaging must have realistic data for testing but no real PII. We serve EU customers.",
-    "assertions": [
-      {
-        "type": "content_matches_regex",
-        "value": "GDPR|Article|regulation|data protection|lawful",
-        "description": "Must reference GDPR requirements for data masking"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "email.*mask|mask.*email|fake.*email|synthetic.*email|anonymiz",
-        "description": "Must specify masking strategy for email addresses"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "format.preserv|tokeniz|synthetic|faker|fake data|realistic",
-        "description": "Must recommend format-preserving masking or synthetic data generation"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "free.text|support_ticket|body|unstructured|ticket.*body|agent.*notes",
-        "description": "Must address free-text fields (support ticket body, agent notes) as requiring NLP-based or full replacement masking"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "referential integrity|foreign key|user_id|relationship|consistent",
-        "description": "Must address maintaining referential integrity across masked tables"
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sanitize-pii/examples/01-log-pii-detection.md

@@ -1,146 +0,0 @@
-# Example 1: Detecting and Remediating PII in Application Logs
-
-## User Prompt
-
-> Our compliance team flagged that our application logs might contain PII. Review these log samples and tell us what to fix:
->
-> ```
-> 2025-03-10 09:15:22 INFO  [UserController] User registered: email=sarah.jones@company.com, name=Sarah Jones, DOB=1990-05-15
-> 2025-03-10 09:15:23 DEBUG [PaymentService] Charging card 4532015112830366 exp 12/26 for user_id=8842
-> 2025-03-10 09:15:24 ERROR [AuthService] Failed login attempt: username=admin, password=P@ssw0rd123, IP=203.0.113.42
-> 2025-03-10 09:15:25 INFO  [OrderService] Shipping order #9921 to 742 Evergreen Terrace, Springfield, IL 62704
-> 2025-03-10 09:15:26 WARN  [APIGateway] Rate limited: user_agent=Mozilla/5.0, client_ip=198.51.100.23, api_key=ak_prod_7f3a9b2c1d
-> 2025-03-10 09:15:27 INFO  [SupportBot] Ticket #4412 from John Smith (SSN: 987-65-4321): "I need to update my bank account to 021000021-1234567890"
-> ```
-
-## Expected Response
-
-### PII Detection Report
-
-#### Findings Summary
-
-| # | Log Line | PII Type | Sensitivity | Severity |
-|---|----------|----------|-------------|----------|
-| 1 | UserController | Email, full name, date of birth | High | High |
-| 2 | PaymentService | Full credit card number, expiration | Critical | Critical |
-| 3 | AuthService | Plaintext password | Critical | Critical |
-| 4 | OrderService | Physical address | Medium | Medium |
-| 5 | APIGateway | IP address, API key | Medium | Medium |
-| 6 | SupportBot | SSN, full name, bank routing + account number | Critical | Critical |
-
----
-
-#### Finding 1: User Registration Log (HIGH)
-
-**Location:** `[UserController]` — user registration flow
-
-**PII detected:**
-- Email address: `sarah.jones@company.com`
-- Full name: `Sarah Jones`
-- Date of birth: `1990-05-15`
-
-**Risk:** Email + name + DOB is sufficient for identity theft and social engineering. Violates GDPR data minimization principle.
-
-**Remediation:**
-```javascript
-// BEFORE (leaking PII)
-logger.info(`User registered: email=${user.email}, name=${user.name}, DOB=${user.dob}`);
-
-// AFTER (redacted)
-logger.info(`User registered: user_id=${user.id}`);
-```
-
-Log only the internal user ID. If email is needed for debugging, use a truncated hash: `email_hash=${sha256(user.email).slice(0,8)}`.
-
----
-
-#### Finding 2: Credit Card in Payment Log (CRITICAL)
-
-**Location:** `[PaymentService]` — payment processing
-
-**PII detected:**
-- Full credit card number: `4532015112830366`
-- Expiration date: `12/26`
-
-**Risk:** This is a PCI DSS violation. Logging full card numbers can result in fines up to $500,000 per incident and loss of payment processing privileges.
-
-**Remediation:**
-```javascript
-// BEFORE (PCI violation)
-logger.debug(`Charging card ${cardNumber} exp ${expiry} for user_id=${userId}`);
-
-// AFTER (PCI compliant)
-logger.debug(`Charging card ending ${cardNumber.slice(-4)} for user_id=${userId}`);
-```
-
-Additionally, change log level from DEBUG to INFO for payment events and never log expiration dates.
-
----
-
-#### Finding 3: Plaintext Password in Auth Log (CRITICAL)
-
-**Location:** `[AuthService]` — authentication flow
-
-**PII detected:**
-- Plaintext password: `P@ssw0rd123`
-
-**Risk:** Passwords must never be logged under any circumstances. If logs are compromised, all passwords logged this way are exposed. This also violates every security compliance framework.
-
-**Remediation:**
-```javascript
-// BEFORE (catastrophic)
-logger.error(`Failed login: username=${username}, password=${password}, IP=${ip}`);
-
-// AFTER (safe)
-logger.warn(`Failed login attempt: username=${username}, IP=${ip}`);
-```
-
-Remove the password parameter entirely from all logging code paths. Add a log sanitizer that blocks any field named `password`, `passwd`, `secret`, or `token`.
-
----
-
-#### Finding 4: Physical Address (MEDIUM)
-
-**Location:** `[OrderService]` — shipping flow
-
-**Remediation:** Log only order ID and shipping status. If address debugging is needed, log city/state only.
-
-#### Finding 5: IP Address and API Key (MEDIUM)
-
-**Location:** `[APIGateway]` — rate limiting
-
-**Remediation:** IP addresses are PII under GDPR. Hash or truncate IPs in logs. Redact the API key to last 4 characters.
-
-#### Finding 6: SSN and Bank Account (CRITICAL)
-
-**Location:** `[SupportBot]` — ticket ingestion
-
-**Remediation:** Implement PII scrubbing on all free-text input before logging. Use regex patterns to detect and redact SSN, bank account numbers, and credit card numbers from support ticket bodies before they reach the logging pipeline.
-
----
-
-### Systematic Remediation Plan
-
-**1. Build a centralized log sanitizer middleware:**
-```javascript
-const PII_PATTERNS = {
-  ssn: /\b\d{3}-\d{2}-\d{4}\b/g,
-  credit_card: /\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b/g,
-  email: /\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b/g,
-  bank_account: /\b\d{9}-\d{7,17}\b/g,
-};
-
-function sanitizeLog(message) {
-  let sanitized = message;
-  for (const [type, pattern] of Object.entries(PII_PATTERNS)) {
-    sanitized = sanitized.replace(pattern, `[REDACTED:${type}]`);
-  }
-  return sanitized;
-}
-```
-
-**2. Add pre-commit PII scanning** using `detect-secrets` or a custom regex scanner.
-
-**3. Configure structured logging** so PII fields can be programmatically redacted rather than relying on string matching.
-
-**4. Audit all existing log statements** across all services for PII exposure patterns.