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

Aberta
#143 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
68/100
Tipo de issue
Refatoração
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
github, python
Domínio
testing, tooling

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Python
Estrelas
4
Forks
1
Merge médio
10h 41min
PRs com merge (30d)
79

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de cpp-best-practices/project_validator

Todas as issues de cpp-best-practices/project_validator

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.