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

Offen
#143 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
68/100
Issue-Typ
Refactoring
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
github, python
Bereich
testing, tooling

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
Python
Sterne
4
Forks
1
Ø Merge
10 Std. 41 Min.
Gemergte PRs (30 T.)
79

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cpp-best-practices/project_validator

Alle Issues in cpp-best-practices/project_validator

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.