Multi-language scanners and auditors should declare the languages they read

Ouverte
#143 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
68/100
Type d'issue
Refactorisation
Clarté
Clairement spécifiée
Activité
Active
Stack technique
github, python
Domaine
testing, tooling

Piste de recherche

Start by reading the shared modules that define multi_language_scanners and multi_ecosystem_audits, then inspect the profiles that currently filter tools by language name. The issue also points to tests/checks/test_security_scanning.py::test_passes_with_codeql_in_every_layout; use that test to understand the current exclusions. Done means tool language or lockfile support is declared centrally, profiles select compatible tools from that data, and the test derives CodeQL exclusions from it.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

multi_language_scanners(languages) returns CodeQL, GitLab SAST and semgrep for whatever languages a profile passes, and multi_ecosystem_audits returns osv-scanner, trivy, snyk and GitLab Dependency Scanning likewise. But the tools do not read every language: CodeQL reads none of PHP, HCL, Elixir, Erlang, Scala or Dart; osv-scanner and trivy read no sbt build; snyk reads no pubspec.lock. So each profile filters the lists by name (php, terraform, beam, scala, dart all do), and tests/checks/test_security_scanning.py::test_passes_with_codeql_in_every_layout keeps a hand-written set of the languages CodeQL does not read.

Better: the shared modules know what each tool reads (CODEQL_LANGUAGES = {"C", "C++", "Go", "Java", ...}, OSV_LOCKFILES per ecosystem), and a profile asks for multi_language_scanners(languages) and gets only the tools that read one of them. The CodeQL layout test then derives its exclusions from the same table.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt

Langage dominant
Python
Étoiles
4
Forks
1
Merge moyen
10 h 41 min
PR mergées (30 j)
79

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cpp-best-practices/project_validator

Toutes les issues de cpp-best-practices/project_validator

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.