triaging-security-findings

Paysage des scanners

Bitwarden utilise trois scanners, tous déclenchés par le workflow GitHub Actions scan.yml dans chaque dépôt :

Checkmarx One — Scanning SAST (analyse statique) et IaC (infrastructure as code). Tenant cloud dédié nommé "bitwarden". Les résultats sont téléchargés vers GitHub Advanced Security au format SARIF et affichés comme annotations de PR. Checkmarx comprend les différences entre branches, ainsi les résultats de PR ne montrent que ce qui a changé. Accédez à l'application web Checkmarx via AST WebApp (tenant : "bitwarden") ou via le répertoire Workspace.

SonarCloud — Scanning de qualité et détection des hotspots de sécurité. Offre cloud publique gratuite (non licenciée pour les dépôts privés). Utilise des profils de qualité et des gates pour des résultats personnalisés. Affiche les annotations de PR. Les résultats se propagent également vers la section sécurité de GitHub. Configurez via l'entrée sonar-config : default, dotnet ou maven.

Grype — Scanner de vulnérabilités pour images conteneur et systèmes de fichiers. Orienté CVE. Utilisé pour la détection des vulnérabilités de la chaîne d'approvisionnement et des dépendances.

API GitHub Advanced Security

Utilisez ces commandes gh api pour interroger et gérer les résultats de sécurité :

Alertes de scanning de code (Checkmarx, SonarCloud)

# Lister toutes les alertes de scanning de code ouvertes
gh api /repos/{owner}/{repo}/code-scanning/alerts --jq '.[] | {number, state, rule: .rule.id, severity: .rule.security_severity_level, path: .most_recent_instance.location.path}'

# Obtenir les détails d'une alerte spécifique
gh api /repos/{owner}/{repo}/code-scanning/alerts/{alert_number}

# Filtrer les alertes par chemin (utile pour la triage spécifique à un fichier)
gh api "/repos/{owner}/{repo}/code-scanning/alerts?ref={branch}&state=open" --jq '.[] | select(.most_recent_instance.location.path | startswith("src/Api"))'

# Filtrer par outil (séparer les résultats Checkmarx des résultats SonarCloud)
gh api "/repos/{owner}/{repo}/code-scanning/alerts?tool_name=Checkmarx&state=open"
gh api "/repos/{owner}/{repo}/code-scanning/alerts?tool_name=SonarQube&state=open"

# Rejeter une alerte comme faux positif
gh api -X PATCH /repos/{owner}/{repo}/code-scanning/alerts/{alert_number} \
  -f state=dismissed \
  -f dismissed_reason=false\ positive \
  -f dismissed_comment="Rationale for dismissal"

# Rejeter comme ne sera pas corrigé
gh api -X PATCH /repos/{owner}/{repo}/code-scanning/alerts/{alert_number} \
  -f state=dismissed \
  -f dismissed_reason=won\'t\ fix \
  -f dismissed_comment="Rationale"

Alertes Dependabot

# Lister les alertes Dependabot ouvertes
gh api /repos/{owner}/{repo}/dependabot/alerts --jq '.[] | {number, state, severity: .security_vulnerability.severity, package: .security_vulnerability.package.name, ecosystem: .security_vulnerability.package.ecosystem}'

# Obtenir les détails d'une alerte spécifique
gh api /repos/{owner}/{repo}/dependabot/alerts/{alert_number}

Alertes de secret scanning

# Lister les alertes de secret scanning
gh api /repos/{owner}/{repo}/secret-scanning/alerts --jq '.[] | {number, state, secret_type, created_at}'

États des résultats Checkmarx

Voici les états disponibles dans Checkmarx pour gérer les résultats. Bien définir l'état est important — cela détermine si le résultat réapparaît dans les scans futurs.

Règles critiques pour les changements d'état

• Ne jamais marquer comme Not Exploitable simplement parce que l'application n'est pas encore en production, ou parce qu'elle est actuellement sur un serveur local. Considérez le cycle de vie complet du produit — si le déploiement dans le cloud ou la mise en production la rendrait exploitable, elle EST exploitable.
• La validation ne suffit pas. Checkmarx ne considère pas l'ajout d'étapes de validation comme une solution infaillible car elles laissent les valeurs d'entrée menaçantes en place. Les sanitizers (qui remplacent les valeurs menaçantes) sont préférés. Ne marquez pas un résultat comme Not Exploitable uniquement sur la base d'une étape de validation.
• En cas d'incertitude, utilisez Proposed Not Exploitable et discutez-en avec l'équipe ou #team-eng-appsec.
• Documentez la justification — chaque changement d'état doit inclure une explication claire du pourquoi.

Gestion des résultats SonarCloud

SonarCloud classe les résultats en issues (qualité du code et bugs) et security hotspots (code nécessitant un examen manuel de sécurité).

• Les issues ont des niveaux de sévérité et peuvent être résolues, confirmées ou marquées comme ne sera pas corrigé
• Les security hotspots nécessitent une révision pour déterminer s'ils sont réellement vulnérables
• Les quality gates imposent des seuils — une quality gate échouée bloque la PR
• Les résultats dépendent de la qualité de la branche de base ; jusqu'à ce que le triage initial soit complet, les résultats de PR peuvent être bruyants

Protocole de faux positif

Avant de rejeter un résultat, suivez cet arbre de décision :

1. Tracez le flux de données. L'entrée non fiable peut-elle vraiment atteindre le sink marqué ? Suivez les données depuis le point d'entrée à travers toutes les transformations jusqu'à l'emplacement marqué.
2. Vérifiez l'existence d'une sanitisation. Y a-t-il encodage, échappement ou sanitisation dans le chemin des données ? Rappelez-vous : la validation seule est insuffisante pour les résultats Checkmarx.
3. Considérez le cycle de vie complet. Même si le code n'est pas déployé dans un environnement à risque aujourd'hui, le sera-t-il ? Les dépôts privés peuvent devenir publics. Les déploiements locaux peuvent passer au cloud.
4. Documentez la justification. Chaque rejet doit inclure une explication claire et vérifiable du pourquoi le résultat n'est pas exploitable.

Si une étape est incertaine, marquez comme Proposed Not Exploitable plutôt que Not Exploitable.

Modèles de mise en œuvre des corrections

Modèles de correction courants par type de vulnérabilité :

Notes sur les dépôts privés

• Le téléchargement SARIF vers GitHub Advanced Security échouera pour les dépôts privés (limitation de facturation GitHub). Désactivez en passant upload-sarif: false au workflow réutilisable Checkmarx.
• SonarCloud n'est pas licencié pour les dépôts privés. Supprimez complètement le job quality de scan.yml pour les dépôts privés.
• Quand un dépôt privé devient public, réactivez les deux.