Référence politique CVE¶

settings.json → "cve_policy" associe chaque niveau de sévérité CVE à une action. Cette page est la référence de consultation rapide — pour le workflow et le raisonnement derrière ces choix, voir Workflow CVE (anglais).

Niveaux de sévérité¶

Les chaînes de sévérité proviennent du vocabulaire propre à Grype. Les clés de cve_policy sont leur forme en minuscules.

Sévérité Grype	Clé `cve_policy`	Action par défaut
`Critical`	`critical`	`block`
`High`	`high`	`review`
`Medium`	`medium`	`warn`
`Low`	`low`	`allow`
`Negligible`	`negligible`	`allow`
`Unknown`	(pas une clé de politique)	traité comme `allow` — toute sévérité absente de `cve_policy` a pour valeur par défaut `allow`

Les quatre actions¶

Action	Signification
`block`	Rejet immédiat. Le paquet est mis en quarantaine et n'atteint jamais le stockage / la distribution.
`review`	Le paquet est accepté en stockage mais retenu avant publication/service (`cve_status`/`status` du manifeste = `"pending_review"`) jusqu'à ce qu'un RSSI l'approuve ou le rejette via `POST /security/packages/{name}/{version}/decide`.
`warn`	Le paquet est accepté et publié normalement. Le CVE est enregistré et visible, mais rien ne bloque le flux.
`allow`	Transparent — aucun avertissement visible, aucune action.

Action par mécanisme de scan¶

cve_policy est évaluée par quatre mécanismes indépendants, à différents moments du cycle de vie d'un paquet. Ils n'honorent pas tous block de la même façon.

Mécanisme	Où	`block`	`review`	`warn`	`allow`
Scan Grype natif (upload/import)	`services/validator_apt.py:_apply_cve_policy()` (partagé par RPM/APK/Maven/PyPI/npm/OCI, qui appellent tous la même fonction)	`cve_status = "blocked"`, la validation échoue, le fichier est mis en quarantaine	`cve_status = "pending_review"` — atterrit dans le stockage équivalent à `pool` mais n'est pas publié (non indexé par reprepro/createrepo_c/APKINDEX, masqué des listings Maven/PyPI/npm)	`cve_status = "approved"`, publié normalement, avertissement enregistré dans `validation_steps`	`cve_status = "approved"`, aucune action
Scan CVE des dépendances (dépendances déclarées npm/Maven/PyPI, `services/osv_lookup.py:worst_dependency_action()`)	Évalué à l'intérieur de `finish_npm_publish()`/`finish_maven_deploy()`/`finish_pypi_upload()`, après que le scan Grype propre au paquet a déjà tourné	rétrogradé à `review` — jamais un rejet pur et simple	`pending_review`, même file RSSI	enregistré, ne change pas le statut	aucune action
Dual scan (croisement Grype + Trivy, SaaS uniquement, `services/dual_scan.py:_worst_action_for()`)	Évalué uniquement pour les CVE avec `detected_by == ["trivy"]` (trouvé par Trivy, manqué par le scan Grype initial) sur un paquet déjà `validated`	rétrogradé à `review` — jamais un rejet pur ou une dépublication	fait passer le `status` du manifeste à `pending_review`, même file RSSI	aucun changement de statut	aucune action
Re-matching CVE (re-scan périodique via le SBOM stocké, les 7 formats, `services/cve_rematch.py:rematch_one()`)	Évalué uniquement pour les identifiants CVE nouvellement apparus depuis le dernier scan (`newly_appeared = new_ids - old_ids`) sur un paquet déjà `validated`	route vers `pending_review`, comme `review` — jamais une dépublication/un rejet pur	fait passer le `status` du manifeste à `pending_review`, même file RSSI	aucun changement de statut	aucune action

Seul le scan Grype natif peut jamais block purement et simplement

Le scan des dépendances, le dual scan et le re-matching CVE tournent tous après qu'un paquet est déjà publié ou stocké — aucun d'eux ne peut rétroactivement rejeter un paquet. Une correspondance de sévérité block trouvée par l'un des trois mécanismes rétroactifs est plutôt traitée comme review, et route vers la même file de décision RSSI (decision_records) qu'une détection review native.

Un CVE précédemment connu qui disparaît ne redéclenche jamais une décision

Le dual scan comme le re-matching CVE n'évaluent que les nouvelles détections face à cve_policy — un CVE qui cesse de matcher (correction de la base du moteur, ou Trivy qui ne le signale simplement plus une deuxième fois) est retiré de la liste affichée sans jamais rouvrir de révision.

File de décision RSSI¶

Tout mécanisme qui route vers pending_review utilise la même table sous-jacente, decision_records, et le même endpoint :

POST /security/packages/{name}/{version}/decide

Décisions possibles : accept_risk, exception, reject, upgrade_required — voir Workflow CVE (anglais) pour le cycle de vie complet des décisions et le suivi des SLA.

Champs SLA¶

cve_policy porte également des délais de SLA de remédiation (en jours), utilisés par le job cron sla_check_daily :

Clé	Défaut	Signification
`sla_critical_days`	`0`	Jours accordés pour une détection Critical — `0` signifie immédiat/bloqué, aucun délai de grâce.
`sla_high_days`	`30`	Jours accordés pour une détection High en attente de décision.
`sla_medium_days`	`90`	Jours accordés pour une détection Medium en attente de décision.

Configurer `cve_policy`¶

Via l'interface web : Paramètres → Sécurité → Politique CVE (rôle admin requis).

Via l'API :

curl -X PATCH http://REPO_HOST:8000/api/v1/settings/ \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"cve_policy": {"critical": "block", "high": "review", "medium": "warn", "low": "allow", "negligible": "allow"}}'