Basis: PartMe.AI "Data Security Standards", "Network Security Standards", "MLPS and Cryptography Evaluation Standards".
I. Plaintext Storage Check (Privacy Fields Must Be Encrypted)
Privacy fields such as ID card numbers, mobile phone numbers, addresses, bank card numbersPlaintext storage in the database is prohibited：
- Implement automatic storage encryption at the framework layer (e.g., field encryption/decryption in Mybatis-Plus-Enhance)
- Encryption algorithms: prefer Chinese commercial cryptography SM4 (storage encryption), SM2 (asymmetric/key exchange), SM3 (digest/signature)
- Centralized key management (configuration center/KMS); keys must not be stored in the same database as ciphertext
AI behavior: when creating a new entity containing fields such as mobile phone numbers/ID numbers, proactively prompt and add encryption annotations/converters.
II. Information Leakage Check (Returns Must Be Masked)
- Masking at the data return stage: mobile phone number
138****5678, ID card3301**********1234, name张*三 - Low-privilege users must not obtain high-privilege data beyond their authorization (in conjunction with authentication/data permissions from the API security skill)
AI behavior: when writing a return DTO, apply masking tools/annotations to sensitive fields; when writing logs,prohibitedto output complete sensitive fields.
III. Login and API Control
- Single-device login (a new login kicks out the old session)
- Login environment detection, abnormal login detection (alert or secondary verification for unusual locations/devices)
- API authentication: use annotations according to the framework (see the API security skill for details)
IV. File Upload (in conjunction with the API security skill)
Frontend format/size whitelist → backend type detection + size limit → Nginx client_max_body_size.
API authentication and upload boundaries are delegated to the codeguard-security-api skill. Installation:npx skills add full-stack-skills/codeguard-skills --skill codeguard-security-api。
V. MLPS and Cryptography Evaluation (Compliance Background)
| Concept | Description |
|---|---|
| MLPS | Network security multi-level protection; systems are divided into 5 levels according to importance; evaluation targets include information systems, cloud platforms, and data resources |
| Cryptography evaluation | Commercial cryptography application security evaluation, a legal obligation; targets include critical information infrastructure, MLPS Level 3 and above systems, etc. |
| CII | Critical Information Infrastructure (public services, energy, transportation, water conservancy, finance, e-government, etc.) |
- MLPS Level 3 and above, CII, cryptography evaluation: evaluate at least once a year
- Sub-directions: server security, database security, logs and dataOffsite backup
Transmission/storage confidentiality and integrity solution
| Requirement | Technical implementation (team solution) |
|---|---|
| Transmission confidentiality/integrity | Unified encryption/decryption and signing via Spring Gateway GlobalFilter |
| Storage confidentiality/integrity | Field encryption/decryption and signing via Mybatis-Plus-Enhance |
Chinese Commercial Cryptography Algorithms Quick Reference
| Algorithm | Type | Purpose |
|---|---|---|
| SM2 | Asymmetric | Signature, key exchange (comparable to RSA/ECC) |
| SM3 | Hash | Digest/Integrity (comparable to SHA-256) |
| SM4 | Symmetric block | Data storage/transmission encryption (comparable to AES) |
| SM1 | Symmetric (hardware) | Cryptographic card/dedicated hardware scenarios |
Difference from digital signatures: hashing (SM3) only ensures integrity; digital signatures (SM2+SM3) additionally ensure non-repudiation and identity.
Six, AI self-check list
- Newly added sensitive fields are stored encrypted (SM4/framework annotations)
- Return values are masked; logs do not contain complete sensitive fields
- Login state considers single-device/abnormal detection
- For systems involving MLPS Level 3/cryptographic evaluation: transmission and storage schemes comply with the GlobalFilter + Mybatis-Plus-Enhance pattern
- Backup strategy mentions offsite backup
Out of scope (when it should not be used)
- The main issue is API authentication, file upload, or dependency CVE, and the corresponding specialized skill should be used.
- Only the algorithm name is known, but data classification, key custody, threat model, and regulatory scope are lacking.
- Real personal data, production keys, or plaintext-ciphertext pairs are needed for demonstration.
Standard Workflow
Step 1: Data discovery and classification
List data types, sources, subjects, sensitivity levels, purposes, retention periods, and regulatory scope.
Step 2: Track the lifecycle
Check protection measures across collection, transmission, processing, storage, return, logging, backup, export, and destruction.
Step 3: Design cryptographic boundaries
Before choosing an algorithm, clarify purpose, mode, random numbers/nonce, key generation, custody, rotation, versioning, and recovery.
Step 4: Implement masking and minimization
Distinguish display masking, irreversible tokenization, encrypted storage, and logging red lines; minimize data collection and retention as much as possible.
Step 5: Produce auditable evidence
Record rules, configurations, tests, key rotation drills, access logs, backup recovery, and residual risks.
Rules
- Keys and ciphertext must not share a database or the same privilege boundary.
- Logs, traces, error pages, and analytics platforms must not record complete sensitive values.
- Masking rules must be designed according to user roles and business necessity.
- Algorithm compliance cannot replace key management, access control, and auditing.
Gotchas
- Hashing is not encryption: fields whose original values need to be recovered cannot only be hashed.
- Deterministic encryption leaks equality relationships: if used for queries, residual risks must be clarified.
- Key rotation requires version fields and a migration path, otherwise old data may become undecryptable.
- Backup and export are often overlooked: they must have independent encryption, access, and destruction policies.
- Test data should not copy real production values, synthetic data should be used.
- MLPS/cryptographic evaluation is an evidence system: a single code snippet or algorithm choice cannot prove compliance.
Load resources on demand
- Read for decisions and handover
references/rules/decision-contract.mdandreferences/operations/evidence-playbook.md。 - only open
examples/examples matching the current data lifecycle.