Add malicious package signal to Dependency Firewall enforcement (beta)

Hannah Bakerrequested to merge
602204-depfw-malware-rules into master

What this does

Adds the third Dependency Firewall signal — malicious packages — alongside the existing license and vulnerability checks. At download/upload, the enforcement service fetches a malicious-package signal and passes it through the policy evaluator into MaliciousRule, which blocks or warns when a package is flagged.

MaliciousRule, its JSON schema, and rule registration already landed on master. This MR adds the missing pieces:

  • FetchPackageMaliciousService — resolves the malicious signal for a (name, purl_type, version) and returns the matching advisories (not just a boolean, so a block can report what flagged the package).
  • Threads malicious_packages through EnforcementService and PolicyEvaluator into the rule metadata.
  • Adds malicious to the DependencyFirewallPolicyRule type enum so the rule can be persisted — the lib and JSON schema already allowed it, only the model enum was missing.

Scope

The malicious-package data isn't available yet, so FetchPackageMaliciousService#execute returns []: the rule is a no-op (always allows) and the whole path stays behind the existing dependency_firewall_phase1 flag. That makes this safe to merge on its own — swapping [] for real data is a localized change to one method.

Building that data availability (the query/feed behind the service) is the follow-up: gitlab-org#22692

Left for later, not in this MR: surfacing the triggering advisory in the audit event, and malware-rule exceptions (planned for GA).

Testing

Green across the service, evaluator, enforcement, model, and rule specs — covering the new service, malicious_packages forwarding, and the denied/warned/allowed outcomes.

References

Edited by Hannah Baker

Merge request reports