Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Display vulnerabilities that are ignored in pull requests

Offen
  • Stimmt etwas nicht?
#811 0 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
20/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
github-actions
Bereich
security

Rechercherichtung

Die Anfrage betrifft SARIF-Ergebnisse, die für Pull-Request- und Push-Ereignisse hochgeladen werden, sowie verworfene Findings in der code-scanning UI. Es werden keine Dateien oder Tests genannt; bestimme zunächst, ob diese Verhaltensweisen zu codeql-action oder zum Code-Scanning-Dienst von GitHub gehören. Erledigt wäre eine Auswahlmöglichkeit beim Verwerfen, die Findings für den Default-Branch beibehält, sowie eine Möglichkeit, zuvor verworfene Ergebnisse zu suchen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

enhancement question

I have an action that I'd like to work on both pull requests and push events.
The SARIF is uploaded in both cases. When results of a pull request scan contain problems, it blocks the PR, which is great. The user is presented with a list of options: "Won't Fix", "false positive", "Unit tests". If they click "Won't Fix", the PR can be merged. However, the results never show up in the default branch's scanning results anymore. I think that's intended.

What I'd like is an additional option to the effect of "Will fix in another pull request" or "Won't fix in this pull request" to inform GitHub that it's fine to ignore the results to merge this PR, but that I intend to fix it later so I want the problem to show up on the default branch's scanning results. This is really important: imagine the problem has low criticality, I may want to allow merging the pull request and live with the vulnerability for a few days. If I cannot find the vulnerability on the dashboard, I will for-ever forget to fix it.

In addition: any results that are discarded ("Won't Fix", etc) are very hard to find in the UI. For example, as a security engineer, I may want to review all previous "Won''t Fix" in a branch. I can search for "is:closed" by branch, but I don't seem to be able to find those marked as "Won't Fix", etc. We all make mistakes, so giving the ability search through past choices is useful.

Vorherrschende Sprache
TypeScript
Sterne
1.6k
Forks
493
Ø Merge
1 T. 9 Std.
Gemergte PRs (30 T.)
46

Entwicklungsumgebung

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 github/codeql-action

Alle Issues in github/codeql-action

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

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