Doctrine Encryption Bundle Laravel Package

Product Decisions This Supports

• Field-level encryption for sensitive data: Informs decisions on whether to encrypt PII (health records, financial data, credentials, access tokens) at the application layer versus relying solely on database-level encryption (TDE) or disk encryption.
• Compliance-driven roadmap: Supports features tied to GDPR, HIPAA, SOC 2, or PCI-DSS requirements where encrypted-at-rest columns are demanded by auditors or enterprise customers.
• Build vs. buy vs. fork: Because this package is a thin integration layer over ywh/doctrine-encryption-extension, it frames the decision as “adopt, adapt, or reimplement” rather than a full vendor selection. Given the tiny footprint, an in-house implementation of transparent Doctrine field encryption is a realistic alternative.
• Multi-tenant / SaaS architecture decisions: Helps decide whether per-tenant encryption keys and column-level encryption belong in the platform roadmap.
• Framework migration gating: Signals whether encryption-on-read/write should be part of a Symfony upgrade (Symfony2-era package) or replatforming effort.
• Use cases: legacy Symfony applications handling regulated data, projects migrating from plaintext to encrypted columns, teams needing searchable-but-encrypted fields via a custom Doctrine type.

When to Consider This Package

Consider it when:

• You are on a Symfony2 (or closely related) codebase with Doctrine and need transparent, column-level encryption with minimal code changes.
• You need to prove “encrypted at rest” for specific fields to auditors or enterprise customers, and full-database encryption is insufficient or impractical.
• Your team already uses ywh/doctrine-encryption-extension and wants the Symfony wiring provided by the bundle.
• The scope is small and contained — encrypting a handful of fields rather than redesigning the data model.
• You are evaluating the extension pattern (custom Doctrine types + event subscribers) as a reference implementation you may adapt in-house.

Look elsewhere when:

• You are on Laravel, modern Symfony (5/6/7), or another framework — this package targets Symfony2-era integration and will not fit the framework lifecycle.
• You require active maintenance, security response SLAs, or vendor support — 2 stars and 0 dependents indicate an essentially unmaintained, unreviewed dependency, which is a red flag for a security-sensitive decision.
• You need searchable encryption, key rotation with HSM integration, envelope encryption, or external KMS/Secrets Manager integration — this is a basic field-encryption helper, not a key-management platform.
• You want a battle-tested, audited library — for encryption, provenance and review history matter more than for utility packages.
• Compliance requires independent security review or FIPS-validated modules — an anonymous, low-adoption package will not satisfy that bar.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed helper that enables encryption of individual database fields, giving us a lightweight path to meet “encrypted at rest” commitments for regulated customer data. However, it is a near-abandoned, Symfony2-era package with negligible adoption — we should treat it as a reference design rather than a production dependency. The recommendation is to adopt the pattern, not the package: implement field-level encryption inside our own codebase using a maintained, reviewed approach, so we control the security posture and upgrade path.

For engineering: The bundle is a thin Symfony adapter over ywh/doctrine-encryption-extension. It provides a Doctrine field type for transparent encrypt/decrypt on read/write. There is no meaningful community adoption or maintenance signal, so using it directly introduces supply-chain and long-term-maintenance risk on a security-critical path. Recommended action: fork or reimplement the Doctrine type + subscriber in-house (a few hundred lines), use a vetted crypto primitive (libsodium / OpenSSL AES-GCM), and pair it with a proper KMS for key management. Treat this package as prior art for the approach (custom Doctrine type + event hooks), not as a runtime dependency. If we do consume it, pin the version, vendor the code, and schedule an internal review.