Why this matters
Prevents supply-chain attacks and avoids introducing known-vulnerable versions.
When a PR changes dependency manifests (e.g., package.json, yarn.lock, requirements.txt, composer.json), check for known vulnerabilities and risky packages. - If an OSV/SCA MCP is available: query it for the new package versions and flag recent CVEs. - Otherwise: require evidence (audit output, advisory links) in the PR description. Also flag suspicious packages (typosquats, low-maintenance critical libs, unexpected transitive jumps) and require lockfile updates.
Prevents supply-chain attacks and avoids introducing known-vulnerable versions.
Side-by-side examples engineers can pattern-match during review.
Adds new package with no vetting; lockfile not updated.Adds package X pinned; OSV check clean; lockfile updated; rationale included.package.json changed, no audit/SCA evidenceOSV/SCA result + pinned versions + updated lockfileFrom the same buckets as this rule.
Before persisting ePHI, encrypt using a data key protected by a Key Management Service (KMS). Use authenticated encryption (AES-256-GCM or equivalent), rotate keys, and store the key id and algorithm with the record.